summaryrefslogtreecommitdiffstats
path: root/lib
diff options
context:
space:
mode:
authorVishal Moola (Oracle) <vishal.moola@gmail.com>2024-04-15 14:17:47 -0700
committerAndrew Morton <akpm@linux-foundation.org>2024-04-24 19:34:26 -0700
commit37641efaa3faa4b8292aba4bbd7d71c0b703a239 (patch)
treeba4426bd53e97e37951e37cfbe757ddd7998ecfe /lib
parent682886ec69d22363819a83ddddd5d66cb5c791e1 (diff)
downloadlinux-stable-37641efaa3faa4b8292aba4bbd7d71c0b703a239.tar.gz
linux-stable-37641efaa3faa4b8292aba4bbd7d71c0b703a239.tar.bz2
linux-stable-37641efaa3faa4b8292aba4bbd7d71c0b703a239.zip
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>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions