Messages in this thread | | | Date | Wed, 1 Apr 2009 14:29:42 +0200 | From | Jens Axboe <> | Subject | Re: [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
| |