On Mon, Oct 17, 2016 at 10:13 AM, Andrey Ryabinin <aryabi...@virtuozzo.com> wrote: > > > 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 <dvyu...@google.com> >> Cc: kasan-...@googlegroups.com >> Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> >> Cc: Alexander Potapenko <gli...@google.com> >> Cc: Andrew Morton <a...@linux-foundation.org> >> Cc: linux...@kvack.org >> Cc: linux-kernel@vger.kernel.org >> --- >> 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().
But we have recursion into panic via kasan->panic->warning->panic. Am I missing something? >> + panic("panic_on_warn set ...\n"); >> + } >> kasan_enable_current(); >> }