* Jiri Kosina <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
