public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Fernando Luis Vazquez Cao <fernando@intellilink.co.jp>
To: vgoyal@in.ibm.com
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	ak@suse.de, linux-kernel@vger.kernel.org,
	fastboot@lists.osdl.org
Subject: Re: [PATCH 5/5] stack overflow safe kdump (2.6.15-i386) - private nmi stack
Date: Thu, 19 Jan 2006 13:58:37 +0900	[thread overview]
Message-ID: <1137646717.2985.1.camel@localhost.localdomain> (raw)
In-Reply-To: <20060118015111.GD23143@in.ibm.com>

(Resending without Japanese characters. I apologize for the noise.)

On Tue, 2006-01-17 at 20:56 -0500, Vivek Goyal wrote:
> On Mon, Jan 16, 2006 at 10:25:26PM +0900, Fernando Luis Vazquez Cao wrote:
> > Use a private NMI stack.
> > 
> > ---
> > diff -urNp linux-2.6.15/arch/i386/kernel/irq.c
> > linux-2.6.15-sov/arch/i386/kernel/irq.c
> > --- linux-2.6.15/arch/i386/kernel/irq.c	2006-01-03 12:21:10.000000000
> > +0900
> > +++ linux-2.6.15-sov/arch/i386/kernel/irq.c	2006-01-16
> > 22:04:07.000000000 +0900
> > @@ -37,11 +37,6 @@ void ack_bad_irq(unsigned int irq)
> >  /*
> >   * per-CPU IRQ handling contexts (thread information and stack)
> >   */
> > -union irq_ctx {
> > -	struct thread_info      tinfo;
> > -	u32                     stack[THREAD_SIZE/sizeof(u32)];
> > -};
> > -
> >  static union irq_ctx *hardirq_ctx[NR_CPUS];
> >  static union irq_ctx *softirq_ctx[NR_CPUS];
> >  #endif
> > @@ -154,6 +149,8 @@ void irq_ctx_init(int cpu)
> >  
> >  	printk("CPU %u irqstacks, hard=%p soft=%p\n",
> >  		cpu,hardirq_ctx[cpu],softirq_ctx[cpu]);
> > +
> > +	nmi_ctx_init(cpu);
> >  }
> >  
> >  void irq_ctx_exit(int cpu)
> > diff -urNp linux-2.6.15/arch/i386/kernel/traps.c
> > linux-2.6.15-sov/arch/i386/kernel/traps.c
> > --- linux-2.6.15/arch/i386/kernel/traps.c	2006-01-16 22:00:54.000000000
> > +0900
> > +++ linux-2.6.15-sov/arch/i386/kernel/traps.c	2006-01-16
> > 22:05:51.000000000 +0900
> > @@ -643,6 +643,13 @@ static int dummy_nmi_callback(struct pt_
> >   
> >  static nmi_callback_t nmi_callback = dummy_nmi_callback;
> >  
> > +#ifdef CONFIG_4KSTACKS
> > +/*
> 
> Does not work for 8K stacks. Also we are switching the stack all the
> time for NMI. I am not sure if that is really required (performance?).
Yes, it does not work for 8K stacks, but this is something premeditated.
Since private stacks for interrupts are only used when 4KSTACKS
is enabled I felt that to be consistent it should be the same in
the NMI's case. Anyway if it is deemed correct (I agree it is desirable)
I could implement it.

Regarding the impact in performance, note that when we use 4K stacks we
are switching stacks _every_ time an interrupt occurs. I do not see why
we should not do the same for NMIs. Specially since the cost of
switching stacks is relatively small when compared to the cost of
executing the NMI watchdog's handler.

> Can't it be made to work both for 4K and 8K stack. And switch to reserved
> stack on NMI, only if crash has happened.
Yes, it could be done, but I think it is safer to use a private stack
all the time, so that the NMI handler does not contribute to an eventual
stack overflow. I would like to avoid the case of the the stack
overflowing inside the NMI handler.

Thanks for your comments.

Regards,

Fernando


  reply	other threads:[~2006-01-19  4:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-16 13:25 [PATCH 5/5] stack overflow safe kdump (2.6.15-i386) - private nmi stack Fernando Luis Vazquez Cao
2006-01-18  1:51 ` Vivek Goyal
2006-01-19  4:58   ` Fernando Luis Vazquez Cao [this message]
2006-01-19  5:47   ` Fernando Luis Vazquez Cao
     [not found]   ` <1137645795.2243.32.camel@localhost.localdomain>
     [not found]     ` <20060120131936.GE4695@in.ibm.com>
2006-01-25  7:22       ` Fernando Luis Vazquez Cao

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=1137646717.2985.1.camel@localhost.localdomain \
    --to=fernando@intellilink.co.jp \
    --cc=ak@suse.de \
    --cc=ebiederm@xmission.com \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@in.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox