linux-kernel - Re: [PATCH 02/14] platform/x86/intel/ifs: Propagate load failure error code

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: <4028a1c7-ed84-37a8-1d94-178b5aa201a9@intel.com>
Date:   Mon, 24 Oct 2022 15:52:07 -0700
From:   Sohil Mehta <sohil.mehta@...el.com>
To:     Jithu Joseph <jithu.joseph@...el.com>
CC:     <tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
        <dave.hansen@...ux.intel.com>, <x86@...nel.org>, <hpa@...or.com>,
        <gregkh@...uxfoundation.org>, <ashok.raj@...el.com>,
        <tony.luck@...el.com>, <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <patches@...ts.linux.dev>,
        <ravi.v.shankar@...el.com>, <thiago.macieira@...el.com>,
        <athenas.jimenez.gonzalez@...el.com>, <hdegoede@...hat.com>,
        <markgross@...nel.org>
Subject: Re: [PATCH 02/14] platform/x86/intel/ifs: Propagate load failure
 error code

Hi Jithu,

On 10/21/2022 1:34 PM, Jithu Joseph wrote:
> Existing implementation was returning fixed error code to user space
> regardless of the load failure encountered.
> 

The tense is a bit confusing here. Also, 'Existing implementation' is 
typically implied and unnecessary. Would something like this be better?

The reload operation returns a fixed error code to user space regardless 
of the load failure encountered.

Modify..

> Modify this to propagate the actual error code to user space.
> 

...

> diff --git a/drivers/platform/x86/intel/ifs/load.c b/drivers/platform/x86/intel/ifs/load.c
> index d056617ddc85..ebaa1d6a2b18 100644
> --- a/drivers/platform/x86/intel/ifs/load.c
> +++ b/drivers/platform/x86/intel/ifs/load.c
> @@ -234,7 +234,7 @@ static bool ifs_image_sanity_check(struct device *dev, const struct microcode_he
>    * Load ifs image. Before loading ifs module, the ifs image must be located
>    * in /lib/firmware/intel/ifs and named as {family/model/stepping}.{testname}.
>    */
> -void ifs_load_firmware(struct device *dev)
> +int ifs_load_firmware(struct device *dev)
>   {
>   	struct ifs_data *ifsd = ifs_get_data(dev);
>   	const struct firmware *fw;
> @@ -263,4 +263,6 @@ void ifs_load_firmware(struct device *dev)
>   	release_firmware(fw);
>   done:
>   	ifsd->loaded = (ret == 0);
> +
> +	return ret;
>   }
> diff --git a/drivers/platform/x86/intel/ifs/sysfs.c b/drivers/platform/x86/intel/ifs/sysfs.c
> index 37d8380d6fa8..4af4e1bea98d 100644
> --- a/drivers/platform/x86/intel/ifs/sysfs.c
> +++ b/drivers/platform/x86/intel/ifs/sysfs.c
> @@ -94,9 +94,8 @@ static ssize_t reload_store(struct device *dev,
>   			    struct device_attribute *attr,
>   			    const char *buf, size_t count)
>   {
> -	struct ifs_data *ifsd = ifs_get_data(dev);
>   	bool res;
> -
> +	int rc;
>   

Does rc refer to return code? The other IFS functions like above use the 
commonly used 'ret' variable. Any specific reason for the inconsistency?

Also, patch 11 completely removes the reload_store() function. Should we 
avoid a separate patch to fix something that is going to be removed 
soon? Would re-ordering the patches help in that regard?

>   	if (kstrtobool(buf, &res))
>   		return -EINVAL;
> @@ -106,11 +105,11 @@ static ssize_t reload_store(struct device *dev,
>   	if (down_interruptible(&ifs_sem))
>   		return -EINTR;
>   
> -	ifs_load_firmware(dev);
> +	rc = ifs_load_firmware(dev);
>   
>   	up(&ifs_sem);
>   
> -	return ifsd->loaded ? count : -ENODEV;
> +	return (rc == 0) ? count : rc;
>   }
>   
>   static DEVICE_ATTR_WO(reload);


Sohil