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]
Date:   Thu, 5 Nov 2020 09:55:21 +0100
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Christophe Leroy <christophe.leroy@...roup.eu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        Paul Mackerras <paulus@...ba.org>, linux-serial@...r.kernel.org
Subject: Re: [PATCH 34/36] tty: serial: pmac_zilog: Make disposable variable
 __always_unused

On 05. 11. 20, 9:36, Lee Jones wrote:
> On Thu, 05 Nov 2020, Jiri Slaby wrote:
> 
>> On 05. 11. 20, 8:04, Christophe Leroy wrote:
>>>
>>>
>>> Le 04/11/2020 à 20:35, Lee Jones a écrit :
>>>> Fixes the following W=1 kernel build warning(s):
>>>>
>>>>    drivers/tty/serial/pmac_zilog.h:365:58: warning: variable
>>>> ‘garbage’ set but not used [-Wunused-but-set-variable]
>>>
>>> Explain how you are fixing this warning.
>>>
>>> Setting  __always_unused is usually not the good solution for fixing
>>> this warning, but here I guess this is likely the good solution. But it
>>> should be explained why.
> 
> There are normally 3 ways to fix this warning;
> 
>   - Start using/checking the variable/result
>   - Remove the variable
>   - Mark it as __{always,maybe}_unused
> 
> The later just tells the compiler that not checking the resultant
> value is intentional.  There are some functions (as Jiri mentions
> below) which are marked as '__must_check' which *require* a dummy
> (garbage) variable to be used.
> 
>> Or, why is the "garbage =" needed in the first place? read_zsdata is not
>> defined with __warn_unused_result__.
> 
> I used '__always_used' here for fear of breaking something.
> 
> However, if it's safe to remove it, then all the better.

Yes please -- this "garbage" is one of the examples of volatile misuses. 
If readb didn't work on volatile pointer, marking the return variable as 
volatile wouldn't save it.

>> And even if it was, would (void)!read_zsdata(port) fix it?
> 
> That's hideous. :D

Sure, marking reads as must_check would be insane.

> *Much* better to just use '__always_used' in that use-case.

Then using a dummy variable to fool must_check must mean must_check is 
used incorrectly, no :)? But there are always exceptions…

thanks,
-- 
js
suse labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ