Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   David Hildenbrand <david@redhat.com>
To:     linux-kernel@vger.kernel.org
Cc:     linux-mm@kvack.org, David Hildenbrand <david@redhat.com>
Subject: [PATCH v2 0/2] mm/hugetlb: fix write-fault handling for shared mappings
Date:   Thu, 11 Aug 2022 12:34:33 +0200
Message-Id: <20220811103435.188481-1-david@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

I observed that hugetlb does not support/expect write-faults in shared
mappings that would have to map the R/O-mapped page writable -- and I
found two case where we could currently get such faults and would
erroneously map an anon page into a shared mapping.

Reproducers part of the patches.

I propose to backport both fixes to stable trees. The first fix needs
a small adjustment.

v1 -> v2:
- "mm/hugetlb: fix hugetlb not supporting softdirty tracking"
-> Restrict to softdirty tracking
- "mm/hugetlb: support write-faults in shared mappings"
-> Add reproducer and adjust description
-> Move VM_WRITE sanity check out from MAYSHARE handling

David Hildenbrand (2):
  mm/hugetlb: fix hugetlb not supporting softdirty tracking
  mm/hugetlb: support write-faults in shared mappings

 mm/hugetlb.c | 26 +++++++++++++++++++-------
 mm/mmap.c    |  7 +++++--
 2 files changed, 24 insertions(+), 9 deletions(-)


base-commit: ffcf9c5700e49c0aee42dcba9a12ba21338e8136
-- 
2.35.3