linux-kernel - Re: cpufreq cleanups

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:	Mon, 27 Jul 2009 09:31:06 -0700
From:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Dave Jones <davej@...hat.com>, Thomas Renninger <trenn@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"kernel-testers@...r.kernel.org" <kernel-testers@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Dave Young <hidave.darkstar@...il.com>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: cpufreq cleanups - .30 vs .31

On Mon, 2009-07-27 at 07:25 -0700, Mathieu Desnoyers wrote:
> * Dave Jones (davej@...hat.com) wrote:
> > On Mon, Jul 06, 2009 at 01:18:18PM +0200, Thomas Renninger wrote:
> > 
> >  > So if not find too intrusive, I'd say:
> >  > Venkatesh's whole series of:
> >  > [patch 0/4] Take care of cpufreq lockdep issues (take 2)
> >  > should be seen in .31.
> >  >  ...
> >  > The one patch from Mathieu:
> >  > [patch 2.6.30 2/4] CPUFREQ: fix (utter) cpufreq_add_dev mess
> >  > is a separate, general cleanup which should show up in .31.
> > 
> > I came to the same conclusion after reading the thread, and looking
> > over the patches.  I merged the above, and sent Linus a pull request
> > a few minutes ago.
> > 
> > Thanks Mathieu and Venki for chasing this down.
> > 
> > 	Dave
> 
> Given I never got an answer to this question, I'm re-asking a question I
> asked in a previous thread about Venki's patchset:
> 
> [CPUFREQ] Cleanup locking in ondemand governor
> commit	5a75c82828e7c088ca6e7b4827911dc29cc8e774
> 
> From the earlier thread:
> Subject: Re: [patch 2.6.30 3/4] cpufreq add gov mutex
> 
> I am worried about potential races between add_dev/remove_dev, which
> currently lock the rwsem as mean of protection, and execution of timer
> handler that would not take the rwsem to protect itself anymore, due to
> your changes.
> 
> I'm especially worried about the call to
> 
>               __cpufreq_driver_target(dbs_info->cur_policy,
>                         dbs_info->freq_lo, CPUFREQ_RELATION_H);
> 
> which seems to depend on policy-level information, protected at the
> rwsem-level.
> 
> By removing the rwsem from the timer handler, I don't see how you plan
> to protect this information from add_dev/remove_dev execution.
> 

Sorry I missed the question earlier.

The invariant here is that the timer routine will not be running while
policy is inconsistent due to add/remove. The cpufreq layer calls START
at the end of add_dev when all policy stuff has been setup, which starts
the timer. And STOP along remove_dev before cleaning up policy which
stops the timer.

If you are thinking of races with other cpufreq sysfs interfaces, they
go through the per cpu rwsem along with add/remove.

Thanks,
Venki

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