On 2/19/21 3:03 PM, Eric Blake wrote:
The readahead filter was blindly passing through the plugin's .can_multi_conn, but does not kill the readahead buffer on a flush. This is a bug in the following scenario, when the plugin advertised multi-conn:
In order to preserve the plugin's multi-conn status, we MUST drop our cache any time we flush, so that our next read picks up whatever got flushed from another connection.
But when the server lacks multi-conn, we don't have to kill our readahead buffer on flush, because the client already has no guarantee that a flush from one connection will affect the read seen by another (killing on write was already good enough to maintain semantics). ---
+static int +readahead_flush (struct nbdkit_next_ops *next_ops, void *nxdata, + void *handle, uint32_t flags, int *err) +{ + if (next_ops->can_multi_conn(nxdata) != 1)
That should be ==, to match my commit message.
+ kill_readahead (); + return next_ops->flush (nxdata, flags, err); +} +
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org