[Libguestfs] [libnbd PATCH] copy: Fail nbdcopy if NBD read or write fails

Eric Blake eblake at redhat.com
Fri Feb 4 13:13:23 UTC 2022


On Fri, Feb 04, 2022 at 09:31:19AM +0100, Laszlo Ersek wrote:
> On 02/03/22 15:12, Eric Blake wrote:
> > On Thu, Feb 03, 2022 at 02:46:27PM +0200, Nir Soffer wrote:
> 
> >> So we would use fprintf and strerror, and setting errno would be needed
> >> although it can be used with %m (is it portable?).
> > 
> > %m is not portable in *printf(3).  It IS portable in syslog(3), which
> > is why glibc printf(3) supports %m as well; and in nbdkit, we use a
> > printf wrapper on non-glibc to give unconditional %m support to nbdkit
> > plugins.  But we do not have that printf wrapper here.  Using
> > strerror() instead of perror() is doable in applications (we shouldn't
> > do it directly in libnbd since strerror() has multi-threaded
> > implications and we don't control what the application may be doing in
> > other threads, but in nbdcopy we control the entire application).
> 
> Side topic: what do we think about strerror_r()?

The glibc and POSIX signatures differ, making it a pain to use
portably.  Gnulib has LGPLv2+ wrappers that work around that, but we
can't use gnulib in nbdkit, and libnbd has (so far) been able to cope
without needing a dependency on gnulib.

I also seem to recall that we haven't audited nbdkit for unsafe uses
of strerror and strerror_r, partly because it is relatively
unrewarding grunt work.

> 
> ... Hmmm I recall something... Yep: we now have guestfs_int_strerror()
> in the libguestfs-common project at least.
> 
> (We cannot just copy it over I think, due to licence differences;
> however, with Rich having authored commit 9ec7cd8e23b5 ("utils: Fix
> usage of strerror_r", 2021-12-09), Red Hat seems to "own the copyright
> on that function" (if this statement makes any sense), so we could
> "relicense" it.)

Yes, that is an option, if we decide that it is time to perform that
audit (but it is not my highest priority at the moment).

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




More information about the Libguestfs mailing list