On 10/14/2016 08:10 PM, Dmitry Vyukov wrote: > If user sets panic_on_warn, he wants kernel to panic if there is > anything barely wrong with the kernel. KASAN-detected errors > are definitely not less benign than an arbitrary kernel WARNING. > > Panic after KASAN errors if panic_on_warn is set. > > We use this for continuous fuzzing where we want kernel to stop > and reboot on any error. > > Signed-off-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > Cc: kasan-dev@xxxxxxxxxxxxxxxx > Cc: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx> > Cc: Alexander Potapenko <glider@xxxxxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: linux-mm@xxxxxxxxx > Cc: linux-kernel@xxxxxxxxxxxxxxx > --- > mm/kasan/report.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c > index 24c1211..ca0bd48 100644 > --- a/mm/kasan/report.c > +++ b/mm/kasan/report.c > @@ -133,6 +133,10 @@ static void kasan_end_report(unsigned long *flags) > pr_err("==================================================================\n"); > add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE); > spin_unlock_irqrestore(&report_lock, *flags); > + if (panic_on_warn) { > + panic_on_warn = 0; Why we need to reset panic_on_warn? I assume this was copied from __warn(). AFAIU in __warn() this protects from recursion: __warn() -> painc() ->__warn() -> panic() -> ... which is possible if WARN_ON() triggered in panic(). But KASAN is protected from such recursion via kasan_disable_current(). > + panic("panic_on_warn set ...\n"); > + } > kasan_enable_current(); > } > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>