The reason I started looking out for a flag was because I got the
impression that the RDR must be serializing requests to me. The plan
still is to figure out a workaround in my file system driver and the
reason I can’t go ahead is that I don’t know what “not to do”. My FSD
tries to satisfy file system requests by blocking them using
“KeWaitForSingleObject” (instead of marking the rx request pending),
tries to satisfy the request using a user mode thread which uses the
local file system cache to satisfy the request. The deadlock occurs when
the user mode thread tries to satisfy a request by calling
Getfileattributes() which tries to acquire the PEB lock.
Do you think it’s very likely that this problem will go away if I
rearchitect my FSD to pend rx requests instead of blocking them ? Is
there something I’ve mentioned that might sound a little unusual to you
?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Monday, June 19, 2006 11:56 PM
To: Windows File Systems Devs Interest List
Subject: [SPAM] - Re: [ntfsd] ntdll!RtlAcquirePebLock : When
does this get acquired ? - Bayesian Filter detected spam
When does the peb lock get acquired by windows ? How can I
prevent windows
> from acquiring the peb lock. I have a pseudo FSD using
> RDBSSLIB that satisfies file system
I guess the problem is not in acquiring PEB lock, but in your
filter.
There’s no “flag fo disable PEB lock acquiring”. Basically,
locks are acquired
for a reason (usually), you can’t just stop doing it.
Rather try to analyze where in your filter is the problem.
L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com