On Thu, 11 Aug 2022 11:59:09 -0700 Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > On 08/11/22 12:34, David Hildenbrand wrote: > > If we ever get a write-fault on a write-protected page in a shared mapping, > > we'd be in trouble (again). Instead, we can simply map the page writable. > > > <snip> > > > > Reason is that uffd-wp doesn't clear the uffd-wp PTE bit when > > unregistering and consequently keeps the PTE writeprotected. Reason for > > this is to avoid the additional overhead when unregistering. Note > > that this is the case also for !hugetlb and that we will end up with > > writable PTEs that still have the uffd-wp PTE bit set once we return > > from hugetlb_wp(). I'm not touching the uffd-wp PTE bit for now, because it > > seems to be a generic thing -- wp_page_reuse() also doesn't clear it. > > > > VM_MAYSHARE handling in hugetlb_fault() for FAULT_FLAG_WRITE > > indicates that MAP_SHARED handling was at least envisioned, but could never > > have worked as expected. > > > > While at it, make sure that we never end up in hugetlb_wp() on write > > faults without VM_WRITE, because we don't support maybe_mkwrite() > > semantics as commonly used in the !hugetlb case -- for example, in > > wp_page_reuse(). > > Nit, > to me 'make sure that we never end up in hugetlb_wp()' implies that > we would check for condition in callers as opposed to first thing in > hugetlb_wp(). However, I am OK with description as it. Is that new WARN_ON_ONCE() in hugetlb_wp() meant to indicate a real bug? It is triggered by libhugetlbfs testcase "HUGETLB_ELFMAP=R linkhuge_rw" (at least on s390), and crashes our CI, because it runs with panic_on_warn enabled. Not sure if this means that we have bug elsewhere, allowing us to get to the WARN in hugetlb_wp().
