linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Axel Rasmussen <axelrasmussen@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christian Brauner <brauner@kernel.org>,
	David Hildenbrand <david@redhat.com>,
	Hongchen Zhang <zhanghongchen@loongson.cn>,
	Huang Ying <ying.huang@intel.com>,
	James Houghton <jthoughton@google.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	"Mike Rapoport (IBM)" <rppt@kernel.org>,
	Nadav Amit <namit@vmware.com>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	Shuah Khan <shuah@kernel.org>,
	ZhangPeng <zhangpeng362@huawei.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 1/3] mm: userfaultfd: add new UFFDIO_SIGBUS ioctl
Date: Wed, 24 May 2023 11:05:43 -0400	[thread overview]
Message-ID: <ZG4nxwdbWzhtR4pP@x1n> (raw)
In-Reply-To: <CAJHvVcjh6hOrZyr1t92v07+PVNVJH-BnPDs+ZSUWsLVjpLEuHA@mail.gmail.com>

On Tue, May 23, 2023 at 10:59:05AM -0700, Axel Rasmussen wrote:
> > Actually.. I think maybe we should have 1 patch changing SWAPIN_ERROR from
> > VM_FAULT_SIGBUS to VM_FAULT_HWPOISON.
> >
> > Let's imagine a VM having anonymous page backing and got a swapin error
> > when faulted on one of the guest page.  Instead of crashing the hypervisor
> > with sigbus we should probably make it a MCE injected into the guest too,
> > because there's no page corrupt in bare metal in this specific case,
> > however to the guest it's the same as having one page corrupted just like a
> > real MCE.
> 
> This is a great idea, you're right that injecting an MCE into the
> guest is exactly the end goal, and it seems like VM_FAULT_HWPOISON
> will "just work". Also the name UFFDIO_POISON resolves any confusion
> with UFFD_FEATURE_SIGBUS, so that's a nice side benefit.

Hopefully!  Please double check it with KVM running altogether to make sure
the patch works exactly as expected.

[...]

> We'll want hugetlbfs support for this operation too, but it's only
> really useful (at least for our use case) after HGM is merged. But,
> there's no strong reason not to just implement both all at once - I'll
> extend v2 to also work properly with hugetlbfs. Probably it isn't too
> hard, I just need to do a bit more reading of how swap markers are
> handled in hugetlbfs.

Sure.  We have too many flags separating different types of memory, so I
think it'll be nice if when it can still trivially work for everything.

For this specific case, since your goal is definitely having hugetlb hgm
supported so it'll be even more trickier if only hgm will be supported but
not !hgm hugetlbs, so we'd better target it initially with all mem types.

Thanks,

-- 
Peter Xu


      reply	other threads:[~2023-05-24 15:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 18:24 [PATCH 1/3] mm: userfaultfd: add new UFFDIO_SIGBUS ioctl Axel Rasmussen
2023-05-11 18:24 ` [PATCH 2/3] selftests/mm: refactor uffd_poll_thread to allow custom fault handlers Axel Rasmussen
2023-05-11 18:24 ` [PATCH 3/3] selftests/mm: add uffd unit test for UFFDIO_SIGBUS Axel Rasmussen
2023-05-11 20:22 ` [PATCH 1/3] mm: userfaultfd: add new UFFDIO_SIGBUS ioctl Mike Kravetz
2023-05-11 20:40   ` Axel Rasmussen
2023-05-11 21:05     ` Axel Rasmussen
2023-05-11 22:00 ` James Houghton
2023-05-17 22:12   ` Peter Xu
2023-05-17 22:20     ` Peter Xu
2023-05-17 22:28       ` Axel Rasmussen
2023-05-18  0:20         ` Peter Xu
2023-05-18  0:43         ` Jiaqi Yan
2023-05-18 16:05           ` Peter Xu
2023-05-18 20:38             ` Axel Rasmussen
2023-05-18 21:38               ` Peter Xu
2023-05-18 21:50                 ` Peter Xu
2023-05-19  8:38               ` David Hildenbrand
2023-05-19 15:04                 ` Jiaqi Yan
2023-05-19 16:20                   ` Peter Xu
2023-05-19 17:32                     ` Axel Rasmussen
2023-05-23 17:27                       ` Peter Xu
2023-05-23 17:26 ` Peter Xu
2023-05-23 17:59   ` Axel Rasmussen
2023-05-24 15:05     ` Peter Xu [this message]

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=ZG4nxwdbWzhtR4pP@x1n \
    --to=peterx@redhat.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=brauner@kernel.org \
    --cc=david@redhat.com \
    --cc=jthoughton@google.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=namit@vmware.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=ying.huang@intel.com \
    --cc=zhanghongchen@loongson.cn \
    --cc=zhangpeng362@huawei.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).