Received-SPF: pass (google.com: domain of linux-kernel+bounces-73811-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org,
	muchun.song@linux.dev,
	"Vishal Moola (Oracle)" <vishal.moola@gmail.com>
Subject: [PATCH 0/3] Handle hugetlb faults under the VMA lock
Date: Tue, 20 Feb 2024 15:14:21 -0800
Message-ID: <20240220231424.126600-1-vishal.moola@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

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