Re: garbled oopsen

[Andrew Morton <akpm@digeo.com>]

"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> >>> Can these be cleaned up in any reasonable way?
> >> 
> >> It needs some additional spinlock in there.  People have moaned for over a
> >> year, patches have been floating about but nobody has taken the time to
> >> finish one off and submit it.
> > 
> > I considered it for x86-64 and even implemented it, but never submitted
> > in fear of deadlocks e.g. when an oops recurses. For this a 
> > spinlock_timeout() would be useful. Print anyways when you cannot get the
> > lock in a second or two.
> 
> The trouble is that the subsystems you want may be broken (eg timers).
> IMHO it's better to just spew whatever you can (the current crap) ... 
> wait a couple of seconds, then have another go at doing it properly.

A recursive oops is easy enough to detect anyway.

	preempt_disable();
	if (oops_cpu == -1 || oops_cpu != smp_processor_id()) {
		_raw_spin_lock(&oops_lock);
		oops_cpu = smp_processor_id();
	}
	<current stuff>
	oops_cpu = -1;
	spin_lock_init(&oops_lock);
	preempt_enable();

or something like that.

> That way people can't complain it's worse than it is now in any way ;-)

Too many complaints, too few unified diffs on this one.