On Mon, Aug 15, 2022 at 3:36 PM Gerald Schaefer <gerald.schaefer@xxxxxxxxxxxxx> wrote: > > 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. > 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.
