linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Aili Yao" <yaoaili@kingsoft.com>,
	"HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>,
	dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, hpa@zytor.com, x86@kernel.org,
	yangfeng1@kingsoft.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] x86/fault: Send a SIGBUS to user process always for hwpoison page access.
Date: Tue, 23 Feb 2021 08:42:59 -0800	[thread overview]
Message-ID: <20210223164259.GA166727@agluck-desk2.amr.corp.intel.com> (raw)
In-Reply-To: <788DFBA0-903F-4548-9C2F-B1A1543EE770@amacapital.net>

On Tue, Feb 23, 2021 at 07:33:46AM -0800, Andy Lutomirski wrote:
> 
> > On Feb 23, 2021, at 4:44 AM, Aili Yao <yaoaili@kingsoft.com> wrote:
> > 
> > On Fri, 5 Feb 2021 17:01:35 +0800
> > Aili Yao <yaoaili@kingsoft.com> wrote:
> > 
> >> When one page is already hwpoisoned by MCE AO action, processes may not
> >> be killed, processes mapping this page may make a syscall include this
> >> page and result to trigger a VM_FAULT_HWPOISON fault, as it's in kernel
> >> mode it may be fixed by fixup_exception, current code will just return
> >> error code to user code.
> >> 
> >> This is not sufficient, we should send a SIGBUS to the process and log
> >> the info to console, as we can't trust the process will handle the error
> >> correctly.
> >> 
> >> Suggested-by: Feng Yang <yangfeng1@kingsoft.com>
> >> Signed-off-by: Aili Yao <yaoaili@kingsoft.com>
> >> ---
> >> arch/x86/mm/fault.c | 62 +++++++++++++++++++++++++++++----------------
> >> 1 file changed, 40 insertions(+), 22 deletions(-)
> >> 
> > Hi luto;
> >  Is there any feedback?
> 
> At the very least, this needs a clear explanation of why your proposed behavior is better than the existing behavior.

The explanation is buried in that "can't trust the process" line.

E.g. user space isn't good about checking for failed write(2) syscalls.
So if the poison was in a user buffer passed to write(fd, buffer, count)
sending a SIGBUS would be the action if they read the poison directly,
so it seems reasonable to send the same signal if the kernel read their
poison for them.

It would avoid users that didn't check the return value merrily proceeding
as if everything was ok.

-Tony


  reply	other threads:[~2021-02-23 16:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01  8:17 [PATCH v2] x86/fault: Send a SIGBUS to user process always for hwpoison page access Aili Yao
2021-02-01 16:58 ` Andy Lutomirski
2021-02-01 21:10   ` Luck, Tony
2021-02-01 22:09     ` Andy Lutomirski
2021-02-02  6:42   ` Aili Yao
2021-02-04  7:25 ` HORIGUCHI NAOYA(堀口 直也)
2021-02-05  5:06   ` Aili Yao
2021-02-05  9:01   ` [PATCH v3] " Aili Yao
2021-02-23 12:44     ` Aili Yao
2021-02-23 15:33       ` Andy Lutomirski
2021-02-23 16:42         ` Luck, Tony [this message]
2021-02-25  4:47           ` Aili Yao
2021-02-27  3:40             ` Andy Lutomirski
2021-03-01  7:57               ` Aili Yao
2021-03-01 18:12                 ` Luck, Tony
2021-03-01 19:02               ` Luck, Tony
2021-03-01 19:09                 ` Andy Lutomirski
2021-03-03 12:24                   ` Aili Yao
2021-03-03 12:51                     ` Aili Yao
2021-03-07 19:16                       ` Andy Lutomirski
2021-03-08  9:49                         ` Aili Yao
2021-03-08 18:14                           ` Andy Lutomirski
2021-03-08 18:31                             ` Luck, Tony
2021-03-08 19:00                               ` Andy Lutomirski
2021-03-11  1:19                                 ` Aili Yao
2021-03-11  1:28                                   ` Andy Lutomirski
2021-03-11  2:01                                     ` Aili Yao
2021-03-11 16:52                                     ` Luck, Tony
2021-03-11 16:56                                       ` Peter Zijlstra
2021-03-09  2:14                               ` Aili Yao
2021-03-09  2:25                                 ` Aili Yao

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=20210223164259.GA166727@agluck-desk2.amr.corp.intel.com \
    --to=tony.luck@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yangfeng1@kingsoft.com \
    --cc=yaoaili@kingsoft.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;
as well as URLs for NNTP newsgroup(s).