All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vivek Goyal <vgoyal@redhat.com>,
	Brayan Arraes <brayan@yack.com.br>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Ken'ichi Ohmichi" <oomichi@mxs.nes.nec.co.jp>
Subject: Re: [PATCH] sysrq, kdump: fix regression, revert "simplify sysrq-c handler"
Date: Thu, 23 Jul 2009 10:09:20 +0900	[thread overview]
Message-ID: <4A67B840.2090401@jp.fujitsu.com> (raw)
In-Reply-To: <20090722111049.GB4539@hmsreliant.think-freely.org>

Neil Horman wrote:
> On Wed, Jul 22, 2009 at 11:01:29AM +0900, Hidetoshi Seto wrote:
>> Neil Horman wrote:
>>  static void sysrq_handle_crash(int key, struct tty_struct *tty)
>>  {
>> -	char *killer = NULL;
>> -	*killer = 1;
>> +	panic("SysRq-triggered panic!\n");
>>  }
>>
> Well, this removes the ability from sysrq-c to test the oops handling path, but
> I suppose it does buy us consistent behavior between the keyboard and proc
> interfaces, which is likely more important.  I can agree to that.  Perhaps we
> can create another sysctl to test the oops path later.
> 
>> I agree that causing a real crash(panic) is better way to test crashdump than
>> calling the entry function of the crashdump directly, and also that opening
>> the path for other dump mechanisms is welcomed.
>>  
> Ok, so we're in line there :)
> 
>>> It seems to
>>> me that right now your major complaint is that the documentation is out of date,
>>> and you're having to do things slightly differently to get the same behavioral
>>> results.  Would it solve your issue, if we simply updated the documentation to
>>> illustrate how it works now?
>> Of course the documentation should be updated asap.
>> But I think the major complaint is about a difference in the behaviors of SysRq-c
>> and "echo c > /proc/sysrq-trigger".
>>
> Ok, I can agree with that.  I'd support a change like what you have above to
> bring the keyboard and proc interface behavior in line.

Thank you for your understanding!

I'll write & post a patch soon.  Please review it.


Thanks,
H.Seto


      parent reply	other threads:[~2009-07-23  1:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-20 12:46 [PATCH] sysrq, kdump: fix regression, revert "simplify sysrq-c handler" Lai Jiangshan
2009-07-20 19:22 ` Eric W. Biederman
2009-07-20 21:16   ` Neil Horman
2009-07-21  6:46     ` Lai Jiangshan
2009-07-21 22:18       ` Eric W. Biederman
2009-07-21  6:00   ` Lai Jiangshan
2009-07-21  6:56     ` Eric W. Biederman
2009-07-21  6:49 ` Hidetoshi Seto
2009-07-21 11:08   ` Neil Horman
2009-07-21 12:16     ` Lai Jiangshan
2009-07-22  2:01     ` Hidetoshi Seto
2009-07-22 11:10       ` Neil Horman
2009-07-22 13:42         ` Vivek Goyal
2009-07-22 19:38           ` Neil Horman
2009-07-23  1:10             ` Hidetoshi Seto
2009-07-23  1:09         ` Hidetoshi Seto [this message]

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=4A67B840.2090401@jp.fujitsu.com \
    --to=seto.hidetoshi@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=brayan@yack.com.br \
    --cc=ebiederm@xmission.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=oomichi@mxs.nes.nec.co.jp \
    --cc=vgoyal@redhat.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.