Messages in this thread | | | From | Marco Elver <> | Date | Tue, 8 Feb 2022 01:10:57 +0100 | Subject | Re: BUG: KCSAN: data-race in add_device_randomness+0x20d/0x290 |
| |
On Mon, 7 Feb 2022 at 22:49, Jann Horn <jannh@google.com> wrote: > +KCSAN people > > On Mon, Feb 7, 2022 at 7:42 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Thanks for the report. I assume that this is actually an old bug. Do > > you have a vmlinux or a random.o from this kernel you could send me to > > double check? Without that, my best guess, which I'd say I have > > relatively high confidence about, > > Maybe KCSAN should go through the same instruction-bytes-dumping thing > as normal BUG() does? That might be helpful for cases like this...
A BUG() on x86 actually generates a ud2, and somewhere along the way it uses pt_regs in show_opcodes(). Generating KCSAN stack traces is very different, and there's no pt_regs because it's going through compiler instrumentation.
In general, I wouldn't spend much time on one-sided non-symbolized KCSAN reports, unless it's obvious what's going on. I've been thinking of making CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n the default, because the one-sided race reports are not very useful. We need to see what we're racing against. With the normal reports where both threads' stack traces are shown it's usually much easier to narrow down what's happening even in the absence of symbolized stack traces.
My suggestion would be to try and get a normal "2-sided" data race report.
I also haven't found something similar in my pile of data race reports sitting in syzbot moderation.
Jason - if you're interested in KCSAN data race reports in some subsystems you maintain (I see a few in Wireguard), let me know, and I'll release them from syzbot's moderation queue. The way we're trying to do it with KCSAN is that we pre-moderate and ask maintainers if they're happy to be forwarded all reports that syzbot finds (currently some Networking and RCU, though the latter finds almost all data races via KCSAN-enabled rcutorture).
Thanks, -- Marco
| |