Joel,
I had a design that called ZwCreateFile() from my create dispatch and I
changed it due to the recursive create discussion on this list. What I do
now is “borrow” the create irp sent to me by the IO manager. I modify the
irp based on my needs and send it on using IoCallDriver(). After I’ve
finished “borrowing” the irp, I restore any values I’ve modified to the
original values (this works because I always return
STATUS_MORE_PROCESSING_REQUIRED from my completion routine which allows my
create dispatch routine to restore the values). I like this a whole lot
better because it avoids the re-entrancy problems caused by ZwCreateFile().
It’s been working great!
good luck,
Marc
-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Tuesday, December 12, 2000 11:08 AM
To: File Systems Developers
Subject: [ntfsd] railing on reentrancy (wasRe: thread local storage in ker
nel mode)
The more I think about, the more I disklike using ZwCreatFile at all
in this scenario. The issue of reentering the device stack during create
processing was discussed exhaustively a few months back (search for
recursive create in the ntfs archive) and I don’t want to re-open that can
of worms. It seems that my proposed implementation lends itself to one of
those nightmare scenarios where another file system filter, also reentrant
and processing creates in multiple threads (i.e. a heirarchical storage file
system filter that processes some creates in the context of a service thread
before switching back to the original context to forward the irp to the next
driver) is layered below me. The potential for deadlocks or endless loops
is obvious. I can anticipate many potential problems, but surely not them
all. Yes, the plugfests and such will weed out these potential conflicts,
but not everyone in the game can attend these events.
I think we can all agree that reentering the device stack while
processing a dispatch routine is a bad idea, frought with peril; It can be
done, but is hard to get right, and depends on everyone else in the stack
getting it right too. All irps generated within the stack should go
strictly down the stack. If all filter driver implementors obeyed this
simple maxim, stability of the os (when running multiple filters) would
surely be increased. In the interest of the precieved stability of
WindowsNT, why hasn’t someone documented how to roll create irps? I can
find a few implementations, but they are from developers who have obviously
reverse engineered some IO manager routines to this effect. With everyone
using ‘home grown’ techniques of rolling create irps, I’m not sure if we are
being self defeating in our attempts to resolve the reentrancy problems.
Can anyone help US out here?
-Joel
-----Original Message-----
From: Smith, Joel
Sent: Tuesday, December 12, 2000 9:38 AM
To: ‘File Systems Developers’
Subject: RE: [ntfsd] Re: thread local storage in kernel mode
As a means of detecting reentrancy; I am developing a file system
filter. I am building up a prefix table of paths for file’s in the system.
The prefix table entries point to a unique identifier (either an FCB or an
ID, I haven’t decided yet) so that I can quickly and unambiguously resolve
contexts assigned to directory nodes (regardless of filename format, long,
short, etc). In order to do this, I traverse each node of the path in
create, checking the prefix on each iteration to see if it is in the prefix
table. If the prefix is not in the prefix table, I open it, get the unique
id, and add an entry to the prefix table.
I am using ZwCreateFile to open each prefix from the create dispatch
routine. I considered rolling my own irp to avoid the reentrancy or
employing a reparse scheme, but decided the reentrant employment of
ZwCreateFile would be adequate and easiest to implement. It would be nice
to have a counter in TLS to detect the reentrancy for efficiency reasons;
without TLS, I have to maintain a table with proper synchronization. With
TLS, I would not have to acquire any synchronization primitives and would
not have to keep the counter in a table.
Note that none of this is implemented yet, so there may be holes in
the logic.
-Joel
-----Original Message-----
From: Phillip Susi [mailto:xxxxx@iag.net mailto:xxxxx]
Sent: Monday, December 11, 2000 10:39 PM
To: File Systems Developers
Subject: [ntfsd] Re: thread local storage in kernel mode
Just out of curiocity, why would you need this?
At 04:14 AM 12/12/00 +0300, you wrote:
>thread local storage in kernel mode> Are there a kernel mode
>equivelents to the win32 Tls* calls?
>
>Unfortunately, no, and this is very grieveous.
>
> Max
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@iag.net
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
–>Phillip Susi
xxxxx@iag.net
—
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
—
You are currently subscribed to ntfsd as: xxxxx@bionetrix.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)</mailto:xxxxx>