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
Subject: Re: [PATCH 2/3] hugetlbfs: close race between MADV_DONTNEED and page fault
Date: Mon, 02 Oct 2023 09:13:35 -0400 [thread overview]
Message-ID: <5c6c554ad749531826e71083f56cde90f336942a.camel@surriel.com> (raw)
In-Reply-To: <20231002043958.GB11194@monkey>
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.
next prev parent reply other threads:[~2023-10-02 13:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-01 0:55 [PATCH v5 0/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-10-01 0:55 ` [PATCH 1/3] hugetlbfs: extend hugetlb_vma_lock to private VMAs riel
2023-10-01 0:55 ` [PATCH 2/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-10-02 4:39 ` Mike Kravetz
2023-10-02 13:13 ` Rik van Riel [this message]
2023-10-03 19:35 ` Rik van Riel
2023-10-03 20:19 ` Mike Kravetz
2023-10-04 0:20 ` Rik van Riel
2023-10-01 0:55 ` [PATCH 3/3] hugetlbfs: replace hugetlb_vma_lock with invalidate_lock riel
2023-10-02 5:22 ` Mike Kravetz
2023-10-01 2:54 ` [PATCH v5 0/3] hugetlbfs: close race between MADV_DONTNEED and page fault Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2023-10-04 3:25 [PATCH v6 " riel
2023-10-04 3:25 ` [PATCH 2/3] " riel
2023-10-05 3:19 ` Mike Kravetz
2023-10-05 13:23 ` Rik van Riel
2023-10-05 22:59 ` Mike Kravetz
2023-09-26 3:10 [PATCH v4 0/3] " riel
2023-09-26 3:10 ` [PATCH 2/3] " riel
2023-09-26 21:15 ` Andrew Morton
2023-09-26 23:57 ` Rik van Riel
2023-09-25 20:28 [PATCH v3 0/3] " riel
2023-09-25 20:28 ` [PATCH 2/3] " riel
2023-09-25 22:25 ` Mike Kravetz
2023-09-26 0:46 ` Rik van Riel
2023-09-22 19:02 [PATCH v2 0/3] " riel
2023-09-22 19:02 ` [PATCH 2/3] " riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5c6c554ad749531826e71083f56cde90f336942a.camel@surriel.com \
--to=riel@surriel.com \
--cc=akpm@linux-foundation.org \
--cc=kernel-team@meta.com \
--cc=leit@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.