Sequence using IRP for File IO instead of ZwReadFile/ZwWriteFile

Hi,

I’ve read the warning of using ZwReadFile for reading to a buffer provided in the IRP or Srb, but instead to use the Mdl given directly. So I have a situation in storport where I need to break up the file reads/writes, so I’ll IoAllocateIrp, IoAllocateMdl, and IoBuildPartialMdl, I presume the Srb->DataBuffer is already locked and correct virtual buffer for IoBuildPartialMdl? I’ll setup the completion routine and send the irp down to the files device object. Using the Srp device extension and completion routine, the SRB will be completed properly.

My question is (besides confirming my presumption above), are the IRP’s sent down to the file guaranteed to complete in the order sent? Of course reads don’t matter as much as Writes. Now I know within servicing a SRP no writes will overlap, however, it will be returning the SRP pending. So could another SRP come in and those writes get completed prior to the existing write sent in the prior SRP?

TIA!!

if the mini port never sends another srb until the other one finishes than returning pending isn’t going to cause any race condition.

Where are you sending these IRPs to that you need to break up the transfer? Seems easier to just correctly set your maximum transfer length in the first place…

If you grab the original MDL with StorPortGetOriginalMdl and build partial MDLs you should be OK. You can use Srb->DataBuffer as the virtual address, just make sure you set Irp->UserBuffer to this address before you send the IRP.

With respect to overlapping writes…You’re just a proxy in this case. If the caller really needs write B to complete after write A then they need to wait for A to complete before sending B.

Sending the IRP’s to the file for IO instead of ZwReadFile/ZwWriteFile. Does the file IO ensure it’s handled in order? Or does SRB process allow overlapping IO or is it synchronous.

Nothing ensures requests are handled “in order”… in Windows, there IS no such thing as “in order”… if you want two IRPs to be processed in a specific order, you must send one request and wait for it to complete, the send the next one. This is how Windows works.

Peter

Does miniport work that way or does it send SRP’s overlapped?

I don’t understand your question. More than one sentence is usually helpful.

We had a long discussion about this recently on the forum in this thread,

Peter

Thanks, the thread answered my question I think. The file system (requestor) itself handles ensuring the order of writes completing (the incoming to the virtual device), therefore another request to write that lba won’t come from the file system (requestor) again until the SRP is fully completed (not just set pending), therefore we don’t need to worry that our backing file will get another write to the same area (from the file system) until it completed the prior one. Of course multiple writes to same area could come in random order from various requestor but that’s not our (device level) problem.

that’s not our (device level) problem

Yup. You got it.

Peter