Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

thread local storage in kernel

sudhakarsudhakar Posts: 9
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.

Comments

  • Jamey_KirbyJamey_Kirby Posts: 377
    Confirmed

    On Thu, May 3, 2018 at 6:01 AM xxxxx@gmail.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>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >


    --
    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.*
  • anton_bassovanton_bassov Posts: 4,800
    >Confirmed


    Post of the year, Jamey.....


    Anton Bassov
  • Tim_RobertsTim_Roberts Posts: 12,623
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • sudhakarsudhakar Posts: 9
    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.
  • MBondMBond Posts: 843
    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 for Windows 10



    ________________________________
    From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.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:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
  • Pavel_APavel_A Posts: 2,643
    > 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
  • MBondMBond Posts: 843
    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 for Windows 10



    ________________________________
    From: xxxxx@lists.osr.com on behalf of xxxxx@fastmail.fm
    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:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
  • anton_bassovanton_bassov Posts: 4,800
    >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
  • sudhakarsudhakar Posts: 9
    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...
    >
    >
    > Anton Bassov
    >
    > ---
    > 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>;
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!