[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191003205303.ge324uspaaocfxq4@willie-the-truck>
Date: Thu, 3 Oct 2019 21:53:04 +0100
From: Will Deacon <will@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
contact@...ium.me, Russell King <linux@...linux.org.uk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ingo Molnar <mingo@...hat.com>,
Kees Cook <keescook@...omium.org>, stable@...r.kernel.org
Subject: Re: [PATCH] panic: Ensure preemption is disabled during panic()
Hi Andrew,
Thanks for having a look.
On Wed, Oct 02, 2019 at 02:45:58PM -0700, Andrew Morton wrote:
> On Wed, 2 Oct 2019 13:35:38 +0100 Will Deacon <will@...nel.org> wrote:
> > Disable preemption in 'panic()' before re-enabling interrupts.
> >
> > ...
> >
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -180,6 +180,7 @@ void panic(const char *fmt, ...)
> > * after setting panic_cpu) from invoking panic() again.
> > */
> > local_irq_disable();
> > + preempt_disable_notrace();
> >
> > /*
> > * It's possible to come here directly from a panic-assertion and
>
> We still do a lot of stuff (kexec, kgdb, etc) after this
> preempt_disable() and I worry that something in there will now trigger
> a might_sleep() warning as a result?
Given that interrupts are already disabled at this point, I don't think
we'll get any additional warnings here by disabling preemption as well.
Will
Powered by blists - more mailing lists