Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Message-ID: <5c6c554ad749531826e71083f56cde90f336942a.camel@surriel.com>
Subject: Re: [PATCH 2/3] hugetlbfs: close race between MADV_DONTNEED and
 page fault
From:   Rik van Riel <riel@surriel.com>
To:     Mike Kravetz <mike.kravetz@oracle.com>
Cc:     linux-kernel@vger.kernel.org, kernel-team@meta.com,
        linux-mm@kvack.org, akpm@linux-foundation.org,
        muchun.song@linux.dev, leit@meta.com, willy@infradead.org
Date:   Mon, 02 Oct 2023 09:13:35 -0400
In-Reply-To: <20231002043958.GB11194@monkey>
References: <20231001005659.2185316-1-riel@surriel.com>
         <20231001005659.2185316-3-riel@surriel.com> <20231002043958.GB11194@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 Sun, 2023-10-01 at 21:39 -0700, Mike Kravetz wrote:
> 
> Looks like vma->vm_file is NULL and __hugetlb_zap_begin is trying to
> do
> i_mmap_lock_write(vma->vm_file->f_mapping).
> 
> Guess I did look closely. :)

Ugh. It looks like the fix for this bug ended up getting pulled
into patch 3, instead of patch 2.  I've had it in my code for a
while now :/

Let me move the fix for this thing into patch 2.

void __hugetlb_zap_begin(struct vm_area_struct *vma,
                         unsigned long *start, unsigned long *end)
{
        adjust_range_if_pmd_sharing_possible(vma, start, end);
        hugetlb_vma_lock_write(vma);
        if (vma->vm_file)
                i_mmap_lock_write(vma->vm_file->f_mapping);
}


-- 
All Rights Reversed.