On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > 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?
I am getting stackump, but I am perhaps just blind and don't see how to
use it to distinguish the two WARN_ONs() conveniently, besides of
disassembling the __mutex_lock_dommon and comparing it with offset in a
stackdump. Well, not that it's not doable, but ...
> 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; \
>
Yep, making it dependent on CONFIG_DEBUG_BUGVERBOSE makes sense. Andrew,
will you take such patch? (when I also fix the evaluating-twice issue).
Thanks,
--
Jiri Kosina
-
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/
