From: "A lneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nick Piggin <npiggin@gmail.com>, Linux-MM <linux-mm@kvack.org>,
Kalesh Singh <kaleshsingh@google.com>,
Joel Fernandes <joel@joelfernandes.org>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v6 updated 9/11] mm/mremap: Fix race between mremap and pageout
Date: Tue, 25 May 2021 14:14:09 +0530 [thread overview]
Message-ID: <87pmxf6w4m.fsf@linux.ibm.com> (raw)
In-Reply-To: <CAHk-=whtmtA0SC5pjoeJ5+nHeiroQen0bph1abMJyb6Ge1b_wQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, May 24, 2021 at 3:38 AM Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> Avoid the above race with MOVE_PMD by holding pte ptl in mremap and waiting for
>> parallel pagetable walk to finish operating on pte before updating new_pmd
>
> Ack on the concept.
Should we worry about the below race. The window would be small
CPU 1 CPU 2 CPU 3
mremap(old_addr, new_addr) page_shrinker/try_to_unmap_one
mmap_write_lock_killable()
addr = old_addr
lock(pmd_ptl)
pmd = *old_pmd
pmd_clear(old_pmd)
flush_tlb_range(old_addr)
lock(pte_ptl)
*new_pmd = pmd
unlock(pte_ptl)
unlock(pmd_ptl)
lock(pte_ptl)
*new_addr = 10; and fills
TLB with new addr
and old pfn
ptep_clear_flush(old_addr)
old pfn is free.
Stale TLB entry
>
> However, not so much on the patch.
>
> Odd whitespace change:
>
>> @@ -254,6 +254,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
>> if (WARN_ON_ONCE(!pmd_none(*new_pmd)))
>> return false;
>>
>> +
>> /*
>> * We don't have to worry about the ordering of src and dst
>> * ptlocks because exclusive mmap_lock prevents deadlock.
>
> And new optimization for empty pmd, which seems unrelated to the
> change and should presumably be separate:
That was added that we can safely do pte_lockptr() below
>
>> @@ -263,6 +264,10 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
>> if (new_ptl != old_ptl)
>> spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
>>
>> + if (pmd_none(*old_pmd))
>> + goto unlock_out;
>> +
>> + pte_ptl = pte_lockptr(mm, old_pmd);
>> /* Clear the pmd */
>> pmd = *old_pmd;
>> pmd_clear(old_pmd);
>
> And also, why does the above assign 'pte_ptl' without using it, when
> the actual use is ten lines further down?
So that we fetch the pte_ptl before we clear old_pmd.
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: "A lneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux-MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Kalesh Singh <kaleshsingh@google.com>,
Nick Piggin <npiggin@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Christophe Leroy <christophe.leroy@csgroup.eu>
Subject: Re: [PATCH v6 updated 9/11] mm/mremap: Fix race between mremap and pageout
Date: Tue, 25 May 2021 14:14:09 +0530 [thread overview]
Message-ID: <87pmxf6w4m.fsf@linux.ibm.com> (raw)
In-Reply-To: <CAHk-=whtmtA0SC5pjoeJ5+nHeiroQen0bph1abMJyb6Ge1b_wQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, May 24, 2021 at 3:38 AM Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> Avoid the above race with MOVE_PMD by holding pte ptl in mremap and waiting for
>> parallel pagetable walk to finish operating on pte before updating new_pmd
>
> Ack on the concept.
Should we worry about the below race. The window would be small
CPU 1 CPU 2 CPU 3
mremap(old_addr, new_addr) page_shrinker/try_to_unmap_one
mmap_write_lock_killable()
addr = old_addr
lock(pmd_ptl)
pmd = *old_pmd
pmd_clear(old_pmd)
flush_tlb_range(old_addr)
lock(pte_ptl)
*new_pmd = pmd
unlock(pte_ptl)
unlock(pmd_ptl)
lock(pte_ptl)
*new_addr = 10; and fills
TLB with new addr
and old pfn
ptep_clear_flush(old_addr)
old pfn is free.
Stale TLB entry
>
> However, not so much on the patch.
>
> Odd whitespace change:
>
>> @@ -254,6 +254,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
>> if (WARN_ON_ONCE(!pmd_none(*new_pmd)))
>> return false;
>>
>> +
>> /*
>> * We don't have to worry about the ordering of src and dst
>> * ptlocks because exclusive mmap_lock prevents deadlock.
>
> And new optimization for empty pmd, which seems unrelated to the
> change and should presumably be separate:
That was added that we can safely do pte_lockptr() below
>
>> @@ -263,6 +264,10 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
>> if (new_ptl != old_ptl)
>> spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
>>
>> + if (pmd_none(*old_pmd))
>> + goto unlock_out;
>> +
>> + pte_ptl = pte_lockptr(mm, old_pmd);
>> /* Clear the pmd */
>> pmd = *old_pmd;
>> pmd_clear(old_pmd);
>
> And also, why does the above assign 'pte_ptl' without using it, when
> the actual use is ten lines further down?
So that we fetch the pte_ptl before we clear old_pmd.
-aneesh
next prev parent reply other threads:[~2021-05-25 8:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <id:20210524090114.63446-10-aneesh.kumar@linux.ibm.com>
2021-05-24 13:38 ` [PATCH v6 updated 9/11] mm/mremap: Fix race between mremap and pageout Aneesh Kumar K.V
2021-05-24 13:38 ` Aneesh Kumar K.V
2021-05-24 17:16 ` Linus Torvalds
2021-05-24 17:16 ` Linus Torvalds
2021-05-25 8:44 ` A lneesh Kumar K.V [this message]
2021-05-25 8:44 ` A lneesh Kumar K.V
2021-05-25 17:22 ` Linus Torvalds
2021-05-25 17:22 ` Linus Torvalds
2021-05-24 9:01 [PATCH v6 09/11] " Aneesh Kumar K.V
2021-05-24 13:38 ` [PATCH v6 updated 9/11] " Aneesh Kumar K.V
2021-05-24 13:38 ` Aneesh Kumar K.V
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=87pmxf6w4m.fsf@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=joel@joelfernandes.org \
--cc=kaleshsingh@google.com \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=torvalds@linux-foundation.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.