linux-kernel - Re: [PATCH RFT v2] x86: move cacheinfo sysfs to generic cacheinfo infrastructure

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: <54F6D5FA.6000307@arm.com>
Date:	Wed, 04 Mar 2015 09:52:58 +0000
From:	Sudeep Holla <sudeep.holla@....com>
To:	Borislav Petkov <bp@...e.de>,
	Andre Przywara <Andre.Przywara@....com>,
	Tejun Heo <tj@...nel.org>
CC:	Sudeep Holla <sudeep.holla@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH RFT v2] x86: move cacheinfo sysfs to generic cacheinfo
 infrastructure



On 03/03/15 18:45, Borislav Petkov wrote:
[...]

> Now, previously the code did
>
> -			if (!per_cpu(ici_cpuid4_info, i))
> -				continue;
>
>
> and __cache_cpumap_setup() already does:
>
>                          if (i == cpu || !sib_cpu_ci->info_list)
>                                  continue;/* skip if itself or no cacheinfo */
>
> so maybe we should do that too in __cache_amd_cpumap_setup():
>
>                          if (!this_cpu_ci->info_list)
>                                  continue;
>
> for the index == 3 case?
>
> It boots fine here with that change and it is consistent with the
> previous code.
>

Ok, I will add the above check. Sorry for missing that.

> And yes, the x86 cacheinfo code could use a serious rubbing and cleanup.
>
> Btw, this patch introduces a bunch of new sysfs nodes in the caches
> hierarchy:
>
> --- caches-guest-before.txt     2015-03-03 15:11:09.168276423 +0100
> +++ caches-guest-after.txt      2015-03-03 18:19:04.084426130 +0100
> @@ -1,6 +1,22 @@
> +/sys/devices/system/cpu/cpu0/cache/power/control:1:auto
> +/sys/devices/system/cpu/cpu0/cache/power/async:1:disabled
> +/sys/devices/system/cpu/cpu0/cache/power/runtime_enabled:1:disabled
> +/sys/devices/system/cpu/cpu0/cache/power/runtime_active_kids:1:0
> +/sys/devices/system/cpu/cpu0/cache/power/runtime_active_time:1:0
> +/sys/devices/system/cpu/cpu0/cache/power/runtime_status:1:unsupported
> +/sys/devices/system/cpu/cpu0/cache/power/runtime_usage:1:0
> +/sys/devices/system/cpu/cpu0/cache/power/runtime_suspended_time:1:0
>   /sys/devices/system/cpu/cpu0/cache/index0/size:1:64K
>   /sys/devices/system/cpu/cpu0/cache/index0/type:1:Data
>   /sys/devices/system/cpu/cpu0/cache/index0/level:1:1
> +/sys/devices/system/cpu/cpu0/cache/index0/power/control:1:auto
> +/sys/devices/system/cpu/cpu0/cache/index0/power/async:1:disabled
> +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_enabled:1:disabled
> +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_active_kids:1:0
> +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_active_time:1:0
> +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_status:1:unsupported
> +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_usage:1:0
> +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_suspended_time:1:0
>   /sys/devices/system/cpu/cpu0/cache/index0/number_of_sets:1:512
>   /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map:1:1
>   /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_list:1:0
>   ...
>
> What do those things mean? runtime_active_kids ?? Kids are active during
> runtime?! Well, that's a given, no need for a sysfs node for that :-)
>

Those extra sysfs are due to that fact that generic cacheinfo sysfs
is not using raw kobjects directly anymore (which was the case with most
of the old cacheinfo sysfs implementation), but uses device/device
attributes as Greg suggested to simply the code and reuse device model
code.

Regards,
Sudeep

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