From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nicholas Piggin <npiggin@gmail.com>, linuxppc-dev@lists.ozlabs.org
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
Anton Blanchard <anton@samba.org>,
Paul Mackerras <paulus@ozlabs.org>
Subject: Re: [RFC][PATCH] powerpc/64s: Leave IRQs hard enabled over context switch
Date: Wed, 03 May 2017 10:28:27 +0200 [thread overview]
Message-ID: <1493800107.25766.352.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170503073414.18776-1-npiggin@gmail.com>
On Wed, 2017-05-03 at 17:34 +1000, Nicholas Piggin wrote:
> Extending the soft IRQ disable to cover PMU interrupts will allow this
> hard disable to be removed from hash based kernels too, but they will
> still have to soft-disable PMU interrupts.
>
> - Q1: Can we do this? It gives nice profiles of context switch code
> rather than assigning it all to local_irq_enable.
Probably ok with radix yes.
> - Q2: What is the unrecoverable SLB miss on exception entry? Is there
> anywhere we access the kernel stack with RI disabled? Something else?
Not sure what you mean by Q2, but the original problem is an occurrence
of what we call the 'megabug' which hit us in different forms over the
years, and happens when we get a kernel stack SLB entry wrong.
Normally, the segment containing the current kernel stack is always
bolted in the SLB in a specific slot. If we accidentally lose that
"bolt", we can end up faulting it into the wrong slot, thus making it
possible for it to get evicted later on etc...
That in turns hits the exception return path which accesses the kernel
stack after clearing RI and setting SRR0/1 to the return values.
Cheers,
Ben.
next prev parent reply other threads:[~2017-05-03 8:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 7:34 [RFC][PATCH] powerpc/64s: Leave IRQs hard enabled over context switch Nicholas Piggin
2017-05-03 8:28 ` Benjamin Herrenschmidt [this message]
2017-05-03 9:17 ` Nicholas Piggin
2017-05-03 10:26 ` Michael Ellerman
2017-05-03 16:24 ` Benjamin Herrenschmidt
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=1493800107.25766.352.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=anton@samba.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=paulus@ozlabs.org \
/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;
as well as URLs for NNTP newsgroup(s).