Re: [PATCH] kasan: distinguish kasan report from generic BUG()

[Dmitry Vyukov]

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