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 <stefa...@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.I'm surprised -EIO is being returned but all the more reason to check what effect changing to -EINVAL has. If you find it's safe to change to -EINVAL then that's consistent with how file I/O syscalls work and I think it would be nice. Stefan
signature.asc
Description: PGP signature
