linux-kernel - Re: [PATCH 2/8] block: fix SG_IO vector request data length handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 01 Apr 2009 21:27:11 +0900
From:	Tejun Heo <tj@...nel.org>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
CC:	jens.axboe@...cle.com, bharrosh@...asas.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/8] block: fix SG_IO vector request data length	handling

FUJITA Tomonori wrote:
> On Wed, 1 Apr 2009 13:50:58 +0200
> Jens Axboe <jens.axboe@...cle.com> wrote:
> 
>> On Wed, Apr 01 2009, FUJITA Tomonori wrote:
>>> On Wed,  1 Apr 2009 20:04:38 +0900
>>> Tejun Heo <tj@...nel.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...

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/