From: Mel Gorman <mgorman@suse.de>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Alex Thorlton <athorlton@sgi.com>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 11/18] mm: fix TLB flush race between migration, and change_protection_range
Date: Wed, 11 Dec 2013 11:21:37 +0000 [thread overview]
Message-ID: <20131211112137.GZ11295@suse.de> (raw)
In-Reply-To: <20131210180208.GY4208@linux.vnet.ibm.com>
On Tue, Dec 10, 2013 at 10:02:08AM -0800, Paul E. McKenney wrote:
> > > Should this be smp_mb__after_unlock_lock(); ?
> >
> > I think this is still ok. Minimally, it's missing the unlock/lock pair that
> > would cause smp_mb__after_unlock_lock() to be treated as a full barrier
> > on architectures that care. The CPU executing this code as already seen
> > the pmd_numa update if it's in the fault handler so it just needs to be
> > sure to not reorder the check with respect to the page copy.
>
> You really do need a lock operation somewhere shortly before the
> smp_mb__after_unlock_lock().
>
My badly phrased point was that there was no unlock/lock operation nearby
that needs to be ordered with respect to the tlb_flush_pending check. I
do not see a need for smp_mb__after_unlock_lock() here and just this
hunk is required.
> > index c122bb1..33e5519 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -482,7 +482,12 @@ static inline bool tlb_flush_pending(struct mm_struct *mm)
> > static inline void set_tlb_flush_pending(struct mm_struct *mm)
> > {
> > mm->tlb_flush_pending = true;
> > - barrier();
> > +
> > + /*
> > + * Guarantee that the tlb_flush_pending store does not leak into the
> > + * critical section updating the page tables
> > + */
> > + smp_mb_before_spinlock();
> > }
> > /* Clearing is done after a TLB flush, which also provides a barrier. */
> > static inline void clear_tlb_flush_pending(struct mm_struct *mm)
> >
A double check would be nice please.
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Alex Thorlton <athorlton@sgi.com>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 11/18] mm: fix TLB flush race between migration, and change_protection_range
Date: Wed, 11 Dec 2013 11:21:37 +0000 [thread overview]
Message-ID: <20131211112137.GZ11295@suse.de> (raw)
In-Reply-To: <20131210180208.GY4208@linux.vnet.ibm.com>
On Tue, Dec 10, 2013 at 10:02:08AM -0800, Paul E. McKenney wrote:
> > > Should this be smp_mb__after_unlock_lock(); ?
> >
> > I think this is still ok. Minimally, it's missing the unlock/lock pair that
> > would cause smp_mb__after_unlock_lock() to be treated as a full barrier
> > on architectures that care. The CPU executing this code as already seen
> > the pmd_numa update if it's in the fault handler so it just needs to be
> > sure to not reorder the check with respect to the page copy.
>
> You really do need a lock operation somewhere shortly before the
> smp_mb__after_unlock_lock().
>
My badly phrased point was that there was no unlock/lock operation nearby
that needs to be ordered with respect to the tlb_flush_pending check. I
do not see a need for smp_mb__after_unlock_lock() here and just this
hunk is required.
> > index c122bb1..33e5519 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -482,7 +482,12 @@ static inline bool tlb_flush_pending(struct mm_struct *mm)
> > static inline void set_tlb_flush_pending(struct mm_struct *mm)
> > {
> > mm->tlb_flush_pending = true;
> > - barrier();
> > +
> > + /*
> > + * Guarantee that the tlb_flush_pending store does not leak into the
> > + * critical section updating the page tables
> > + */
> > + smp_mb_before_spinlock();
> > }
> > /* Clearing is done after a TLB flush, which also provides a barrier. */
> > static inline void clear_tlb_flush_pending(struct mm_struct *mm)
> >
A double check would be nice please.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2013-12-11 11:21 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 7:08 [PATCH 00/18] NUMA balancing segmentation fault fixes and misc followups v3 Mel Gorman
2013-12-09 7:08 ` Mel Gorman
2013-12-09 7:08 ` [PATCH 01/18] mm: numa: Serialise parallel get_user_page against THP migration Mel Gorman
2013-12-09 7:08 ` Mel Gorman
2013-12-09 14:08 ` Rik van Riel
2013-12-09 14:08 ` Rik van Riel
2013-12-09 7:08 ` [PATCH 02/18] mm: numa: Call MMU notifiers on " Mel Gorman
2013-12-09 7:08 ` Mel Gorman
2013-12-09 14:09 ` Rik van Riel
2013-12-09 14:09 ` Rik van Riel
2013-12-09 7:08 ` [PATCH 03/18] mm: Clear pmd_numa before invalidating Mel Gorman
2013-12-09 7:08 ` Mel Gorman
2013-12-09 14:14 ` Rik van Riel
2013-12-09 14:14 ` Rik van Riel
2013-12-09 7:08 ` [PATCH 04/18] mm: numa: Do not clear PMD during PTE update scan Mel Gorman
2013-12-09 7:08 ` Mel Gorman
2013-12-09 14:22 ` Rik van Riel
2013-12-09 14:22 ` Rik van Riel
2013-12-09 7:08 ` [PATCH 05/18] mm: numa: Do not clear PTE for pte_numa update Mel Gorman
2013-12-09 7:08 ` Mel Gorman
2013-12-09 14:31 ` Rik van Riel
2013-12-09 14:31 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 06/18] mm: numa: Ensure anon_vma is locked to prevent parallel THP splits Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 14:34 ` Rik van Riel
2013-12-09 14:34 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 07/18] mm: numa: Avoid unnecessary work on the failure path Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 14:42 ` Rik van Riel
2013-12-09 14:42 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 08/18] sched: numa: Skip inaccessible VMAs Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 14:50 ` Rik van Riel
2013-12-09 14:50 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 09/18] mm: numa: Clear numa hinting information on mprotect Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 15:57 ` Rik van Riel
2013-12-09 15:57 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 10/18] mm: numa: Avoid unnecessary disruption of NUMA hinting during migration Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 16:10 ` Rik van Riel
2013-12-09 16:10 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 11/18] mm: fix TLB flush race between migration, and change_protection_range Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-10 14:25 ` Rik van Riel
2013-12-10 14:25 ` Rik van Riel
2013-12-10 17:19 ` Mel Gorman
2013-12-10 17:19 ` Mel Gorman
2013-12-10 18:02 ` Paul E. McKenney
2013-12-10 18:02 ` Paul E. McKenney
2013-12-11 11:21 ` Mel Gorman [this message]
2013-12-11 11:21 ` Mel Gorman
2013-12-09 7:09 ` [PATCH 12/18] mm: numa: Defer TLB flush for THP migration as long as possible Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 16:13 ` Rik van Riel
2013-12-09 16:13 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 13/18] mm: numa: Make NUMA-migrate related functions static Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 7:20 ` Wanpeng Li
[not found] ` <20131209072010.GA3716@hacker.(null)>
2013-12-09 8:46 ` Mel Gorman
2013-12-09 8:46 ` Mel Gorman
2013-12-09 8:57 ` Wanpeng Li
[not found] ` <20131209085720.GA16251@hacker.(null)>
2013-12-09 9:08 ` Mel Gorman
2013-12-09 9:08 ` Mel Gorman
2013-12-09 9:13 ` Wanpeng Li
2013-12-09 16:14 ` Rik van Riel
2013-12-09 16:14 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 14/18] mm: numa: Limit scope of lock for NUMA migrate rate limiting Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 16:47 ` Rik van Riel
2013-12-09 16:47 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 15/18] mm: numa: Trace tasks that fail migration due to " Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 16:57 ` Rik van Riel
2013-12-09 16:57 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 16/18] mm: numa: Do not automatically migrate KSM pages Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 16:57 ` Rik van Riel
2013-12-09 16:57 ` Rik van Riel
2013-12-09 7:09 ` [PATCH 17/18] sched: Tracepoint task movement Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 18:54 ` Rik van Riel
2013-12-09 18:54 ` Rik van Riel
2013-12-10 8:42 ` Mel Gorman
2013-12-10 8:42 ` Mel Gorman
2013-12-10 9:06 ` Andrew Jones
2013-12-10 9:06 ` Andrew Jones
2013-12-09 7:09 ` [PATCH 18/18] sched: Add tracepoints related to NUMA task migration Mel Gorman
2013-12-09 7:09 ` Mel Gorman
2013-12-09 19:06 ` Rik van Riel
2013-12-09 19:06 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2013-12-10 15:51 [PATCH 00/17] NUMA balancing segmentation fault fixes and misc followups v4 Mel Gorman
2013-12-10 15:51 ` [PATCH 11/18] mm: fix TLB flush race between migration, and change_protection_range Mel Gorman
2013-12-10 15:51 ` Mel Gorman
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=20131211112137.GZ11295@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=athorlton@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
/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.