linux-kernel - Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume

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, 11 Jul 2013 10:23:19 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
cc:	Lan Tianyu <lantianyu1986@...il.com>,
	Toralf Förster <toralf.foerster@....de>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	<cpufreq@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Jarzmik, Robert" <robert.jarzmik@...el.com>,
	"R, Durgadoss" <durgadoss.r@...el.com>,
	Dirk Brandewie <dirk.brandewie@...il.com>,
	<tianyu.lan@...el.com>
Subject: Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume

On Thu, 11 Jul 2013, Srivatsa S. Bhat wrote:

> Oops! You are right. Hmm, this looks quite difficult to get right :(
> There are multiple challenges here:
> 
> 1. The sysfs files must not be removed during cpu_down, and not initialized
> 
>    during cpu_up. That would help us preserve the file permissions.
> 2. But we should ensure that we really do the cpufreq-core parts of the cpu
>    initialization during cpu_up. If we fail to free some of the data-structures
>    during cpu_down, the cpu_up callback will think that a full-init is not
>    required and not do its job. That will make cpufreq behave erratically after
>    suspend/resume and take us back to square one.
> 
> 3. A full re-init in the cpu_up callback also involves memory allocations.
>    So if we don't release the memory in the cpu_down callback, we'll end up
>    in a memory leak.
> 
> I tried to address all these in this patch, but you found yet another serious
> loop-hole. I guess I'm out of ideas now... if anybody has any thoughts on how
> to get this right, then I'm all ears. Else, we'll just revert the original
> commit like Rafael suggested and leave it upto userspace to save and restore
> the permissions across suspend/resume if it wants ;-(

Asking as a naive outsider who is completely unfamiliar with the code,
why are any of these things at all troublesome?

	Can't cpu_up tell the difference between activating a brand-new
	CPU and reactivating one that was present before but was
	temporarily disabled?

	Doesn't cpu_up know which data structures get freed when an
	active CPU is temporarily deactivated?

	Doesn't cpu_down know what memory gets allocated in cpu_up?
	Can't it deallocate just the right parts for the type of
	transition it is doing?

It sounds like you're really asking how to make sure that cpu_up and 
cpu_down both know what the other is doing, so that each can do the 
opposite of the other.  That doesn't sound hard.

Alan Stern

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