* x86_64 segfault error codes
@ 2005-12-14 18:17 Dave
2005-12-14 18:31 ` Andi Kleen
0 siblings, 1 reply; 8+ messages in thread
From: Dave @ 2005-12-14 18:17 UTC (permalink / raw)
To: linux-kernel
For segfault error codes on x86_64, bits 0-3 are documented in
arch/x86_64/mm/fault.c. However, I am getting error 0x14 and 0x15 with this
particular user app when it segfaults. Is bit 4 valid and what does that
imply?
xxx-001[2085]: segfault at 0000007f960ea86b rip 0000007f960ea86b rsp
0000007fbfffe968 error 14
xxx-001[2091]: segfault at 0000007fbfffe670 rip 0000007fbfffe670 rsp
0000007fbfffe668 error 15
--
-= Dave =-
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86_64 segfault error codes
2005-12-14 18:17 x86_64 segfault error codes Dave
@ 2005-12-14 18:31 ` Andi Kleen
2005-12-14 19:24 ` Dave
0 siblings, 1 reply; 8+ messages in thread
From: Andi Kleen @ 2005-12-14 18:31 UTC (permalink / raw)
To: Dave; +Cc: linux-kernel
Dave <dave.jiang@gmail.com> writes:
> For segfault error codes on x86_64, bits 0-3 are documented in
> arch/x86_64/mm/fault.c. However, I am getting error 0x14 and 0x15 with this
> particular user app when it segfaults. Is bit 4 valid and what does that
> imply?
bit 4 is documented too in 2.6. It means it was an instruction fetch.
The error code is just the architectural error code for page faults
BTW, see the Intel and AMD manuals for details.
-Andi
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86_64 segfault error codes
2005-12-14 18:31 ` Andi Kleen
@ 2005-12-14 19:24 ` Dave
2005-12-14 19:58 ` Andi Kleen
0 siblings, 1 reply; 8+ messages in thread
From: Dave @ 2005-12-14 19:24 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Ah ok, thx! Looks like the comment in mm/fault.c is wrong then.... It
says bit 3 is instruction fetch and no mention of bit 4.
On 14 Dec 2005 19:31:07 +0100, Andi Kleen <ak@suse.de> wrote:
> Dave <dave.jiang@gmail.com> writes:
>
> > For segfault error codes on x86_64, bits 0-3 are documented in
> > arch/x86_64/mm/fault.c. However, I am getting error 0x14 and 0x15 with this
> > particular user app when it segfaults. Is bit 4 valid and what does that
> > imply?
>
> bit 4 is documented too in 2.6. It means it was an instruction fetch.
> The error code is just the architectural error code for page faults
> BTW, see the Intel and AMD manuals for details.
>
> -Andi
>
--
-= Dave =-
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86_64 segfault error codes
2005-12-14 19:24 ` Dave
@ 2005-12-14 19:58 ` Andi Kleen
2005-12-14 20:09 ` Dave
2005-12-15 9:55 ` Hugh Dickins
0 siblings, 2 replies; 8+ messages in thread
From: Andi Kleen @ 2005-12-14 19:58 UTC (permalink / raw)
To: Dave; +Cc: Andi Kleen, linux-kernel
On Wed, Dec 14, 2005 at 12:24:42PM -0700, Dave wrote:
> Ah ok, thx! Looks like the comment in mm/fault.c is wrong then.... It
> says bit 3 is instruction fetch and no mention of bit 4.
Don't know what kernel you're looking at, but 2.6.15rc5 has
* bit 0 == 0 means no page found, 1 means protection fault
* bit 1 == 0 means read, 1 means write
* bit 2 == 0 means kernel, 1 means user-mode
* bit 3 == 1 means use of reserved bit detected
* bit 4 == 1 means fault was an instruction fetch
-Andi
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86_64 segfault error codes
2005-12-14 19:58 ` Andi Kleen
@ 2005-12-14 20:09 ` Dave
2005-12-15 9:55 ` Hugh Dickins
1 sibling, 0 replies; 8+ messages in thread
From: Dave @ 2005-12-14 20:09 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
On 12/14/05, Andi Kleen <ak@suse.de> wrote:
> On Wed, Dec 14, 2005 at 12:24:42PM -0700, Dave wrote:
> > Ah ok, thx! Looks like the comment in mm/fault.c is wrong then.... It
> > says bit 3 is instruction fetch and no mention of bit 4.
>
> Don't know what kernel you're looking at, but 2.6.15rc5 has
>
> * bit 0 == 0 means no page found, 1 means protection fault
> * bit 1 == 0 means read, 1 means write
> * bit 2 == 0 means kernel, 1 means user-mode
> * bit 3 == 1 means use of reserved bit detected
> * bit 4 == 1 means fault was an instruction fetch
Ah sorry. Was looking at 2.6.14.
--
-= Dave =-
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86_64 segfault error codes
2005-12-14 19:58 ` Andi Kleen
2005-12-14 20:09 ` Dave
@ 2005-12-15 9:55 ` Hugh Dickins
2005-12-15 9:59 ` Andi Kleen
2005-12-15 14:49 ` Andi Kleen
1 sibling, 2 replies; 8+ messages in thread
From: Hugh Dickins @ 2005-12-15 9:55 UTC (permalink / raw)
To: Andi Kleen; +Cc: Dave, linux-kernel
On Wed, 14 Dec 2005, Andi Kleen wrote:
>
> Don't know what kernel you're looking at, but 2.6.15rc5 has
>
> * bit 0 == 0 means no page found, 1 means protection fault
> * bit 1 == 0 means read, 1 means write
> * bit 2 == 0 means kernel, 1 means user-mode
> * bit 3 == 1 means use of reserved bit detected
> * bit 4 == 1 means fault was an instruction fetch
I can't see it there in 2.6.15-rc5 or 2.6.15-rc5-git; but it is there
in 2.6.15-rc5-mm3: which seems to contains a lot of x86_64 patches,
perhaps some of which you're expecting already to be in 2.6.15?
Hugh
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86_64 segfault error codes
2005-12-15 9:55 ` Hugh Dickins
@ 2005-12-15 9:59 ` Andi Kleen
2005-12-15 14:49 ` Andi Kleen
1 sibling, 0 replies; 8+ messages in thread
From: Andi Kleen @ 2005-12-15 9:59 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Andi Kleen, Dave, linux-kernel
On Thu, Dec 15, 2005 at 09:55:40AM +0000, Hugh Dickins wrote:
> On Wed, 14 Dec 2005, Andi Kleen wrote:
> >
> > Don't know what kernel you're looking at, but 2.6.15rc5 has
> >
> > * bit 0 == 0 means no page found, 1 means protection fault
> > * bit 1 == 0 means read, 1 means write
> > * bit 2 == 0 means kernel, 1 means user-mode
> > * bit 3 == 1 means use of reserved bit detected
> > * bit 4 == 1 means fault was an instruction fetch
>
> I can't see it there in 2.6.15-rc5 or 2.6.15-rc5-git; but it is there
> in 2.6.15-rc5-mm3: which seems to contains a lot of x86_64 patches,
> perhaps some of which you're expecting already to be in 2.6.15?
Yah it's only in the 2.6.16 queue. Sorry for the confusion.
Anyways nobody should rely on these comments. If you want the details
look at the architecture manuals.
-Andi
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86_64 segfault error codes
2005-12-15 9:55 ` Hugh Dickins
2005-12-15 9:59 ` Andi Kleen
@ 2005-12-15 14:49 ` Andi Kleen
1 sibling, 0 replies; 8+ messages in thread
From: Andi Kleen @ 2005-12-15 14:49 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Andi Kleen, Dave, linux-kernel
FWIW I converted the magic numbers now to defines in the source
and deleted the comment (since kernel source is no replacement
for an architecture manual)
-Andi
Review welcome. I think I didn't do any mistakes though
and the result at least boots.
Convert page fault error codes to symbolic constants.
Much better to deal with these than with the magic numbers.
And remove the comment describing the bits - kernel source
is no replacement for an architecture manual.
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux/arch/x86_64/mm/fault.c
===================================================================
--- linux.orig/arch/x86_64/mm/fault.c
+++ linux/arch/x86_64/mm/fault.c
@@ -35,6 +35,13 @@
#include <asm-generic/sections.h>
#include <asm/kdebug.h>
+/* Page fault error code bits */
+#define PF_PROT (1<<0) /* or no page found */
+#define PF_WRITE (1<<1)
+#define PF_USER (1<<2)
+#define PF_RSVD (1<<3)
+#define PF_INSTR (1<<4)
+
void bust_spinlocks(int yes)
{
int loglevel_save = console_loglevel;
@@ -68,7 +75,7 @@ static noinline int is_prefetch(struct p
unsigned char *max_instr;
/* If it was a exec fault ignore */
- if (error_code & (1<<4))
+ if (error_code & PF_INSTR)
return 0;
instr = (unsigned char *)convert_rip_to_linear(current, regs);
@@ -293,13 +300,6 @@ int exception_trace = 1;
* This routine handles page faults. It determines the address,
* and the problem, and then passes it off to one of the appropriate
* routines.
- *
- * error_code:
- * bit 0 == 0 means no page found, 1 means protection fault
- * bit 1 == 0 means read, 1 means write
- * bit 2 == 0 means kernel, 1 means user-mode
- * bit 3 == 1 means use of reserved bit detected
- * bit 4 == 1 means fault was an instruction fetch
*/
asmlinkage void __kprobes do_page_fault(struct pt_regs *regs,
unsigned long error_code)
@@ -350,7 +350,7 @@ asmlinkage void __kprobes do_page_fault(
* is always initialized because it's shared with the main
* kernel text. Only vmalloc may need PML4 syncups.
*/
- if (!(error_code & 0xd) &&
+ if (!(error_code & (PF_RSVD|PF_KERNEL|PF_PROT)) &&
((address >= VMALLOC_START && address < VMALLOC_END))) {
if (vmalloc_fault(address) < 0)
goto bad_area_nosemaphore;
@@ -363,7 +363,7 @@ asmlinkage void __kprobes do_page_fault(
goto bad_area_nosemaphore;
}
- if (unlikely(error_code & (1 << 3)))
+ if (unlikely(error_code & PF_RSVD))
pgtable_bad(address, regs, error_code);
/*
@@ -390,7 +390,7 @@ asmlinkage void __kprobes do_page_fault(
* thus avoiding the deadlock.
*/
if (!down_read_trylock(&mm->mmap_sem)) {
- if ((error_code & 4) == 0 &&
+ if ((error_code & PF_KERNEL) == 0 &&
!search_exception_tables(regs->rip))
goto bad_area_nosemaphore;
down_read(&mm->mmap_sem);
@@ -417,17 +417,17 @@ asmlinkage void __kprobes do_page_fault(
good_area:
info.si_code = SEGV_ACCERR;
write = 0;
- switch (error_code & 3) {
+ switch (error_code & (PF_PROT|PF_READ) {
default: /* 3: write, present */
/* fall through */
- case 2: /* write, not present */
+ case PF_WRITE: /* write, not present */
if (!(vma->vm_flags & VM_WRITE))
goto bad_area;
write++;
break;
- case 1: /* read, present */
+ case PF_PROT: /* read, present */
goto bad_area;
- case 0: /* read, not present */
+ case 0: /* read, not present */
if (!(vma->vm_flags & (VM_READ | VM_EXEC)))
goto bad_area;
}
@@ -462,7 +462,7 @@ bad_area:
bad_area_nosemaphore:
/* User mode accesses just cause a SIGSEGV */
- if (error_code & 4) {
+ if (error_code & PF_USER) {
if (is_prefetch(regs, address, error_code))
return;
@@ -478,7 +478,7 @@ bad_area_nosemaphore:
if (exception_trace && unhandled_signal(tsk, SIGSEGV)) {
printk(
- "%s%s[%d]: segfault at %016lx rip %016lx rsp %016lx error %lx\n",
+ "%s%s[%d]: segfault at %016lx rip %016lx rsp %016lx error %x\n",
tsk->pid > 1 ? KERN_INFO : KERN_EMERG,
tsk->comm, tsk->pid, address, regs->rip,
regs->rsp, error_code);
@@ -558,7 +558,7 @@ do_sigbus:
up_read(&mm->mmap_sem);
/* Kernel mode? Handle exceptions or die */
- if (!(error_code & 4))
+ if (!(error_code & PF_USER))
goto no_context;
tsk->thread.cr2 = address;
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-12-15 14:49 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-14 18:17 x86_64 segfault error codes Dave
2005-12-14 18:31 ` Andi Kleen
2005-12-14 19:24 ` Dave
2005-12-14 19:58 ` Andi Kleen
2005-12-14 20:09 ` Dave
2005-12-15 9:55 ` Hugh Dickins
2005-12-15 9:59 ` Andi Kleen
2005-12-15 14:49 ` Andi Kleen
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®