Hi Oscar,
On 6/2/25 22:16, Oscar Salvador wrote:
> 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?
Sorry for the late response. My capacity is limited in the last two
weeks of joining an event and didn't notice the talk. And it seems
already huge discussions and good progress. Currently, I saw the
discussion is in another latest thread:
https://lore.kernel.org/linux-mm/20250612134701.377855-1-osalvador@suse.de/
Please let me know if the testing is still useful.
>
> 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(-)