From: Nicholas Piggin <npiggin@gmail.com>
To: Reza Arbab <arbab@linux.ibm.com>
Cc: Santosh Sivaraj <santosh@fossix.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Mahesh Salgaonkar <mahesh@linux.ibm.com>,
Chandan Rajendra <chandan@linux.vnet.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [v2 09/12] powerpc/mce: Enable MCE notifiers in external modules
Date: Fri, 05 Jul 2019 15:29:39 +1000 [thread overview]
Message-ID: <1562304274.ecukc5yx4t.astroid@bobo.none> (raw)
In-Reply-To: <20190705025042.nnov5s45jc4jd5ld@arbab-vm>
Reza Arbab's on July 5, 2019 12:50 pm:
> On Thu, Jul 04, 2019 at 12:36:18PM +1000, Nicholas Piggin wrote:
>>Reza Arbab's on July 4, 2019 3:20 am:
>>> Since the notifier chain is actually part of the decision between (1)
>>> and (2), it's a hard limitation then that callbacks be in real address
>>> space. Is there any way to structure things so that's not the case?
>>
>>If we tested for KVM guest first, and went through and marked (maybe
>>in a paca flag) everywhere else that put the MMU into a bad / non-host
>>state, and had the notifiers use the machine check stack, then it
>>would be possible to enable MMU here.
>>
>>Hmm, testing for IR|DR after testing for KVM guest might actually be
>>enough without requiring changes outside the machine check handler...
>>Actually no that may not quite work because the handler could take a
>>SLB miss and it might have been triggered inside the SLB miss handler.
>>
>>All in all I'm pretty against turning on MMU in the MCE handler
>>anywhere.
>
> Hey, fair enough. Just making sure there really isnt't any room to make
> things work the way I was trying.
Understand.
>
>>> Luckily this patch isn't really necessary for memcpy_mcsafe(), but we
>>> have a couple of other potential users of the notifier from external
>>> modules (so their callbacks would require virtual mode).
>>
>>What users are there? Do they do any significant amount of logic that
>>can not be moved to vmlinux?
>
> One I had in mind was the NVIDIA driver. When taking a UE from defective
> GPU memory, it could use the notifier to save the bad address to a
> blacklist in their nvram. Not so much recovering the machine check, just
> logging before the system reboots.
>
> The other user is a prototype driver for the IBM Research project we had
> a talk about offline a while back.
Okay. It might be possible to save the address in the kernel and
then notify the driver afterward. For user-mode and any non-atomic
user copy AFAIK the irq_work should practically run synchronously
after the machine check returns so it might be enough to have a
notifier in the irq work processing.
> We can make this patchset work for memcpy_mcsafe(), but I think it's
> back to the drawing board for the others.
For the first stage that would be preferable.
Thanks,
Nick
next prev parent reply other threads:[~2019-07-05 5:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 5:19 [v2 00/12] powerpc: implement machine check safe memcpy Santosh Sivaraj
2019-07-02 5:19 ` [v2 01/12] powerpc/mce: Make machine_check_ue_event() static Santosh Sivaraj
2019-07-02 5:19 ` [v2 02/12] powerpc/mce: Bug fixes for MCE handling in kernel space Santosh Sivaraj
2019-07-02 5:19 ` [v2 03/12] powerpc/mce: Add MCE notification chain Santosh Sivaraj
2019-07-02 14:55 ` Reza Arbab
2019-07-02 5:19 ` [v2 04/12] powerpc/mce: Move machine_check_ue_event() call Santosh Sivaraj
2019-07-02 5:19 ` [v2 05/12] powerpc/mce: Allow notifier callback to handle MCE Santosh Sivaraj
2019-07-02 5:19 ` [v2 06/12] powerpc/mce: Add fixup address to UE events Santosh Sivaraj
2019-07-02 5:19 ` [v2 07/12] powerpc/memcpy: Add memcpy_mcsafe for pmem Santosh Sivaraj
2019-07-02 5:19 ` [v2 08/12] powerpc/mce: Handle memcpy_mcsafe() Santosh Sivaraj
2019-07-02 5:19 ` [v2 09/12] powerpc/mce: Enable MCE notifiers in external modules Santosh Sivaraj
2019-07-02 6:17 ` Nicholas Piggin
2019-07-02 9:33 ` Mahesh Jagannath Salgaonkar
2019-07-03 17:20 ` Reza Arbab
2019-07-04 2:36 ` Nicholas Piggin
2019-07-05 2:50 ` Reza Arbab
2019-07-05 5:29 ` Nicholas Piggin [this message]
2019-07-08 15:23 ` Reza Arbab
2019-07-02 5:19 ` [v2 10/12] powerpc/memcpy_mcsafe: return remaining bytes Santosh Sivaraj
2019-07-02 5:19 ` [v2 11/12] powerpc: add machine check safe copy_to_user Santosh Sivaraj
2019-07-02 5:19 ` [v2 12/12] powerpc/64s: Save r13 in machine_check_common_early Santosh Sivaraj
2019-07-02 6:19 ` Nicholas Piggin
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=1562304274.ecukc5yx4t.astroid@bobo.none \
--to=npiggin@gmail.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=arbab@linux.ibm.com \
--cc=chandan@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mahesh@linux.ibm.com \
--cc=santosh@fossix.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).