Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 10  
03 May 18 06:00
sudhakar
xxxxxx@gmail.com
Join Date: 03 May 2018
Posts To This List: 5
thread local storage in kernel

I am looking for this important feature in kernel but all I got was related to user space in my search. Just wanted to confirm the same. Thanks.
  Message 2 of 10  
03 May 18 08:45
Jamey Kirby
xxxxxx@gmail.com
Join Date: 31 Dec 2014
Posts To This List: 276
thread local storage in kernel

Confirmed On Thu, May 3, 2018 at 6:01 AM xxxxx@gmail.com <xxxxx@lists.osr.com> wrote: > I am looking for this important feature in kernel but all I got was > related to user space in my search. Just wanted to confirm the same. > Thanks. > > --- > NTDEV is sponsored by OSR > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > <...excess quoted lines suppressed...> -- Jamey Kirby Disrupting the establishment since 1964 *This is a personal email account and as such, emails are not subject to archiving. Nothing else really matters.* --
  Message 3 of 10  
03 May 18 15:53
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4472
thread local storage in kernel

>Confirmed Post of the year, Jamey..... Anton Bassov
  Message 4 of 10  
04 May 18 02:15
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11925
thread local storage in kernel

On May 3, 2018, at 3:01 AM, xxxxx@gmail.com <xxxxx@lists.osr.com> wrote: > > I am looking for this important feature in kernel but all I got was related to user space in my search. Just wanted to confirm the same. There is virtually no need. Most drivers spend all of their time in "borrowed" threads. ??? Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 5 of 10  
04 May 18 02:37
sudhakar
xxxxxx@gmail.com
Join Date: 03 May 2018
Posts To This List: 5
thread local storage in kernel

I agree most of the time it is no need. But I have a peculiar problem where I had to debug a complex issue and the debug framework required this and not the production code.
  Message 6 of 10  
05 May 18 17:41
M M
xxxxxx@hotmail.com
Join Date: 21 Oct 2010
Posts To This List: 764
thread local storage in kernel

It is not a question of whether it is required but of practicability. Many (most?) KM routines can execute in arbitrary _thread_ context. Where thread here is defined as the TEB or context in which TLS could be maintained. This is different from the meaning of the word thread in other senses, but in terms of windows KM programming the effective defintion Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 ________________________________ From: xxxxx@lists.osr.com <xxxxx@lists.osr.com> on behalf of xxxxx@gmail.com <xxxxx@lists.osr.com> Sent: Friday, May 4, 2018 2:38:10 AM To: Windows System Software Devs Interest List Subject: RE:[ntdev] thread local storage in kernel I agree most of the time it is no need. But I have a peculiar problem where I had to debug a complex issue and the debug framework required this and not the production code. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --
  Message 7 of 10  
06 May 18 12:43
Pavel A
xxxxxx@fastmail.fm
Join Date: 21 Jul 2008
Posts To This List: 2420
thread local storage in kernel

> But I have a peculiar problem where I > had to debug a complex issue OK, there are known situations when you need a per-thread context. For example, to detect recursive calls. But in Windows kernel, there's nothing like TLS in usermode. At least, nothing documented and safe to use. This is yet another example how the kernel mode is a special kind of execution environment. -- pa
  Message 8 of 10  
08 May 18 20:11
M M
xxxxxx@hotmail.com
Join Date: 21 Oct 2010
Posts To This List: 764
thread local storage in kernel

Recursive calls in KM will either be 1. benign and part of the normal course of events; or 2. result in a stall or hang of a particular driver / stack ? in which case you can acquire a crash dump; or 3. result in a stall or hand of the whole system ? in which case it us also possible to acquire a crash dump acquiring these dumps may be harder that it sounds and it may be necessary to acquire many of them before one leads you to the ?smoking gun? . I may be wrong, but I can?t imagine what kind of debugging aid a per thread context could provide in KM Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 ________________________________ From: xxxxx@lists.osr.com <xxxxx@lists.osr.com> on behalf of xxxxx@fastmail.fm <xxxxx@lists.osr.com> Sent: Sunday, May 6, 2018 12:44:38 PM To: Windows System Software Devs Interest List Subject: RE:[ntdev] thread local storage in kernel > But I have a peculiar problem where I > had to debug a complex issue OK, there are known situations when you need a per-thread context. For example, to detect recursive calls. But in Windows kernel, there's nothing like TLS in usermode. At least, nothing documented and safe to use. This is yet another example how the kernel mode is a special kind of execution environment. -- pa --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --
  Message 9 of 10  
08 May 18 20:43
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4472
thread local storage in kernel

>But I have a peculiar problem where I had to debug a complex issue and the debug > framework required this and not the production code. Well, who holds you back from implementing your own one if you are so desperate to have TLS in the kernel? You've got thread creation and termination callbacks that provide you with a target thread's ID. This is the only thing that you need in order to implement your own version of TLS in the kernel. Create your own table that is indexed by TID, add support routines that manage table entries, plus add a routine that takes TID as a parameter and returns you pointer to thread-specific context, and that's it. Certainly, it may sound a bit awkward, but, in actuality, it can be done without too much work. To make it even more interesting, the whole thing may be made reusable and consistent with TLS interface in the userland, at least from C caller's perspective... Anton Bassov
  Message 10 of 10  
10 May 18 15:27
sudhakar
xxxxxx@gmail.com
Join Date: 03 May 2018
Posts To This List: 5
thread local storage in kernel

Thanks for all the inputs. Yes this is what I did finally though not at creation and termination callbacks. On Wed, May 9, 2018 at 6:12 AM, xxxxx@hotmail.com <xxxxx@lists.osr.com> wrote: >>But I have a peculiar problem where I had to debug a complex issue and the debug >> framework required this and not the production code. > > Well, who holds you back from implementing your own one if you are so desperate to have TLS in the kernel? > > > You've got thread creation and termination callbacks that provide you with a target thread's ID. This is the only thing that you need in order to implement your own version of TLS in the kernel. Create your own table that is indexed by TID, add support routines that manage table entries, plus add a routine that takes TID as a parameter and returns you pointer to thread-specific context, and that's it. > > Certainly, it may sound a bit awkward, but, in actuality, it can be done without too much work. To make it even more interesting, the whole thing may be made reusable and consistent with TLS interface in the userland, at least from C caller's perspective... > <...excess quoted lines suppressed...>
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 15:33.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license