linux-kernel - Re: [PATCH 1/3 v6] cpufreq: Add debugfs directory for 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]

Date:	Wed, 24 Jul 2013 18:05:33 +0900
From:	Chanwoo Choi <cw00.choi@...sung.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	rjw@...k.pl, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, cpufreq@...r.kernel.org,
	kyungmin.park@...sung.com, myungjoo.ham@...sung.com,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>
Subject: Re: [PATCH 1/3 v6] cpufreq: Add debugfs directory for cpufreq

On 07/24/2013 05:51 PM, Viresh Kumar wrote:
> On 24 July 2013 14:16, Chanwoo Choi <cw00.choi@...sung.com> wrote:
>> In case that all CPUs share same cpufreq policy. Each debugfs dentry of CPU[1-3]
>> except for CPU0 has symbolic link to CPU0's debugfs directory as following.
>>
>> -sh-4.1# ls -al /sys/kernel/debug/cpufreq/
>> total 0
>> drwxr-xr-x  3 root root 0 Jan  1 09:00 .
>> drwx------ 28 root root 0 Jan  1 09:00 ..
>> drwxr-xr-x  2 root root 0 Jan  1 09:00 cpu0             (policy->cpu is 0)
>> lrwxrwxrwx  1 root root 0 Jan  1 09:00 cpu1 -> ./cpu0
>> lrwxrwxrwx  1 root root 0 Jan  1 09:00 cpu2 -> ./cpu0
>> lrwxrwxrwx  1 root root 0 Jan  1 09:00 cpu3 -> ./cpu0
>>
>> If turn off CPU0 state, I have to move debugfs directory data from cpu0 to cpu1
>> and again create link to cpu1's debugfs directory for CPU[2-3] debugfs directory.
>> So, I removed dentry link of CPU[1-3] before creating link again.
>>
>> cpu1
>> cpu2 -> ./cpu1
>> cpu3 -> ./cpu1
>>
>> But I can rewrite new link of CPU[2-3] to previous dentry link(policy->cpu_debugfs[2] or policy->cpu_debugfs[3])
>> for reducing unnecessary code without revmoval sequence.
> 
> Because we aren't freeing the debugfs node at all (just renaming
> it), the links might still be good after renaming.. But please check
> if it is true.
> 
> So, according to me you need to do this:
> - Remove symlink for new policy->cpu, i..e cpu1 in your example
> - rename debugfs entry to give it to cpu1 instead of cpu0.
> - Set cpu0 pointer to NULL.
> 
> Probably that's it.
> 

And, I add additional step on below:

> - Remove symlink for new policy->cpu, i..e cpu1 in your example
> - rename debugfs entry to give it to cpu1 instead of cpu0.
  - Store renamed cpu0 pointer to cpu1 pointer
  - Create new link for CPU[2-3] to CPU1's debugfs directory
	because debugfs use string path to create symbolic link.
	It isn't automatically connected with new CPU1 debugfs directory. 
> - Set cpu0 pointer to NULL.
> 

Thanks,
Chanwoo Choi



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