* Ingo Oeser <[email protected]> wrote:
> Hi Ingo,
> you wrote:
>
> > --- linux/lib/spinlock_debug.c.orig
> > +++ linux/lib/spinlock_debug.c
> > +#define SPIN_BUG_ON(cond, lock, msg) \
> > + if (unlikely(cond)) spin_bug(lock, __FILE__, __LINE__, msg)
> > +#define RWLOCK_BUG_ON(cond, lock, msg) \
> > + if (unlikely(cond)) rwlock_bug(lock, __FILE__, __LINE__, msg)
>
> I would suggest propagating the __FILE__ and __LINE__ from the CALLERS
> of those functions in lib/spinlock_debug.c into these macros, to make
> this info more useful. At the moment you just know, that the bug
> happend on some spinlock/rwlock, but not who caused this.
the real call site info comes from dump_stack(). Maybe i should remove
the __FILE__,__LINE__ info altogether. (albeit a bit redundancy wont
hurt) I dont think we want to pass in __FILE__,__LINE__ all the way from
the main APIs.
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/
[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]
