Some FSDs - NT4’s FASTFAT, for instance - have no
AcquireForCcFlush routine.
In this case, FsRtlAcquireFileForCcFlush does default handling -
just grabs the resource lock.
The problem is that in this case FsRtlAcquireFileForCcFlush does
not update the TopLevelIrp field in the thread (obvious from
disassembly of this short function), and thus the filter receives an
IRP with FCB locks held and with TopLevelIrp == NULL.
Am I wrong that, if the FCB locks are acquired while sending an
IRP, then TopLevelIrp MUST be non-NULL? If I’m right in this, then
FsRtlAcquireFileForCcFlush has a bug, though it can be masked off by
FSDs having explicit AcquireForCcFlush routine.
Max
Maxim -
I agree it would be nice if the filesystems actually set TopLevelIrp()
everytime a resource was held by the file-system before a new i/o
courses down through the stack. However in practice this is not true -
filesystems, Mm & Cc indicate themselves as top-level components ONLY
when it’s *necessary* for *them* to indicate to the file system.
In this case this is followed by a flush - which occurs via a series of
paging i/o writes.
In general if TopLevelIrp is non-NULL *OR* it’s paging i/o it would mean
that some sort of lock was acquired from the file-system already. You
should check for both.
Ravi
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, July 09, 2002 1:59 PM
To: File Systems Developers
Subject: [ntfsd] FsRtlAcquireFileForCcFlush - a bug?
Some FSDs - NT4’s FASTFAT, for instance - have no AcquireForCcFlush
routine.
In this case, FsRtlAcquireFileForCcFlush does default handling -
just grabs the resource lock.
The problem is that in this case FsRtlAcquireFileForCcFlush does not
update the TopLevelIrp field in the thread (obvious from disassembly of
this short function), and thus the filter receives an IRP with FCB
locks held and with TopLevelIrp == NULL.
Am I wrong that, if the FCB locks are acquired while sending an IRP,
then TopLevelIrp MUST be non-NULL? If I’m right in this, then
FsRtlAcquireFileForCcFlush has a bug, though it can be masked off by
FSDs having explicit AcquireForCcFlush routine.
Max
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%
>In general if TopLevelIrp is non-NULL *OR* it’s paging i/o it would
mean
that some sort of lock was acquired from the file-system already.
Can I simply rely on the fact that ALL paging IRPs are sent with FCB
locks held?
What about MPW thread and writes from it?
Max
the MPW thread will use FsRtlAcquireForModWrite. This routine is also preety
simple and obivious and makes
the folowing assumptions (I looked into it back last year when a guy on
this list had some problems with FsRtlAcquireForModWrite fast IO entry.):
if it does not find a fast io entry for FastIoAcquireForModWrite it will get
Fcb = FileObject->FsContext;
if there is no main resource in fcb it will acquire ntohing, returning true
if there is main resource and Fcb->Flags has flag
FSRTL_FLAG_ACQUIRE_MAIN_RSRC_EX
or if its an extending write acquire the resource exclusive
else if the Fcb->Flags has set FSRTL_FLAG_ACQUIRE_MAIN_RSRC_SH acquire the
main resource exclusive
else acquire the paging resource
if there is no paging resource, acquire main one shared
Ciao, Dan
----- Original Message -----
From: “Maxim S. Shatskih”
To: “File Systems Developers”
Sent: Wednesday, July 10, 2002 3:00 PM
Subject: [ntfsd] RE: FsRtlAcquireFileForCcFlush - a bug?
> >In general if TopLevelIrp is non-NULL OR it’s paging i/o it would
> mean
> >that some sort of lock was acquired from the file-system already.
>
> Can I simply rely on the fact that ALL paging IRPs are sent with FCB
> locks held?
> What about MPW thread and writes from it?
>
> Max
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
I just understood I asked a stupid thing. MPW sets TopLevelIrp to
MOD_WRITE, a small positive value different from zero and from any
sane IRP pointer.
So, I can catch MPW by nonzero TopLevelIrp.
Max
----- Original Message -----
From: “Dan Partelly”
To: “File Systems Developers”
Sent: Wednesday, July 10, 2002 4:20 PM
Subject: [ntfsd] RE: FsRtlAcquireFileForCcFlush - a bug?
> the MPW thread will use FsRtlAcquireForModWrite. This routine is
also preety
> simple and obivious and makes
> the folowing assumptions (I looked into it back last year when a
guy on
> this list had some problems with FsRtlAcquireForModWrite fast IO
entry.):
>
> if it does not find a fast io entry for FastIoAcquireForModWrite it
will get
> Fcb = FileObject->FsContext;
>
> if there is no main resource in fcb it will acquire ntohing,
returning true
>
> if there is main resource and Fcb->Flags has flag
> FSRTL_FLAG_ACQUIRE_MAIN_RSRC_EX
> or if its an extending write acquire the resource exclusive
>
> else if the Fcb->Flags has set FSRTL_FLAG_ACQUIRE_MAIN_RSRC_SH
acquire the
> main resource exclusive
> else acquire the paging resource
> if there is no paging resource, acquire main one shared
>
> Ciao, Dan
>
> ----- Original Message -----
> From: “Maxim S. Shatskih”
> To: “File Systems Developers”
> Sent: Wednesday, July 10, 2002 3:00 PM
> Subject: [ntfsd] RE: FsRtlAcquireFileForCcFlush - a bug?
>
>
> > >In general if TopLevelIrp is non-NULL OR it’s paging i/o it
would
> > mean
> > >that some sort of lock was acquired from the file-system already.
> >
> > Can I simply rely on the fact that ALL paging IRPs are sent with
FCB
> > locks held?
> > What about MPW thread and writes from it?
> >
> > Max
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>