[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250602141610.173698-1-osalvador@suse.de>
Date: Mon, 2 Jun 2025 16:16:07 +0200
From: Oscar Salvador <osalvador@...e.de>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Muchun Song <muchun.song@...ux.dev>,
David Hildenbrand <david@...hat.com>,
James Houghton <jthoughton@...gle.com>,
Peter Xu <peterx@...hat.com>,
Gavin Guo <gavinguo@...lia.com>,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Oscar Salvador <osalvador@...e.de>
Subject: [RFC PATCH 0/3] Clean up locking in hugetlb faulting code
Hi all,
This RFC is the culmination of the discussion that happened in [1].
TLDR: No one really knew what the locks were protecting us against, and
whether we needed them at all.
Some reasearch showed that most of them were introduced in a time were
truncation was not serialized with the mutex, as it is today, so we were
relying on the lock for the page to not go away from the pagecache.
More details can be find in patch#1.
This is for the locks, but I also started to look at the references
we take in hugetlb_fault and hugetlb_wp as it seems to me we are taking
more than actually needed, but that is once we manage to sort this out.
I ran hugetlb LTP tests and nothing screamed, and I also plan to run selftests
later on.
@Galvin. Could you please run your syzkaller with this patchset applied and
see whether you can trigger something?
Special thanks to David and Peter Xu that were helping out with this mess.
[1] https://lore.kernel.org/linux-mm/aDeBUXCRLRZobHq0@localhost.localdomain/T/#md02880ebc2c679678b7f326c5e9e93992428e124
Oscar Salvador (3):
mm, hugetlb: Clean up locking in hugetlb_fault and hugetlb_wp
mm, hugetlb: Update comments in hugetlb_fault
mm, hugetlb: Drop unlikelys from hugetlb_fault
include/linux/hugetlb.h | 12 +++++
mm/hugetlb.c | 117 +++++++++++++++++-----------------------
2 files changed, 62 insertions(+), 67 deletions(-)
--
2.49.0
Powered by blists - more mailing lists