[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061206085428.GA28160@elte.hu>
Date: Wed, 6 Dec 2006 09:54:28 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Jiri Kosina <jikos@...os.cz>
Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] let WARN_ON() output the condition
* Jiri Kosina <jikos@...os.cz> wrote:
> On Wed, 6 Dec 2006, Ingo Molnar wrote:
>
> > a WARN_ON() also triggers a stack dump, which should pinpoint the exact
> > location. (especially if combined with kallsyms) For example:
>
> Actually, I was referring to something a little bit different. For example
> kernel/mutex.c:__mutex_lock_common() calls spin_lock_mutex() on line 132.
> spin_lock_mutex() contains
>
> DEBUG_LOCKS_WARN_ON(in_interrupt()); \
> local_irq_save(flags); \
> __raw_spin_lock(&(lock)->raw_lock); \
> DEBUG_LOCKS_WARN_ON(l->magic != l); \
>
> When one of these two WARN_ONs trigger, we get only
>
> WARNING at kernel/mutex.c:132 __mutex_lock_common()
no, that's not all we get - we should also get a stackdump. Are you not
getting a stackdump perhaps?
but i agree with you in theory that your proposed output is better, but
the side-effect issue is a killer i think. Could you try to rework it to
not evaluate the condition twice and to make it dependent on
CONFIG_DEBUG_BUGVERBOSE? You can avoid the evaluation side-effect issue
by doing something like:
int __c = (c); \
\
if (unlikely(__c)) { \
if (debug_locks_off()) \
WARN_ON(__c); \
__ret = 1; \
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists