linux-kernel - Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency

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]

Date:	Thu, 30 Nov 2006 11:40:09 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Gautham R Shenoy <ego@...ibm.com>, linux-kernel@...r.kernel.org,
	torvalds@...l.org, davej@...hat.com, dipankar@...ibm.com,
	vatsa@...ibm.com
Subject: Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency

On Thu, 30 Nov 2006 12:46:17 +0100
Ingo Molnar <mingo@...e.hu> wrote:

> * Andrew Morton <akpm@...l.org> wrote:
> 
> > > This would be done totally serialized and while holding the hotplug 
> > > lock, so no CPU could go away or arrive while this operation is 
> > > going on.
> > 
> > You said "the hotplug lock".  That is the problem.
> 
> maybe i'm too dense today but i still dont see the fundamental problem. 
> 
> Even with complex inter-subsystem interactions, hotplugging could be 
> effectively and scalably controlled via a self-recursive per-CPU mutex, 
> and a pointer to it embedded in task_struct:

Yes, I suppose we could come up with now new lock type which fixes the
problem.  But first, let us review the problem.

Someone went through cpufreq sprinkling lock_cpu_hotplug() everywhere as if
it had magical properties.  For the past year or more, others have been
picking through the resulting bugs, trying to make things better and
treating that initial magic-pixie-dust as if it were inviolate and nobody
had a chance of understanding it.

IOW, cpufreq is screwed up, and we keep on trying to come up with more
complexity to unscrew it.

So what I would propose is that rather than going ahead and piling more
complexity on top of the existing poo-pile in an attempt to make it seem to
work, we should simply rip all the cpu-hotplug locking out of cpufreq
(there's a davej patch for that in -mm) and then just redo it all in an
organised fashion.

If, as a result of that exercise, we decide that the existing cpu-hotplug
serialisation mechanisms (ie: per-subsystem notification callbacks and
preempt_disable()) are insufficient then sure, that is the time to think
about more sophisticated locking primitives.

But please, let's stop asking "how do we make cpufreq's hotplug locking
work?".  Let's instead ask "how do we make cpufreq safe wrt hotplug?"

To do the latter is a matter of

- identify the per-cpu resources which need locking

- decide what mechanism is to be used to protect each such resource

- design the locking and its hierarchy

- implement, test.

In all this time, Gautham's emails from yesterday were the first occasion
on which anybody has taken the time to sit down and get us started on this
quite ordinary design & devel process.

Let me re-re-re-re-reiterate: this is a cpufreq problem.  It has not yet
been demonstrated (AFAICS) that it is a general problem.  I am unaware of
any other subsystems having got themselves into such a mess over hotplug
locking.  Now, maybe that's because cpufreq really is especially hard.  Or
maybe it's because it's just messed up.  I don't believe we know which of
those is true yet.
-
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/