From: "Luck, Tony" <tony.luck@intel.com>
To: Andy Lutomirski <luto@kernel.org>, Aili Yao <yaoaili@kingsoft.com>
Cc: "HORIGUCHI NAOYA( 堀口 直也)" <naoya.horiguchi@nec.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, "X86 ML" <x86@kernel.org>,
"yangfeng1@kingsoft.com" <yangfeng1@kingsoft.com>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v3] x86/fault: Send a SIGBUS to user process always for hwpoison page access.
Date: Mon, 1 Mar 2021 19:02:41 +0000 [thread overview]
Message-ID: <8d0c76f97f35499f91a2b82d3e7c024d@intel.com> (raw)
In-Reply-To: <CALCETrXT9vGRT1S6Kk5ExfU+mW16rCY964r73ihRf5ZSh9H8jg@mail.gmail.com>
> Some programs may use read(2), write(2), etc as ways to check if
> memory is valid without getting a signal. They might not want
> signals, which means that this feature might need to be configurable.
That sounds like an appalling hack. If users need such a mechanism
we should create some better way to do that.
An aeon ago ACPI created the RASF table as a way for the OS to
ask the platform to scan a block of physical memory using the patrol
scrubber in the memory controller. I never did anything with it in Linux
because it was just too complex and didn't know of any use cases.
Users would want to check virtual addresses. Perhaps some new
option MADV_CHECKFORPOISON to madvise(2) ?
-Tony
next prev parent reply other threads:[~2021-03-01 19:02 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 8:17 [PATCH v2] " 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
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 [this message]
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=8d0c76f97f35499f91a2b82d3e7c024d@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@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