[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZRrf8NligMzwqx97@x1n>
Date: Mon, 2 Oct 2023 11:21:20 -0400
From: Peter Xu <peterx@...hat.com>
To: David Hildenbrand <david@...hat.com>
Cc: Jann Horn <jannh@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>,
akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
brauner@...nel.org, shuah@...nel.org, aarcange@...hat.com,
lokeshgidra@...gle.com, hughd@...gle.com, mhocko@...e.com,
axelrasmussen@...gle.com, rppt@...nel.org, willy@...radead.org,
Liam.Howlett@...cle.com, zhangpeng362@...wei.com,
bgeffon@...gle.com, kaleshsingh@...gle.com, ngeoffray@...gle.com,
jdduke@...gle.com, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH v2 2/3] userfaultfd: UFFDIO_REMAP uABI
On Mon, Oct 02, 2023 at 10:00:03AM +0200, David Hildenbrand wrote:
> In case we cannot simply remap the page, the fallback sequence (from the
> cover letter) would be triggered.
>
> 1) UFFDIO_COPY
> 2) MADV_DONTNEED
>
> So we would just handle the operation internally without a fallback.
Note that I think there will be a slight difference on whole remap
atomicity, on what happens if the page is modified after UFFDIO_COPY but
before DONTNEED.
UFFDIO_REMAP guarantees full atomicity when moving the page, IOW, threads
can be updating the pages when ioctl(UFFDIO_REMAP), data won't get lost
during movement, and it will generate a missing event after moved, with
latest data showing up on dest.
I'm not sure that means such a fallback is a problem, Suren may know
better with the use case.
Thanks,
--
Peter Xu
Powered by blists - more mailing lists