headers
Dave Anderson | 1 May 2012 20:29
Picon
Favicon

Fwd: s390x fixes


Mistakenly cc'd to "crash-utility-owner <at> redhat.com" instead of this
list...

----- Forwarded Message -----
From: "Dave Anderson" <anderson <at> redhat.com>
To: "Michael Holzheu" <holzheu <at> linux.vnet.ibm.com>
Cc: crash-utility-owner <at> redhat.com
Sent: Monday, April 30, 2012 4:53:46 PM
Subject: s390x fixes

Hi Michael,

I've got a couple simple bug fixes for s390x that I want to
run by you, plus a third one that I don't have a fix for.

First the easy ones:

(1) "bt -t" and "bt -T" fail on the active task on a live system:

  crash> bt -t
  PID: 34875  TASK: 14342540          CPU: 1   COMMAND: "crash"
  bt: invalid/stale stack pointer for this task: 0
  crash> bt -T
  PID: 34875  TASK: 14342540          CPU: 1   COMMAND: "crash"
  bt: invalid/stale stack pointer for this task: 0
  crash>

That can be fixed by adding a !LIVE() check to s390x_get_stack_frame()
so that it will use (bt->task + OFFSET(task_struct_thread_ksp):
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Anderson | 1 May 2012 21:24
Picon
Favicon

Re: Fwd: s390x fixes


Hi Michael,

With respect to the 3rd "vm -p" bug, I did some cursory debugging, and
here's what I found.

In all cases, the readmem() failure occurs in _kl_pg_table_deref_s390x() 
as a result of transitioning from one page of PTEs to the next, because
the pointer to the "next" page of PTES contains 0x20, which looks to be 
_SEGMENT_ENTRY_INV or _REGION_ENTRY_INV? (not sure of the s390x nomenclature...)

So you'll see something like this in the page table that points
to the pages of PTEs:

         ...
         c6386e0:  0000000000000020 0000000000000020   ....... ....... 
         c6386f0:  000000001608c800 0000000000000020   ............... 
         c638700:  0000000000000020 0000000000000020   ....... ....... 
         ...

The vaddr's in the page of PTEs pointed to by c6386f0 (at 000000001608c800) 
all resolve as expected, but when the virtual address bumps it to c6386f8,
it reads the 0x20, and passes it to _kl_pg_table_deref_s390x().  The user
vaddr(s) that resolve to that next page of PTEs are legitimate, given that
they are in the virtual region defined by the vm_area_struct.  But they
certainly may not be mapped.

Anyway, it seems that there should be something that catches the invalid entry
in s390x_vtop() -- prior to calling _kl_pg_table_deref_s390x()--  and return
FALSE at that point.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dave Anderson | 2 May 2012 14:55
Picon
Favicon

Fwd: s390x fixes


----- Forwarded Message -----
From: "Michael Holzheu" <holzheu <at> linux.vnet.ibm.com>
To: "Dave Anderson" <anderson <at> redhat.com>
Cc: crash-utility-owner <at> redhat.com
Sent: Wednesday, May 2, 2012 8:49:56 AM
Subject: Re: s390x fixes

Hi Dave,

On Mon, 30 Apr 2012 16:53:46 -0400 (EDT)
Dave Anderson <anderson <at> redhat.com> wrote:
> I've got a couple simple bug fixes for s390x that I want to
> run by you, plus a third one that I don't have a fix for.
> 
> First the easy ones:
> 
> (1) "bt -t" and "bt -T" fail on the active task on a live system:
> 
>   crash> bt -t
>   PID: 34875  TASK: 14342540          CPU: 1   COMMAND: "crash"
>   bt: invalid/stale stack pointer for this task: 0
>   crash> bt -T
>   PID: 34875  TASK: 14342540          CPU: 1   COMMAND: "crash"
>   bt: invalid/stale stack pointer for this task: 0
>   crash>
> 
> That can be fixed by adding a !LIVE() check to s390x_get_stack_frame()
> so that it will use (bt->task + OFFSET(task_struct_thread_ksp):
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Holzheu | 2 May 2012 14:58
Picon

Re: Fwd: s390x fixes

Hi Dave,

On Tue, 01 May 2012 15:24:17 -0400 (EDT)
Dave Anderson <anderson <at> redhat.com> wrote:

> With respect to the 3rd "vm -p" bug, I did some cursory debugging, and
> here's what I found.
> 
> In all cases, the readmem() failure occurs in
> _kl_pg_table_deref_s390x() as a result of transitioning from one page
> of PTEs to the next, because the pointer to the "next" page of PTES
> contains 0x20, which looks to be _SEGMENT_ENTRY_INV or
> _REGION_ENTRY_INV? (not sure of the s390x nomenclature...)
> 
> So you'll see something like this in the page table that points
> to the pages of PTEs:
>          
>          ...
>          c6386e0:  0000000000000020
> 0000000000000020   ....... ....... c6386f0:  000000001608c800
> 0000000000000020   ............... c638700:  0000000000000020
> 0000000000000020   ....... ....... ...
> 
> The vaddr's in the page of PTEs pointed to by c6386f0 (at
> 000000001608c800) all resolve as expected, but when the virtual
> address bumps it to c6386f8, it reads the 0x20, and passes it to
> _kl_pg_table_deref_s390x().  The user vaddr(s) that resolve to that
> next page of PTEs are legitimate, given that they are in the virtual
> region defined by the vm_area_struct.  But they certainly may not be
> mapped.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Anderson | 2 May 2012 15:08
Picon
Favicon

Re: Fwd: s390x fixes


----- Original Message -----
> Hi Dave,
> 
> On Tue, 01 May 2012 15:24:17 -0400 (EDT)
> Dave Anderson <anderson <at> redhat.com> wrote:
> 
> > With respect to the 3rd "vm -p" bug, I did some cursory debugging,
> > and
> > here's what I found.
> > 
> > In all cases, the readmem() failure occurs in
> > _kl_pg_table_deref_s390x() as a result of transitioning from one
> > page
> > of PTEs to the next, because the pointer to the "next" page of PTES
> > contains 0x20, which looks to be _SEGMENT_ENTRY_INV or
> > _REGION_ENTRY_INV? (not sure of the s390x nomenclature...)
> > 
> > So you'll see something like this in the page table that points
> > to the pages of PTEs:
> >          
> >          ...
> >          c6386e0:  0000000000000020
> > 0000000000000020   ....... ....... c6386f0:  000000001608c800
> > 0000000000000020   ............... c638700:  0000000000000020
> > 0000000000000020   ....... ....... ...
> > 
> > The vaddr's in the page of PTEs pointed to by c6386f0 (at
> > 000000001608c800) all resolve as expected, but when the virtual
> > address bumps it to c6386f8, it reads the 0x20, and passes it to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Anderson | 2 May 2012 15:21
Picon
Favicon

Re: Fwd: s390x fixes


----- Original Message -----

> > 
> > And that's because when a "machdep->uvtop()" operation is done on a
> > user page that is not resident, the machine-dependent function should
> > return FALSE -- but it should return the PTE value in the paddr
> > pointer field so that it can be translated by vm_area_page_dump().
> > The s390x_uvtop() does not return the PTE, so the failed output can
> > vary, because it's using an uninitialized "paddr" stack variable.
> > But this is another easy fix, in this case to s390x_vtop():
> > 
> > /* lookup virtual address in page tables */
> > int s390x_vtop(ulong table, ulong vaddr, physaddr_t *phys_addr, int
> > verbose) {
> >         ulong entry, paddr;
> >         int level, len;
> > 
> > +       *phys_addr = 0;
> 
> 
> Looks also good. But probably I should implement a better fix that
> returns the pte for s390x swap entries.

That's true -- so since you've got the __swp_type() and __swp_offset()
macros #define'd for s390x, presumably it should work if you just pass
it back as is?  Even though you've got the common s390x_vtop() function
used by both s390x_kvtop() and s390x_uvtop(), I think it would be
safe to pass the PTE entry back in either case, because kvtop() operations
don't care about the paddr contents if you return FALSE.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Holzheu | 2 May 2012 18:02
Picon

Re: Fwd: s390x fixes

Hi Dave,

On Wed, 02 May 2012 09:21:57 -0400 (EDT)
Dave Anderson <anderson <at> redhat.com> wrote:
> 
> ----- Original Message -----
> 
> > > 
> > > And that's because when a "machdep->uvtop()" operation is done on
> > > a user page that is not resident, the machine-dependent function
> > > should return FALSE -- but it should return the PTE value in the
> > > paddr pointer field so that it can be translated by
> > > vm_area_page_dump(). The s390x_uvtop() does not return the PTE,
> > > so the failed output can vary, because it's using an
> > > uninitialized "paddr" stack variable. But this is another easy
> > > fix, in this case to s390x_vtop():
> > > 
> > > /* lookup virtual address in page tables */
> > > int s390x_vtop(ulong table, ulong vaddr, physaddr_t *phys_addr,
> > > int verbose) {
> > >         ulong entry, paddr;
> > >         int level, len;
> > > 
> > > +       *phys_addr = 0;
> > 
> > 
> > Looks also good. But probably I should implement a better fix that
> > returns the pte for s390x swap entries.
> 
> That's true -- so since you've got the __swp_type() and __swp_offset()
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Anderson | 2 May 2012 20:00
Picon
Favicon

Re: Fwd: s390x fixes


----- Original Message -----
> Hi Dave,
> 
> On Wed, 02 May 2012 09:21:57 -0400 (EDT)
> Dave Anderson <anderson <at> redhat.com> wrote:
> > 
> > ----- Original Message -----
> > 
> > > > 
> > > > And that's because when a "machdep->uvtop()" operation is done on
> > > > a user page that is not resident, the machine-dependent function
> > > > should return FALSE -- but it should return the PTE value in the
> > > > paddr pointer field so that it can be translated by
> > > > vm_area_page_dump(). The s390x_uvtop() does not return the PTE,
> > > > so the failed output can vary, because it's using an
> > > > uninitialized "paddr" stack variable. But this is another easy
> > > > fix, in this case to s390x_vtop():
> > > > 
> > > > /* lookup virtual address in page tables */
> > > > int s390x_vtop(ulong table, ulong vaddr, physaddr_t *phys_addr,
> > > > int verbose) {
> > > >         ulong entry, paddr;
> > > >         int level, len;
> > > > 
> > > > +       *phys_addr = 0;
> > > 
> > > 
> > > Looks also good. But probably I should implement a better fix that
> > > returns the pte for s390x swap entries.
(Continue reading)

Permalink | Reply | 0 comments |
headers
qiaonuohan | 9 May 2012 10:47
Favicon

Adding a new command rbtree

Hello HATAYAMA,

I am trying to add a new command can be used to display rbtree and
radix tree. After some investigation, I find they are similar to the
build-in command "list". So I send this mail to ask your opinion about
making cmd_list to be similar to the command "struct/union/*".

Another thing needed to be inquired is about the style of displaying
tree. I will list some of my thought, and some suggestion will be glad
to get from you.

1.
NODE ... : ...
   NODE ... : ...
     NODE ... : ...
       NODE ... : ...
     NODE ... : ...
   NODE ... : ...

This style can not indicate whether the leaf is left or right. And with
a big depth, the output may be ugly. So I do not like it.

2.
l - left child
r - right child

root NODE ... : ...
l    NODE ... : ...
ll   NODE ... : ...
lll  NODE ... : ...
(Continue reading)

Permalink | Reply | 29 comments |
headers
Per Fransson | 9 May 2012 11:07

[PATCH]: double free in trace extension

Hi Dave and other list readers,

First, just like some other contributors, I've come across an issue 
triggered by a dump being corrupt. In my case it's this code in 
kernel.c:cpu_maps_init():

    if (*maskptr & (0x1UL << c)) {
       cpu = (i * BITS_PER_LONG) + c;
       kt->cpu_flags[cpu] |= mapinfo[m].cpu_flag;
    }

The mask is corrupt, making Crash believe there are more CPU's than the 
four we have allocated space for in kernel.c:kernel_init. How do you 
think this should be handled?

Second, I believe there is a double free in the trace extension. When 
ftrace_init_pages() fails it will free

    cpu_buffer->pages

and

    cpu_buffer->linear_pages

But when ftrace_init_pages() fails, ftrace_init_buffers() will call 
ftrace_destroy_buffers() which also free's this space. For me this 
resulted in a segfault in a malloc() a little later.

Regards,
Per
(Continue reading)

Permalink | Reply | 12 comments |

Gmane