On Wed, 24 Nov 2021 at 19:06, Marco Elver <elver@xxxxxxxxxx> wrote: > > On Wed, 24 Nov 2021 at 18:41, Jiri Kosina <jikos@xxxxxxxxxx> wrote: > > > > From: Jiri Kosina <jkosina@xxxxxxx> > > > > The typical KASAN report always begins with > > > > BUG: KASAN: .... > > > > in kernel log. That 'BUG:' prefix creates a false impression that it's an > > actual BUG() codepath being executed, and as such things like > > 'panic_on_oops' etc. would work on it as expected; but that's obviously > > not the case. > > > > Switch the order of prefixes to make this distinction clear and avoid > > confusion. > > > > Signed-off-by: Jiri Kosina <jkosina@xxxxxxx> > > I'm afraid writing "KASAN: BUG: " doesn't really tell me this is a > non-BUG() vs. "BUG: KASAN". Using this ordering ambiguity to try and > resolve human confusion just adds more confusion. > > The bigger problem is a whole bunch of testing tools rely on the > existing order, which has been like this for years -- changing it now > just adds unnecessary churn. For example syzkaller, which looks for > "BUG: <tool>: report". > > Changing the order would have to teach all kinds of testing tools to > look for different strings. The same format is also used by other > dynamic analysis tools, such as KCSAN, and KFENCE, for the simple > reason that it's an established format and testing tools don't need to > be taught new tricks. Yes, lots of kernel testing systems may be looking just for "BUG:" and start missing KASAN bugs. Or they may be doing more special things when they see the current "BUG: KASAN:". > Granted, there is a subtle inconsistency wrt. panic_on_oops, in that > the debugging tools do use panic_on_warn instead, since their > reporting behaviour is more like a WARN. But I'd also not want to > prefix them with "WARNING" either, since all reports are serious bugs > and shouldn't be ignored. KASAN has more fine-grained control on when > to panic, see Documentation/dev-tools/kasan.rst. > > If the problem is potentially confusing people, I think the better > solution is to simply document all kernel error reports and their > panic-behaviour (and flags affecting panic-behaviour) in a central > place in Documentation/. > > Thanks, > -- Marco
