[Libguestfs] [PATCH nbdkit 2/2] server: Zero the read buffer before passing it to plugin .pread method.

Eric Blake eblake at redhat.com
Tue Apr 23 13:45:04 UTC 2019


On 4/23/19 8:34 AM, Richard W.M. Jones wrote:
> I agree we should only be zeroing this buffer on NBD_CMD_READ, so the
> patch is wrong as it stands.
> 
> Having an "I promise not to be bad!" flag I think just adds more
> complexity to plugins.  It would be nice to do the best thing
> automatically.
> 
> If we have a per-thread buffer then we're still (potentially) leaking
> data between clients, even if that data only consists of previously
> read data from another part of the disk.  However this does seem like
> the least bad approach since (a) we're not leaking random heap data
> like secret keys and (b) we don't need to make the plugin API any more
> complicated.  I'll see how easy this is to implement ...

Right now, we're firing up separate threads for separate clients - a
given thread is only reused by a single client.  (Observe a trace of the
file module with two simultaneous clients - our default of spawning 16
threads per connection means 32 helper threads are active at once when
there are two clients).

Of course, if we DO switch to a smarter thread-pooling approach (where
we put a ceiling of at most 16 outstanding requests from a given client,
but only add threads as we actually get enough parallel requests), then
we may indeed start having to worry about reusing a thread to service
requests from more than one client.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190423/ad17480c/attachment.sig>


More information about the Libguestfs mailing list