Messages in this thread | | | From | Marco Elver <> | Date | Tue, 8 Feb 2022 01:12:56 +0100 | Subject | Re: BUG: KCSAN: data-race in add_device_randomness+0x20d/0x290 |
| |
On Tue, 8 Feb 2022 at 01:10, Marco Elver <elver@google.com> wrote: > > 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
(That should have been KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=n ... copy-paste error.)
> 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
| |