search for: c306fa93ab

...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. > >...

...standalone nbd plugin prior to the use of libnbd in v1.14. But in > 1.15.1, we added an assert in our backend code if an enabled feature > bit is not exactly 1. To avoid tripping the assertion, we have to > normalize the plugin values before storing our internal value. > > Fixes: c306fa93ab > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > server/plugins.c | 24 ++++++++++++++++-------- > 1 file changed, 16 insertions(+), 8 deletions(-) > > diff --git a/server/plugins.c b/server/plugins.c > index 78ed6723..4a4fcdee 100644 > --- a/server/plugins.c...

...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 plug...

...s, 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 <...

...g 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 lib...

...s behavior, including the standalone nbd plugin prior to the use of libnbd in v1.14. But in 1.15.1, we added an assert in our backend code if an enabled feature bit is not exactly 1. To avoid tripping the assertion, we have to normalize the plugin values before storing our internal value. Fixes: c306fa93ab Signed-off-by: Eric Blake <eblake@redhat.com> --- server/plugins.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/server/plugins.c b/server/plugins.c index 78ed6723..4a4fcdee 100644 --- a/server/plugins.c +++ b/server/plugins.c @@ -1,5 +1,5 @@...

Either patch 1 or patch 2 in isolation is sufficient to fix the problem that Rich forwarded on from an archlinux tester (name so I can credit them?). But both patches should be applied, as well as backported to appropriate stable branches, to maximize cross-version interoperability of nbdkit vs. plugins. Patch 3 will let us detect future similar bugs much faster. I want patch 4 to ensure that

In commit c306fa93ab and neighbors (v1.15.1), a concerted effort went into caching the results of .can_FOO callbacks, with commit messages demonstrating that a plugin with a slow callback should not have that delay magnified multiple times. But nothing was added to the testsuite at the time, and with the sh and eval p...

When I added .can_FOO caching in 1.16, I missed the case that the sh plugin itself was calling .can_flush twice in some situations (in order to default .can_fua). Then right after, I regressed it to call .can_zero twice (in order to default .can_fast_zero). I also missed that .thread_model could use better caching, because at the time, I did not add testsuite coverage. Fix that now. Eric Blake

On 3/18/20 8:21 PM, Eric Blake wrote: > In commit c306fa93ab and neighbors (v1.15.1), a concerted effort went > into caching the results of .can_FOO callbacks, with commit messages > demonstrating that a plugin with a slow callback should not have that > delay magnified multiple times. But nothing was added to the > testsuite at the time, and wi...