Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Short MDL in Storport miniport driver

Alex_GrigAlex_Grig Member Posts: 3,238
In a virtual Stor miniport, in Windows 2008 RTM, we're occasionally getting an MDL for Write operation that describes a buffer shorter than Srb->DataTransferLength. For example, MmGetMdlByteCount will return 0xECE0, but DataTransferLength is 0xEE00, which is MDL length rounded up to whole sector.

This can happen during installation. I suspect it's caused by WriteFile with FILE_FLAG_WRITE_THROUGH, when a request gets written to the disk immediately, but the lengths is not necessarily multiple of sectors.

Is it calid case which the miniport should handle? I don't see anything in the WDK docs. Should I just zero-pad the transfer up to DataTransferLength?

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,135
    Why are you looking at the byte count in the MDL? That's not the correct
    place to check for the length of the transfer, you should only be concerned
    with the transfer length specified in the SRB (and of course the lengths of
    the scatter gather elements).

    As for WHY you're seeing this, I'm not sure. Clearly somebody is rounding up
    for some reason or another and I'd hope that they'd ensure enough space in
    the buffer to accommodate it (though I have seen bad cases where people just
    assume the space is available). If you honor the transfer length it
    shouldn't matter, but if you're curious I'd track down the original I/O
    request and check out the parameters.

    -scott


    --
    Scott Noone
    Software Engineer
    OSR Open Systems Resources, Inc.
    http://www.osronline.com


    wrote in message news:xxxxx@ntdev...
    > In a virtual Stor miniport, in Windows 2008 RTM, we're occasionally
    > getting an MDL for Write operation that describes a buffer shorter than
    > Srb->DataTransferLength. For example, MmGetMdlByteCount will return
    > 0xECE0, but DataTransferLength is 0xEE00, which is MDL length rounded up
    > to whole sector.
    >
    > This can happen during installation. I suspect it's caused by WriteFile
    > with FILE_FLAG_WRITE_THROUGH, when a request gets written to the disk
    > immediately, but the lengths is not necessarily multiple of sectors.
    >
    > Is it calid case which the miniport should handle? I don't see anything in
    > the WDK docs. Should I just zero-pad the transfer up to
    > DataTransferLength?
    >
    >

    -scott
    OSR

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,262
    <QUOTE>
    when a request gets written to the disk immediately, but the lengths is not necessarily multiple of sectors
    </QUOTE>

    To continue where SNoone (who is entirely correct, of course) left off:

    Where's the data buffer? I bet its in pool (not in the user application).

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alex_GrigAlex_Grig Member Posts: 3,238
    [ScottN]
    >Why are you looking at the byte count in the MDL? That's not the correct
    >place to check for the length of the transfer, you should only be concerned
    >with the transfer length specified in the SRB (and of course the lengths of
    >the scatter gather elements).

    To get data froom the buffer, we need to build SGL. If we request to build SGL longer than the MDL describes, what will happen?

    [PeterV]
    >Where's the data buffer? I bet its in pool (not in the user application).

    The request comes from the modified page writer. Since it's not a multiple of pages, I suspect it's file cache commit, rather than pageout.

    Related question: If I pass Length greater than the MDL describes, to StorPortBuildScatterGatherList, is it allowed?
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,135
    > To get data froom the buffer, we need to build SGL. If we request to build
    > SGL longer than the MDL describes, what will >happen?

    You pass the SRB to StorPorGetScatterGatherList, not the MDL. Thus, it's
    StorPort's problem (if it's even a problem at all). It's still not clear why
    you're even messing with the MDL. Did this come from StorPortGetOriginalMdl
    (Vista and later) or did you poof up your own mechanism?

    While I'm admittedly not the biggest fan of the port driver architectures,
    I'd say that in this particular case you might be poking under the covers
    too much. There's not much you can do if the wrapper is screwing things this
    badly. If you're finding corruptions, failures, or other issues and you're
    thinking that this is the cause, I'd again recommend that you isolate the
    original I/O request and find out where the rounding up is occurring. But,
    my guess is that you're missing part of the puzzle and this is a red
    herring.


    -scott

    --
    Scott Noone
    Software Engineer
    OSR Open Systems Resources, Inc.
    http://www.osronline.com


    wrote in message news:xxxxx@ntdev...
    > [ScottN]
    >>Why are you looking at the byte count in the MDL? That's not the correct
    >>place to check for the length of the transfer, you should only be
    >>concerned
    >>with the transfer length specified in the SRB (and of course the lengths
    >>of
    >>the scatter gather elements).
    >
    > To get data froom the buffer, we need to build SGL. If we request to build
    > SGL longer than the MDL describes, what will happen?
    >
    > [PeterV]
    >>Where's the data buffer? I bet its in pool (not in the user application).
    >
    > The request comes from the modified page writer. Since it's not a multiple
    > of pages, I suspect it's file cache commit, rather than pageout.
    >
    > Related question: If I pass Length greater than the MDL describes, to
    > StorPortBuildScatterGatherList, is it allowed?
    >
    >

    -scott
    OSR

  • Alex_GrigAlex_Grig Member Posts: 3,238
    [ScottN]
    >You pass the SRB to StorPorGetScatterGatherList, not the MDL. Thus, it's
    >StorPort's problem (if it's even a problem at all). It's still not clear why
    >you're even messing with the MDL. Did this come from >StorPortGetOriginalMdl
    >(Vista and later) or did you poof up your own mechanism?

    This is virtual miniport. For such, storport doesn't build SGL just in case, and StorPorGetScatterGatherList returns NULL. Thus, we need to call StorPortBuildSGL.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,135
    Ahh, OK, that makes sense.

    This has to be a thin wrapper around the underlying DMA APIs and, having
    been through this before long ago for reasons long forgotten, I do know that
    they handle this case for some reason or another.

    There's definitely code in the FSDs to round up I/Os to sector boundaris
    (non-cached I/O comes to mind) and that might cause you to see something
    like this.

    But, again, this is all out of your control and is likely to be normal. You
    didn't initiate the transfer, you didn't build the MDL, you're just a lowly
    block device at the mercy of the wrapper. Unless these MDLs are causing the
    DMA APIs to fail or corruptions to occur it's probably worth spending your
    time elsewhere.

    -scott

    --
    Scott Noone
    Software Engineer
    OSR Open Systems Resources, Inc.
    http://www.osronline.com



    wrote in message news:xxxxx@ntdev...
    > [ScottN]
    >>You pass the SRB to StorPorGetScatterGatherList, not the MDL. Thus, it's
    >>StorPort's problem (if it's even a problem at all). It's still not clear
    >>why
    >>you're even messing with the MDL. Did this come from
    >> >StorPortGetOriginalMdl
    >>(Vista and later) or did you poof up your own mechanism?
    >
    > This is virtual miniport. For such, storport doesn't build SGL just in
    > case, and StorPorGetScatterGatherList returns NULL. Thus, we need to call
    > StorPortBuildSGL.
    >
    >
    >

    -scott
    OSR

  • Alex_GrigAlex_Grig Member Posts: 3,238
    Following up on this:

    The "short MDL" condition happens in FlushViewOfFile path, if the file contents is not in the file cache (which means it was never touched by ReadFile/WriteFile), and the file length is not exact multiple of sectors.

    If I feed Srb->DataTransferLength to StorPortBuildScatterGatherList, it will simply extend the last item, regardless that MDL length doesn't cover it. It's benign, but I wonder if that's the right thing to do. I suspect this is what non-virtual storport path does.
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,306
    Block devices can't (obviously) have less than a blocks worth of data. Just
    write away and don't worry about it. If there isn't an actual physical
    memory location for the extra bytes, somebody above you screwed up.

    On Fri, Apr 18, 2008 at 4:24 PM, wrote:

    > Following up on this:
    >
    > The "short MDL" condition happens in FlushViewOfFile path, if the file
    > contents is not in the file cache (which means it was never touched by
    > ReadFile/WriteFile), and the file length is not exact multiple of sectors.
    >
    > If I feed Srb->DataTransferLength to StorPortBuildScatterGatherList, it
    > will simply extend the last item, regardless that MDL length doesn't cover
    > it. It's benign, but I wonder if that's the right thing to do. I suspect
    > this is what non-virtual storport path does.
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >



    --
    Mark Roddy
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA