[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