Hi Again,
Thanks Maxim!
I am sorry if I did not provide enough details. I didn’t really knew of
a deadlock scenario on my resource. I’m still not sure that such a thing
can occur since (if it’s my resource that we are talking of) I’m
actually using in most of the cases the
ExAcquireResourceSharedLite()(and not as the subject question may
insinuate, I acquire the resource exclusively only once in an internal
ioctl coming from my other FDO driver in order to unregister itself)
which according to the documentation can be re-acquired(doc quote: “If
the caller already has acquired the resource (for shared or exclusive
access), the current thread is granted the same type of access
recursively. Note that making this call does not convert a caller’s
exclusive ownership of a given resource to shared.”)
I actually have Readers-Writer mechanism between two drivers in order to
unable the unloading of the functional driver. (One driver is a file
system filter driver and the other is a dynamic (unloadable) functional
driver(fdo) that actually holds the functionality of the filter by
providing to him function pointers interface. The FS filter calls the
FDO only if it gets the resource (using
ExAcquireResourceSharedLite().b.t.w. only the reg-unregister internal
ioctal flow acquire the resource exclusively). The fdo eventually either
returns and the next driver get called or in some cases the fdo itself
calls to the next driver. I may add that the fdo doesn’t have any
completion routines, And that the filter FS his based upon Sfilter IFS
example.
I was just about delivering this to the QA. )-:
I have inherit this peace of code, so although I had my doubts
everything seems to work fine for most of the time (but didn’t yet went
to production).
If this is still an issue, I guess I should either replace this
Readers-Writer mechanism to use FastMutex ? or just throw a way all of
our work? )-:
I’m really in a very big dilemma.
Thanks
Daniel.
-----Original Message-----
From: xxxxx@openmars.com [mailto:xxxxx@openmars.com]
Sent: Monday, December 04, 2006 4:17 AM
To: Daniel Arosh
Subject: RE: [ntfsd] Can I call IoCallDriver() after calling
KeEnterCriticalRegion ? and ExAcquireResourceExclusive() ???
The file system is re-entrant in many surprising ways, so this resource
could very well be whatever resource you have internally.
t.
On Mon, 4 Dec 2006, Daniel Arosh wrote:
Hi Maxim,
What do you mean by saying “this ERESOURCE”? my specific resource
that I just acquired or something else ?
Thanks !
> Is it OK to call IoCallDriver() after calling KeEnterCriticalRegion
> and
> ExAcquireResourceExclusive() ???
Bad idea. IoCallDriver will fire the completion path, which can
deadlock on this ERESOURCE.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com http:</http:>
Hi All,
Is it OK to call IoCallDriver() after calling KeEnterCriticalRegion and
ExAcquireResourceExclusive() ???
I just read in the Ifs doc(FsRtlEnterFileSystem) something that brought
me some serious doubts about my code:
" Note that, unlike file systems, file system filter drivers should
never disable delivery of normal kernel APCs (by calling
FsRtlEnterFileSystem or KeEnterCriticalRegion or by raising to IRQL
APC_LEVEL) across a call to IoCallDriver.
The only time when a file system filter driver should disable normal
kernel APCs is immediately before calling ExAcquireResourceExclusive or
ExAcquireResourceExclusiveLite. After calling ExReleaseResource or
ExReleaseResourceLite, the filter driver should immediately reenable
delivery of normal kernel APCs.
"
Thanks!
Daniel
Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.aspx
*********************************************************************
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.
*********************************************************************