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: Thu, 27 Jul 2006 10:38:12 -0700 From: Ashok Raj <ashok.raj@...el.com> To: Ingo Molnar <mingo@...e.hu> Cc: Linus Torvalds <torvalds@...l.org>, Srivatsa Vaddagiri <vatsa@...ibm.com>, Arjan van de Ven <arjan@...ux.intel.com>, Dave Jones <davej@...hat.com>, Chuck Ebbert <76306.1226@...puserve.com>, Ashok Raj <ashok.raj@...el.com>, linux-kernel <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...l.org> Subject: Re: [patch] Reorganize the cpufreq cpu hotplug locking to not be totally bizare On Thu, Jul 27, 2006 at 03:40:49AM +0200, Ingo Molnar wrote: > > * Linus Torvalds <torvalds@...l.org> wrote: > > > But I agree with Arjan - I think the fundamental problem is that cpu > > hotplug locking is just is fundamentally badly designed as-is. There's > > really very little point to making it a _lock_ per se, since most > > people really want more of a "I'm using this CPU, don't try to remove > > it right now" thing which is more of a ref-counting-like issue. > > we'd also need a facility to wait on that refcount - i.e. a waitqueue. > Which means we'd have a "refcount + waitqueue", which is equivalent to a > "recursive, sleeping read-lock", where the write-side could be used as a > simple facility to "wait for all readers to go away and block new > readers from entering the critical sections". [which type of lock Linux > does not have right now. rwsems come the closest but they dont recurse.] sounds like some varient of conditional variables, caveat might be that new readers permitted if in the same call thread/cpu? (i.e recurive inside the same context?) for e.g with the cpufreq kind of usage today, cpu_down() waits for ref to drop to zero; // now signalled by last reader when refcnt drops to 0 do pre-remove-notify---> cpufreq // this attempt to acquire read lock again shoudnt be blocked right // even though we have officially started waiting for cnt to drop 0? problem was with the kondemand() when a remove_wq() caused a flush_wq() that started to yeild and run the other wq thread. Now the depth control that checked if the locking_task == current wasnt true that caused the dead lock again. > > Also, the hotplug lock is global right now which is pretty unscalable, > so the rw-mutex should also be per-CPU, and the hotplug locking API > should be changed to something like: > > cpu = cpu_hotplug_lock(); so this is sort of like the get_cpu()/put_cpu() interface that does preempt_disable() + get current cpu. -- Cheers, Ashok Raj - Open Source Technology Center - 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