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 specific operation takes a long time. Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> |
||
---|---|---|
.. | ||
fork_fuzz.c | ||
fork_fuzz.h | ||
fork_fuzz.ld | ||
fuzz.c | ||
fuzz.h | ||
generic_fuzz.c | ||
generic_fuzz_configs.h | ||
i440fx_fuzz.c | ||
meson.build | ||
qos_fuzz.c | ||
qos_fuzz.h | ||
qtest_wrappers.c | ||
virtio_blk_fuzz.c | ||
virtio_net_fuzz.c | ||
virtio_scsi_fuzz.c |