Re: [BUG -rt] Double OOPs - thread_info free race / printk recursive lock
- From: Bill Huey (hui) <billh@xxxxxxxxxxxxxxxxx>
- Date: Fri, 4 Aug 2006 14:10:11 -0700
On Fri, Aug 04, 2006 at 10:43:05AM -0700, Darren Hart wrote:
We've seen very rarely over the last few months, on various -rt kernels. The
latest reproduction is on 2.6.16-rt22 (+some minor fixups). Analysis of the
vmcore produced by kdump suggests two problems:
1) An invalid pointer dereference in cache_flusharray() which causes the page
fault.
My guess is that this is after some bogus stuff going on after the real event.
2) Then printk calls kmalloc when trying to print the oops, which grabs a
recursive lock and prints a different oops.
Can't say for sure, but this sounds a lot like the problem I've been dealing
with in free_task(). The stack trace is pretty contorted and it's been difficult
to unwind it in any meaningful manner, although I'm making progress. Writing
some tools to deal with this now.
bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [BUG -rt] Double OOPs - thread_info free race / printk recursive lock
- From: Darren Hart
- [BUG -rt] Double OOPs - thread_info free race / printk recursive lock
- Prev by Date: Re: reiser4: maybe just fix bugs?
- Next by Date: Re: [HW_RNG] How to use generic rng in kernel space
- Previous by thread: [BUG -rt] Double OOPs - thread_info free race / printk recursive lock
- Next by thread: Re: [linux-usb-devel] Stability-Problem of EHCI with a larger number of USB-Hubs/Devices
- Index(es):