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.
Note that there is no need to do any kind of reservation in hugetlb_fault() in this case ... because we already have a hugetlb page mapped R/O that we will simply map writable and we are not dealing with COW/unsharing.
Note that we are not really doing any reservation adjustment in hugetlb_fault(). That code does pre-allocation of reservation data in case we might need it in hugetlb_wp. Since hugetlb_wp will certainly not do an allocation in this case, we do not even need to do the preallocation here. This change is more of an optimization. I am still happy with it.
Fixes: b1f9e876862d ("mm/uffd: enable write protection for shmem & hugetlbfs") Cc: stable@vger.kernel.org # v5.19 Signed-off-by: David Hildenbrand david@redhat.com
mm/hugetlb.c | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-)
Thanks,
Reviewed-by: Mike Kravetz mike.kravetz@oracle.com