[Libguestfs] [libnbd PATCH 1/2] api: Tighter checking of structured read replies
Eric Blake
eblake at redhat.com
Wed Jun 1 13:57:29 UTC 2022
On Tue, May 31, 2022 at 10:32:23PM +0300, Nir Soffer wrote:
> > > But we can have this case:
> > >
> > > 1. ask for 32m
> > > 2. server sends 16m (data_seen increase to 16m)
> > > 3. server sends 16m (data_seen increase to 32m)
> > > 4. server sends 1m (data_seen does not increase)
> >
> > Yes it does. 32m <= cmd->count is true, so we bump data_seen to 33m.
>
> Right! I missed this.
>
> > Then, later on when retiring the command, we note that 33m != 32m and
> > fail the read with EIO (if it has not already failed for other
> > reasons).
> >
> > > 5. entire request succeeds
> > >
> > > Shouldn't we fail if server sends unexpected data?
> > >
> > > If we detected that all data was received, and we get
> > > unexpected data, why not fail immediately?
> > >
> > > cmd->data_seen += length
> > > if (cmd->data_seen > cmd->count)
> > > switch to dead state?
> >
> > Switching immediately to a dead state is also possible, but it's nice
> > to try and keep the connection alive as long as we can with a nice
> > diagnosis of a failed CMD_READ but still allow further commands,
> > rather than an abrupt disconnect that takes out all other use of the
> > server.
>
> I agree, this is better.
>
> Reviewed-by: Nir Soffer <nsoffer at redhat.com>
I've pushed this one as edd8f5c; the rest of the series will be
tweaked and posted as v2.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
More information about the Libguestfs
mailing list