On Wed, 24 Nov 2021 at 22:20, <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > The patch titled > Subject: kasan: distinguish kasan report from generic BUG() > has been added to the -mm tree. Its filename is > kasan-distinguish-kasan-report-from-generic-bug.patch > > This patch should soon appear at > https://ozlabs.org/~akpm/mmots/broken-out/kasan-distinguish-kasan-report-from-generic-bug.patch > and later at > https://ozlabs.org/~akpm/mmotm/broken-out/kasan-distinguish-kasan-report-from-generic-bug.patch > > Before you just go and hit "reply", please: > a) Consider who else should be cc'ed > b) Prefer to cc a suitable mailing list as well > c) Ideally: find the original patch on the mailing list and do a > reply-to-all to that, adding suitable additional cc's > > *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** > > The -mm tree is included into linux-next and is updated > there every 3-4 working days > > ------------------------------------------------------ > From: Jiri Kosina <jkosina@xxxxxxx> > Subject: kasan: distinguish kasan report from generic BUG() > > 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. > > Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.2111241839590.16505@xxxxxxxxxxxxx > Signed-off-by: Jiri Kosina <jkosina@xxxxxxx> > Cc: Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx> > Cc: Alexander Potapenko <glider@xxxxxxxxxx> > Cc: Andrey Konovalov <andreyknvl@xxxxxxxxx> > Cc: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > Cc: Jiri Slaby <jirislaby@xxxxxxxxxx> > Cc: Marco Elver <elver@xxxxxxxxxx> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Oh dear, I don't think we were ready -- this patch would cause all kinds of issues: https://lkml.kernel.org/r/CANpmjNOHN7SWu-pKGr9EBb3=in2AWiGmqNb6sYwhebGtRk+1uQ@xxxxxxxxxxxxxx Apart from the high-level issues, it'd come with a long-tail of other cleanups that are missing (docs, other tools, etc.) -- at the latest, doing those would show that this change is a bad idea, and its subjective improvements weighs against a real cost of long-tail changes, changes that might mean tools, scripts, people, might miss real bugs. I would much rather see a central place in Documentation/ ("error-reports.rst"?) list the various errors one could see, incl. their panic behaviour and flags. Thanks, -- Marco