linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tiezhu Yang <yangtiezhu@loongson.cn>
To: Marco Elver <elver@google.com>
Cc: Baoquan He <bhe@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	kexec@lists.infradead.org, linux-doc@vger.kernel.org,
	kasan-dev@googlegroups.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] sched: unset panic_on_warn before calling panic()
Date: Sun, 30 Jan 2022 08:29:08 +0800	[thread overview]
Message-ID: <0e700c2c-8523-ebc3-f006-e463f1fb7d0f@loongson.cn> (raw)
In-Reply-To: <CANpmjNPYYAy2jy_U_c7QjTsco6f1Hk2q=HP34di4YRMgdKsa+g@mail.gmail.com>



On 1/28/22 19:52, Marco Elver wrote:
> On Fri, 28 Jan 2022 at 12:42, Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>>
>> As done in the full WARN() handler, panic_on_warn needs to be cleared
>> before calling panic() to avoid recursive panics.
>>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
>> ---
>>   kernel/sched/core.c | 11 ++++++++++-
>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 848eaa0..f5b0886 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -5524,8 +5524,17 @@ static noinline void __schedule_bug(struct task_struct *prev)
>>                  pr_err("Preemption disabled at:");
>>                  print_ip_sym(KERN_ERR, preempt_disable_ip);
>>          }
>> -       if (panic_on_warn)
>> +
>> +       if (panic_on_warn) {
>> +               /*
>> +                * This thread may hit another WARN() in the panic path.
>> +                * Resetting this prevents additional WARN() from panicking the
>> +                * system on this thread.  Other threads are blocked by the
>> +                * panic_mutex in panic().
>> +                */
>> +               panic_on_warn = 0;
>>                  panic("scheduling while atomic\n");
> 
> I agree this is worth fixing.
> 
> But: Why can't the "panic_on_warn = 0" just be moved inside panic(),
> instead of copy-pasting this all over the place?

OK, it looks better.

Let me wait for some days, if no more comments, I will send v2
to move "panic_on_warn = 0" inside panic() and remove it from
the other places, like this:

diff --git a/kernel/panic.c b/kernel/panic.c
index 55b50e052ec3..95ba825522dd 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -185,6 +185,16 @@ void panic(const char *fmt, ...)
         int old_cpu, this_cpu;
         bool _crash_kexec_post_notifiers = crash_kexec_post_notifiers;

+       if (panic_on_warn) {
+               /*
+                * This thread may hit another WARN() in the panic path.
+                * Resetting this prevents additional WARN() from 
panicking the
+                * system on this thread.  Other threads are blocked by the
+                * panic_mutex in panic().
+                */
+               panic_on_warn = 0;
+       }
+
         /*
          * Disable local interrupts. This will prevent panic_smp_self_stop
          * from deadlocking the first cpu that invokes the panic, since
@@ -576,16 +586,8 @@ void __warn(const char *file, int line, void 
*caller, unsigned taint,
         if (regs)
                 show_regs(regs);

-       if (panic_on_warn) {
-               /*
-                * This thread may hit another WARN() in the panic path.
-                * Resetting this prevents additional WARN() from 
panicking the
-                * system on this thread.  Other threads are blocked by the
-                * panic_mutex in panic().
-                */
-               panic_on_warn = 0;
+       if (panic_on_warn)
                 panic("panic_on_warn set ...\n");
-       }

         if (!regs)
                 dump_stack();
diff --git a/lib/ubsan.c b/lib/ubsan.c
index bdc380ff5d5c..36bd75e33426 100644
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -154,16 +154,8 @@ static void ubsan_epilogue(void)

         current->in_ubsan--;

-       if (panic_on_warn) {
-               /*
-                * This thread may hit another WARN() in the panic path.
-                * Resetting this prevents additional WARN() from 
panicking the
-                * system on this thread.  Other threads are blocked by the
-                * panic_mutex in panic().
-                */
-               panic_on_warn = 0;
+       if (panic_on_warn)
                 panic("panic_on_warn set ...\n");
-       }
  }

  void __ubsan_handle_divrem_overflow(void *_data, void *lhs, void *rhs)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 3ad9624dcc56..f14146563d41 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -117,16 +117,8 @@ static void end_report(unsigned long *flags, 
unsigned long addr)
 
pr_err("==================================================================\n");
         add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
         spin_unlock_irqrestore(&report_lock, *flags);
-       if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT, 
&kasan_flags)) {
-               /*
-                * This thread may hit another WARN() in the panic path.
-                * Resetting this prevents additional WARN() from 
panicking the
-                * system on this thread.  Other threads are blocked by the
-                * panic_mutex in panic().
-                */
-               panic_on_warn = 0;
+       if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
                 panic("panic_on_warn set ...\n");
-       }
         if (kasan_arg_fault == KASAN_ARG_FAULT_PANIC)
                 panic("kasan.fault=panic set ...\n");
         kasan_enable_current();

Thanks,
Tiezhu

> 
> I may be missing something obvious why this hasn't been done before...
> 
> Thanks,
> -- Marco


  reply	other threads:[~2022-01-30  0:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-28 11:42 [PATCH 0/5] Update doc and fix some issues about kdump Tiezhu Yang
2022-01-28 11:42 ` [PATCH 1/5] docs: kdump: update description about sysfs file system support Tiezhu Yang
2022-01-30  2:10   ` Baoquan He
2022-01-28 11:42 ` [PATCH 2/5] docs: kdump: add scp sample to write out the dump file Tiezhu Yang
2022-01-30  2:46   ` Baoquan He
2022-01-28 11:42 ` [PATCH 3/5] kcsan: unset panic_on_warn before calling panic() Tiezhu Yang
2022-01-28 11:42 ` [PATCH 4/5] sched: " Tiezhu Yang
2022-01-28 11:52   ` Marco Elver
2022-01-30  0:29     ` Tiezhu Yang [this message]
2022-01-28 11:42 ` [PATCH 5/5] kfence: " Tiezhu Yang

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=0e700c2c-8523-ebc3-f006-e463f1fb7d0f@loongson.cn \
    --to=yangtiezhu@loongson.cn \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=corbet@lwn.net \
    --cc=elver@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).