On 201220 0256, Qiuhao Li wrote:
> Since programmers usually trigger an IO just before they need it. Try to
> delay some IO instructions may help us better understanding the timing
> context when debug.
>
> Tested with Bug 1908062. Refined vs. Original result:
>
> outl 0xcf8 0x8000081c outl 0xcf8 0x0
> outb 0xcfc 0xc3 | outl 0xcf8 0x8000081c
> outl 0xcf8 0x80000804 | outb 0xcfc 0xc3
> outl 0xcfc 0x10000006 | outl 0xcf8 0x80000804
> write 0xc300001028 0x1 0x5a | outl 0xcfc 0x10000006
> write 0xc300001024 0x2 0x10 | write 0xc300001028 0x1 0x5a
> write 0xc30000101c 0x1 0x01 | writel 0xc30000100c 0x2a6f6c63
> write 0xc300003002 0x1 0x0 v write 0xc300001024 0x2 0x10
> write 0x5c 0x1 0x10 write 0xc30000101c 0x1 0x01
> writel 0xc30000100c 0x2a6f6c63 write 0xc300001018 0x1 0x80
> write 0xc300001018 0x1 0x80 write 0x5c 0x1 0x10
> outl 0xcf8 0x0 write 0xc300003002 0x1 0x0
>
In this example, I can remove the outl 0xcf8 0x0, and I still see the
crash, so maybe the 1st step in the minimizer is failing somewhere..
Is the Refined one better? To me the original one read as:
"Do a bunch of PCI configuration to map an MMIO BAR, then interact with
the MMIO range and trigger some DMA activity". I also know exactly the
line that will trigger the DMA activity and access 0x5c. With the
refined one, I'm not so sure. Which line now causes the DMA read from
0x5c? writel 0xc30000100c? write 0xc300001018?
Is there another example where this type of reordering makes the result
easier to read?
> Signed-off-by: Qiuhao Li <qiuhao...@outlook.com>
> ---
> scripts/oss-fuzz/minimize_qtest_trace.py | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/scripts/oss-fuzz/minimize_qtest_trace.py
> b/scripts/oss-fuzz/minimize_qtest_trace.py
> index f3e88064c4..da7aa73b3c 100755
> --- a/scripts/oss-fuzz/minimize_qtest_trace.py
> +++ b/scripts/oss-fuzz/minimize_qtest_trace.py
> @@ -214,6 +214,27 @@ def minimize_trace(inpath, outpath):
>
> assert(check_if_trace_crashes(newtrace, outpath))
>
> + # delay IO instructions until they can't trigger the crash
> + # Note: O(n^2) and many timeouts, kinda slow
Maybe do a binary search instead of a linear scan for the optimal position
to save some time?
Also, if you re-run this multiple times, you can end up with different
results, since some lines might not really be tied to a position (e.g.
the outl cf8 0x0 in your example). Maybe it's not a problem, but i'm
still not sure that this is making the result easier to read.
-Alex
> + i = len(newtrace) - 1
> + while i >= 0:
> + tmp_i = newtrace[i]
> + if len(tmp_i) < 2:
> + i -= 1
> + continue
> + print("Delaying ", newtrace[i])
> + for j in reversed(range(i+1, len(newtrace)+1)):
> + newtrace.insert(j, tmp_i)
> + del newtrace[i]
> + if check_if_trace_crashes(newtrace, outpath):
> + break
> + newtrace.insert(i, tmp_i)
> + del newtrace[j]
> + i -= 1
> +
> + assert(check_if_trace_crashes(newtrace, outpath))
> + # maybe another removing round
> +
>
> if __name__ == '__main__':
> if len(sys.argv) < 3:
> --
> 2.25.1
>
