On Tue, Mar 17, 2020 at 06:59:09AM -0500, Eric Blake wrote:
 On 3/17/20 3:12 AM, Richard W.M. Jones wrote:
 >On Mon, Mar 16, 2020 at 10:36:15PM -0500, Eric Blake wrote:
 >>Although nbdkit documents that any positive value should be treated as
 >>success to the .can_* callbacks, we had a window of releases where
 >>anything other than 1 could trigger an assertion failure, fixed in the
 >>previous patch.  Update what we return to avoid tripping the bug in
 >>broken nbdkit.
 >>
 >>Our return value has been latent since 0e8e8eb11d (v1.1.17), but the
 >>assertion failures did not occur until c306fa93ab and neighboring
 >>commits (v1.15.1).  As v1.13.6 was the point where we started
 >>preferring builds against libnbd, where we always returned 1 on
 >>success, the problem was not detected until now; but it is still in
 >>the wild for any user mixing old plugins with new libnbd.
 >>
 >>Signed-off-by: Eric Blake <eblake(a)redhat.com>
 >>---
 >>  plugins/nbd/nbd-standalone.c | 12 ++++++------
 >>  1 file changed, 6 insertions(+), 6 deletions(-)
 
 >While I don't like the idea of modifying plugins to fix broken nbdkit
 >behaviour, you make a good case for this being safer, so:
 >
 >ACK
 
 Think of it as working around broken nbdkit behavior, rather than
 fixing it (as the fix is in patch 1/4).  How many stable branches
 should we backport this to?  Going all the way back to stable-1.2
 seems like it might be overkill; maybe back to stable-1.14 (where
 nbd-standalone was first split off) or stable-1.12 (the last release
 that did not use libnbd) is sufficient? 
I'm routinely backporting only to 1.16 and 1.18.
And then backporting to other branches only as-needed.  For example I
backported something to 1.4 yesterday, but that was only because I was
trying to check for a bug which had been reported against 1.4 and I
needed the backport to make the branch compile on a modern distro.
By the way I'm happy to do these cherry picks (just for 1.16 and 1.18)
because I find it helps me to keep the commits in their original order
so I know which ones have been applied and which ones have been
skipped.  Unless there is tooling which does this, which I've
occasionally looked for but never found.
Rich.
-- 
Richard Jones, Virtualization Group, Red Hat 
http://people.redhat.com/~rjones
Read my programming and virtualization blog: 
http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html