Messages in this thread |  | | | Subject | Re: Kernel rwlock design, Multicore and IGMP | | From | Eric Dumazet <> | | Date | Fri, 12 Nov 2010 08:27:54 +0100 |
| |
Le vendredi 12 novembre 2010 à 15:13 +0800, Américo Wang a écrit : > On Fri, Nov 12, 2010 at 11:32:59AM +0800, Cypher Wu wrote: > >On Thu, Nov 11, 2010 at 11:23 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > >> Le jeudi 11 novembre 2010 à 21:49 +0800, Cypher Wu a écrit : > >> > >> Hi > >> > >> CC netdev, since you ask questions about network stuff _and_ rwlock > >> > >> > >>> I'm using TILEPro and its rwlock in kernel is a liitle different than > >>> other platforms. It have a priority for write lock that when tried it > >>> will block the following read lock even if read lock is hold by > >>> others. Its code can be read in Linux Kernel 2.6.36 in > >>> arch/tile/lib/spinlock_32.c. > >> > >> This seems a bug to me. > >> > >> read_lock() can be nested. We used such a schem in the past in iptables > >> (it can re-enter itself), > >> and we used instead a spinlock(), but with many discussions with lkml > >> and Linus himself if I remember well. > >> > >It seems not a problem that read_lock() can be nested or not since > >rwlock doesn't have 'owner', it's just that should we give > >write_lock() a priority than read_lock() since if there have a lot > >read_lock()s then they'll starve write_lock(). > >We should work out a well defined behavior so all the > >platform-dependent raw_rwlock has to design under that principle. >
AFAIK, Lockdep allows read_lock() to be nested.
> It is a known weakness of rwlock, it is designed like that. :) >
Agreed.
> The solution is to use RCU or seqlock, but I don't think seqlock > is proper for this case you described. So, try RCU lock.
In the IGMP case, it should be easy for the task owning a read_lock() to pass a parameter to the called function saying 'I already own the read_lock(), dont try to re-acquire it'
A RCU conversion is far more complex.
-- 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/
|  |