linux-kernel - Re: [PATCH 03/11] 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: <1242099783.19949.8.camel@mulgrave.int.hansenpartnership.com>
Date:	Mon, 11 May 2009 22:43:03 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	bharrosh@...asas.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, Eric.Moore@....com,
	stern@...land.harvard.edu, zaitcev@...hat.com,
	Geert.Uytterhoeven@...ycom.com, sfr@...b.auug.org.au,
	grant.likely@...retlab.ca, paul.clements@...eleye.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, dgilbert@...erlog.com,
	djwong@...ibm.com
Subject: Re: [PATCH 03/11] block: add rq->resid_len

On Tue, 2009-05-12 at 09:19 +0900, Tejun Heo wrote:
> Hello, all.
> 
> James Bottomley wrote:
> >>> Does resid_len make any sense w/ failed requests?  I think we would be
> >>> better off with declaring residual count to be undefined on request
> >>> failure.  Is there any place which depends on it?
> >> IIRC, I wrote the code. I think that this doesn't matter but it's
> >> better not to change the behavior unless Eric ack on this change
> >> (maybe LSI has some management binary that assume this behavior though
> >> it's unlikely).
> > 
> > Actually, yes it does, for many possible reasons.
> > 
> > The first being if the device is too stupid to report an actual sector
> > location the next best way of determining where the error occurred is
> > from the residual.  We don't make use of this in kernel (perhaps we
> > should?) but some of the user space programs for CD/DVD burning do.
> 
> Really?  Residual count on command success is used but on failure?
> That's a dangerous territory.  When a SG_IO fails, the only data the
> app should be accessing is the sense data if the status indicates its
> validity.  The problems with residual count on failed command are...
> 
> * Not well defined.  What does it mean really?  It can't indicate
>   successful partial transfer.  If the request partially succeeded,
>   the required behavior is to successfully complete the request
>   partially with residual count and then fail the latter part when
>   issued again.  If the failure applies to the whole request but
>   location information is useful, it should be carried in the sense
>   data.

The definition is the amount of data transfer requested less the actual
that went over the wire ... that's certainly a well defined quantity;
although, one could argue about what this means in the device.
Certainly I agree that just because the data was transferred to or from
the device is no guarantee that the device did anything with it (or
transferred it accurately).

> * What about corner values?  What does 0 or full resid count on
>   failure mean?

0 means everything transferred, full residual means nothing did.

> * Different layers of failing.  In SG_IO interface, a request may fail
>   with -EIO way before it reaches block layer.  Residual count can't
>   be set to any meaningful value in these cases.  We can set it to
>   full count for these fast fail paths, but do we really wanna go
>   there?  Another problem is when a driver is missing SG_IO
>   capability.  Who's responsible for setting resid count in that case?
>   How is upper layer gonna determine a SG_IO failed because lower
>   level driver didn't support it or it genuinely failed?

Well, I prefer the concept of transfer length, which would be
initialised to zero ... however, residuals should be initialised to the
actual transfer count.

> I think it's just silly to give any meaning to resid count when the
> request fails.  It's best to leave the field unmodified or just
> declare it undefined.

It's current behaviour.  Technically that makes it part of the SG_IO
ABI ... although it could be deprecated if someone can verify there are
no current users.

James


--
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/