hugetlb: check for anon_vma prior to folio allocation
authorVishal Moola (Oracle) <vishal.moola@gmail.com>
Mon, 15 Apr 2024 21:17:47 +0000 (14:17 -0700)
committerAndrew Morton <akpm@linux-foundation.org>
Thu, 25 Apr 2024 02:34:26 +0000 (19:34 -0700)
commit37641efaa3faa4b8292aba4bbd7d71c0b703a239
treeba4426bd53e97e37951e37cfbe757ddd7998ecfe
parent682886ec69d22363819a83ddddd5d66cb5c791e1
hugetlb: check for anon_vma prior to folio allocation

Commit 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of
anon_vma_prepare()") may bailout after allocating a folio if we do not
hold the mmap lock.  When this occurs, vmf_anon_prepare() will release the
vma lock.  Hugetlb then attempts to call restore_reserve_on_error(), which
depends on the vma lock being held.

We can move vmf_anon_prepare() prior to the folio allocation in order to
avoid calling restore_reserve_on_error() without the vma lock.

Link: https://lkml.kernel.org/r/ZiFqSrSRLhIV91og@fedora
Fixes: 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of anon_vma_prepare()")
Reported-by: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com
Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/hugetlb.c