Re: BUG-lockdep and freeze (was: Arrr! Linux 2.6.18)

Jan Beulich
2006-10-04T09:14:13Z

>>> Linus Torvalds <torvalds@osdl.org> 30.09.06 21:54 >>>
>On Sat, 30 Sep 2006, Eric Rannaud wrote:
>>
>> (2) is introduced by d94a041519f3ab1ac023bf917619cd8c4a7d3c01
>> [PATCH] taskstats: free skb, avoid returns in send_cpu_listeners,
>> Signed-off-by: Shailabh Nagar.
>> The kernel freezes after a BUG (no sysrq magic).
>
>This one looks like the real problem is that totally broken stack unwinder
>again.

I can only support Andi here - I disagree that the unwinder is totally
broken, and most code fragments you presented during the thread
to support your statements were actually not even introduced by the
unwinding patches. While you ask Andi to look at the old code, it
seems to me you haven't really looked at the new one.

>Andi, I really think that Dwarf unwinder needs to go. The code is totally
>unreadable, and it's clearly fragile as hell. It doesn't check that the
>pointers it gets are even remotely valid, but just follows them as if they
>were.

Rather than ripping out the unwinder, anyone not liking the way it
works or it is implemented can easily just disable it - I always thought
that's what config options are for.

>The whole unwinder seems buggier than any bug it can ever unwind would be.
>Really. Let's go back to the sane "try our best, don't guarantee anything,
>but at least don't make things worse!" old code.
>
>The people who wrote that crap (and yes, Andi, I mean apparently you and
>Jan Beulich) really _have_ to get his act together. It's not just
>unreadable and obviously buggy, it's so scarily that it's hard to even
>talk about it. Lookie here:
>
> #define HANDLE_STACK(cond) \
> do while (cond) { \
> unsigned long addr = *stack++; \
>
>What the F*CK! "do while(cond) {" ????
>
>Please. Somebody just rip out all this crap. I beg of you.

One example of you blaming the unwind code for something that
was all there before. (I agree that I wrote that code, but a lot
earlier, and in order to replace what I could call crap: repeating
the same code sequence three times, making it necessary to apply
any adjustments to it in three places).

Also, I'd really like to understand if we're on a technical discussion
here, or whether we're just trying to exchange emotions.

Jan