All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: stable@vger.kernel.org,
	Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
	Kees Cook <keescook@chromium.org>, SeongJae Park <sj@kernel.org>,
	Seth Jenkins <sethjenkins@google.com>,
	Jann Horn <jannh@google.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Patricia Alfonso <trishalfonso@google.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Shuah Khan <shuah@kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	David Gow <davidgow@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrey Konovalov <andreyknvl@google.com>,
	Brendan Higgins <brendanhiggins@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 4.19 03/16] mm: kasan: do not panic if both panic_on_warn and kasan_multishot set
Date: Thu,  2 Feb 2023 19:37:20 +0000	[thread overview]
Message-ID: <20230202193720.168040-1-sj@kernel.org> (raw)
In-Reply-To: <20230202052604.179184-4-ebiggers@kernel.org>

On Wed, 1 Feb 2023 21:25:51 -0800 Eric Biggers <ebiggers@kernel.org> wrote:

> From: David Gow <davidgow@google.com>
> 
> commit be4f1ae978ffe98cc95ec49ceb95386fb4474974 upstream.
> 
> KASAN errors will currently trigger a panic when panic_on_warn is set.
> This renders kasan_multishot useless, as further KASAN errors won't be
> reported if the kernel has already paniced.  By making kasan_multishot
> disable this behaviour for KASAN errors, we can still have the benefits of
> panic_on_warn for non-KASAN warnings, yet be able to use kasan_multishot.
> 
> This is particularly important when running KASAN tests, which need to
> trigger multiple KASAN errors: previously these would panic the system if
> panic_on_warn was set, now they can run (and will panic the system should
> non-KASAN warnings show up).
> 
> Signed-off-by: David Gow <davidgow@google.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
> Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Juri Lelli <juri.lelli@redhat.com>
> Cc: Patricia Alfonso <trishalfonso@google.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> Link: https://lkml.kernel.org/r/20200915035828.570483-6-davidgow@google.com
> Link: https://lkml.kernel.org/r/20200910070331.3358048-6-davidgow@google.com
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  mm/kasan/report.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 5c169aa688fde..90fdb261a5e2d 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -176,7 +176,7 @@ 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)
> +	if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
>  		panic("panic_on_warn set ...\n");
>  	kasan_enable_current();


Seems this introduced a build failure when CONFIG_KASAN is enabled, as also
reported by Sasha[1].

    mm/kasan/report.c: In function ‘kasan_end_report’:
    mm/kasan/report.c:179:16: error: ‘KASAN_BIT_MULTI_SHOT’ undeclared (first use in this function)
      179 |  if (!test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
          |                ^~~~~~~~~~~~~~~~~~~~
    arch/x86/include/asm/bitops.h:342:25: note: in definition of macro ‘test_bit’
      342 |  (__builtin_constant_p((nr))  \
          |                         ^~
    mm/kasan/report.c:179:16: note: each undeclared identifier is reported only once for each function it appears in
      179 |  if (!test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
          |                ^~~~~~~~~~~~~~~~~~~~
    arch/x86/include/asm/bitops.h:342:25: note: in definition of macro ‘test_bit’
      342 |  (__builtin_constant_p((nr))  \
          |                         ^~
    mm/kasan/report.c:179:39: error: ‘kasan_flags’ undeclared (first use in this function)
      179 |  if (!test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
          |                                       ^~~~~~~~~~~
    arch/x86/include/asm/bitops.h:343:30: note: in definition of macro ‘test_bit’
      343 |   ? constant_test_bit((nr), (addr)) \
          |                              ^~~~

I confirmed dropping this patch fixes the build failure.  It causes a conflict
to a following patch[1], but seems it's not that difficult to resolve.  I
updated kernel/panic.c part of the patch like attached below to resolve the
conflict.

[1] https://lore.kernel.org/stable/Y9v3G6UantaCo29G@sashalap/
[2] https://lore.kernel.org/stable/20230202052604.179184-13-ebiggers@kernel.org/


Thanks,
SJ


================================ >8 ===========================================

diff --git a/kernel/panic.c b/kernel/panic.c
index a078d413042f..08b8adc55b2b 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -125,6 +125,12 @@ void nmi_panic(struct pt_regs *regs, const char *msg)
 }
 EXPORT_SYMBOL(nmi_panic);

+void check_panic_on_warn(const char *origin)
+{
+       if (panic_on_warn)
+               panic("%s: panic_on_warn set ...\n", origin);
+}
+
 /**
  *     panic - halt the system
  *     @fmt: The text string to print
@@ -540,8 +546,7 @@ void __warn(const char *file, int line, void *caller, unsigned taint,
        if (args)
                vprintk(args->fmt, args->args);

-       if (panic_on_warn)
-               panic("panic_on_warn set ...\n");
+       check_panic_on_warn("kernel");

        print_modules();


  reply	other threads:[~2023-02-02 19:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-02  5:25 [PATCH 4.19 00/16] Backport oops_limit to 4.19 Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 01/16] sysctl: add a new register_sysctl_init() interface Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 02/16] panic: unset panic_on_warn inside panic() Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 03/16] mm: kasan: do not panic if both panic_on_warn and kasan_multishot set Eric Biggers
2023-02-02 19:37   ` SeongJae Park [this message]
2023-02-02  5:25 ` [PATCH 4.19 04/16] exit: Add and use make_task_dead Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 05/16] objtool: Add a missing comma to avoid string concatenation Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 06/16] hexagon: Fix function name in die() Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 07/16] h8300: Fix build errors from do_exit() to make_task_dead() transition Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 08/16] ia64: make IA64_MCA_RECOVERY bool instead of tristate Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 09/16] exit: Put an upper limit on how often we can oops Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 10/16] exit: Expose "oops_count" to sysfs Eric Biggers
2023-02-02  5:25 ` [PATCH 4.19 11/16] exit: Allow oops_limit to be disabled Eric Biggers
2023-02-02  5:26 ` [PATCH 4.19 12/16] panic: Consolidate open-coded panic_on_warn checks Eric Biggers
2023-02-02  5:26 ` [PATCH 4.19 13/16] panic: Introduce warn_limit Eric Biggers
2023-02-02  5:26 ` [PATCH 4.19 14/16] panic: Expose "warn_count" to sysfs Eric Biggers
2023-02-02  5:26 ` [PATCH 4.19 15/16] docs: Fix path paste-o for /sys/kernel/warn_count Eric Biggers
2023-02-02  5:26 ` [PATCH 4.19 16/16] exit: Use READ_ONCE() for all oops/warn limit reads Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230202193720.168040-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=brendanhiggins@google.com \
    --cc=davidgow@google.com \
    --cc=dvyukov@google.com \
    --cc=ebiederm@xmission.com \
    --cc=ebiggers@kernel.org \
    --cc=harshit.m.mogalapalli@oracle.com \
    --cc=jannh@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sethjenkins@google.com \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=trishalfonso@google.com \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.