linux-kernel - Re: [PATCH] backlight: report error on failure

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: <20170219081311.GA30444@wychelm.lan>
Date:   Sun, 19 Feb 2017 08:13:11 +0000
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc:     Jingoo Han <jingoohan1@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        linux-kernel@...r.kernel.org, linux-fbdev@...r.kernel.org
Subject: Re: [PATCH] backlight: report error on failure

On Wed, Jan 18, 2017 at 09:23:50PM +0000, Sudip Mukherjee wrote:
> It is possible to update the backlight power and the brightness using
> the sysfs and on writing it either returns the count or if the callback
> function does not exist then returns the error code 'ENXIO'.
> 
> We have a situation where the userspace client is writing to the sysfs
> to update the power and since the callback function exists the client
> receives the return value as count and considers the operation to be
> successful. That is correct as the write to the sysfs was successful.
> But there is no way to know if the actual operation was done or not.

For brightness there is the actual_brightness file... but I don't think
there's anything for power.


> backlight_update_status() returns the error code if it fails. Pass that
> to the userspace client who is trying to update the power so that the
> client knows that the operation failed.

Strictly speaking this is an ABI change. Its probably a harmless one
making it ok to change but I'm interested what testing or code review 
you've done to be sure the userspace doesn't do odd things if the kernel
starts to pass through errors.


> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@...ethink.co.uk>
> ---
>  drivers/video/backlight/backlight.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index 288318a..74b72b5 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -146,9 +146,9 @@ static ssize_t bl_power_store(struct device *dev, struct device_attribute *attr,
>  		pr_debug("set power to %lu\n", power);
>  		if (bd->props.power != power) {
>  			bd->props.power = power;
> -			backlight_update_status(bd);
> +			rc = backlight_update_status(bd);
>  		}
> -		rc = count;
> +		rc = rc ? rc : count;

Shouldn't bd->props,power be rolled back on error?

Without it we end up in an odd situation with the lazy updates, 
specifically if the userspace observes original error and retries then we
will spuriously succeed due to the lazy update (leaving us not much 
better off than without this change).


>  	mutex_unlock(&bd->ops_lock);
>  
> @@ -176,8 +176,7 @@ int backlight_device_set_brightness(struct backlight_device *bd,
>  		else {
>  			pr_debug("set brightness to %lu\n", brightness);
>  			bd->props.brightness = brightness;
> -			backlight_update_status(bd);
> -			rc = 0;
> +			rc = backlight_update_status(bd);

Again, there is no roll back on error.


Daniel.