You'll probably get a tag just from using the British English spelling of 'honour' from me :P (joking! ;)
On Tue, Oct 28, 2025 at 12:09:52PM +0530, Dev Jain wrote:
Currently mremap folio pte batch ignores the writable bit during figuring out a set of similar ptes mapping the same folio. Suppose that the first pte of the batch is writable while the others are not - set_ptes will end up setting the writable bit on the other ptes, which is a violation of mremap semantics. Therefore, use FPB_RESPECT_WRITE to check the writable bit while determining the pte batch.
Yikes.
Cc: stable@vger.kernel.org #6.17 Fixes: f822a9a81a31 ("mm: optimize mremap() by PTE batching") Reported-by: David Hildenbrand david@redhat.com Debugged-by: David Hildenbrand david@redhat.com Signed-off-by: Dev Jain dev.jain@arm.com
LGTM, so:
Reviewed-by: Lorenzo Stoakes lorenzo.stoakes@oracle.com
mm-selftests pass. Based on mm-new. Need David H. to confirm whether the repro passes.
Given he A-b'd I assume it did :)
mm/mremap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/mremap.c b/mm/mremap.c index a7f531c17b79..8ad06cf50783 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -187,7 +187,7 @@ static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned long addr if (!folio || !folio_test_large(folio)) return 1;
- return folio_pte_batch(folio, ptep, pte, max_nr);
- return folio_pte_batch_flags(folio, NULL, ptep, &pte, max_nr, FPB_RESPECT_WRITE);
}
static int move_ptes(struct pagetable_move_control *pmc,
2.30.2