On 04/19/2018 12:26 PM, Richard W.M. Jones wrote:
On Wed, Apr 11, 2018 at 12:03:40AM -0500, Eric Blake wrote:
> Adjust internal functions in preparation for FUA support; although
> at this point, the default plugins.c can_fua implementation
> correctly reports python as needing emulation, and we can assert
> that we aren't seeing a FUA flag.
>
> Signed-off-by: Eric Blake <eblake(a)redhat.com>
> ---
> plugins/python/python.c | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> static int
> py_pread (void *handle, void *buf,
> - uint32_t count, uint64_t offset)
> + uint32_t count, uint64_t offset, uint32_t flags)
> {
> PyObject *obj = handle;
> PyObject *fn;
> PyObject *r;
>
> + assert (!flags);
I'm confused by the assertions here (I understand that these are
relaxed in the next patch, but still present).
Shouldn't this return an error instead of segfaulting the daemon?
If the daemon passes us a flag we don't know how to handle, that's a bug
in the daemon and should cause an assert (we can't tell if the flag
would require us to support semantics we are unprepared for). That is,
in order to abide by our C ABI back-compat rules, a newer daemon can
support newer flags, but in doing so, must NOT hand those flags to an
older plugin; nbdkit-plugin.pod even guarantees the condition under
which flags will be passed to the plugin (where violating those
guarantees is a bug in the daemon, not the plugin); the filters are
under similar rules to follow the same rules as the daemon about which
flags are safe to pass.
Do we assume that the nbdkit python plugin is special because you're
basically always running the version that ships with the daemon?
No, you can run a newer nbdkit with an older python plugin without
issues, again, because the burden is on the daemon and not on the
plugin, when it comes to not handing unexpected flags to the plugin.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org