All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Vehlow <lkml@jv-coder.de>
To: peterz@infradead.org
Cc: 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, 7 Sep 2020 14:03:09 +0200	[thread overview]
Message-ID: <5c3a502f-2255-5aae-3599-5220aa4b8328@jv-coder.de> (raw)
In-Reply-To: <20200907114618.GR2674@hirez.programming.kicks-ass.net>



On 9/7/2020 1:46 PM, peterz@infradead.org wrote:
> I think it's too complicated for that is needed, did you see my
> suggestion from a year ago? Did i miss something obvious?
>
This one? 
https://lore.kernel.org/linux-fsdevel/20191219090535.GV2844@hirez.programming.kicks-ass.net/

I think it may be a bit incorrect?
According to the original comment in __crash_kexec, the mutex was used to
prevent a sys_kexec_load, while crash_kexec is executed. Your proposed 
patch
does not lock the mutex in crash_kexec. This does not cover the original 
use
case anymore. The only thing that is protected now are two panicing cores at
the same time.
Actually, this implementation feels even more hacky to me....

Jörg

  reply	other threads:[~2020-09-07 17:50 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 [this message]
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
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=5c3a502f-2255-5aae-3599-5220aa4b8328@jv-coder.de \
    --to=lkml@jv-coder.de \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --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.