Re: [PATCH] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages

[Andi Kleen]

> > And printing the offset into a mapping also always allows to find the 
> > correct fault point in a library even with randomized mappings. Previously
> > there was no way to actually find the correct code address inside
> > the randomized mapping.
> > 
> > Relies on earlier patch to shorten the printk formats.
> > 
> > They are often now longer than 80 characters, but I think that's worth 
> > it.
> 
> why not make it multi-line? that way the %lx hack wouldnt be needed 
> either.

I prefer it single-line. I also disagree on %lx being a hack.

> 
> > +void print_vma_addr(char *prefix, unsigned long ip)
> > +{
> > +   struct mm_struct *mm = current->mm;
> > +   struct vm_area_struct *vma;
> > +   down_read(>mmap_sem);
> > +   vma = find_vma(mm, ip);
> 
> grumble. Proper CodingStyle please.


Looks fine to me. If you mean the new line after variables -- that was always 
optional.

Anyways I'll repost with the error check.

Also it seems like you did apply only parts of the patchkit. If you do that can
you send a list of what patches you didn't add, otherwise it'll be messy to 
figure
this out from here.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages

[Ingo Molnar]

* Andi Kleen <[EMAIL PROTECTED]> wrote:

> They now look like
> 
> hal-resmgr[13791]: segfault at 3c rip 2b9c8caec182 rsp 7fff1e825d30 
> error 4 in libacl.so.1.1.0[2b9c8caea000+6000]
> 
> This makes it easier to pinpoint bugs to specific libraries.

yep, that's really useful.

I think the patch needs one more iteration though:

> And printing the offset into a mapping also always allows to find the 
> correct fault point in a library even with randomized mappings. Previously
> there was no way to actually find the correct code address inside
> the randomized mapping.
> 
> Relies on earlier patch to shorten the printk formats.
> 
> They are often now longer than 80 characters, but I think that's worth 
> it.

why not make it multi-line? that way the %lx hack wouldnt be needed 
either.

> +void print_vma_addr(char *prefix, unsigned long ip)
> +{
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma;
> + down_read(>mmap_sem);
> + vma = find_vma(mm, ip);

grumble. Proper CodingStyle please.

> + if (buf) {
> + char *p, *s;
> + p = d_path(f->f_dentry, f->f_vfsmnt, buf, PAGE_SIZE);

this one too.

> + if (show_unhandled_signals && printk_ratelimit()) {
> + printk("%s[%d] bad frame in %s frame:%p ip:%lx sp:%lx orax:%lx",
>  me->comm,me->pid,where,frame,regs->ip,regs->sp,regs->orig_ax);

and this.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages

[Ingo Molnar]

* Andi Kleen [EMAIL PROTECTED] wrote:

 They now look like
 
 hal-resmgr[13791]: segfault at 3c rip 2b9c8caec182 rsp 7fff1e825d30 
 error 4 in libacl.so.1.1.0[2b9c8caea000+6000]
 
 This makes it easier to pinpoint bugs to specific libraries.

yep, that's really useful.

I think the patch needs one more iteration though:

 And printing the offset into a mapping also always allows to find the 
 correct fault point in a library even with randomized mappings. Previously
 there was no way to actually find the correct code address inside
 the randomized mapping.
 
 Relies on earlier patch to shorten the printk formats.
 
 They are often now longer than 80 characters, but I think that's worth 
 it.

why not make it multi-line? that way the %lx hack wouldnt be needed 
either.

 +void print_vma_addr(char *prefix, unsigned long ip)
 +{
 + struct mm_struct *mm = current-mm;
 + struct vm_area_struct *vma;
 + down_read(mm-mmap_sem);
 + vma = find_vma(mm, ip);

grumble. Proper CodingStyle please.

 + if (buf) {
 + char *p, *s;
 + p = d_path(f-f_dentry, f-f_vfsmnt, buf, PAGE_SIZE);

this one too.

 + if (show_unhandled_signals  printk_ratelimit()) {
 + printk(%s[%d] bad frame in %s frame:%p ip:%lx sp:%lx orax:%lx,
  me-comm,me-pid,where,frame,regs-ip,regs-sp,regs-orig_ax);

and this.

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages

[Andi Kleen]

  And printing the offset into a mapping also always allows to find the 
  correct fault point in a library even with randomized mappings. Previously
  there was no way to actually find the correct code address inside
  the randomized mapping.
  
  Relies on earlier patch to shorten the printk formats.
  
  They are often now longer than 80 characters, but I think that's worth 
  it.
 
 why not make it multi-line? that way the %lx hack wouldnt be needed 
 either.

I prefer it single-line. I also disagree on %lx being a hack.

 
  +void print_vma_addr(char *prefix, unsigned long ip)
  +{
  +   struct mm_struct *mm = current-mm;
  +   struct vm_area_struct *vma;
  +   down_read(mm-mmap_sem);
  +   vma = find_vma(mm, ip);
 
 grumble. Proper CodingStyle please.


Looks fine to me. If you mean the new line after variables -- that was always 
optional.

Anyways I'll repost with the error check.

Also it seems like you did apply only parts of the patchkit. If you do that can
you send a list of what patches you didn't add, otherwise it'll be messy to 
figure
this out from here.

-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages

[Eric Dumazet]

Andi Kleen a écrit :

They now look like

hal-resmgr[13791]: segfault at 3c rip 2b9c8caec182 rsp 7fff1e825d30 error 4 in 
libacl.so.1.1.0[2b9c8caea000+6000]

This makes it easier to pinpoint bugs to specific libraries. 

And printing the offset into a mapping also always allows to find the 
correct fault point in a library even with randomized mappings. Previously

there was no way to actually find the correct code address inside
the randomized mapping.

Relies on earlier patch to shorten the printk formats.

They are often now longer than 80 characters, but I think that's worth 
it.


Patch for i386 and x86-64.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 arch/x86/kernel/signal_32.c |7 +--
 arch/x86/kernel/signal_64.c |7 +--
 arch/x86/kernel/traps_32.c  |7 +--
 arch/x86/mm/fault_32.c  |4 +++-
 include/linux/mm.h  |1 +
 mm/memory.c |   27 +++
 6 files changed, 46 insertions(+), 7 deletions(-)

Index: linux/include/linux/mm.h
===
--- linux.orig/include/linux/mm.h
+++ linux/include/linux/mm.h
@@ -1145,6 +1145,7 @@ extern int randomize_va_space;
 #endif
 
 const char * arch_vma_name(struct vm_area_struct *vma);

+void print_vma_addr(char *prefix, unsigned long rip);
 
 struct page *sparse_mem_map_populate(unsigned long pnum, int nid);

 pgd_t *vmemmap_pgd_populate(unsigned long addr, int node);
Index: linux/mm/memory.c
===
--- linux.orig/mm/memory.c
+++ linux/mm/memory.c
@@ -2746,3 +2746,30 @@ int access_process_vm(struct task_struct
 
 	return buf - old_buf;

 }
+
+/*
+ * Print the name of a VMA.
+ */
+void print_vma_addr(char *prefix, unsigned long ip)
+{
+   struct mm_struct *mm = current->mm;
+   struct vm_area_struct *vma;
+   down_read(>mmap_sem);
+   vma = find_vma(mm, ip);
+   if (vma && vma->vm_file) {
+   struct file *f = vma->vm_file;
+   char *buf = (char *)__get_free_page(GFP_KERNEL);
+   if (buf) {
+   char *p, *s;
+   p = d_path(f->f_dentry, f->f_vfsmnt, buf, PAGE_SIZE);


d_path() can returns an error. You should add :

if (IS_ERR(p))
p = "?";


+   s = strrchr(p, '/');
+   if (s)
+   p = s+1;
+   printk("%s%s[%lx+%lx]", prefix, p,
+   vma->vm_start,
+   vma->vm_end - vma->vm_start);
+   free_page((unsigned long)buf);
+   }
+   }
+   up_read(>mm->mmap_sem);
+}


Thank you

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages

[Eric Dumazet]

Andi Kleen a écrit :

They now look like

hal-resmgr[13791]: segfault at 3c rip 2b9c8caec182 rsp 7fff1e825d30 error 4 in 
libacl.so.1.1.0[2b9c8caea000+6000]

This makes it easier to pinpoint bugs to specific libraries. 

And printing the offset into a mapping also always allows to find the 
correct fault point in a library even with randomized mappings. Previously

there was no way to actually find the correct code address inside
the randomized mapping.

Relies on earlier patch to shorten the printk formats.

They are often now longer than 80 characters, but I think that's worth 
it.


Patch for i386 and x86-64.

Signed-off-by: Andi Kleen [EMAIL PROTECTED]

---
 arch/x86/kernel/signal_32.c |7 +--
 arch/x86/kernel/signal_64.c |7 +--
 arch/x86/kernel/traps_32.c  |7 +--
 arch/x86/mm/fault_32.c  |4 +++-
 include/linux/mm.h  |1 +
 mm/memory.c |   27 +++
 6 files changed, 46 insertions(+), 7 deletions(-)

Index: linux/include/linux/mm.h
===
--- linux.orig/include/linux/mm.h
+++ linux/include/linux/mm.h
@@ -1145,6 +1145,7 @@ extern int randomize_va_space;
 #endif
 
 const char * arch_vma_name(struct vm_area_struct *vma);

+void print_vma_addr(char *prefix, unsigned long rip);
 
 struct page *sparse_mem_map_populate(unsigned long pnum, int nid);

 pgd_t *vmemmap_pgd_populate(unsigned long addr, int node);
Index: linux/mm/memory.c
===
--- linux.orig/mm/memory.c
+++ linux/mm/memory.c
@@ -2746,3 +2746,30 @@ int access_process_vm(struct task_struct
 
 	return buf - old_buf;

 }
+
+/*
+ * Print the name of a VMA.
+ */
+void print_vma_addr(char *prefix, unsigned long ip)
+{
+   struct mm_struct *mm = current-mm;
+   struct vm_area_struct *vma;
+   down_read(mm-mmap_sem);
+   vma = find_vma(mm, ip);
+   if (vma  vma-vm_file) {
+   struct file *f = vma-vm_file;
+   char *buf = (char *)__get_free_page(GFP_KERNEL);
+   if (buf) {
+   char *p, *s;
+   p = d_path(f-f_dentry, f-f_vfsmnt, buf, PAGE_SIZE);


d_path() can returns an error. You should add :

if (IS_ERR(p))
p = ?;


+   s = strrchr(p, '/');
+   if (s)
+   p = s+1;
+   printk(%s%s[%lx+%lx], prefix, p,
+   vma-vm_start,
+   vma-vm_end - vma-vm_start);
+   free_page((unsigned long)buf);
+   }
+   }
+   up_read(current-mm-mmap_sem);
+}


Thank you

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/