lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <4CDF1945.8090101@tilera.com> Date: Sat, 13 Nov 2010 18:03:33 -0500 From: Chris Metcalf <cmetcalf@...era.com> To: Américo Wang <xiyou.wangcong@...il.com> CC: Cypher Wu <cypher.w@...il.com>, Eric Dumazet <eric.dumazet@...il.com>, linux-kernel@...r.kernel.org, netdev <netdev@...r.kernel.org> Subject: Re: Kernel rwlock design, Multicore and IGMP On 11/12/2010 2:13 AM, Américo Wang wrote: > 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@...il.com> wrote: >>> Le jeudi 11 novembre 2010 à 21:49 +0800, Cypher Wu a écrit : >>>> 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. >>> [...] >>> >> 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. > > It is a known weakness of rwlock, it is designed like that. :) Exactly. The tile rwlock correctly allows recursively reacquiring the read lock. But it does give priority to writers, for the (unfortunately incorrect) reasons Cypher Wu outlined above, e.g.: - Core A takes a read lock - Core B tries for a write lock and blocks new read locks - Core A tries for a (recursive) read lock and blocks Core A and B are now deadlocked. The solution is actually to simplify the tile rwlock implementation so that both readers and writers contend fairly for the lock. I'll post a patch in the next day or two for tile. -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists