<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Richard,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Some more queries below.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 7, 2019 at 11:36 PM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.com" target="_blank">rpalethorpe@suse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Allows one to run the Syzkaller reproducers as part of the LTP.<br>
<br>
<span class="gmail_default" style="font-size:small">...</span><br>
<br>
+AC_ARG_WITH([syzkaller-repros],<br>
+ [AC_HELP_STRING([--with-syzkaller-repros],<br>
+ [compile and install Syzkaller reproducers (default=no)])],<br>
+ [with_syzkaller_repros=$withval]<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">To strictly, the [action-if-not-given] should be added too?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+)<br>
+if test "x$with_syzkaller_repros" = xyes; then<br>
+ AC_SUBST([WITH_SYZKALLER_REPROS],["yes"])<br>
+else<br>
+ AC_SUBST([WITH_SYZKALLER_REPROS],["no"])<br>
+fi<br>
<span class="gmail_default" style="font-size:small">...</span><br>
diff --git a/runtest/.gitignore b/runtest/.gitignore<br>
new file mode 100644<br>
index 000000000..2ae05bfac<br>
--- /dev/null<br>
+++ b/runtest/.gitignore<br>
@@ -0,0 +1 @@<br>
+syzkaller*<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Why adding syzkaller* in here?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
diff --git a/testcases/kernel/Makefile b/testcases/kernel/Makefile<br>
index 3319b3163..0150cfb4f 100644<br>
--- a/testcases/kernel/Makefile<br>
+++ b/testcases/kernel/Makefile<br>
@@ -53,6 +53,7 @@ SUBDIRS += connectors \<br>
sched \<br>
security \<br>
sound \<br>
+ syzkaller-repros \<br>
tracing \<br>
uevents \<br>
<br>
diff --git a/testcases/kernel/syzkaller-repros/.gitignore b/testcases/kernel/syzkaller-repros/.gitignore<br>
new file mode 100644<br>
index 000000000..dbda1c71f<br>
--- /dev/null<br>
+++ b/testcases/kernel/syzkaller-repros/.gitignore<br>
@@ -0,0 +1 @@<br>
+syzwrap<br>
diff --git a/testcases/kernel/syzkaller-repros/Makefile b/testcases/kernel/syzkaller-repros/Makefile<br>
new file mode 100644<br>
<span class="gmail_default" style="font-size:small">...</span><br>
+# Some useful compiler flags for the LTP will cause problems with the<br>
+# syzkaller repros so the repros have seperate flags<br>
+SYZKALLER_CFLAGS ?= -pthread<br>
+SYZKALLER_REPROS = $(subst $(abs_top_srcdir),$(abs_top_builddir),$(SYZKALLER_REPROS_SRCS:.c=))<br>
+$(SYZKALLER_REPROS): %: %.c<br>
+ -@if grep -q "__NR_mmap2" $^; then \<br>
+ M32="-m32"; \<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I got compiling errors on s390x:</div><div class="gmail_default" style="font-size:small"> gcc: error: unrecognized command line option ‘-m32’; did you mean ‘-m31’?</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My other concern is syzkaller (I guess maybe) have some package dependencies, and that will break the compiler phase on the embedded system.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail_default" style="font-size:small">....</span><br>
+ while (!waitpid(pid, &status, WNOHANG)) {<br>
+ rem = tst_timeout_remaining();<br>
+<br>
+ if (!sent_kill && rem / exec_time_start < 0.5) {<br>
+ tst_res(TINFO, "Timeout; killing reproducer");<br>
+<br>
+ TEST(kill(pid, SIGKILL));<br>
+ if (TST_RET == -1)<br>
+ tst_res(TWARN | TTERRNO, "kill() failed");<br>
+ else<br>
+ sent_kill = 1;<br>
+ }<br>
+<br>
+ usleep(backoff);<br>
+ backoff = MIN(2 * backoff, 1000000);<br>
+ }<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Force to kill a timeout test process is fine, but one thing makes me worried is that we don't do any cleanup work(e.g. release hugepage, devices or other resources) for the children, that very probably causes many additional issues in the next testing and not easy to reproduce it in a new run.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+<br>
+ if (tst_taint_check()) {<br>
+ tst_res(TFAIL, "Kernel is tainted");<br>
+ } else {<br>
+ tst_res(TPASS, "Kernel is not tainted");<br>
+ }</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">If this is the only condition to judge if all tests pass or not, we may miss some test failure logs after running, unless we don't care about that.</div><br></div><div><div class="gmail_default" style="font-size:small">Btw, I can't even finish one round for the test then system panic there. </div></div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>