Re: 2.6.15-git7 oopses in ext3 during LTP runs

[Pavel Machek <pavel@suse.cz>]

On St 11-01-06 23:47:53, Jesper Juhl wrote:
> On 1/11/06, Pavel Machek <pavel@suse.cz> wrote:
> > On St 11-01-06 22:27:55, Arjan van de Ven wrote:
> > > > We expect the lock to be held on entry.  Hence we expect mutex_trylock()
> > > > to return zero.
> > >
> > > you are correct, and the x86-64 mutex.h is buggy
> > >
> > > --- linux-2.6.15/include/asm-x86_64/mutex.h.org       2006-01-11 22:25:37.000000000 +0100
> > > +++ linux-2.6.15/include/asm-x86_64/mutex.h   2006-01-11 22:25:43.000000000 +0100
> > > @@ -104,7 +104,7 @@
> > >  static inline int
> > >  __mutex_fastpath_trylock(atomic_t *count, int (*fail_fn)(atomic_t *))
> > >  {
> > > -     if (likely(atomic_cmpxchg(count, 1, 0)) == 1)
> > > +     if (likely(atomic_cmpxchg(count, 1, 0) == 1))
> > >               return 1;
> > >       else
> > >               return 0;
> > >
> > > changes the asm to be the correct one for me.
> > > This is odd/evil though..
....
> > +++ b/kernel/sched.c
> > @@ -367,7 +367,7 @@ repeat_lock_task:
> >         local_irq_save(*flags);
> >         rq = task_rq(p);
> >         spin_lock(&rq->lock);
> > -       if (unlikely(rq != task_rq(p))) {
> > +       if unlikely(rq != task_rq(p)) {
> 
> This is confusing to read. Why not keep the parenthesis around
> (unlikely(...)) ?  Yes, it's an extra set of parenthesis that are not
> strictly needed now that you've added them to the likely/unlikely
> macros, but they don't do any harm either and make the code less
> surprising to read...   I know that I at least think *BUG* at once

Read the email from the start, there's very nice example why the extra
()'s are evil in mutex_fast_trylock.

								Pavel
-- 
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/