Pending IRPs to the queue in FS filter

NTFSD
1

Hi!

My FS filter needs to do some operation with the guarantee that no FSD operations of some kind will run in parallel with my
operation.

My current solution is to use ERESOURCE lock which is acquired shared on usual operations (both IRPs and FastIos) and exclusive on
my operation. This works without bugs, though I synchronize all FSD IRPs by waiting for them if STATUS_PENDING was returned. Not so
good, I will fix this.

I had also other solution attempt. Namely - to put all IRPs to the queue while my operation is in progress. This lead to a problem
since I dequeue them and send them down in my process (process which requested my operation), not in their original processes.
This surely causes STATUS_INVALID_USER_BUFFER IRP failure.

Surely I can look at FASTFAT to see what IRP preprocessing is done by it before posting the IRP to the worker thread and do the
same.

My question is:

  • is it a good idea at all to queue FSD IRPs in the FS filter?
  • is ERESOURCE better?

Any opinions?

regards,
Max

2

Queueing up the IRPs is the right approach.

However if the FSD is not the top-level component for the request -
(i.e. IoGetTopLevelIrp() is non-NULL )
remember you will not be able to let the request through in a different
thread, for obvious reasons.
Not much option here, sorry…

In other cases, yes - if you are letting the queued request through,
you can simply lock down the user buffers (at the right time
MmProbeAndLockProcessPages is your friend, it stack attaches to the
target process to lock down the buffer) before sending it down.

If you are queuing them up for a long time (‘long’ is subjective, but
I’d say anything on the order of 1 sec or more is long), please make
sure to set a cancel routine - and I recommend using the cancel-safe
queues. Getting cancel right on your own is non-trivial.

This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, April 18, 2002 3:17 PM
To: File Systems Developers
Subject: [ntfsd] Pending IRPs to the queue in FS filter

Hi!

My FS filter needs to do some operation with the guarantee that no FSD
operations of some kind will run in parallel with my operation.

My current solution is to use ERESOURCE lock which is acquired shared on
usual operations (both IRPs and FastIos) and exclusive on my operation.
This works without bugs, though I synchronize all FSD IRPs by waiting
for them if STATUS_PENDING was returned. Not so good, I will fix this.

I had also other solution attempt. Namely - to put all IRPs to the queue
while my operation is in progress. This lead to a problem since I
dequeue them and send them down in my process (process which requested
my operation), not in their original processes. This surely causes
STATUS_INVALID_USER_BUFFER IRP failure.

Surely I can look at FASTFAT to see what IRP preprocessing is done by it
before posting the IRP to the worker thread and do the same.

My question is:

  • is it a good idea at all to queue FSD IRPs in the FS filter?
  • is ERESOURCE better?

Any opinions?

regards,
Max

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%