linux-kernel - Re: Remove hotplug cpu crap from cpufreq.

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: <20061102184637.GA23489@in.ibm.com>
Date:	Fri, 3 Nov 2006 00:16:37 +0530
From:	Dipankar Sarma <dipankar@...ibm.com>
To:	Dave Jones <davej@...hat.com>, Linus Torvalds <torvalds@...l.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, Gautham Shenoy <ego@...ibm.com>
Subject: Re: Remove hotplug cpu crap from cpufreq.

Dave,

On Wed, Nov 01, 2006 at 06:32:50PM -0500, Dave Jones wrote:
> On Wed, Nov 01, 2006 at 03:09:52PM -0800, Linus Torvalds wrote:
> 
>  > Hmm. People _have_ given a damn, and I think you were even cc'd.
> 
> You're right. In my defense, that stuff arrived the day I went
> on vacation for two weeks, and I subsequently forgot all about it.
> Looking back over that thread though, a few people seemed to pick a
> number of holes in the patches, and there are some real gems in that
> thread like.

Have you looked at this patchset - http://lkml.org/lkml/2006/10/26/65 ?
This is the latest patchset posted last week and I haven't seen any 
comments on it.

>  > Really, the hotplug locking rules are fairly simple-
>  > 
>  > 1. If you are in cpu hotplug callback path, don't take any lock.
> 
> Which is just great, as afair, the cpufreq locks were there _before_
> someone liberally sprinkled lock_cpu_hotplug() everywhere.

This one has a major *cleanup* of cpufreq code including removel
of unncessary lock_cpu_hotplug() from cpufreq.

> 
> From what I can tell from looking at that thread back in August,
> it went on for a while with a number of people picking holes in the
> proposed patches, but there wasn't any reposted after that, and
> certainly nothing that ended up in -mm.
> 
> _something_ needs to be done. If someone wants to fix it, great, but
> until we see something mergable, we're left in this half-assed state
> which is freaking people out.

There are two approaches - Implicit hotplug callback order-based locking
as Andrew has done or keep the current cpu hotplug "lock" semantics
and just use a better lock (RCU-based) with cpu-local access in
the fast path. Gautham's patchset does the latter. lock_cpu_hotplug() is 
a misnomer, we should probably use get_cpu_hotplug() and 
put_cpu_hotplug() there.

Thanks
Dipankar
-
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/