linux-kernel - [PATCH 0/3] Handle hugetlb faults under the VMA lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240220231424.126600-1-vishal.moola@gmail.com>
Date: Tue, 20 Feb 2024 15:14:21 -0800
From: "Vishal Moola (Oracle)" <vishal.moola@...il.com>
To: linux-mm@...ck.org
Cc: linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org,
	muchun.song@...ux.dev,
	"Vishal Moola (Oracle)" <vishal.moola@...il.com>
Subject: [PATCH 0/3] Handle hugetlb faults under the VMA lock

It is generally safe to handle hugetlb faults under the VMA lock. The
only time this is unsafe is when no anon_vma has been allocated to this
vma yet, so we can use vmf_anon_prepare() instead of anon_vma_prepare()
to bailout if necessary. This may only happen for the first non-shared
hugetlb page in the vma.

-----
The last patch in this series may cause ltp hugemmap10 to "fail". This
is expected behavior - see the commit message for patch 3 in this series.
The rest of the ltp hugetlb tests pass.

This patchset applies cleanly ontop of mm-unstable.

Vishal Moola (Oracle) (3):
  mm/memory: Change vmf_anon_prepare() to be non-static
  hugetlb: Use vmf_anon_prepare() instead of anon_vma_prepare()
  hugetlb: Allow faults to be handled under the VMA lock

 include/linux/hugetlb.h |  1 +
 mm/hugetlb.c            | 33 +++++++++++++++++++++------------
 mm/memory.c             |  2 +-
 3 files changed, 23 insertions(+), 13 deletions(-)

-- 
2.43.0