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

From: Marco Elver <elver@google.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	kasan-dev@googlegroups.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, jslaby@suse.cz
Subject: Re: [PATCH] kasan: distinguish kasan report from generic BUG()
Date: Wed, 24 Nov 2021 19:06:22 +0100	[thread overview]
Message-ID: <CANpmjNOHN7SWu-pKGr9EBb3=in2AWiGmqNb6sYwhebGtRk+1uQ@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.2111241839590.16505@cbobk.fhfr.pm>

On Wed, 24 Nov 2021 at 18:41, Jiri Kosina <jikos@kernel.org> wrote:
>
> From: Jiri Kosina <jkosina@suse.cz>
>
> 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@suse.cz>

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.

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