linux-kernel - Re: [patch] Reorganize the cpufreq cpu hotplug locking to not be totally bizare

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060727103811.A29962@unix-os.sc.intel.com>
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/