[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.11.2012021410260.4989@eggly.anvils>
Date: Wed, 2 Dec 2020 14:37:33 -0800 (PST)
From: Hugh Dickins <hughd@...gle.com>
To: Andrea Arcangeli <aarcange@...hat.com>
cc: Peter Xu <peterx@...hat.com>, Matthew Wilcox <willy@...radead.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Hugh Dickins <hughd@...gle.com>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH v2] mm: Don't fault around userfaultfd-registered regions
on reads
On Tue, 1 Dec 2020, Andrea Arcangeli wrote:
>
> Any suggestions on how to have the per-vaddr per-mm _PAGE_UFFD_WP bit
> survive the pte invalidates in a way that remains associated to a
> certain vaddr in a single mm (so it can shoot itself in the foot if it
> wants, but it can't interfere with all other mm sharing the shmem
> file) would be welcome...
I think it has to be a new variety of swap-like non_swap_entry() pte,
see include/linux/swapops.h. Anything else would be more troublesome.
Search for non_swap_entry and for migration_entry, to find places that
might need to learn about this new variety.
IIUC you only need a single value, no need to carve out another whole
swp_type: could probably be swp_offset 0 of any swp_type other than 0.
Note that fork's copy_page_range() does not "copy ptes where a page
fault will fill them correctly", so would in effect put a pte_none
into the child where the parent has this uffd_wp entry. I don't know
anything about uffd versus fork, whether that would pose a problem.
Hugh
Powered by blists - more mailing lists