All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Vehlow <lkml@jv-coder.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: peterz@infradead.org, Steven Rostedt <rostedt@goodmis.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Huang Ying <ying.huang@intel.com>,
	linux-kernel@vger.kernel.org,
	Joerg Vehlow <joerg.vehlow@aox-tech.de>
Subject: Re: [BUG RT] dump-capture kernel not executed for panic in interrupt context
Date: Mon, 14 Sep 2020 08:03:27 +0200	[thread overview]
Message-ID: <22bad750-ef5d-82a5-527c-5213346dd280@jv-coder.de> (raw)
In-Reply-To: <87sgbo3p5w.fsf@x220.int.ebiederm.org>

Hi Eric,
> What is this patch supposed to be doing?
>
> What bug is it fixing?
This information is part in the first message of this mail thread.
The patch was intendedfor the active discussion in this thread,
not for a broad review.
A short summary: In the rt kernel, a panic in an interrupt context does
not start the dump-capture kernel, because there is a mutex_trylock in
__crash_kexe. If this is called in interrupt context, it always fails.
In the non-rt kernel calling mutex_trylock is not allowed according to
the comment of the function, but it still works.

> A BUG_ON that triggers inside of BUG_ONs seems not just suspect but
> outright impossible to make use of.
I am not entirely sure what would happen here. But even if it gets in
some kind ofendless loop, I guess this is ok, because it allows finding
the problem. A piece of code in the function, that ensures the precondition
is a lot better than relying on only a comment.
If this was in mtex_trylock, the bug described above wouldn't have sneaked
in 12 years ago...
> I get the feeling skimming this that it is time to sort out and simplify
> the locking here, rather than make it more complex, and more likely to
> fail.
I would very much like that, but sadly it looks like it is not possible.
Either it wouldrequire blocking locks, that may fail, or not locking at
all, that may also fail.Using a different kind of lock (like spinlock)
is also not possible, becausespinlock_trylock again uses mutex_trylock
in the rt kernel.
>
> I get the feeling that over the years somehow the assumption that the
> rest of the kernel is broken and that we need to get out of the broken
> kernel as fast and as simply as possible has been lost.
Yes I also have the feeling, that the mutexes need fixing, but I wouldn't
to post any patch for that. At the moment, given the interface of the mutex,
this is clearly a bug in kexec, even if it works in the non-rt kernel.

Jörg

  reply	other threads:[~2020-09-14  6:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 11:41 [BUG RT] dump-capture kernel not executed for panic in interrupt context Joerg Vehlow
2020-05-28 12:46 ` Steven Rostedt
2020-07-22  4:30   ` Joerg Vehlow
2020-07-22 20:51     ` Steven Rostedt
2020-07-27 23:36     ` Andrew Morton
2020-08-21 10:25       ` Joerg Vehlow
2020-08-21 15:08         ` Steven Rostedt
2020-08-21 20:47           ` Andrew Morton
2020-08-21 21:03             ` Steven Rostedt
2020-08-22 12:32               ` peterz
2020-08-22 23:49                 ` Steven Rostedt
2020-09-07 11:41                   ` peterz
2020-09-07 12:49                     ` Valentin Schneider
2020-09-14 19:00                     ` Steven Rostedt
2020-09-07 10:51               ` Joerg Vehlow
2020-09-07 11:46                 ` peterz
2020-09-07 12:03                   ` Joerg Vehlow
2020-09-07 16:23                     ` peterz
2020-09-08  5:48                       ` Joerg Vehlow
2020-09-09  5:46                         ` Joerg Vehlow
2020-09-11 22:48                           ` Eric W. Biederman
2020-09-14  6:03                             ` Joerg Vehlow [this message]
2020-09-14 16:46                               ` Eric W. Biederman
2020-09-14 16:46                                 ` Eric W. Biederman

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=22bad750-ef5d-82a5-527c-5213346dd280@jv-coder.de \
    --to=lkml@jv-coder.de \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=ebiederm@xmission.com \
    --cc=joerg.vehlow@aox-tech.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=ying.huang@intel.com \
    /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.