Just to add here, writing to any of these pages from the Host
will trigger a RMP #PF which will cause the RMP page fault handler
to send a SIGBUS to the current process, as this page is not owned
by Host.
So calling memory_failure() is proactively doing the same,
marking the page as poisoned and probably also killing the
current process.
Thanks,
Ashish
On 10/25/2022 5:25 AM, Borislav Petkov wrote:
On Fri, Oct 14, 2022 at 03:00:09PM -0500, Kalra, Ashish wrote:
If it is "still" accessed/touched then it can cause RMP #PF.
On the other hand,
* PG_hwpoison... Accessing is
* not safe since it may cause another machine check. Don't touch!
That sounds exactly the state we want these page(s) to be in ?
Another possibility is PG_error.
Something like this:
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index e66f7aa3191d..baffa9c0dc30 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -186,6 +186,7 @@ enum pageflags {
* THP.
*/
PG_has_hwpoisoned = PG_error,
+ PG_offlimits = PG_hwpoison,
#endif
/* non-lru isolated movable page */
and SNP will have to depend on CONFIG_MEMORY_FAILURE.
But I'd let mm folks correct me here on the details.
