Andrew Morton <[email protected]> wrote:
> On Wed, 6 Dec 2006 01:51:01 +0100 (CET)
> Jiri Kosina <[email protected]> wrote:
>
> > [PATCH] let WARN_ON() output the condition
> >
> > It is possible, in some cases, that the output of WARN_ON() is ambiguous
> > and can't be properly used to identify the exact condition which caused
> > the warning to trigger. This happens whenever there is a macro that
> > contains multiple WARN_ONs inside. Notable example is spin_lock_mutex().
> > If any of the two WARN_ONs trigger, we are not able to say which one was
> > the cause (as we get only line number, which however belongs to the place
> > where the macro was expanded).
> >
> > This patch lets WARN_ON() to output also the condition and fixes the
> > DEBUG_LOCKS_WARN_ON() macro to pass the condition properly to WARN_ON. The
> > possible drawback could be when someone passes a condition which has
> > sideeffects. Then it would be evaluated twice, instead of current one
> > evaluation. On the other hand, when anyone passes expression with
> > sideeffects to WARN_ON(), he is asking for problems anyway.
> >
> > Patch against 2.6.19-rc6-mm2.
> >
> > Signed-off-by: Jiri Kosina <[email protected]>
> >
> > ---
> >
> > include/asm-generic/bug.h | 4 ++--
> > include/linux/debug_locks.h | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> > index a06eecd..af7574e 100644
> > --- a/include/asm-generic/bug.h
> > +++ b/include/asm-generic/bug.h
> > @@ -35,8 +35,8 @@ #ifndef HAVE_ARCH_WARN_ON
> > #define WARN_ON(condition) ({ \
> > typeof(condition) __ret_warn_on = (condition); \
> > if (unlikely(__ret_warn_on)) { \
> > - printk("WARNING at %s:%d %s()\n", __FILE__, \
> > - __LINE__, __FUNCTION__); \
> > + printk("WARNING (%s) at %s:%d %s()\n", #condition, \
> > + __FILE__,__LINE__, __FUNCTION__); \
__FILE__, __LINE__, __FUNCTION__);
(missing space after "__FILE__,")
> > dump_stack(); \
> > } \
> > unlikely(__ret_warn_on); \
> > diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
> > index 952bee7..1c2b682 100644
> > --- a/include/linux/debug_locks.h
> > +++ b/include/linux/debug_locks.h
> > @@ -25,7 +25,7 @@ ({ \
> > \
> > if (unlikely(c)) { \
> > if (debug_locks_off()) \
> > - WARN_ON(1); \
> > + WARN_ON(c); \
> > __ret = 1; \
> > } \
> > __ret; \
Why not just:
WARN_ON(debug_locks_off())
here? Would give a more readable message too, IMHO.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
