TopLevelIrp is a field in the ETHREAD structure - there is one per thread of
execution. And, while initially used for storing the address of an
in-progress file system IRP, several clever file systems now use it as a
general purpose storage area.
On first entry to an FSD, the TopLevelIrp is NULL. Correspondingly, if it
is not, the FSD may behave differently (knowing that it is being
“reentered”.) The FSD can then set this field. Subsequent operations into
the FSD will allow the FSD to detect the recursion (because the TopLevelIrp
field is NOT NULL.)
Some parts of the OS (cache manager and memory manager) set this field prior
to calling the FSD as well but they use values that are not valid kernel
addresses (presently, they only use very small values but be aware that the
OS guys *own* all values that aren’t valid kernel addresses and can start
using them at any point in time!)
In either case, the original intent was to perform locking properly. First
time in - no locks are held, so the FSD should acquire the needed locks.
Second time in - locks ARE held, so the FSD need not acquire those locks
again. The cache manager and memory manager call the FSD, acquire the
locks, and then call into the FSD, which is why setting the top level irp
field to a constant value works as well - the locks are held.
Clever programmers have expanded the use of this field (pointing to data
structures, not the IRP itself) since the actual meaning of this field
(assuming it is a valid kernel address pointer) is up to the FSD to
interpret.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Mike Malgin [mailto:xxxxx@yahoo.com]
Sent: Saturday, January 12, 2002 2:08 PM
To: File Systems Developers
Subject: [ntfsd] ETHREAD - TopLevelIrp
Hi,
Thanks for the attention.
I’m having a big problem with the concept of
TopLevelIrp.
I understand its basic idea that it’s used for
preserving the original
kernel component request initiator, though, I do not
understand how it can
also be used for protecting from a recursive call that
might
incur a dead lock.
I also read in Nagar book about it and he gave some
example about
a user that request to extend a file length, then the
FSD in the write
dispatch routine call CcZeroData() to zero the extend
part he described that
apparently behind the scene ccZeroData invoke
CcFlush… that end up in the FSD
(i.e. write dispatch) and hence results in a recursive
call to the write dispatch.
Furthermore as he wrote that by doing this the FSD
won’t invoke the CcZeroData again
because it can “see” from the TopLevelIRP that it’s a
recursive call, what going on ?!
is this possible ?!
How the FSD can know if it’s in a recursion from the
TopLevelIrp, after all the TopLevelIRP
members just contain the initiator component “ID” ?
The second confusing thing is that when the
TopLevelIRP is NOT less
from the FSRTL_TOP_LEVEL_IRP flag, then the FSD assume
that it doesn’t in a
recursive situation, so this means that when the FSD
is a the initiator it
can NOT make recursive call ?!
I will appreciate any explanation on this particular
confusing subject.
Thanks !!
Mike.
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com