On Fri, Oct 07, 2022 at 10:22:57AM +0100, Richard W.M. Jones wrote:
On Thu, Oct 06, 2022 at 04:34:52PM -0500, Eric Blake wrote:
> Give the fuzzer a few more points to experiment with added branching
> by explicitly using opt mode.
> ---
>
> I'm not quite sure whether the fuzzer is able to synthesize specific
> API calls from the client side; but if it can, letting the client
> specifically enter the NEGOTIATING state may allow the fuzzer to spot
> other nbd_opt_* API call chains that could provoke odd interactions,
> which would be completely missed when sticking with the default of
> skipping opt mode.
It's essentially looking for new paths through the code. If the
change allows new libnbd paths to be explored then it will be
beneficial to fuzzing, if not then it'll make no difference. I have
no objection to trying the patch anyway, so ACK.
Ok, in as 8592caba
Thinking about ways to expose even more code-paths, I wonder if we
could tweak the client along the lines of:
if (rand () & 1)
nbd_set_handshake_flags (nbd, rand ());
if (rand () & 1)
nbd_set_strict_mode (nbd, rand ());
and so forth, to allow the fuzzer to explore different combinations of
settings. Another idea might be:
static void do_opt_structured_reply (void)
{ /* call nbd_opt_structured_reply() */ }
static void do_opt_list_meta_context (void)
{ /* call nbd_opt_list_meta_context[_queries]() */ }
...
void (*opts[])(void) = {
do_opt_structured_reply,
do_opt_list_meta_context,
...
};
for (i = rand () % 20; i > 0; i--)
opts[i % ARRAY_SIZE (opts)] ();
to play with different handshake sequences.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org