netdev - Re: [PATCH] sfc-falcon: Fix missing error code in ef4_reset

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] [day] [month] [year] [list]

Date:   Tue, 1 Jun 2021 12:22:50 +0100
From:   Edward Cree <ecree.xilinx@...il.com>
To:     Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>
Cc:     habetsm.xilinx@...il.com, davem@...emloft.net, kuba@...nel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sfc-falcon: Fix missing error code in ef4_reset_up()

On 01/06/2021 12:06, Jiapeng Chong wrote:
> The error code is missing in this code scenario, add the error code
> '-EINVAL' to the return value 'rc'.
> 
> Eliminate the follow smatch warning:
> 
> drivers/net/ethernet/sfc/falcon/efx.c:2389 ef4_reset_up() warn: missing
> error code 'rc'.
> 
> Reported-by: Abaci Robot <abaci@...ux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>
> ---
>  drivers/net/ethernet/sfc/falcon/efx.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/sfc/falcon/efx.c b/drivers/net/ethernet/sfc/falcon/efx.c
> index 5e7a57b..d336c24 100644
> --- a/drivers/net/ethernet/sfc/falcon/efx.c
> +++ b/drivers/net/ethernet/sfc/falcon/efx.c
> @@ -2385,8 +2385,10 @@ int ef4_reset_up(struct ef4_nic *efx, enum reset_type method, bool ok)
>  		goto fail;
>  	}
>  
> -	if (!ok)
> +	if (!ok) {
> +		rc = -EINVAL;
>  		goto fail;
> +	}
Not sure this is correct.  Without the patch, we return with rc == 0
 (set by the efx->type->init() call just above), which seems reasonable
 as we successfully finished a RESET_TYPE_DISABLE.
The label name 'fail:' might be misleading; it does seem like this is
 intended behaviour.
Have you tested this at all?

Note that the sfc driver (efx_common.c) does much the same thing as the
 code here before your patch.

-ed

>  
>  	if (efx->port_initialized && method != RESET_TYPE_INVISIBLE &&
>  	    method != RESET_TYPE_DATAPATH) {
>