linux-kernel - Re: [PATCH 03/10] block: add rq->resid

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: <49F905EE.2020407@kernel.org>
Date:	Thu, 30 Apr 2009 10:59:10 +0900
From:	Tejun Heo <tj@...nel.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	axboe@...nel.dk, linux-kernel@...r.kernel.org, jeff@...zik.org,
	linux-ide@...r.kernel.org, linux-scsi@...r.kernel.org,
	bzolnier@...il.com, petkovbb@...glemail.com,
	sshtylyov@...mvista.com, mike.miller@...com,
	chirag.kantharia@...com, Eric.Moore@....com,
	stern@...land.harvard.edu, fujita.tomonori@....ntt.co.jp,
	zaitcev@...hat.com, Geert.Uytterhoeven@...ycom.com,
	sfr@...b.auug.org.au, grant.likely@...retlab.ca,
	paul.clements@...eleye.com, jesper.juhl@...il.com,
	tim@...erelk.net, jeremy@...source.com, adrian@...en.demon.co.uk,
	oakad@...oo.com, dwmw2@...radead.org, schwidefsky@...ibm.com,
	ballabio_dario@....com, davem@...emloft.net, rusty@...tcorp.com.au,
	Markus.Lidel@...dowconnect.com, bharrosh@...asas.com,
	Doug Gilbert <dgilbert@...erlog.com>,
	"Darrick J. Wong" <djwong@...ibm.com>
Subject: Re: [PATCH 03/10] block: add rq->resid_len

Hello, James.

James Bottomley wrote:
> This looks good (although I'd like to test it first).

Yeah, this will need quite a bit of testing.

> Might it not be better to have an accessor setting resid_len?  All
> the other patches in the series insulate users from the actual
> members of struct request by accessors, so this is a bit the odd man
> out.

I actually think it's better to expose resid_len in this case as the
semantics of the field is - initialized to zero on issue, contains
residual count on completion and whatever it contains inbetween is
upto the low level driver.  Request position or length are different
as they must contain well defined values throughout request processing
and both block layer and low level driver should agree on what they
mean.

Fancy words aside, it basically boils down to allowing llds to do
either "rq->resid_len = blk_rq_bytes() - xferred" on completion or
"rq->resid_len = blk_rq_bytes()" on issue and "rq->resid_len -=
increments" while processing.

It would be better to check that the value is sane on completion tho.

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/