[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=o6g2cxcL_F-ZTZZkMUFT39jLtyRdTigZRbA5o@mail.gmail.com>
Date: Fri, 13 Aug 2010 16:38:02 -0700
From: Tony Luck <tony.luck@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Michel Lespinasse <walken@...gle.com>,
David Howells <dhowells@...hat.com>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mike Waychison <mikew@...gle.com>,
Suleiman Souhlal <suleiman@...gle.com>,
Ying Han <yinghan@...gle.com>
Subject: Re: [PATCH 06/11] rwsem: wake queued readers when writer blocks on
active read lock
Aha!. I think I found it.
This embarrassing declaration in ia64's asm/atomic.h:
static __inline__ int
ia64_atomic64_add (__s64 i, atomic64_t *v)
looks to be the key. Obviously it would be better to return all
64 bits of the answer using "long" rather than just 32 bits with "int".
The critical change in the rwsem code that exposed this silliness
is:
- (rwsem_atomic_update(0, sem) & RWSEM_ACTIVE_MASK))
- /* Someone grabbed the sem already */
+ rwsem_atomic_update(0, sem) < RWSEM_WAITING_BIAS)
+ /* Someone grabbed the sem for write already */
i.e. the old code only looked at the low 32-bits of the return value
(RWSEM_ACTIVE_MASK is 0xffffffff) - so the truncation didn't
matter.
ia64_atomic64_add() has been broken like this since before the
dawn of git time in 2.6.12. Obviously we haven't been using
atomic64_t much.
Running a new test now. 12 iterations so far (which is slightly
further than this test usually gets ... but I'll let it run for a few
more hours before declaring victory).
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists