qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Darren Kenny <darren.kenny@oracle.com>
To: Alexander Bulekov <alxndr@bu.edu>, qemu-devel@nongnu.org
Cc: "Laurent Vivier" <lvivier@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Alexander Bulekov" <alxndr@bu.edu>,
	"Bandan Das" <bsd@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH v3 1/4] fuzz: adjust timeout to allow for longer inputs
Date: Thu, 24 Jun 2021 10:23:10 +0100	[thread overview]
Message-ID: <m28s2zk45d.fsf@oracle.com> (raw)
In-Reply-To: <20210624034503.86256-2-alxndr@bu.edu>

On Wednesday, 2021-06-23 at 23:45:00 -04, Alexander Bulekov wrote:
> Using a custom timeout is useful to continue fuzzing complex devices,
> even after we run into some slow code-path. However, simply adding a
> fixed timeout to each input effectively caps the maximum input
> length/number of operations at some artificial value. There are two
> major problems with this:
> 1. Some code might only be reachable through long IO sequences.
> 2. Longer inputs can actually be _better_ for performance. While the
>    raw number of fuzzer executions decreases with larger inputs, the
>    number of MMIO/PIO/DMA operation/second actually increases, since
>    were are speding proportionately less time fork()ing.
>
> With this change, we keep the custom-timeout, but we renew it, prior to
> each MMIO/PIO/DMA operation. Thus, we time-out only when a particaly

TYPO: s/particaly/specific/ or s/particaly/particular/ ?

> operation takes a long time.
>
> Signed-off-by: Alexander Bulekov <alxndr@bu.edu>

Otherwise,

Reviewed-by: Darren Kenny <darren.kenny@oracle.com>

Thanks,

Darren.

> ---
>  tests/qtest/fuzz/generic_fuzz.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/tests/qtest/fuzz/generic_fuzz.c b/tests/qtest/fuzz/generic_fuzz.c
> index cea7d4058e..71d36e8f6f 100644
> --- a/tests/qtest/fuzz/generic_fuzz.c
> +++ b/tests/qtest/fuzz/generic_fuzz.c
> @@ -661,15 +661,16 @@ static void generic_fuzz(QTestState *s, const unsigned char *Data, size_t Size)
>      uint8_t op;
>  
>      if (fork() == 0) {
> +        struct sigaction sact;
> +        struct itimerval timer;
>          /*
>           * Sometimes the fuzzer will find inputs that take quite a long time to
>           * process. Often times, these inputs do not result in new coverage.
>           * Even if these inputs might be interesting, they can slow down the
> -         * fuzzer, overall. Set a timeout to avoid hurting performance, too much
> +         * fuzzer, overall. Set a timeout for each command to avoid hurting
> +         * performance, too much
>           */
>          if (timeout) {
> -            struct sigaction sact;
> -            struct itimerval timer;
>  
>              sigemptyset(&sact.sa_mask);
>              sact.sa_flags   = SA_NODEFER;
> @@ -679,13 +680,17 @@ static void generic_fuzz(QTestState *s, const unsigned char *Data, size_t Size)
>              memset(&timer, 0, sizeof(timer));
>              timer.it_value.tv_sec = timeout / USEC_IN_SEC;
>              timer.it_value.tv_usec = timeout % USEC_IN_SEC;
> -            setitimer(ITIMER_VIRTUAL, &timer, NULL);
>          }
>  
>          op_clear_dma_patterns(s, NULL, 0);
>          pci_disabled = false;
>  
>          while (cmd && Size) {
> +            /* Reset the timeout, each time we run a new command */
> +            if (timeout) {
> +                setitimer(ITIMER_VIRTUAL, &timer, NULL);
> +            }
> +
>              /* Get the length until the next command or end of input */
>              nextcmd = memmem(cmd, Size, SEPARATOR, strlen(SEPARATOR));
>              cmd_len = nextcmd ? nextcmd - cmd : Size;
> -- 
> 2.28.0


  reply	other threads:[~2021-06-24  9:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24  3:44 [PATCH v3 0/4] Miscellaneous fuzzer changes Alexander Bulekov
2021-06-24  3:45 ` [PATCH v3 1/4] fuzz: adjust timeout to allow for longer inputs Alexander Bulekov
2021-06-24  9:23   ` Darren Kenny [this message]
2021-06-24  3:45 ` [PATCH v3 2/4] fuzz: add an instrumentation filter Alexander Bulekov
2021-06-24  8:03   ` Philippe Mathieu-Daudé
2021-06-24  3:45 ` [PATCH v3 3/4] fuzz: fix the AC97 generic-fuzzer config Alexander Bulekov
2021-06-24  9:18   ` Darren Kenny
2021-06-24  3:45 ` [PATCH v3 4/4] fuzz: fix the ES1370 " Alexander Bulekov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m28s2zk45d.fsf@oracle.com \
    --to=darren.kenny@oracle.com \
    --cc=alxndr@bu.edu \
    --cc=bsd@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).