[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231103023737.GC3531@monkey>
Date: Thu, 2 Nov 2023 19:37:37 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Rik van Riel <riel@...riel.com>
Cc: Edward Adam Davis <eadavis@...com>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
llvm@...ts.linux.dev, muchun.song@...ux.dev, nathan@...nel.org,
ndesaulniers@...gle.com,
syzbot+6ada951e7c0f7bc8a71e@...kaller.appspotmail.com,
syzkaller-bugs@...glegroups.com, trix@...hat.com
Subject: Re: [PATCH] mm/hugetlb: fix null ptr defer in hugetlb_vma_lock_write
On 11/02/23 19:24, Mike Kravetz wrote:
>
> In the specific case causing the null-ptr-deref, the resv_map pointer
> (vm_private_data) is NULL.
Hi Rik,
In commit bf4916922c60 hugetlbfs: extend hugetlb_vma_lock to private VMAs,
it correctly says:
Extend the locking scheme used to protect shared hugetlb mappings from
truncate vs page fault races, in order to protect private hugetlb mappings
(with resv_map) against MADV_DONTNEED.
That qualification '(with resv_map)' caught my attention originally, and
I thought about it again while looking into this. We now cover the common
cases, but there are still quite a few cases where resv_map is NULL for
private mappings. In such cases, the race between MADV_DONTNEED and page
fault still exists. Is that a concern?
With a bit more work we 'could' make sure every hugetlb vma has a lock
to participate in this scheme.
Any thhoughts?
--
Mike Kravetz
Powered by blists - more mailing lists