linux-kernel - Re: [PATCH v3 15/22] ACPI: platform_profile: Only show profiles common for all handlers

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: <7fec9e68-4cc7-4db9-a6a3-8a2917132ac8@app.fastmail.com>
Date: Fri, 01 Nov 2024 22:15:03 -0400
From: "Mark Pearson" <mpearson-lenovo@...ebb.ca>
To: "Limonciello, Mario" <mario.limonciello@....com>,
 "Hans de Goede" <hdegoede@...hat.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, "Len Brown" <lenb@...nel.org>,
 "Maximilian Luz" <luzmaximilian@...il.com>, "Lee Chun-Yi" <jlee@...e.com>,
 "Shyam Sundar S K" <Shyam-sundar.S-k@....com>,
 "Corentin Chary" <corentin.chary@...il.com>,
 "Luke D . Jones" <luke@...nes.dev>, "Ike Panhc" <ike.pan@...onical.com>,
 "Henrique de Moraes Holschuh" <hmh@....eng.br>,
 "Alexis Belmonte" <alexbelm48@...il.com>,
 Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
 "Ai Chao" <aichao@...inos.cn>, "Gergo Koteles" <soyer@....hu>,
 "open list" <linux-kernel@...r.kernel.org>,
 "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
 "platform-driver-x86@...r.kernel.org" <platform-driver-x86@...r.kernel.org>,
 "open list:THINKPAD ACPI EXTRAS DRIVER" <ibm-acpi-devel@...ts.sourceforge.net>,
 "Matthew Schwartz" <matthew.schwartz@...ux.dev>
Subject: Re: [PATCH v3 15/22] ACPI: platform_profile: Only show profiles common for all
 handlers

On Thu, Oct 31, 2024, at 12:09 AM, Mario Limonciello wrote:
> If multiple platform profile handlers have been registered, don't allow
> switching to profiles unique to only one handler.
>
> Tested-by: Matthew Schwartz <matthew.schwartz@...ux.dev>
> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
> ---
>  drivers/acpi/platform_profile.c | 38 +++++++++++++++++++++++++--------
>  1 file changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/acpi/platform_profile.c b/drivers/acpi/platform_profile.c
> index 7bd32f1e8d834..90cbc0de4d5bc 100644
> --- a/drivers/acpi/platform_profile.c
> +++ b/drivers/acpi/platform_profile.c
> @@ -29,23 +29,43 @@ static bool platform_profile_is_registered(void)
>  	return !list_empty(&platform_profile_handler_list);
>  }
> 
> +static unsigned long platform_profile_get_choices(void)
> +{
> +	struct platform_profile_handler *handler;
> +	unsigned long aggregate = 0;
> +	int i;
> +
> +	lockdep_assert_held(&profile_lock);
> +	list_for_each_entry(handler, &platform_profile_handler_list, list) {
> +		unsigned long individual = 0;
> +
> +		for_each_set_bit(i, handler->choices, PLATFORM_PROFILE_LAST)
> +			individual |= BIT(i);
> +		if (!aggregate)
> +			aggregate = individual;
> +		else
> +			aggregate &= individual;
> +	}
> +
> +	return aggregate;
> +}
> +

I realise this is very unlikely but isn't it possible that the number of profiles could overflow unsigned long number of bits? As handler->choices is an array of them. It should loop through BITS_TO_LONGS(PLATFORM_PROFILE_LAST) cycles.

Also wondered if this could be simplified with setting aggregate = ~0 and then & it with each handler->choices to avoid having to scan individual bits?

>  static ssize_t platform_profile_choices_show(struct device *dev,
>  					struct device_attribute *attr,
>  					char *buf)
>  {
> +	unsigned long choices;
>  	int len = 0;
>  	int i;
> 
> -	scoped_cond_guard(mutex_intr, return -ERESTARTSYS, &profile_lock) {
> -		if (!cur_profile)
> -			return -ENODEV;
> +	scoped_cond_guard(mutex_intr, return -ERESTARTSYS, &profile_lock)
> +		choices = platform_profile_get_choices();
> 
> -		for_each_set_bit(i, cur_profile->choices, PLATFORM_PROFILE_LAST) {
> -			if (len == 0)
> -				len += sysfs_emit_at(buf, len, "%s", profile_names[i]);
> -			else
> -				len += sysfs_emit_at(buf, len, " %s", profile_names[i]);
> -		}
> +	for_each_set_bit(i, &choices, PLATFORM_PROFILE_LAST) {
> +		if (len == 0)
> +			len += sysfs_emit_at(buf, len, "%s", profile_names[i]);
> +		else
> +			len += sysfs_emit_at(buf, len, " %s", profile_names[i]);
>  	}
>  	len += sysfs_emit_at(buf, len, "\n");
> 
> -- 
> 2.43.0

This links in to the later patches - but I was wondering if at profile registration/unregistration if building a local choices selection would simplify things.
Then instead of needing platform_profile_get_choices, you can just use your local choices selection to make decisions on what to show, or cycle to - instead of having to cycle thru the profiles and bits every time.

Not 100% sure how well it would work out - but might be simpler and faster?

Mark