[Crash-utility] kmem -[sS] segfault on 2.6.25.17

[Dave Anderson]

----- "Mike Snitzer" <snitzer at gmail.com> wrote:

> On Thu, Oct 16, 2008 at 12:25 PM, Dave Anderson <anderson at redhat.com>
> wrote:
> >
> > ----- "Mike Snitzer" <snitzer at gmail.com> wrote:
> >
> >> I'm getting a core when I try to show slab data (kmem -[sS]) on
> >> 2.6.25.17 with both a live crash or saved vmcore.
> >>
> >> The core shows that the segv is coming from memset() via
> >> gather_cpudata_list_v2_nodes (memory.c:10119).  This is with crash
> >> 4.0-7.4, but the same crash occurs with crash 4.0-6.3
> >> (memory.c:10108)
> >> and older.
> >>
> >> I've also seen kmem -[sS] segfaults with older kernels too (e.g.
> >> 2.6.22.x).
> >>
> >> Have others experienced this?  Would it be useful for me to
> provide
> >> my
> >> kernel config?
> >
> > No that won't help.
> 
> Actually I think it may considering kmem -[sS] works perfectly fine
> on
> the same identical 2.6.22.19 kernel if various debug features are
> _not_ enabled, see the attached .config diff.  Of note:
> -# CONFIG_DEBUG_SLAB is not set
> +CONFIG_DEBUG_SLAB=y
> +CONFIG_DEBUG_SLAB_LEAK=y
> 
> Comparable debug features are enabled in my 2.6.25 kernel that causes
> crash to segfault.

Good point... 

> 
> > It's failing in the BZERO() here:
> >
> >  10117         for (i = 0; (i < ARRAY_LENGTH(kmem_cache_s_array))
> &&
> >  10118              (cpudata[i]) && !(index); i++) {
> >  10119                 BZERO(si->cpudata[i], sizeof(ulong) *
> vt->kmem_max_limit);
> >
> > What is "i" equal to when it segfaults?  If you have a crash core
> file,
> > print out the contents of the global "vm_table".  In that structure
> > there is a "kmem_max_cpus" field.  If "i" is greater or equal to
> that,
> > then that's one explanation.
> 
> i=0 and kmem_max_cpus=4.

Ok, then I can't see off-hand why it would segfault.  Prior to this
routine running, si->cpudata[0...i] all get allocated buffers equal
to the size that's being BZERO'd.

Is si->cpudata[i] NULL or something?

Dave