linux-kernel - Re: [PATCH] iio: cros_ec_accel_legacy: Mark expected switch fall-throughs

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:   Wed, 20 Feb 2019 12:47:08 -0600
From:   "Gustavo A. R. Silva" <gustavo@...eddedor.com>
To:     Jonathan Cameron <jic23@...nel.org>,
        Kees Cook <keescook@...omium.org>
Cc:     Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        linux-iio@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Gwendal Grignou <gwendal@...omium.org>
Subject: Re: [PATCH] iio: cros_ec_accel_legacy: Mark expected switch
 fall-throughs



On 2/20/19 12:34 PM, Jonathan Cameron wrote:
> On Wed, 20 Feb 2019 10:20:39 -0800
> Kees Cook <keescook@...omium.org> wrote:
> 
>> On Mon, Oct 8, 2018 at 10:24 AM Gustavo A. R. Silva
>> <gustavo@...eddedor.com> wrote:
>>>
>>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>>> where we are expecting to fall through.
>>>
>>> Addresses-Coverity-ID: 1397962 ("Missing break in switch")
>>> Signed-off-by: Gustavo A. R. Silva <gustavo@...eddedor.com>
>>> ---
>>>  drivers/iio/accel/cros_ec_accel_legacy.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c b/drivers/iio/accel/cros_ec_accel_legacy.c
>>> index 063e89e..d609654 100644
>>> --- a/drivers/iio/accel/cros_ec_accel_legacy.c
>>> +++ b/drivers/iio/accel/cros_ec_accel_legacy.c
>>> @@ -385,8 +385,10 @@ static int cros_ec_accel_legacy_probe(struct platform_device *pdev)
>>>                 switch (i) {
>>>                 case X:
>>>                         ec_accel_channels[X].scan_index = Y;
>>> +                       /* fall through */
>>>                 case Y:
>>>                         ec_accel_channels[Y].scan_index = X;
>>> +                       /* fall through */
>>>                 case Z:
>>>                         ec_accel_channels[Z].scan_index = Z;
>>>                 }  
>>
>> Shouldn't these actually be "break;"s ? It seems like the loop is
>> stepping through X, Y, and Z. The _result_ is accidentally the same:
>>
>> X: set X, Y, and Z
>> Y: set Y and Z
>> Z: set Z
>>
>> result: X, Y, and Z are set correctly. But the code is technically wrong.
>>

Yeah. Actually, we can even take the switch and for out of the equation,
and the code can be rewritten as follows:

ec_accel_channels[X].scan_index = Y;
ec_accel_channels[Y].scan_index = X;
ec_accel_channels[Z].scan_index = Z;

if (state->sensor_num == MOTIONSENSE_LOC_LID)
	state->sign[X] = state->sign[Z] = -1;
else
	state->sign[X] = state->sign[Y] = state->sign[Z] = 1;

> 
> Agreed, it's 'novel'.  Waiting for Gwendal or someone else to come
> back and check it wasn't meant to be doing something else.
> 

We've been waiting 5 months for Gwendal. :/

Thanks
--
Gustavo