Re: [PATCH v3 07/10] block: Implement bdrv_{pread,pwrite,pwrite_zeroes}() using generated_co_wrapper

[Stefan Hajnoczi]

On Fri, May 27, 2022 at 09:25:06AM -0500, Eric Blake wrote:
> On Thu, May 26, 2022 at 08:23:02PM +0100, Alberto Faria wrote:
> > On Thu, May 26, 2022 at 9:55 AM Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > > The bdrv_pread()/bdrv_pwrite() errno for negative bytes changes from
> > > EINVAL to EIO. Did you audit the code to see if it matters?
> > 
> > I don't believe I had, but I checked all calls now. There's ~140 of
> > them, so the probability of me having overlooked something isn't
> > exactly low, but it seems callers either cannot pass in negative
> > values or don't care about the particular error code returned.
> > 
> > Another option is to make bdrv_co_pread() and bdrv_co_pwrite() (which
> > have much fewer callers) fail with -EINVAL when bytes is negative, but
> > perhaps just getting rid of this final inconsistency between
> > bdrv_[co_]{pread,pwrite}[v]() now will be worth it in the long run.
> 
> Failing with -EINVAL for negative bytes makes more sense at
> identifying a programming error (whereas EIO tends to mean hardware
> failure), so making that sort of cleanup seems reasonable.

From IRC:

13:50 < stefanha> kwolf hreitz: Is there a reason why bdrv_check_qiov_request() 
fails with -EIO instead of -EINVAL when parameters are invalid?
13:51 < hreitz> I think the reason is “EIO is kind of the default error value 
in the block layer”
13:53 < stefanha> bdrv_pwrite() has its own if (bytes < 0) return -EINVAL 
check, duplicating the input validation (but returning a different errno).
13:54 < hreitz> I think I’m only responsible for blk_check_byte_request(), but 
AFAIR that was my reasoning there
13:54 < stefanha> That makes me wonder if something depends on the exact errno.
13:54 < hreitz> I hope not
13:54 < stefanha> ...and what would break if it was changed to be EINVAL 
(consistent with file I/O syscalls).
13:55 < hreitz> Speaking for myself, I don’t think I’ve ever spent much 
consideration on what error codes to use in the block layer…
13:55 < kwolf> My guess is that it has always been EIO and nobody was bothered 
enough to check whether returning EINVAL instead would break anything
13:55 < stefanha> Thanks!
13:55 < hreitz> E2BIG might be special, and EAGAIN might do funny things 
sometimes, but other than that I’d’ve hoped everything’s treated equally
13:55 < stefanha> I'll add this information to the afaria's patch series 
discussion.

signature.asc
Description: PGP signature