| 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
| ||
|
Date: Mon, 23 Nov 2009 15:54:09 +0100 From: Nick Piggin <npiggin@...e.de> To: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: [rfc] "fair" rw spinlocks 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. Anyway, I would like to add some kind of fairness or at least anti starvation for writers. We have a customer seeing total livelock on tasklist_lock for write locking on a system as small as 8 core Opteron. This was basically reproduced by several cores executing wait with WNOHANG. Of course it would always be nice to improve locking so contention isn't an issue, but so long as we have rwlocks, we could possibly get into a situation where starvation is triggered *somehow*. So I'd really like to fix this. This particular starvation on tasklist lock I guess is a local DoS vulnerability even if the workload is not particularly realistic. Anyway, I don't have a patch yet. I'm sure it can be done without extra atomics in fastpaths. Comments? -- 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