On Thu, 11 Aug 2022 11:59:09 -0700 Mike Kravetz mike.kravetz@oracle.com 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().