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 <[email protected]>
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 _______________________________________________ Libguestfs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/libguestfs
