lkml.org 
[lkml]   [2009]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/8] block: fix SG_IO vector request data length handling
    On Wed, Apr 01 2009, Tejun Heo wrote:
    > FUJITA Tomonori wrote:
    > > On Wed, 1 Apr 2009 13:50:58 +0200
    > > Jens Axboe <jens.axboe@oracle.com> wrote:
    > >
    > >> On Wed, Apr 01 2009, FUJITA Tomonori wrote:
    > >>> On Wed, 1 Apr 2009 20:04:38 +0900
    > >>> Tejun Heo <tj@kernel.org> wrote:
    > >>>
    > >>>> Impact: fix SG_IO behavior such that it matches the documentation
    > >>>>
    > >>>> SG_IO howto says that if ->dxfer_len and sum of iovec disagress, the
    > >>>> shorter one wins. However, the current implementation returns -EINVAL
    > >>>> for such cases. Trim iovc if it's longer than ->dxfer_len.
    > >>> Is that description about sg's SG_IO?
    >
    > It looks like it's the closest thing.
    >
    > >> The more important question is what sg.c actually does, that's more
    > >> important than the documentation.
    >
    > The current code would fail it with -EINVAL but after brief look into
    > 2.6.12-rc2, it seems like it would use the shorter one. On direct
    > mapping path, it builds considering both lengths and on indirect path
    > it doesn't seem to look at the iov supplied till the transfer is
    > actually complete using the dxfer_len and then copy out whatever can
    > be copied out.
    >
    > > Do you think that Doug is a person who makes such mistake? ;)
    > >
    > > Seems that sg worked as the howto says. But I think that I broke it
    > > when I converted sg to use the block layer. I'll fix it soon.
    > >
    > > About this patch, as we know, there are lots of subtle differences
    > > between sg's SG_IO and the block's. I'm not sure that it's a good idea
    > > to change the behavior of the block's SG_IO.
    >
    > I think it's better to make the behavior more consistent. Using
    > shorter dxfer_len can be considered a feature too, so...

    It's definitely a good feature, it's how you'd probe lots of scsi
    command returns. Setting up the iovec once and passing first a smaller
    than a larger dxfer_len would be a perfectly reasonable way to do that.

    --
    Jens Axboe



    \
     
     \ /
      Last update: 2009-04-01 14:33    [W:2.361 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site