[Openib-windows] Using of fast mutexes in WinIb
Fab Tillier
ftillier at silverstorm.com
Wed Nov 16 23:37:37 PST 2005
Hi Jan,
> From: Jan Bottorff [mailto:jbottorff at xsigo.com]
> Sent: Wednesday, November 16, 2005 7:06 PM
>
> > BTW, have you had a chance to look over the new verb API that
> > would allow calls at IRQL <= DISPATCH_LEVEL? Any comments?
> > I'd really like to get past these IRQL limitations.
>
> Are there any docs on what the current IRQL limitations are?
I just added this to the Access Layer information, and will hopefully get this
information into the header file documentation:
https://openib.org/tiki/tiki-index.php?page=Access+Layer
Note that I did a quick scan of the code and only classified the calls by < vs.
<= DISPATCH_LEVEL, without distinguishing between APC_LEVEL and PASSIVE_LEVEL.
We can update this to be finer grained if required.
> A frequent reason for wanting I/O initiation to work at DISPATCH_LEVEL
> is so you can initiate new I/O in a completion handler. Certainly having
> SOME functions work at DISPATCH_LEVEL is highly desirable. Initiating
> new I/O from a completion callback (like IRP completion) is a common
> hidden bug in Windows drivers. There are many samples of code on the
> Internet that do this, and those chunks of code will on occasion fail
> with a crash. The issue is kernel stack overflow can happen if the
> callback happens before even returning from the call that initiated the
> I/O, and you nest down the stack with many pairs of initiate/callback.
Aren't drivers expected to check in the I/O completion callback if the IRP was
marked pending and if not delay processing until the IoCallDriver call unwinds?
If the IRP was marked pending isn't issuing the next I/O request form the I/O
completion callback is OK?
One of the main reasons I am pushing for things to work at DISPATCH_LEVEL is to
allow kernel clients that get called by a port driver (like StorPort, for
example) to make verb calls from the context of their entry points, rather than
having to find a way to get into a thread context capable of talking to the HCA.
This will push the thread context switch into the HCA if required, rather than
duplicating this functionality in all clients.
- Fab
More information about the ofw
mailing list