Unable to do IA64 stacktrace in early boot

Unable to do IA64 stacktrace in early boot

[Keith Owens]

Booting 2.6.20-rc1 on IA64 with CONFIG_DEBUG_LOCKING_API_SELFTESTS=y.

| Locking API testsuite:
----------------------------------------------------------------------------
                                 | spin |wlock |rlock |mutex | wsem | rsem |
  --------------------------------------------------------------------------
                     A-A deadlock:failed|failed|  ok  |failed|failed|failed|
                 A-B-B-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-B-C-C-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-C-A-B-C deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-B-C-C-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-C-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
                    double unlock:  ok  |  ok  |failed|WARNING at /build/kaos/kernel.org-sgidev/linux/kernel/mutex-debug.c:83 debug_mutex_unlock()
Unable to handle kernel NULL pointer dereference (address 0000000000000000)

mutex-debug uses DEBUG_LOCKS_WARN_ON() which indirectly calls
dump_stack which the IA64 unwind code (arch/ia64/kernel/unwind.c) calls
kmalloc.  The lockdep tests are run before the slab caches have been
allocated so cpu_cache_get is called with a NULL cachep, hence the
oops.

This problem is masked by the KDB patches because they replace the
kmalloc/kfree code in IA64 unwind with a static allocation pool.  With
KDB applied IA64 does not require the slab to be initialised before you
can do a backtrace.

If we want backtraces on IA64 before slab has been initialized then the
ia64 unwinder has to use a different allocation method.  This may also
be a problem for other architectures that use kmalloc in their unwind
code.

Re: Unable to do IA64 stacktrace in early boot

[Matthew Wilcox]

On Thu, Dec 21, 2006 at 02:56:10PM +1100, Keith Owens wrote:
>                     double unlock:  ok  |  ok  |failed|WARNING at /build/kaos/kernel.org-sgidev/linux/kernel/mutex-debug.c:83 debug_mutex_unlock()
> Unable to handle kernel NULL pointer dereference (address 0000000000000000)
> 
> mutex-debug uses DEBUG_LOCKS_WARN_ON() which indirectly calls
> dump_stack which the IA64 unwind code (arch/ia64/kernel/unwind.c) calls
> kmalloc.  The lockdep tests are run before the slab caches have been
> allocated so cpu_cache_get is called with a NULL cachep, hence the
> oops.

Yup.  I just debugged and fixed the same problem on parisc.  I didn't
think to check ia64; I checked to see what x86-64 did.  Unfortunately,
the ia64 unwind code seems a lot more subtle and more allocation-happy
than the parisc unwind code, so I'm not sure exactly how to fix ia64.

Re: Unable to do IA64 stacktrace in early boot

[Ingo Molnar]

On Wed, 2006-12-20 at 22:03 -0700, Matthew Wilcox wrote:
> > mutex-debug uses DEBUG_LOCKS_WARN_ON() which indirectly calls
> > dump_stack which the IA64 unwind code (arch/ia64/kernel/unwind.c)
> calls
> > kmalloc.  The lockdep tests are run before the slab caches have been
> > allocated so cpu_cache_get is called with a NULL cachep, hence the
> > oops.
> 
> Yup.  I just debugged and fixed the same problem on parisc.  I didn't
> think to check ia64; I checked to see what x86-64 did.  Unfortunately,
> the ia64 unwind code seems a lot more subtle and more allocation-happy
> than the parisc unwind code, so I'm not sure exactly how to fix ia64.

yeah. calling kmalloc() within the unwinder is a no-no. What if the
unwind happens while kmalloc() is crashing?

	Ingo
> 

Re: Unable to do IA64 stacktrace in early boot

[David Mosberger-Tang]

The libunwind-based unwinder uses it's own primitive allocator to
avoid such problems.  I posted a working patch a couple of months
back.

  --david

On 12/21/06, Ingo Molnar <mingo@redhat.com> wrote:
> On Wed, 2006-12-20 at 22:03 -0700, Matthew Wilcox wrote:
> > > mutex-debug uses DEBUG_LOCKS_WARN_ON() which indirectly calls
> > > dump_stack which the IA64 unwind code (arch/ia64/kernel/unwind.c)
> > calls
> > > kmalloc.  The lockdep tests are run before the slab caches have been
> > > allocated so cpu_cache_get is called with a NULL cachep, hence the
> > > oops.
> >
> > Yup.  I just debugged and fixed the same problem on parisc.  I didn't
> > think to check ia64; I checked to see what x86-64 did.  Unfortunately,
> > the ia64 unwind code seems a lot more subtle and more allocation-happy
> > than the parisc unwind code, so I'm not sure exactly how to fix ia64.
>
> yeah. calling kmalloc() within the unwinder is a no-no. What if the
> unwind happens while kmalloc() is crashing?
>
>         Ingo
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/