| 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: <alpine.LFD.2.02.1301111522150.7475@ionos> Date: Fri, 11 Jan 2013 15:34:41 +0100 (CET) From: Thomas Gleixner <tglx@...utronix.de> To: Michel Lespinasse <walken@...gle.com> cc: David Howells <dhowells@...hat.com>, Salman Qazi <sqazi@...gle.com>, Oleg Nesterov <oleg@...hat.com>, LKML <linux-kernel@...r.kernel.org> Subject: Re: rwlock_t unfairness and tasklist_lock On Tue, 8 Jan 2013, Michel Lespinasse wrote: > - Does anyone know of any current work towards removing the > tasklist_lock use of rwlock_t ? Thomas Gleixner mentioned 3 years ago > that he'd give it a shot (https://lwn.net/Articles/364601/), did he > encounter some unforeseen difficulty that we should learn from ? I converted quite a bunch of the read side instances to rcu protection, but got distracted. There was no fundamental difficulty, just lack of time. > - Would there be any fundamental objection to implementing a fair > rwlock_t and dealing with the reentrancy issues in tasklist_lock ? My > proposal there would be along the lines of: > > 1- implement a fair rwlock_t - the ticket based idea from David > Howells seems quite appropriate to me Nah. Lets get it killed. Most of the stuff can be converted to RCU and the remaining bits and pieces are the write lock sides which then can be converted to a big standard spinlock. There might be a few more complex ones, but Oleg said back then that those should be solved by locking the process instead of locking the whole tasklist. Thanks, tglx -- 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