All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: linux-mm@kvack.org, mpe@ellerman.id.au,
	linuxppc-dev@lists.ozlabs.org, kaleshsingh@google.com,
	npiggin@gmail.com, joel@joelfernandes.org,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	stable@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v2 6/6] mm/mremap: hold the rmap lock in write mode when moving page table entries.
Date: Wed, 16 Jun 2021 18:43:16 -0700	[thread overview]
Message-ID: <20210616184316.17229c71508fbd536afa3662@linux-foundation.org> (raw)
In-Reply-To: <20210616045239.370802-7-aneesh.kumar@linux.ibm.com>

On Wed, 16 Jun 2021 10:22:39 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:

> To avoid a race between rmap walk and mremap, mremap does take_rmap_locks().
> The lock was taken to ensure that rmap walk don't miss a page table entry due to
> PTE moves via move_pagetables(). The kernel does further optimization of
> this lock such that if we are going to find the newly added vma after the
> old vma, the rmap lock is not taken. This is because rmap walk would find the
> vmas in the same order and if we don't find the page table attached to
> older vma we would find it with the new vma which we would iterate later.
> 
> As explained in commit eb66ae030829 ("mremap: properly flush TLB before releasing the page")
> mremap is special in that it doesn't take ownership of the page. The
> optimized version for PUD/PMD aligned mremap also doesn't hold the ptl lock.
> This can result in stale TLB entries as show below.
> 
> ...
>
> Cc: stable@vger.kernel.org

Sneaking a -stable patch into the middle of all of this was ... sneaky :(

It doesn't actually apply to current mainline either.

I think I'll pretend I didn't notice.  Please sort this out with Greg
when he reports this back to you.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>,
	npiggin@gmail.com, linux-mm@kvack.org, kaleshsingh@google.com,
	joel@joelfernandes.org,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	stable@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v2 6/6] mm/mremap: hold the rmap lock in write mode when moving page table entries.
Date: Wed, 16 Jun 2021 18:43:16 -0700	[thread overview]
Message-ID: <20210616184316.17229c71508fbd536afa3662@linux-foundation.org> (raw)
In-Reply-To: <20210616045239.370802-7-aneesh.kumar@linux.ibm.com>

On Wed, 16 Jun 2021 10:22:39 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:

> To avoid a race between rmap walk and mremap, mremap does take_rmap_locks().
> The lock was taken to ensure that rmap walk don't miss a page table entry due to
> PTE moves via move_pagetables(). The kernel does further optimization of
> this lock such that if we are going to find the newly added vma after the
> old vma, the rmap lock is not taken. This is because rmap walk would find the
> vmas in the same order and if we don't find the page table attached to
> older vma we would find it with the new vma which we would iterate later.
> 
> As explained in commit eb66ae030829 ("mremap: properly flush TLB before releasing the page")
> mremap is special in that it doesn't take ownership of the page. The
> optimized version for PUD/PMD aligned mremap also doesn't hold the ptl lock.
> This can result in stale TLB entries as show below.
> 
> ...
>
> Cc: stable@vger.kernel.org

Sneaking a -stable patch into the middle of all of this was ... sneaky :(

It doesn't actually apply to current mainline either.

I think I'll pretend I didn't notice.  Please sort this out with Greg
when he reports this back to you.

  reply	other threads:[~2021-06-17  1:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16  4:52 [PATCH v2 0/6] mrermap fixes Aneesh Kumar K.V
2021-06-16  4:52 ` Aneesh Kumar K.V
2021-06-16  4:52 ` [PATCH v2 1/6] selftest/mremap_test: Update the test to handle pagesize other than 4K Aneesh Kumar K.V
2021-06-16  4:52   ` Aneesh Kumar K.V
2021-06-16  4:52 ` [PATCH v2 2/6] selftest/mremap_test: Avoid crash with static build Aneesh Kumar K.V
2021-06-16  4:52   ` Aneesh Kumar K.V
2021-06-16  4:52 ` [PATCH v2 3/6] mm/mremap: Convert huge PUD move to separate helper Aneesh Kumar K.V
2021-06-16  4:52   ` Aneesh Kumar K.V
2021-06-16  4:52 ` [PATCH v2 4/6] mm/mremap: Don't enable optimized PUD move if page table levels is 2 Aneesh Kumar K.V
2021-06-16  4:52   ` Aneesh Kumar K.V
2021-06-16  4:52 ` [PATCH v2 5/6] mm/mremap: Use pmd/pud_poplulate to update page table entries Aneesh Kumar K.V
2021-06-16  4:52   ` Aneesh Kumar K.V
2021-06-16  4:52 ` [PATCH v2 6/6] mm/mremap: hold the rmap lock in write mode when moving " Aneesh Kumar K.V
2021-06-16  4:52   ` Aneesh Kumar K.V
2021-06-17  1:43   ` Andrew Morton [this message]
2021-06-17  1:43     ` Andrew Morton
2021-06-16 14:39 ` [PATCH v2 0/6] mrermap fixes Linus Torvalds
2021-06-16 14:39   ` Linus Torvalds
2021-06-17  1:00 ` Andrew Morton
2021-06-17  1:00   ` Andrew Morton

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=20210616184316.17229c71508fbd536afa3662@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=hughd@google.com \
    --cc=joel@joelfernandes.org \
    --cc=kaleshsingh@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=stable@vger.kernel.org \
    --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.