linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Stanislav Meduna <stano@meduna.org>,
	"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	Hai Huang <hhuang@redhat.com>
Subject: [PATCH] mm: fix up a spurious page fault whenever it happens
Date: Wed, 22 May 2013 13:41:11 -0400	[thread overview]
Message-ID: <20130522134111.33a695c5@cuia.bos.redhat.com> (raw)
In-Reply-To: <CA+55aFxMqvDvcVtLW-yD2PuU_CcjPOC30Zk07Kuk6S25WCzbHQ@mail.gmail.com>

On Wed, 22 May 2013 08:01:43 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, May 22, 2013 at 5:33 AM, Rik van Riel <riel@redhat.com> wrote:

> > Can you test the attached patch?
> 
> I think you should also remove the
> 
>         if (flags & FAULT_FLAG_WRITE)
> 
> test in handle_pte_fault(). Because if it's spurious, it might happen
> on reads too, I think.

Here you are. I wonder if the conditional was put in because we
originally did a global TLB flush (with IPIs) from the spurious
fault handler...

Stanislav, could you add this patch to your test?

---8<---
Subject: [PATCH] mm: fix up a spurious page fault whenever it happens

The kernel currently only handles spurious page faults when they
"should" happen, but potentially this is not the only situation
where they could happen.

The spurious fault handler only flushes an entry from the local
TLB; this should be a rare event with minimal side effects.

This patch removes the conditional, allowing the spurious fault
handler to execute whenever a spurious page fault happens, which
should eliminate infinite page fault loops.

Signed-off-by: Rik van Riel <riel@redhat.com>
Reported-by: Stanislav Meduna <stano@meduna.org>
---
 mm/memory.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 6dc1882..962477d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3744,13 +3744,11 @@ int handle_pte_fault(struct mm_struct *mm,
 		update_mmu_cache(vma, address, pte);
 	} else {
 		/*
-		 * This is needed only for protection faults but the arch code
-		 * is not yet telling us if this is a protection fault or not.
-		 * This still avoids useless tlb flushes for .text page faults
-		 * with threads.
+		 * The page table entry is good, but the CPU generated a
+		 * spurious fault. Invalidate the corresponding TLB entry
+		 * on this CPU, so the next access can succeed.
 		 */
-		if (flags & FAULT_FLAG_WRITE)
-			flush_tlb_fix_spurious_fault(vma, address);
+		flush_tlb_fix_spurious_fault(vma, address);
 	}
 unlock:
 	pte_unmap_unlock(pte, ptl);

  reply	other threads:[~2013-05-22 17:43 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-17  8:42 [PATCH - sort of] x86: Livelock in handle_pte_fault Stanislav Meduna
2013-05-22  0:39 ` Steven Rostedt
2013-05-22  7:32   ` Stanislav Meduna
2013-05-22 12:33   ` Rik van Riel
2013-05-22 15:01     ` Linus Torvalds
2013-05-22 17:41       ` Rik van Riel [this message]
2013-05-22 18:04         ` [PATCH] mm: fix up a spurious page fault whenever it happens Stanislav Meduna
2013-05-22 18:11           ` Steven Rostedt
2013-05-22 18:21             ` Stanislav Meduna
2013-05-22 18:35               ` Rik van Riel
2013-05-22 18:42                 ` H. Peter Anvin
2013-05-22 18:43                   ` Rik van Riel
2013-05-23  8:07                     ` Stanislav Meduna
2013-05-23 12:19                       ` Rik van Riel
2013-05-23 13:29                         ` Steven Rostedt
2013-05-23 15:06                           ` H. Peter Anvin
2013-05-23 15:27                             ` Steven Rostedt
2013-05-23 17:24                               ` H. Peter Anvin
2013-05-23 17:36                                 ` Steven Rostedt
2013-05-23 17:38                                   ` H. Peter Anvin
2013-05-24  8:29                         ` Stanislav Meduna
2013-05-24 10:28                           ` Stanislav Meduna
2013-05-24 13:06                           ` Rik van Riel
2013-05-24 13:55                             ` Stanislav Meduna
2013-05-24 14:23                               ` Stanislav Meduna
2013-06-16 21:34                             ` Stanislav Meduna
2013-06-18 19:13                               ` Stanislav Meduna
2013-06-19  5:20                                 ` Linus Torvalds
2013-06-19  7:36                                   ` Stanislav Meduna
2013-06-19  8:06                                     ` Peter Zijlstra
2013-06-20 17:50                                       ` Stanislav Meduna
2013-05-23 14:45                       ` Linus Torvalds
2013-05-23 14:50                         ` Linus Torvalds
2013-05-23 15:03                           ` Stanislav Meduna
2013-05-22 18:47                 ` Stanislav Meduna

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=20130522134111.33a695c5@cuia.bos.redhat.com \
    --to=riel@redhat.com \
    --cc=hhuang@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=stano@meduna.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).