993f52f4d4
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_configs.h | ||
| generic_fuzz.c | ||
| 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 | ||