On Mon, Aug 15, 2022 at 3:36 PM Gerald Schaefer gerald.schaefer@linux.ibm.com wrote:
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.
Hi Gerald,
Is that new WARN_ON_ONCE() in hugetlb_wp() meant to indicate a real bug?
Most probably, unless I am missing something important.
Something triggers FAULT_FLAG_WRITE on a VMA without VM_WRITE and hugetlb_wp() would map the pte writable. Consequently, we'd have a writable pte inside a VMA that does not have write permissions, which is dubious. My check prevents that and bails out.
Ordinary (!hugetlb) faults have maybe_mkwrite() (e.g., for FOLL_FORCE or breaking COW) semantics such that we won't be mapping PTEs writable if the VMA does not have write permissions.
I suspect that either
a) Some write fault misses a protection check and ends up triggering a FAULT_FLAG_WRITE where we should actually fail early.
b) The write fault is valid and some VMA misses proper flags (VM_WRITE).
c) The write fault is valid (e.g., for breaking COW or FOLL_FORCE) and we'd actually want maybe_mkwrite semantics.
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().
That's what I suspect. Do you have a backtrace?
Note that I'm on vacation this week and might not reply as fast as usual.