Hello,
I’ve come across such comment in Rajeev Nagar’s sample FSD close() routine:
Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
execution to be deferred to a worker thread context)
My question is:
is it really possible for close() to be invoked at higher than PASSIVE_LEVEL
IRQL?
My perception was that it is usually invoked in the caller thread context,
or
if FSD implements some delayed close queue, then in the system worker thread
context.
Am I wrong here?
Thank you very much,
Seva Tonkonoh
ObDereferenceObject is allowed to be called on DISPATCH_LEVEL, and can result
in CLOSE being sent.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Seva Tonkonoh”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, September 27, 2003 12:11 PM
Subject: [ntfsd] IRQL in close()
> Hello,
>
> I’ve come across such comment in Rajeev Nagar’s sample FSD close() routine:
>
> Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
> execution to be deferred to a worker thread context)
>
> My question is:
> is it really possible for close() to be invoked at higher than PASSIVE_LEVEL
> IRQL?
>
> My perception was that it is usually invoked in the caller thread context,
> or
> if FSD implements some delayed close queue, then in the system worker thread
> context.
> Am I wrong here?
>
> Thank you very much,
> Seva Tonkonoh
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks, I understand now.
Although, it doesn’t seem that some filesystems handle this case.
For example, FasfFat.
I’ve looked through FatFsdClose() and FatCommonClose() and they don’t seem
to have
any checking for current IRQL.
Is it something that should be done, but usually is not?
Thanks,
Seva
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Saturday, September 27, 2003 6:39 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: IRQL in close()
ObDereferenceObject is allowed to be called on DISPATCH_LEVEL, and can
result
in CLOSE being sent.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Seva Tonkonoh”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, September 27, 2003 12:11 PM
Subject: [ntfsd] IRQL in close()
> Hello,
>
> I’ve come across such comment in Rajeev Nagar’s sample FSD close()
routine:
>
> Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
> execution to be deferred to a worker thread context)
>
> My question is:
> is it really possible for close() to be invoked at higher than
PASSIVE_LEVEL
> IRQL?
>
> My perception was that it is usually invoked in the caller thread context,
> or
> if FSD implements some delayed close queue, then in the system worker
thread
> context.
> Am I wrong here?
>
> Thank you very much,
> Seva Tonkonoh
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@pacbell.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
FAT checks this indirectly by checking TopLevelIRP and type of the file
being closed.
If IRP_MJ_CLOSE is a top level IRP and the FILE_OBJECT is associated with a
handle (not a file object created internally), then it is safe to proceed
synchronously, otherwise FAT remembers context and queue a work item that
does actual job.
No matter if the actual work is done synchronously or asynchronously
IRP_MJ_CLOSE is always completed synchronously.
Alexei.
“Seva Tonkonoh” wrote in message news:xxxxx@ntfsd…
>
>
> Thanks, I understand now.
> Although, it doesn’t seem that some filesystems handle this case.
> For example, FasfFat.
> I’ve looked through FatFsdClose() and FatCommonClose() and they don’t seem
> to have
> any checking for current IRQL.
>
> Is it something that should be done, but usually is not?
>
> Thanks,
> Seva
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Saturday, September 27, 2003 6:39 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Re: IRQL in close()
>
>
> ObDereferenceObject is allowed to be called on DISPATCH_LEVEL, and can
> result
> in CLOSE being sent.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Seva Tonkonoh”
> To: “Windows File Systems Devs Interest List”
> Sent: Saturday, September 27, 2003 12:11 PM
> Subject: [ntfsd] IRQL in close()
>
>
> > Hello,
> >
> > I’ve come across such comment in Rajeev Nagar’s sample FSD close()
> routine:
> >
> > Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
> > execution to be deferred to a worker thread context)
> >
> > My question is:
> > is it really possible for close() to be invoked at higher than
> PASSIVE_LEVEL
> > IRQL?
> >
> > My perception was that it is usually invoked in the caller thread
context,
> > or
> > if FSD implements some delayed close queue, then in the system worker
> thread
> > context.
> > Am I wrong here?
> >
> > Thank you very much,
> > Seva Tonkonoh
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pacbell.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
I don’t think anybody really calls ObDereferenceObject on DISPATCH_LEVEL.
Maybe this is a documentation bug.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Seva Tonkonoh”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, September 27, 2003 11:31 PM
Subject: [ntfsd] Re: IRQL in close()
>
> Thanks, I understand now.
> Although, it doesn’t seem that some filesystems handle this case.
> For example, FasfFat.
> I’ve looked through FatFsdClose() and FatCommonClose() and they don’t seem
> to have
> any checking for current IRQL.
>
> Is it something that should be done, but usually is not?
>
> Thanks,
> Seva
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Saturday, September 27, 2003 6:39 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Re: IRQL in close()
>
>
> ObDereferenceObject is allowed to be called on DISPATCH_LEVEL, and can
> result
> in CLOSE being sent.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Seva Tonkonoh”
> To: “Windows File Systems Devs Interest List”
> Sent: Saturday, September 27, 2003 12:11 PM
> Subject: [ntfsd] IRQL in close()
>
>
> > Hello,
> >
> > I’ve come across such comment in Rajeev Nagar’s sample FSD close()
> routine:
> >
> > Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
> > execution to be deferred to a worker thread context)
> >
> > My question is:
> > is it really possible for close() to be invoked at higher than
> PASSIVE_LEVEL
> > IRQL?
> >
> > My perception was that it is usually invoked in the caller thread context,
> > or
> > if FSD implements some delayed close queue, then in the system worker
> thread
> > context.
> > Am I wrong here?
> >
> > Thank you very much,
> > Seva Tonkonoh
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pacbell.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks for explanation.
It is almost clear now 
One more disturbing me detail:
FatFsdClose() is decalred as pageable code, but Maxim said,
it can be invoked at DISPATCH_LEVEL.
Any explanation for this?
Thanks very much,
seva
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Alexei Jelvis
Sent: Saturday, September 27, 2003 1:30 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: IRQL in close()
FAT checks this indirectly by checking TopLevelIRP and type of the file
being closed.
If IRP_MJ_CLOSE is a top level IRP and the FILE_OBJECT is associated with a
handle (not a file object created internally), then it is safe to proceed
synchronously, otherwise FAT remembers context and queue a work item that
does actual job.
No matter if the actual work is done synchronously or asynchronously
IRP_MJ_CLOSE is always completed synchronously.
Alexei.
“Seva Tonkonoh” wrote in message news:xxxxx@ntfsd…
>
>
> Thanks, I understand now.
> Although, it doesn’t seem that some filesystems handle this case.
> For example, FasfFat.
> I’ve looked through FatFsdClose() and FatCommonClose() and they don’t seem
> to have
> any checking for current IRQL.
>
> Is it something that should be done, but usually is not?
>
> Thanks,
> Seva
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Saturday, September 27, 2003 6:39 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Re: IRQL in close()
>
>
> ObDereferenceObject is allowed to be called on DISPATCH_LEVEL, and can
> result
> in CLOSE being sent.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Seva Tonkonoh”
> To: “Windows File Systems Devs Interest List”
> Sent: Saturday, September 27, 2003 12:11 PM
> Subject: [ntfsd] IRQL in close()
>
>
> > Hello,
> >
> > I’ve come across such comment in Rajeev Nagar’s sample FSD close()
> routine:
> >
> > Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
> > execution to be deferred to a worker thread context)
> >
> > My question is:
> > is it really possible for close() to be invoked at higher than
> PASSIVE_LEVEL
> > IRQL?
> >
> > My perception was that it is usually invoked in the caller thread
context,
> > or
> > if FSD implements some delayed close queue, then in the system worker
> thread
> > context.
> > Am I wrong here?
> >
> > Thank you very much,
> > Seva Tonkonoh
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pacbell.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
—
You are currently subscribed to ntfsd as: xxxxx@pacbell.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
OK, understandable.
I assume it should be safe to do the same thing as FAT does then.
Where there is a difference between documentation and implementation,
just follow the implementation.
Thanks a lot,
seva
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Saturday, September 27, 2003 2:08 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: IRQL in close()
I don’t think anybody really calls ObDereferenceObject on
DISPATCH_LEVEL.
Maybe this is a documentation bug.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Seva Tonkonoh”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, September 27, 2003 11:31 PM
Subject: [ntfsd] Re: IRQL in close()
>
> Thanks, I understand now.
> Although, it doesn’t seem that some filesystems handle this case.
> For example, FasfFat.
> I’ve looked through FatFsdClose() and FatCommonClose() and they don’t seem
> to have
> any checking for current IRQL.
>
> Is it something that should be done, but usually is not?
>
> Thanks,
> Seva
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Saturday, September 27, 2003 6:39 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Re: IRQL in close()
>
>
> ObDereferenceObject is allowed to be called on DISPATCH_LEVEL, and can
> result
> in CLOSE being sent.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Seva Tonkonoh”
> To: “Windows File Systems Devs Interest List”
> Sent: Saturday, September 27, 2003 12:11 PM
> Subject: [ntfsd] IRQL in close()
>
>
> > Hello,
> >
> > I’ve come across such comment in Rajeev Nagar’s sample FSD close()
> routine:
> >
> > Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
> > execution to be deferred to a worker thread context)
> >
> > My question is:
> > is it really possible for close() to be invoked at higher than
> PASSIVE_LEVEL
> > IRQL?
> >
> > My perception was that it is usually invoked in the caller thread
context,
> > or
> > if FSD implements some delayed close queue, then in the system worker
> thread
> > context.
> > Am I wrong here?
> >
> > Thank you very much,
> > Seva Tonkonoh
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pacbell.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@pacbell.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
Disassembling a few lines into ObDereferenceObject shows that if IRQL >
PASSIVE_LEVEL, a function called ObpDeferObjectDeletion is called, which
apparently schedules the meaty stuff for a work item.
Maxim S. Shatskih wrote:
I don’t think anybody really calls ObDereferenceObject on DISPATCH_LEVEL.
Maybe this is a documentation bug.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Seva Tonkonoh”
> To: “Windows File Systems Devs Interest List”
> Sent: Saturday, September 27, 2003 11:31 PM
> Subject: [ntfsd] Re: IRQL in close()
>
>
>
>>Thanks, I understand now.
>>Although, it doesn’t seem that some filesystems handle this case.
>>For example, FasfFat.
>>I’ve looked through FatFsdClose() and FatCommonClose() and they don’t seem
>>to have
>>any checking for current IRQL.
>>
>>Is it something that should be done, but usually is not?
>>
>>Thanks,
>>Seva
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
>>Sent: Saturday, September 27, 2003 6:39 AM
>>To: Windows File Systems Devs Interest List
>>Subject: [ntfsd] Re: IRQL in close()
>>
>>
>>ObDereferenceObject is allowed to be called on DISPATCH_LEVEL, and can
>>result
>>in CLOSE being sent.
>>
>>Maxim Shatskih, Windows DDK MVP
>>StorageCraft Corporation
>>xxxxx@storagecraft.com
>>http://www.storagecraft.com
>>
>>
>>----- Original Message -----
>>From: “Seva Tonkonoh”
>>To: “Windows File Systems Devs Interest List”
>>Sent: Saturday, September 27, 2003 12:11 PM
>>Subject: [ntfsd] IRQL in close()
>>
>>
>>
>>>Hello,
>>>
>>>I’ve come across such comment in Rajeev Nagar’s sample FSD close()
>>
>>routine:
>>
>>> Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
>>>execution to be deferred to a worker thread context)
>>>
>>>My question is:
>>>is it really possible for close() to be invoked at higher than
>>
>>PASSIVE_LEVEL
>>
>>>IRQL?
>>>
>>>My perception was that it is usually invoked in the caller thread context,
>>>or
>>>if FSD implements some delayed close queue, then in the system worker
>>
>>thread
>>
>>>context.
>>>Am I wrong here?
>>>
>>>Thank you very much,
>>>Seva Tonkonoh
>>>
>>>
>>>
>>>
>>>
>>>—
>>>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@pacbell.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
–
Nick Ryan (MVP for DDK)
Very interesting!
Going back to the original question,
do you think then we can safely assume that close() routine is always
called at PASSIVE_LEVEL?
Thanks,
Seva
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nick Ryan
Sent: Saturday, September 27, 2003 5:07 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: IRQL in close()
Disassembling a few lines into ObDereferenceObject shows that if IRQL >
PASSIVE_LEVEL, a function called ObpDeferObjectDeletion is called, which
apparently schedules the meaty stuff for a work item.
Maxim S. Shatskih wrote:
I don’t think anybody really calls ObDereferenceObject on
DISPATCH_LEVEL.
Maybe this is a documentation bug.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Seva Tonkonoh”
> To: “Windows File Systems Devs Interest List”
> Sent: Saturday, September 27, 2003 11:31 PM
> Subject: [ntfsd] Re: IRQL in close()
>
>
>
>>Thanks, I understand now.
>>Although, it doesn’t seem that some filesystems handle this case.
>>For example, FasfFat.
>>I’ve looked through FatFsdClose() and FatCommonClose() and they don’t seem
>>to have
>>any checking for current IRQL.
>>
>>Is it something that should be done, but usually is not?
>>
>>Thanks,
>>Seva
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
>>Sent: Saturday, September 27, 2003 6:39 AM
>>To: Windows File Systems Devs Interest List
>>Subject: [ntfsd] Re: IRQL in close()
>>
>>
>>ObDereferenceObject is allowed to be called on DISPATCH_LEVEL, and can
>>result
>>in CLOSE being sent.
>>
>>Maxim Shatskih, Windows DDK MVP
>>StorageCraft Corporation
>>xxxxx@storagecraft.com
>>http://www.storagecraft.com
>>
>>
>>----- Original Message -----
>>From: “Seva Tonkonoh”
>>To: “Windows File Systems Devs Interest List”
>>Sent: Saturday, September 27, 2003 12:11 PM
>>Subject: [ntfsd] IRQL in close()
>>
>>
>>
>>>Hello,
>>>
>>>I’ve come across such comment in Rajeev Nagar’s sample FSD close()
>>
>>routine:
>>
>>> Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
>>>execution to be deferred to a worker thread context)
>>>
>>>My question is:
>>>is it really possible for close() to be invoked at higher than
>>
>>PASSIVE_LEVEL
>>
>>>IRQL?
>>>
>>>My perception was that it is usually invoked in the caller thread
context,
>>>or
>>>if FSD implements some delayed close queue, then in the system worker
>>
>>thread
>>
>>>context.
>>>Am I wrong here?
>>>
>>>Thank you very much,
>>>Seva Tonkonoh
>>>
>>>
>>>
>>>
>>>
>>>—
>>>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@pacbell.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
–
Nick Ryan (MVP for DDK)
—
You are currently subscribed to ntfsd as: xxxxx@pacbell.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
Then yes.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Seva Tonkonoh”
To: “Windows File Systems Devs Interest List”
Sent: Sunday, September 28, 2003 9:57 AM
Subject: [ntfsd] Re: IRQL in close()
> Very interesting!
>
> Going back to the original question,
> do you think then we can safely assume that close() routine is always
> called at PASSIVE_LEVEL?
>
> Thanks,
> Seva
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Nick Ryan
> Sent: Saturday, September 27, 2003 5:07 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Re: IRQL in close()
>
>
> Disassembling a few lines into ObDereferenceObject shows that if IRQL >
> PASSIVE_LEVEL, a function called ObpDeferObjectDeletion is called, which
> apparently schedules the meaty stuff for a work item.
>
> Maxim S. Shatskih wrote:
> > I don’t think anybody really calls ObDereferenceObject on
> DISPATCH_LEVEL.
> > Maybe this is a documentation bug.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > ----- Original Message -----
> > From: “Seva Tonkonoh”
> > To: “Windows File Systems Devs Interest List”
> > Sent: Saturday, September 27, 2003 11:31 PM
> > Subject: [ntfsd] Re: IRQL in close()
> >
> >
> >
> >>Thanks, I understand now.
> >>Although, it doesn’t seem that some filesystems handle this case.
> >>For example, FasfFat.
> >>I’ve looked through FatFsdClose() and FatCommonClose() and they don’t seem
> >>to have
> >>any checking for current IRQL.
> >>
> >>Is it something that should be done, but usually is not?
> >>
> >>Thanks,
> >>Seva
> >>
> >>-----Original Message-----
> >>From: xxxxx@lists.osr.com
> >>[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> >>Sent: Saturday, September 27, 2003 6:39 AM
> >>To: Windows File Systems Devs Interest List
> >>Subject: [ntfsd] Re: IRQL in close()
> >>
> >>
> >>ObDereferenceObject is allowed to be called on DISPATCH_LEVEL, and can
> >>result
> >>in CLOSE being sent.
> >>
> >>Maxim Shatskih, Windows DDK MVP
> >>StorageCraft Corporation
> >>xxxxx@storagecraft.com
> >>http://www.storagecraft.com
> >>
> >>
> >>----- Original Message -----
> >>From: “Seva Tonkonoh”
> >>To: “Windows File Systems Devs Interest List”
> >>Sent: Saturday, September 27, 2003 12:11 PM
> >>Subject: [ntfsd] IRQL in close()
> >>
> >>
> >>
> >>>Hello,
> >>>
> >>>I’ve come across such comment in Rajeev Nagar’s sample FSD close()
> >>
> >>routine:
> >>
> >>> Expected IRQL: IRQL_PASSIVE_LEVEL (invocation at higher IRQL will cause
> >>>execution to be deferred to a worker thread context)
> >>>
> >>>My question is:
> >>>is it really possible for close() to be invoked at higher than
> >>
> >>PASSIVE_LEVEL
> >>
> >>>IRQL?
> >>>
> >>>My perception was that it is usually invoked in the caller thread
> context,
> >>>or
> >>>if FSD implements some delayed close queue, then in the system worker
> >>
> >>thread
> >>
> >>>context.
> >>>Am I wrong here?
> >>>
> >>>Thank you very much,
> >>>Seva Tonkonoh
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>—
> >>>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> >>>To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >>
> >>—
> >>You are currently subscribed to ntfsd as: xxxxx@pacbell.net
> >>To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >>
> >>—
> >>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> >>To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pacbell.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com