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

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

KMDF: determine originating thread of WDFREQUEST

OSR_Community_UserOSR_Community_User Posts: 110,218
Hi all,

I have a driver which has an IO queue (WDFQUEUE) to receive requests
(WDFREQUEST) from usermode processes, handles them, and then calls
WdfRequestCompleteWithInformation() to complete them.

My customer has some, well, weird (I call it bullshit) semantics of I2C
communication that I have to implement: a transaction is divided into
non-atomic accesses where transactions may interleave and steal bus
access from each other. This stealing actually happens in rare
circumstances which I use to call a "race condition", and I want to
protect myself from any blames by implementing an "ownership" to detect
such errors and reject bullshit.

What I envision is to remember the thread that *starts* an I2C
transaction, and to release that owner when it *stops* the transaction -
and to reject any request from a different thread should that happen in
the middle of a transaction.

How is this done?

The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
a usermode thread calling DeviceIoControl(). This usermode thread is the
one that should "own" an ongoing I2C transaction, and thus I have to
remember that thread in driver space. I can imagine that the WDFREQUEST
carries that thread's ID with it - it's just that I don't understand how
to access this information.

Can anybody help me please?

Thank you in advance,
Jörg
--
DI Jörg Faschingbauer
Linux und Open Source - Programmierung, Beratung und Schulung
http://www.faschingbauer.co.at

Comments

  • Don_BurnDon_Burn Posts: 1,623
    Actually, the WDFREQUEST does not carry the thread ID, and the thread in the driver is not guaranteed to be the thread from user mode unless you set up the device with additional calls.

    Overall your approach is not viable, can't you have a START TRANSACTION call that driver returns an ID for, then use the ID in your calls, then have an END TRANSACTION to finish things. I.E. do explicitly what you were trying to do with the thread ID?


    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com



    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@faschingbauer.co.at
    Sent: Thursday, January 25, 2018 7:38 AM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST

    Hi all,

    I have a driver which has an IO queue (WDFQUEUE) to receive requests
    (WDFREQUEST) from usermode processes, handles them, and then calls
    WdfRequestCompleteWithInformation() to complete them.

    My customer has some, well, weird (I call it bullshit) semantics of I2C
    communication that I have to implement: a transaction is divided into
    non-atomic accesses where transactions may interleave and steal bus
    access from each other. This stealing actually happens in rare
    circumstances which I use to call a "race condition", and I want to
    protect myself from any blames by implementing an "ownership" to detect
    such errors and reject bullshit.

    What I envision is to remember the thread that *starts* an I2C
    transaction, and to release that owner when it *stops* the transaction -
    and to reject any request from a different thread should that happen in
    the middle of a transaction.

    How is this done?

    The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
    a usermode thread calling DeviceIoControl(). This usermode thread is the
    one that should "own" an ongoing I2C transaction, and thus I have to
    remember that thread in driver space. I can imagine that the WDFREQUEST
    carries that thread's ID with it - it's just that I don't understand how
    to access this information.

    Can anybody help me please?

    Thank you in advance,
    Jörg
    --
    DI Jörg Faschingbauer
    Linux und Open Source - Programmierung, Beratung und Schulung
    http://www.faschingbauer.co.at

    ---
    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>;
  • Doron_HolanDoron_Holan Posts: 10,360
    One way to make this work is to have your transaction semantics on the wdffileobject level. The app would open a handle per thread (or transaction) instead of one overlapped handle shared across all threads.

    Bent from my phone
    ________________________________
    From: xxxxx@lists.osr.com on behalf of xxxxx@windrvr.com
    Sent: Thursday, January 25, 2018 4:51:18 AM
    To: Windows System Software Devs Interest List
    Subject: RE: [ntdev] KMDF: determine originating thread of WDFREQUEST

    Actually, the WDFREQUEST does not carry the thread ID, and the thread in the driver is not guaranteed to be the thread from user mode unless you set up the device with additional calls.

    Overall your approach is not viable, can't you have a START TRANSACTION call that driver returns an ID for, then use the ID in your calls, then have an END TRANSACTION to finish things. I.E. do explicitly what you were trying to do with the thread ID?


    Don Burn
    Windows Driver Consulting
    Website: https://na01.safelinks.protection.outlook.com/?url=http://www.windrvr.com&amp;data=02|01|[email protected]|f4e61e7044a5460bb7f008d563f26695|ee3303d7fb734b0c8589bcd847f1c277|1|0|636524815110984702&amp;sdata=Hy3KaLYcZnezBvMUOfZfMiacErp4JgVYC7xeZG1aJPs=&amp;reserved=0



    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@faschingbauer.co.at
    Sent: Thursday, January 25, 2018 7:38 AM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST

    Hi all,

    I have a driver which has an IO queue (WDFQUEUE) to receive requests
    (WDFREQUEST) from usermode processes, handles them, and then calls
    WdfRequestCompleteWithInformation() to complete them.

    My customer has some, well, weird (I call it bullshit) semantics of I2C
    communication that I have to implement: a transaction is divided into
    non-atomic accesses where transactions may interleave and steal bus
    access from each other. This stealing actually happens in rare
    circumstances which I use to call a "race condition", and I want to
    protect myself from any blames by implementing an "ownership" to detect
    such errors and reject bullshit.

    What I envision is to remember the thread that *starts* an I2C
    transaction, and to release that owner when it *stops* the transaction -
    and to reject any request from a different thread should that happen in
    the middle of a transaction.

    How is this done?

    The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
    a usermode thread calling DeviceIoControl(). This usermode thread is the
    one that should "own" an ongoing I2C transaction, and thus I have to
    remember that thread in driver space. I can imagine that the WDFREQUEST
    carries that thread's ID with it - it's just that I don't understand how
    to access this information.

    Can anybody help me please?

    Thank you in advance,
    J?rg
    --
    DI J?rg Faschingbauer
    Linux und Open Source - Programmierung, Beratung und Schulung
    https://na01.safelinks.protection.outlook.com/?url=http://www.faschingbauer.co.at&amp;data=02|01|[email protected]|f4e61e7044a5460bb7f008d563f26695|ee3303d7fb734b0c8589bcd847f1c277|1|0|636524815110984702&amp;sdata=iVygl6zPH3PJEPhQPVpczMYhfBqU3hTXfeLoWCmMZ4A=&amp;reserved=0

    ---
    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


    ---
    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
  • <quote>
    the WDFREQUEST does not carry the thread ID
    </quote>

    Sure it does. It's in the IRP.

    But, regardless, it is absolutely true that:

    <quote>
    the thread in the driver is not guaranteed to be the thread from user mode
    </quote>

    So...

    <quote>
    One way to make this work is to have your transaction semantics on the
    wdffileobject level.
    </quote>

    This is the best advice. It's easy to implement, and it's handy. The WDF_FILE_OBJECT handle is always available. You can even stuff a context on it., in which you can store per-open-instance stuff.

    Will that work for you?

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • What I found when reading the docs was ...

    WdfRequestGetRequestorProcessId(). Although I'd rather like the sending
    thread's ID, that looks like a hint that the WDFREQUEST somehow exposes
    originator information.

    IRP.Tail.Overlay.Thread. The docs
    (https://msdn.microsoft.com/en-us/library/windows/hardware/ff550694(v=vs.85).aspx)
    say that "For requests that originate in user-mode, the I/O manager
    always sets this field to point to the TCB of the thread that issued the
    request."

    Would IRP.Tail.Overlay.Thread work?

    Thanks,
    Joerg

    On 01/25/2018 01:51 PM, xxxxx@windrvr.com wrote:
    > Actually, the WDFREQUEST does not carry the thread ID, and the thread in the driver is not guaranteed to be the thread from user mode unless you set up the device with additional calls.
    >
    > Overall your approach is not viable, can't you have a START TRANSACTION call that driver returns an ID for, then use the ID in your calls, then have an END TRANSACTION to finish things. I.E. do explicitly what you were trying to do with the thread ID?
    >
    >
    > Don Burn
    > Windows Driver Consulting
    > Website: http://www.windrvr.com
    >
    >
    >
    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@faschingbauer.co.at
    > Sent: Thursday, January 25, 2018 7:38 AM
    > To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    > Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST
    >
    > Hi all,
    >
    > I have a driver which has an IO queue (WDFQUEUE) to receive requests
    > (WDFREQUEST) from usermode processes, handles them, and then calls
    > WdfRequestCompleteWithInformation() to complete them.
    >
    > My customer has some, well, weird (I call it bullshit) semantics of I2C
    > communication that I have to implement: a transaction is divided into
    > non-atomic accesses where transactions may interleave and steal bus
    > access from each other. This stealing actually happens in rare
    > circumstances which I use to call a "race condition", and I want to
    > protect myself from any blames by implementing an "ownership" to detect
    > such errors and reject bullshit.
    >
    > What I envision is to remember the thread that *starts* an I2C
    > transaction, and to release that owner when it *stops* the transaction -
    > and to reject any request from a different thread should that happen in
    > the middle of a transaction.
    >
    > How is this done?
    >
    > The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
    > a usermode thread calling DeviceIoControl(). This usermode thread is the
    > one that should "own" an ongoing I2C transaction, and thus I have to
    > remember that thread in driver space. I can imagine that the WDFREQUEST
    > carries that thread's ID with it - it's just that I don't understand how
    > to access this information.
    >
    > Can anybody help me please?
    >
    > Thank you in advance,
    > Jörg
    >


    --
    DI Jörg Faschingbauer
    Linux und Open Source - Programmierung, Beratung und Schulung
  • Mark_RoddyMark_Roddy Posts: 4,269
    Yes sure, if requester mode is usermode then tail.thread is valid, plus you
    don't have to convince the customer to change their app.

    Mark Roddy

    On Tue, Feb 6, 2018 at 1:49 AM, xxxxx@faschingbauer.co.at
    wrote:

    > What I found when reading the docs was ...
    >
    > WdfRequestGetRequestorProcessId(). Although I'd rather like the sending
    > thread's ID, that looks like a hint that the WDFREQUEST somehow exposes
    > originator information.
    >
    > IRP.Tail.Overlay.Thread. The docs (https://msdn.microsoft.com/en
    > -us/library/windows/hardware/ff550694(v=vs.85).aspx) say that "For
    > requests that originate in user-mode, the I/O manager always sets this
    > field to point to the TCB of the thread that issued the request."
    >
    > Would IRP.Tail.Overlay.Thread work?
    >
    > Thanks,
    > Joerg
    >
    >
    > On 01/25/2018 01:51 PM, xxxxx@windrvr.com wrote:
    >
    >> Actually, the WDFREQUEST does not carry the thread ID, and the thread in
    >> the driver is not guaranteed to be the thread from user mode unless you set
    >> up the device with additional calls.
    >>
    >> Overall your approach is not viable, can't you have a START TRANSACTION
    >> call that driver returns an ID for, then use the ID in your calls, then
    >> have an END TRANSACTION to finish things. I.E. do explicitly what you
    >> were trying to do with the thread ID?
    >>
    >>
    >> Don Burn
    >> Windows Driver Consulting
    >> Website: http://www.windrvr.com
    >>
    >>
    >>
    >> -----Original Message-----
    >> From: xxxxx@lists.osr.com [mailto:bounce-645739-122747@l
    >> ists.osr.com] On Behalf Of xxxxx@faschingbauer.co.at
    >> Sent: Thursday, January 25, 2018 7:38 AM
    >> To: Windows System Software Devs Interest List
    >> Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST
    >>
    >> Hi all,
    >>
    >> I have a driver which has an IO queue (WDFQUEUE) to receive requests
    >> (WDFREQUEST) from usermode processes, handles them, and then calls
    >> WdfRequestCompleteWithInformation() to complete them.
    >>
    >> My customer has some, well, weird (I call it bullshit) semantics of I2C
    >> communication that I have to implement: a transaction is divided into
    >> non-atomic accesses where transactions may interleave and steal bus
    >> access from each other. This stealing actually happens in rare
    >> circumstances which I use to call a "race condition", and I want to
    >> protect myself from any blames by implementing an "ownership" to detect
    >> such errors and reject bullshit.
    >>
    >> What I envision is to remember the thread that *starts* an I2C
    >> transaction, and to release that owner when it *stops* the transaction -
    >> and to reject any request from a different thread should that happen in
    >> the middle of a transaction.
    >>
    >> How is this done?
    >>
    >> The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
    >> a usermode thread calling DeviceIoControl(). This usermode thread is the
    >> one that should "own" an ongoing I2C transaction, and thus I have to
    >> remember that thread in driver space. I can imagine that the WDFREQUEST
    >> carries that thread's ID with it - it's just that I don't understand how
    >> to access this information.
    >>
    >> Can anybody help me please?
    >>
    >> Thank you in advance,
    >> Jörg
    >>
    >>
    >
    > --
    > DI Jörg Faschingbauer
    > Linux und Open Source - Programmierung, Beratung und Schulung
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: lists.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>;
    >
  • Hence my comment two weeks ago:

    <quote>
    Sure it does. It's in the IRP.
    </quote>

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

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!