linux-kernel - Re: [PATCH v2 11/15] ACPI: platform_profile: Set profile for all registered 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: <f65998f4-6396-9cff-09a1-6ee2a49dc254@linux.intel.com>
Date: Tue, 29 Oct 2024 18:50:40 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Mario Limonciello <mario.limonciello@....com>
cc: Hans de Goede <hdegoede@...hat.com>, 
    "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>, 
    "open list:ACPI" <linux-acpi@...r.kernel.org>, 
    "open list:MICROSOFT SURFACE PLATFORM PROFILE DRIVER" <platform-driver-x86@...r.kernel.org>, 
    "open list:THINKPAD ACPI EXTRAS DRIVER" <ibm-acpi-devel@...ts.sourceforge.net>, 
    Mark Pearson <mpearson-lenovo@...ebb.ca>, 
    Matthew Schwartz <matthew.schwartz@...ux.dev>
Subject: Re: [PATCH v2 11/15] ACPI: platform_profile: Set profile for all
 registered handlers

On Tue, 29 Oct 2024, Mario Limonciello wrote:

> On 10/29/2024 05:22, Ilpo Järvinen wrote:
> > On Sun, 27 Oct 2024, Mario Limonciello wrote:
> > 
> > > If multiple platform profile handlers have been registered then when
> > > setting a profile verify that all profile handlers support the requested
> > > profile and set it to each handler.
> > > 
> > > If this fails for any given handler, revert all profile handlers back to
> > > balanced and log an error into the kernel ring buffer.
> > > 
> > > Tested-by: Matthew Schwartz <matthew.schwartz@...ux.dev>
> > > Signed-off-by: Mario Limonciello <mario.limonciello@....com>
> > > ---
> > >   drivers/acpi/platform_profile.c | 47 ++++++++++++++++++---------------
> > >   1 file changed, 26 insertions(+), 21 deletions(-)
> > > 
> > > diff --git a/drivers/acpi/platform_profile.c
> > > b/drivers/acpi/platform_profile.c
> > > index a83842f05022b..db2ebd0393cf7 100644
> > > --- a/drivers/acpi/platform_profile.c
> > > +++ b/drivers/acpi/platform_profile.c
> > > @@ -105,37 +105,42 @@ static ssize_t platform_profile_store(struct device
> > > *dev,
> > >   			    struct device_attribute *attr,
> > >   			    const char *buf, size_t count)
> > >   {
> > > +	struct platform_profile_handler *handler;
> > > +	unsigned long choices;
> > >   	int err, i;
> > >   -	err = mutex_lock_interruptible(&profile_lock);
> > > -	if (err)
> > > -		return err;
> > > -
> > > -	if (!cur_profile) {
> > > -		mutex_unlock(&profile_lock);
> > > -		return -ENODEV;
> > > -	}
> > > -
> > >   	/* Scan for a matching profile */
> > >   	i = sysfs_match_string(profile_names, buf);
> > >   	if (i < 0) {
> > > -		mutex_unlock(&profile_lock);
> > >   		return -EINVAL;
> > >   	}
> > >   -	/* Check that platform supports this profile choice */
> > > -	if (!test_bit(i, cur_profile->choices)) {
> > > -		mutex_unlock(&profile_lock);
> > > -		return -EOPNOTSUPP;
> > > -	}
> > > +	scoped_cond_guard(mutex_intr, return -ERESTARTSYS, &profile_lock) {
> > 
> > You made guard() conversions in the earlier patch but for some reason
> > left scoped_cond_guard() ones mixed into other changes still. Is there
> > a very good reason for that?
> > 
> 
> Using scoped_cond_guard() requires changing the indentation which meant a bit
> of back and forth with code coming and going.  If you think it makes more
> sense to split up even considering the indentation changes I'll do another set
> of patches for the scoped_cond_guard changes only.

There are ways to combat indentation changes while reviewing. However, 
it's a strange argument to bring up because now there are indentation 
changes in these patches exactly because you chose to make the 
scoped_cond_guard() change "while at it" rather than in a separate patch.

I believe the patches will become cleaner and easier to review if you do 
scoped_cond_guard() change separate from any other logic changes.

-- 
 i.