On Mon, Jun 18, 2018 at 6:43 AM, DaeRyong Jeong <
three...@gmail.com> wrote:
> Dear Dmitry Vyukov,
>
> This is Daeryong Jeong, working on RaceFuzzer at KAIST and Purdue University.
> We would like to first thank you for open-sourcing Syzkaller.
> We have learned a lot from Syzkaller and our RaceFuzzer is in fact
> developed based on Syzkaller.
>
> While we are working on RaceFuzzer, we found many race issues seem to
> be related to kernel threads handling irq/softirq/kworker
> ---i.e., at least one of two racing threads is not spawned due to the
> syscall but spawned due to the interrupt (or softirq queue popping).
> Here, our goal is to automatically figure out the root cause of such
> races (i.e., pinpoint racing instructions in the kernel).
>
> We would like to ask if you have observed any race issues in this category.
> If so, would you please point those bugs (it would be the best if it
> is a link to
https://syzkaller.appspot.com/)?
+syzkaller and ktsan mailing lists
Hi Daeryong,
Thank you.
I don't have a ready list of such bugs. I definitely saw lots of bugs
caused by races, but I am not sure what percent of them involved
interrupts.
One easy way to locate them is to look for use-after-free bugs with
use and free stacks in different tasks/interrupts.
Another indication of races is threaded reproducers, however, of
course, it does not mean that they involve interrupts.
Btw, are you aware of KTSAN? It a kernel data race detector, as far as
I remember it is capable of detecting races between a task and
interrupt too:
https://github.com/google/ktsan/wiki
--
Dmitry Vyukov
All about lockfree/waitfree algorithms, multicore, scalability,
parallel computing and related topics:
http://www.1024cores.net