Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Message-ID: <48ec0dd17f048541dd83f7ed7cb29dac91d8c607.camel@surriel.com>
Subject: Re: [PATCH] mm/hugetlb: fix null ptr defer in hugetlb_vma_lock_write
From:   Rik van Riel <riel@surriel.com>
To:     Mike Kravetz <mike.kravetz@oracle.com>
Cc:     Edward Adam Davis <eadavis@qq.com>, akpm@linux-foundation.org,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        llvm@lists.linux.dev, muchun.song@linux.dev, nathan@kernel.org,
        ndesaulniers@google.com,
        syzbot+6ada951e7c0f7bc8a71e@syzkaller.appspotmail.com,
        syzkaller-bugs@googlegroups.com, trix@redhat.com
Date:   Thu, 02 Nov 2023 23:15:50 -0400
In-Reply-To: <20231103023737.GC3531@monkey>
References: <3382634358afa9b95dc4f6db8a53a136d4b9e9cb.camel@surriel.com>
         <tencent_164A247533766D667C3D873798968236C409@qq.com>
         <20231103022426.GA3531@monkey> <20231103023737.GC3531@monkey>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Sender: riel@surriel.com
Precedence: bulk

On Thu, 2023-11-02 at 19:37 -0700, Mike Kravetz wrote:
> 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?

Honestly, I'm not sure. In hugetlb_dup_vma_private, which is
called at fork time, we have this comment:

         * - For MAP_PRIVATE mappings, this is the reserve map which
does
         *   not apply to children.  Faults generated by the children
are
         *   not guaranteed to succeed, even if read-only.

That suggests we already have no guarantee of faults
succeeding after fork.

> 
> With a bit more work we 'could' make sure every hugetlb vma has a
> lock
> to participate in this scheme.
> 
> Any thhoughts?

We can certainly close the race between MADV_DONTNEED
and page faults for MAP_PRIVATE mappings in child processes,
but that does not guarantee that we actually have hugetlb
pages for those processes.

In short, I'm not sure :)

-- 
All Rights Reversed.