linux-kernel - Re: [PATCH] block: fix residual byte count 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]

Message-Id: <20080305092619Y.fujita.tomonori@lab.ntt.co.jp>
Date:	Wed, 05 Mar 2008 09:26:19 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	htejun@...il.com
Cc:	tomof@....org, efault@....de, jens.axboe@...cle.com,
	fujita.tomonori@....ntt.co.jp,
	James.Bottomley@...senPartnership.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	linux-scsi@...r.kernel.org, jgarzik@...ox.com, bzolnier@...il.com
Subject: Re: [PATCH] block: fix residual byte count handling

On Wed, 05 Mar 2008 08:33:05 +0900
Tejun Heo <htejun@...il.com> wrote:

> FUJITA Tomonori wrote:
> > Hmm, does SCSI mid-layer need to care about how many bytes the block
> > layer allocates? I don't think that extra_len is NOT good_bytes.
> > 
> > I think that the block layer had better take care about it (fix
> > __end_that_request_first?).
> 
> Yeah, probably calling completion functions w/o bytes count is the right
> thing to do but what I was talking about was what could break when the
> semantics of rq->data_len changed.  If we keep rq->data_len() ==
> sum(sg), we keep it business as usual for all the rest except for the
> device application layer if we don't we do the reverse and SCSI midlayer
> completion was a good example, I think.

sglist is a low-level I/O representation for device drivers. SCSI
midlayer should not care about sglist. We should not fix SCSI midlayer
for rq->data_len != sum(sg) change (so I can't agree with your
diagrams in another mail).

When if we change a rule, we need to fix something.

If we keep rq->data_len == sum(sg), we need to fix the device
application layer. If we keep rq->data_len == the true data length, we
need to fix the low-level drivers.

Now I'm fine with the commit e97a294ef6938512b655b1abf17656cf2b26f709
since we are in -rc stages. But I plan to send a patch to revert it
and fix this issue in the block layer. I'd like to test it in -mm for
a while.

Only sglist stuff in SCSI midlayer is scsi_req_map_sg now. As you
know, we really want to remove it.


> Things going the other way is fine with me but I at least want to hear a
> valid rationale.  Till now all I got is "because that's the true size"
> which doesn't really make much sense to me.

Most of users of request structure care about only the real data
length, don't care about padding and drain length. Why do they bother
to use a helper function to get the real data length?
--
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/