From: Linus Torvalds <torvalds@linux-foundation.org>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Andi Kleen <andi@firstfloor.org>,
lkml <linux-kernel@vger.kernel.org>,
Jan Beulich <jbeulich@novell.com>, Ingo Molnar <mingo@elte.hu>,
Zachary Amsden <zach@vmware.com>
Subject: Re: crashme fault
Date: Sun, 16 Sep 2007 11:12:23 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.0.999.0709161055070.16478@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0709161004080.16478@woody.linux-foundation.org>
On Sun, 16 Sep 2007, Linus Torvalds wrote:
>
> I'm really starting to suspect some early EM64T bug, and I also suspect
> that it's harmless but that we should just do the trivial patch to say "if
> the register state is in user mode, we don't care if the CPU says it was a
> kernel access".
Namely something like this..
The basic idea is that it's pointless to test for "error_code & PF_USER"
to decide whether we should oops or kill the process: the *real* issue is
whether we *can* kill the process or not. And that depends not on whether
the CPU claimed it was a user access or not, but on whether the register
state we'd return to is user-mode or not!
So anything that decides whether it should send a signal or do to the
"no_context" Ooops path should use "user_mode_vm(regs)" (yeah, I realize
that the "_vm" part is unnecessary on x86-64, but it doesn't hurt either,
and all of the issues are the same on 32/64-bit) which tests the right
thing.
Now, normally the USER bit in the error code should be the exact same
thing, except for
- Some CPU bug (microcode issue, whatever) where some complex fault
situation sets the wrong error code.
- user space accesses that caused a system page fault (ie a page fault
while handling another trap - possibly due to lazy page table setup
and having the LDT or some other CPU data structure in vmalloc space)
Now, the vmalloc space accesses should be handled separately anyway, so I
really wonder if it's some subtle CPU bug (I can't reproduce any problems
on my Core 2 Duo), but the point is that I think this patch really is
conceptually a real fix regardless, even if it _shouldn't_ matter.
Comments?
Randy, this replaces the hacky patch I sent, but also shuts up about the
odd thing you're hitting, so for testing your case further this may not be
the right thing. However, it would be nice to hear whether this just makes
"crashme" work properly for you without any side effects..
Linus
----
arch/x86_64/mm/fault.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86_64/mm/fault.c b/arch/x86_64/mm/fault.c
index 327c9f2..75270a0 100644
--- a/arch/x86_64/mm/fault.c
+++ b/arch/x86_64/mm/fault.c
@@ -87,7 +87,7 @@ static noinline int is_prefetch(struct pt_regs *regs, unsigned long addr,
instr = (unsigned char __user *)convert_rip_to_linear(current, regs);
max_instr = instr + 15;
- if (user_mode(regs) && instr >= (unsigned char *)TASK_SIZE)
+ if (user_mode_vm(regs) && instr >= (unsigned char *)TASK_SIZE)
return 0;
while (scan_more && instr < max_instr) {
@@ -320,7 +320,6 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs *regs,
info.si_code = SEGV_MAPERR;
-
/*
* We fault-in kernel-space virtual memory on-demand. The
* 'reference' page table is init_mm.pgd.
@@ -404,7 +403,7 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs *regs,
goto good_area;
if (!(vma->vm_flags & VM_GROWSDOWN))
goto bad_area;
- if (error_code & 4) {
+ if (error_code & PF_USER) {
/* Allow userspace just enough access below the stack pointer
* to let the 'enter' instruction work.
*/
@@ -558,7 +557,7 @@ out_of_memory:
goto again;
}
printk("VM: killing process %s\n", tsk->comm);
- if (error_code & 4)
+ if (user_mode_vm(regs))
do_group_exit(SIGKILL);
goto no_context;
@@ -566,7 +565,7 @@ do_sigbus:
up_read(&mm->mmap_sem);
/* Kernel mode? Handle exceptions or die */
- if (!(error_code & PF_USER))
+ if (!user_mode_vm(regs))
goto no_context;
tsk->thread.cr2 = address;
next prev parent reply other threads:[~2007-09-16 18:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-13 5:21 Randy Dunlap
2007-09-15 4:28 ` Linus Torvalds
2007-09-15 5:05 ` Randy Dunlap
2007-09-15 5:21 ` Randy Dunlap
2007-09-15 18:34 ` Andi Kleen
2007-09-15 18:40 ` Randy Dunlap
2007-09-15 19:44 ` Linus Torvalds
2007-09-15 19:53 ` Randy Dunlap
2007-09-15 22:15 ` Linus Torvalds
2007-09-15 22:47 ` Linus Torvalds
2007-09-15 23:47 ` Randy Dunlap
2007-09-16 0:34 ` Linus Torvalds
2007-09-16 16:40 ` Randy Dunlap
2007-09-16 17:14 ` Linus Torvalds
2007-09-16 18:12 ` Linus Torvalds [this message]
2007-09-17 5:06 ` Randy Dunlap
2007-09-17 5:28 ` Linus Torvalds
2007-09-17 14:29 ` Randy Dunlap
2007-09-17 14:53 ` Linus Torvalds
2007-09-17 20:05 ` Randy Dunlap
2007-09-16 18:28 ` Andi Kleen
2007-09-16 3:10 ` Andi Kleen
2007-09-16 15:53 ` Andrea Arcangeli
2007-09-16 16:17 ` Randy Dunlap
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=alpine.LFD.0.999.0709161055070.16478@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=randy.dunlap@oracle.com \
--cc=zach@vmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®