Vikas,
This risks creating a deadlock; you are calling the FSD saying “oh, I’m
not holding any locks” when in fact you are. So at some point, no doubt
under high load on an MP system (where race conditions tend to show up)
the threads will hang up and the rest of the system will also hang up (a
“dog pile” of threads, as it were.)
That is in fact why I said to do it asynchronously in a worker thread -
just doing it in another thread, but blocking and waiting risks running
into the same deadlock condition.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vikas Ratna
Sent: Wednesday, February 25, 2004 6:56 PM
To: ntfsd redirect
Subject: RE: [ntfsd] STATUS_FILE_LOCK_CONFLICT
Tony one quick question. If I were to retain following in my code,
instead of processing log from a separate thread,:
- var = IoGetTopLevelIrp();
- IoSetTopLevelIrp (0);
- ZwWrite ();
- IoSetTopLevelIrp(var)
Would there be any issues…? I was looking around on FAQs could not find
much info.
Regards
Vikas
-----Original Message-----
No wonder they say… listen to what Master says:-)
Tony, you are right. Before my write call, I placed a print statment for
IoGetTopLevelIrp(). And yes, whenever the print value was non-zero, I
would get STATUS_FILE_LOCK_CONFLICT error. The print values were
typically FSRTL_CACHE_TOP_LEVEL_IRP.
I went one step further (for fun) just to make it doubly sure, and did
following:
- var = IoGetTopLevelIrp();
- IoSetTopLevelIrp (0);
- ZwWrite ();
- IoSetTopLevelIrp(var);
And yes… no more STATUS_FILE_LOCK_CONFLICT errors.
Thanks Tony, I would place the loging asynchronously in a worker thread.
Regards
Vikas
-----Original Message-----
I do not believe the problem you observe is caused by your using fast
mutex objects - but I am merely warning you that you will observe a
problem in the future.
I still believe the most likely case is that top level IRP is already
set when you are called (IoGetTopLevelIrp() must return NULL). That is
the case in strucsup.c. If IoGetTopLevelIrp() indicates that this is a
recursive call, it is not safe for you to then call back into the file
system and operate on a different file (at least not as a general rule.)
If this is the case, you must post asynchronously to a worker thread
(that is, do not “block and wait” for the worker thread to complete.)
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vikas Ratna
Sent: Sunday, February 22, 2004 9:15 PM
To: ntfsd redirect
Subject: RE: [ntfsd] STATUS_FILE_LOCK_CONFLICT
I tried using fast mutex unsafe and semaphores, yet the same result.
One observation though is - it happens in a specific sequence, whenever
I create my logfile and the information to be written is big…it fails
for first few large writes and then gets ok for the subsequent writes
(small or big). I create a new log file everytime the existing one
exceeds certain size.
When I repeat the same set of IO with a smaller chunk of writes, it
works just fine… no more STATUS_FILE_LOCK_CONFLICT errors. However, I
cannot continue to break my large writes into smaller chunks and perform
multiple writes as it would lead to significant performance degradation.
Yes, you are right my driver is running as filter and on successful
completion of IRP_MJ_WRITE (for a specific set of folders) writes to a
log file (IO from within filter). IRP_MJ_WRITES for other files and
folders are just let go. I have tried using IoCreate…Hint function as
well. No luck…yet.
I am trying to understand the case mentioned in strucsup, lets see…
Any further help would be appreciated.
Vikas
-----Original Message-----
You do realize that using a fast mutex will raise to IRQL APC_LEVEL and
ZwWriteFile can only be safely called from PASSIVE_LEVEL? At some point
this code will cause a thread hang (once this request gets posted by the
underlying FSD).
Also, if you are doing this from within another I/O operation (such as
within a filter) and then call down to the underlying FSD, it is quite
possible the TopLevelIrp field has been set, in which case this will
appear to be a reentrant call to the FSD and it may raise
STATUS_FILE_LOCK_CONFLICT in such cases.
Look at this case in fastfat (strucsup.c) for one such case. NTFS is
assuredly more likely to raise this condition because it has its own
complex internal states to manage (with its own log file).
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vikas Ratna
Sent: Sunday, February 22, 2004 12:22 AM
To: ntfsd redirect
Subject: RE: [ntfsd] STATUS_FILE_LOCK_CONFLICT
Additional Info:
I see this STATUS_FILE_LOCK_CONFLICT message, whenever my log file is
created for the first time. So, the first few writes to log file return
this status and then subsequent writes go thru fine. This pattern is
pretty repeatable.
The flags that I use to create file are Synchronous_noalert and
write_through, with all the share access enabled (read, write , delete).
Thanks, any help would be appreciated.
Vikas
-----Original Message-----
Hi Folks,
I am having trouble with STATUS_FILE_LOCK_CONFLICT.
I have a global log file handle open (opened when user mode sends
operation start IOCTL), which is used at the time a IRP_MJ_WRITE arrives
for a certain set of folders, to log some info. I get the
STATUS_FILE_LOCK_CONFLICT quite intermittently. Is it because of the
FilePointer and FileAllocation related IRP_MJ_SET_INFORMATION that
follow for the log file? Do they do some locking because of which some
of the ZwWrites for log file fail?
LogWriteInfo ()
{
ExAcquireFastMutex(globalLogLock);
Status = ZwWrite(globalLogFileHandle,…);
if (Status != STATUS_SUCCESS)
{
KdPrint (…The Error…);
}
ExReleaseFastMutex(globalLogLock);
}
Best Regards
Vikas
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@agglut.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@agglut.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@agglut.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@agglut.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com