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: <49F95101.3010004@kernel.org>
Date:	Thu, 30 Apr 2009 16:19:29 +0900
From:	Tejun Heo <tj@...nel.org>
To:	petkovbb@...il.com, Tejun Heo <tj@...nel.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	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

Borislav Petkov wrote:
>> 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.
> 
> Actually, the second one sounds more natural: resid_len == data_len on
> issue and decrementing while travelling through block layer and LLDD,
> while resid_len == 0 in issue might get confused somewhere.

Yeap, it depends on how the specific low level driver is doing it.

> And I like it too, we've been coming up with all sorts of hacks in
> ide-atapi wrt to residual completion and accounting of what got xferred
> already and rq->resid_len is much more cleaner, IMHO.
> 
> /me testing...

AFAICT, residual count handling in ide was most broken.  This patch
doesn't fix anything other than making it report 0 resid_len on SG_IO
which is usually better than reporting full residual count.  The only
place inside ide where residual count is used in the tape driver to
determine actually transferred size.  That part works okay with the
patch applied.

Hmmm... maybe it's about time to finally clean up residual count
handling in ide and libata, which BTW doesn't do anything about it at
the moment.

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/