| 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: <87einnwsxv.fsf@basil.nowhere.org> Date: Tue, 24 Nov 2009 21:47:56 +0100 From: Andi Kleen <andi@...stfloor.org> To: Nick Piggin <npiggin@...e.de> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [rfc] "fair" rw spinlocks Nick Piggin <npiggin@...e.de> writes: > Hi, > > Last time this issue came up that I could see, I don't think > there were objections to making rwlocks fair, the main > difficulty seemed to be that we allow reentrant read locks > (so a write lock waiting must not block arbitrary read lockers). > > Nowadays our rwlock usage is smaller although still quite a > few, so it would make better sense to do a conversion by > introducing a new lock type and move them over I guess. You want to do a new lock type for potentially nested rwlocks? >From the basic idea it sounds good, but according to grep the current tree has hundreds of rwlocks all over, and how would you reliably detect whether they are nestable or not? I assume it's not something that could be easily analyzed at compile time and relying on runtime would seem dangerous. Basically it sounds like quite a lot of work. A better plan might be to have new types which are non nestable and only move over audited code to fair rwlocks. -Andi -- ak@...ux.intel.com -- Speaking for myself only. -- 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