All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: Linux 3.19-rc3
Date: Mon, 12 Jan 2015 12:42:56 +0000	[thread overview]
Message-ID: <20150112124256.GB13360@arm.com> (raw)
In-Reply-To: <CA+55aFxBA6F4Kr89iZwPPeBnkiRO4GnrbUSd0CqVG-LD6ZQyiw@mail.gmail.com>

On Sat, Jan 10, 2015 at 07:51:03PM +0000, Linus Torvalds wrote:
> On Sat, Jan 10, 2015 at 5:37 AM, Will Deacon <will.deacon@arm.com> wrote:
> >>
> >> Will?
> >
> > I'm wondering if this is now broken in the fullmm case, because tlb->end
> > will be zero and we won't actually free any of the pages being unmapped
> > on task exit. Does that sound plausible?
> 
> But did anything change wrt fullmm? I don't see any changes wrt fullmm
> logic in generic code.

No, and now that I've had a play, the issue is worse than I thought.

> The arm64 code changed more, so maybe there was somethinig I missed.
> Again, arm64 uses tlb_end_vma() etc, so arm64 certainly triggers code
> that x86 does not.

Yup, and I think tlb_end_vma is also problematic. The issue is that we
reset the range in __tlb_end_vma, and therefore the batched pages don't
get freed. We also have an issue in the fullmm case, because
tlb_flush_mmu tests tlb->end != 0 before doing any freeing.

The fundamental problem is that tlb->end *only* indicates whether or not
TLB invalidation is required, *not* whether there are pages to be freed.
The advantage of the old need_flush flag was that it was sticky over
calls to things like tlb_flush_mmu_tlbonly.

> I can revert the commit that causes problems, but considering the
> performance impact on x86 (it would be a regression since 3.18), I
> would *really* like to fix the arm64 problem instead. So I'll wait
> with the revert for at least a week, I think, hoping that the arm64
> people figure this out. Sound reasonable?

Sure. I've put together the following patch which:

  (1) Uses tlb->end != 0 only as the predicate for TLB invalidation

  (2) Uses tlb->local.nr as the predicate for page freeing in
      tlb_flush_mmu_free

  (3) Ensures tlb->end != 0 for the fullmm case (I think this was a
      benign change introduced by my original patch, but this puts us
      back to 3.18 behaviour)

Since this effectively reverts f045bbb9fa1b, I've added Dave to Cc. It
should fix the leak without reintroducing the performance regression.

Linus: this moves the tlb->end check back into tlb_flush_mmu_tlbonly.
How much do you hate that?

Will

--->8

diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 08848050922e..db284bff29dc 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -136,8 +136,12 @@ static inline void __tlb_adjust_range(struct mmu_gather *tlb,
 
 static inline void __tlb_reset_range(struct mmu_gather *tlb)
 {
-	tlb->start = TASK_SIZE;
-	tlb->end = 0;
+	if (tlb->fullmm) {
+		tlb->start = tlb->end = ~0;
+	} else {
+		tlb->start = TASK_SIZE;
+		tlb->end = 0;
+	}
 }
 
 /*
diff --git a/mm/memory.c b/mm/memory.c
index c6565f00fb38..54f3a9b00956 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -235,6 +235,9 @@ void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long
 
 static void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
 {
+	if (!tlb->end)
+		return;
+
 	tlb_flush(tlb);
 	mmu_notifier_invalidate_range(tlb->mm, tlb->start, tlb->end);
 #ifdef CONFIG_HAVE_RCU_TABLE_FREE
@@ -247,7 +250,7 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
 {
 	struct mmu_gather_batch *batch;
 
-	for (batch = &tlb->local; batch; batch = batch->next) {
+	for (batch = &tlb->local; batch && batch->nr; batch = batch->next) {
 		free_pages_and_swap_cache(batch->pages, batch->nr);
 		batch->nr = 0;
 	}
@@ -256,9 +259,6 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
 
 void tlb_flush_mmu(struct mmu_gather *tlb)
 {
-	if (!tlb->end)
-		return;
-
 	tlb_flush_mmu_tlbonly(tlb);
 	tlb_flush_mmu_free(tlb);
 }

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Laszlo Ersek <lersek@redhat.com>,
	Mark Langsdorf <mlangsdo@redhat.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Steve Capper <steve.capper@linaro.org>,
	"vishnu.ps@samsung.com" <vishnu.ps@samsung.com>,
	main kernel list <linux-kernel@vger.kernel.org>,
	arm kernel list <linux-arm-kernel@lists.infradead.org>,
	Kyle McMartin <kmcmarti@redhat.com>,
	dave@sr71.net
Subject: Re: Linux 3.19-rc3
Date: Mon, 12 Jan 2015 12:42:56 +0000	[thread overview]
Message-ID: <20150112124256.GB13360@arm.com> (raw)
In-Reply-To: <CA+55aFxBA6F4Kr89iZwPPeBnkiRO4GnrbUSd0CqVG-LD6ZQyiw@mail.gmail.com>

On Sat, Jan 10, 2015 at 07:51:03PM +0000, Linus Torvalds wrote:
> On Sat, Jan 10, 2015 at 5:37 AM, Will Deacon <will.deacon@arm.com> wrote:
> >>
> >> Will?
> >
> > I'm wondering if this is now broken in the fullmm case, because tlb->end
> > will be zero and we won't actually free any of the pages being unmapped
> > on task exit. Does that sound plausible?
> 
> But did anything change wrt fullmm? I don't see any changes wrt fullmm
> logic in generic code.

No, and now that I've had a play, the issue is worse than I thought.

> The arm64 code changed more, so maybe there was somethinig I missed.
> Again, arm64 uses tlb_end_vma() etc, so arm64 certainly triggers code
> that x86 does not.

Yup, and I think tlb_end_vma is also problematic. The issue is that we
reset the range in __tlb_end_vma, and therefore the batched pages don't
get freed. We also have an issue in the fullmm case, because
tlb_flush_mmu tests tlb->end != 0 before doing any freeing.

The fundamental problem is that tlb->end *only* indicates whether or not
TLB invalidation is required, *not* whether there are pages to be freed.
The advantage of the old need_flush flag was that it was sticky over
calls to things like tlb_flush_mmu_tlbonly.

> I can revert the commit that causes problems, but considering the
> performance impact on x86 (it would be a regression since 3.18), I
> would *really* like to fix the arm64 problem instead. So I'll wait
> with the revert for at least a week, I think, hoping that the arm64
> people figure this out. Sound reasonable?

Sure. I've put together the following patch which:

  (1) Uses tlb->end != 0 only as the predicate for TLB invalidation

  (2) Uses tlb->local.nr as the predicate for page freeing in
      tlb_flush_mmu_free

  (3) Ensures tlb->end != 0 for the fullmm case (I think this was a
      benign change introduced by my original patch, but this puts us
      back to 3.18 behaviour)

Since this effectively reverts f045bbb9fa1b, I've added Dave to Cc. It
should fix the leak without reintroducing the performance regression.

Linus: this moves the tlb->end check back into tlb_flush_mmu_tlbonly.
How much do you hate that?

Will

--->8

diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 08848050922e..db284bff29dc 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -136,8 +136,12 @@ static inline void __tlb_adjust_range(struct mmu_gather *tlb,
 
 static inline void __tlb_reset_range(struct mmu_gather *tlb)
 {
-	tlb->start = TASK_SIZE;
-	tlb->end = 0;
+	if (tlb->fullmm) {
+		tlb->start = tlb->end = ~0;
+	} else {
+		tlb->start = TASK_SIZE;
+		tlb->end = 0;
+	}
 }
 
 /*
diff --git a/mm/memory.c b/mm/memory.c
index c6565f00fb38..54f3a9b00956 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -235,6 +235,9 @@ void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long
 
 static void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
 {
+	if (!tlb->end)
+		return;
+
 	tlb_flush(tlb);
 	mmu_notifier_invalidate_range(tlb->mm, tlb->start, tlb->end);
 #ifdef CONFIG_HAVE_RCU_TABLE_FREE
@@ -247,7 +250,7 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
 {
 	struct mmu_gather_batch *batch;
 
-	for (batch = &tlb->local; batch; batch = batch->next) {
+	for (batch = &tlb->local; batch && batch->nr; batch = batch->next) {
 		free_pages_and_swap_cache(batch->pages, batch->nr);
 		batch->nr = 0;
 	}
@@ -256,9 +259,6 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
 
 void tlb_flush_mmu(struct mmu_gather *tlb)
 {
-	if (!tlb->end)
-		return;
-
 	tlb_flush_mmu_tlbonly(tlb);
 	tlb_flush_mmu_free(tlb);
 }

  reply	other threads:[~2015-01-12 12:42 UTC|newest]

Thread overview: 154+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-06  1:46 Linux 3.19-rc3 Linus Torvalds
2015-01-06  2:46 ` Dave Jones
2015-01-06  8:18   ` Takashi Iwai
2015-01-06  9:45   ` Jiri Kosina
2015-01-08 12:51 ` Mark Langsdorf
2015-01-08 12:51   ` Mark Langsdorf
2015-01-08 13:45   ` Catalin Marinas
2015-01-08 13:45     ` Catalin Marinas
2015-01-08 17:29     ` Mark Langsdorf
2015-01-08 17:29       ` Mark Langsdorf
2015-01-08 17:34       ` Catalin Marinas
2015-01-08 17:34         ` Catalin Marinas
2015-01-08 18:48         ` Mark Langsdorf
2015-01-08 18:48           ` Mark Langsdorf
2015-01-08 19:21           ` Linus Torvalds
2015-01-08 19:21             ` Linus Torvalds
2015-01-09 23:27             ` Catalin Marinas
2015-01-09 23:27               ` Catalin Marinas
2015-01-10  0:35               ` Kirill A. Shutemov
2015-01-10  0:35                 ` Kirill A. Shutemov
2015-01-10  2:27                 ` Linus Torvalds
2015-01-10  2:27                   ` Linus Torvalds
2015-01-10  2:51                   ` David Lang
2015-01-10  2:51                     ` David Lang
2015-01-10  3:06                     ` Linus Torvalds
2015-01-10  3:06                       ` Linus Torvalds
2015-01-10 10:46                       ` Andreas Mohr
2015-01-10 10:46                         ` Andreas Mohr
2015-01-10 19:42                         ` Linus Torvalds
2015-01-10 19:42                           ` Linus Torvalds
2015-01-13  3:33                     ` Rik van Riel
2015-01-13  3:33                       ` Rik van Riel
2015-01-13 10:28                       ` Catalin Marinas
2015-01-13 10:28                         ` Catalin Marinas
2015-01-10  3:17                   ` Tony Luck
2015-01-10  3:17                     ` Tony Luck
2015-01-10 20:16                   ` Arnd Bergmann
2015-01-10 20:16                     ` Arnd Bergmann
2015-01-10 21:00                     ` Linus Torvalds
2015-01-10 21:00                       ` Linus Torvalds
2015-01-10 21:36                       ` Arnd Bergmann
2015-01-10 21:36                         ` Arnd Bergmann
2015-01-10 21:48                         ` Linus Torvalds
2015-01-10 21:48                           ` Linus Torvalds
2015-01-12 11:37                         ` Kirill A. Shutemov
2015-01-12 11:37                           ` Kirill A. Shutemov
2015-01-12 12:18                         ` Catalin Marinas
2015-01-12 12:18                           ` Catalin Marinas
2015-01-12 13:57                           ` Arnd Bergmann
2015-01-12 13:57                             ` Arnd Bergmann
2015-01-12 14:23                             ` Catalin Marinas
2015-01-12 14:23                               ` Catalin Marinas
2015-01-12 15:42                               ` Arnd Bergmann
2015-01-12 15:42                                 ` Arnd Bergmann
2015-01-12 11:53                     ` Catalin Marinas
2015-01-12 11:53                       ` Catalin Marinas
2015-01-12 13:15                       ` Arnd Bergmann
2015-01-12 13:15                         ` Arnd Bergmann
2015-01-08 15:08   ` Michal Hocko
2015-01-08 15:08     ` Michal Hocko
2015-01-08 15:08     ` Michal Hocko
2015-01-08 16:37     ` Mark Langsdorf
2015-01-08 16:37       ` Mark Langsdorf
2015-01-08 16:37       ` Mark Langsdorf
2015-01-09 15:56       ` Michal Hocko
2015-01-09 15:56         ` Michal Hocko
2015-01-09 15:56         ` Michal Hocko
2015-01-09 12:13   ` Mark Rutland
2015-01-09 12:13     ` Mark Rutland
2015-01-09 14:19     ` Steve Capper
2015-01-09 14:19       ` Steve Capper
2015-01-09 14:27       ` Mark Langsdorf
2015-01-09 14:27         ` Mark Langsdorf
2015-01-09 17:57         ` Mark Rutland
2015-01-09 17:57           ` Mark Rutland
2015-01-09 18:37           ` Marc Zyngier
2015-01-09 18:37             ` Marc Zyngier
2015-01-09 19:43             ` Will Deacon
2015-01-09 19:43               ` Will Deacon
2015-01-10  3:29               ` Laszlo Ersek
2015-01-10  3:29                 ` Laszlo Ersek
2015-01-10  4:39                 ` Linus Torvalds
2015-01-10  4:39                   ` Linus Torvalds
2015-01-10 13:37                   ` Will Deacon
2015-01-10 13:37                     ` Will Deacon
2015-01-10 19:47                     ` Laszlo Ersek
2015-01-10 19:47                       ` Laszlo Ersek
2015-01-10 19:56                       ` Linus Torvalds
2015-01-10 19:56                         ` Linus Torvalds
2015-01-10 20:08                         ` Laszlo Ersek
2015-01-10 20:08                           ` Laszlo Ersek
2015-01-10 19:51                     ` Linus Torvalds
2015-01-10 19:51                       ` Linus Torvalds
2015-01-12 12:42                       ` Will Deacon [this message]
2015-01-12 12:42                         ` Will Deacon
2015-01-12 13:22                         ` Mark Langsdorf
2015-01-12 13:22                           ` Mark Langsdorf
2015-01-12 19:03                         ` Dave Hansen
2015-01-12 19:03                           ` Dave Hansen
2015-01-12 19:06                         ` Linus Torvalds
2015-01-12 19:06                           ` Linus Torvalds
2015-01-12 19:07                           ` Linus Torvalds
2015-01-12 19:07                             ` Linus Torvalds
2015-01-12 19:24                             ` Will Deacon
2015-01-12 19:24                               ` Will Deacon
2015-01-10 15:22                 ` Kyle McMartin
2015-01-10 15:22                   ` Kyle McMartin
  -- strict thread matches above, loose matches on Subject: below --
2015-01-06  4:49 Sedat Dilek
2015-01-06  9:34 ` Sedat Dilek
2015-01-06  9:56   ` Takashi Iwai
2015-01-06 10:06     ` Sedat Dilek
2015-01-06 10:28       ` Takashi Iwai
2015-01-06 10:31         ` Sedat Dilek
2015-01-06 10:37           ` Takashi Iwai
2015-01-06 10:42             ` Sedat Dilek
2015-01-06  9:59   ` Peter Zijlstra
2015-01-06  9:40 ` Peter Zijlstra
2015-01-06  9:42   ` Sedat Dilek
2015-01-06  9:57     ` Sedat Dilek
2015-01-06 10:06       ` Peter Zijlstra
2015-01-06 10:18         ` Sedat Dilek
2015-01-06 11:01           ` Peter Zijlstra
2015-01-06 11:07             ` Kent Overstreet
2015-01-06 11:25               ` Sedat Dilek
2015-01-06 11:40                 ` Kent Overstreet
2015-01-06 12:51                   ` Sedat Dilek
2015-01-06 11:42               ` Peter Zijlstra
2015-01-06 11:48                 ` Peter Zijlstra
2015-01-06 12:01                   ` Kent Overstreet
2015-01-06 12:20                     ` Peter Zijlstra
2015-01-06 12:45                       ` Kent Overstreet
2015-01-06 12:55                       ` Peter Hurley
2015-01-06 17:38                         ` Paul E. McKenney
2015-01-06 17:58                           ` Peter Hurley
2015-01-06 19:25                             ` Paul E. McKenney
2015-01-06 19:57                               ` Peter Hurley
2015-01-06 20:47                                 ` Paul E. McKenney
2015-01-20  0:30                                   ` Paul E. McKenney
2015-01-20 14:03                                     ` Peter Hurley
2015-02-02 16:11                                       ` Paul E. McKenney
2015-02-02 19:03                                         ` Peter Hurley
2015-02-02 19:33                                           ` Paul E. McKenney
2015-01-06 11:56                 ` Kent Overstreet
2015-01-06 12:16                   ` Peter Zijlstra
2015-01-06 12:43                     ` Kent Overstreet
2015-01-06 13:03                       ` Peter Zijlstra
2015-01-06 13:28                         ` Kent Overstreet
2015-01-13 15:23                           ` Peter Zijlstra
2015-01-06 11:58               ` Peter Zijlstra
2015-01-06 12:18                 ` Kent Overstreet
2015-01-16 16:56               ` Peter Hurley
2015-01-16 17:00                 ` Chris Mason
2015-01-16 18:58                   ` Peter Hurley
2015-01-06 10:29   ` Sedat Dilek

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=20150112124256.GB13360@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.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.