[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOdkjpRVJ=TE8JCoMDJ46s6ToSgo0c2RcsoQ-JOPYMgLUpw@mail.gmail.com>
Date: Fri, 8 Mar 2019 13:02:47 -0800
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Nathan Chancellor <natechancellor@...il.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...com>,
Jose Abreu <joabreu@...opsys.com>,
"David S. Miller" <davem@...emloft.net>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>,
clang-built-linux@...glegroups.com
Subject: Re: [PATCH] net: stmmac: Avoid one more sometimes uninitialized Clang warning
On Thu, Mar 7, 2019 at 8:02 PM Nathan Chancellor
<natechancellor@...il.com> wrote:
>
> When building with -Wsometimes-uninitialized, Clang warns:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable
> 'ns' is used uninitialized whenever 'if' condition is false
> [-Werror,-Wsometimes-uninitialized]
> drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable
> 'ns' is used uninitialized whenever '&&' condition is false
> [-Werror,-Wsometimes-uninitialized]
>
> Clang is concerned with the use of stmmac_do_void_callback (which
> stmmac_get_systime wraps), as it may fail to initialize these values if
> the if condition was ever false (meaning the callback doesn't exist).
> It's not wrong because the callback is what initializes ns. While it's
> unlikely that the callback is going to disappear at some point and make
> that condition false, we can easily avoid this warning by zero
> initializing the variable.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/384
> Fixes: df103170854e ("net: stmmac: Avoid sometimes uninitialized Clang warnings")
Was initially confused by the link (thought I caught the 3 previous
instances in code review of df103170854e). I see now that I did not
report stmmac_ptp.c (only stmmac_main.c) properly. Had I, this could
have been bundled up into df103170854e indeed. Sorry. Thanks for
circling back and cleaning up this additional instance.
Reviewed-by: Nick Desaulniers <ndesaulniers@...gle.com>
> Suggested-by: Nick Desaulniers <ndesaulniers@...gle.com>
> Signed-off-by: Nathan Chancellor <natechancellor@...il.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
> index 2293e21f789f..cc60b3fb0892 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
> @@ -105,7 +105,7 @@ static int stmmac_get_time(struct ptp_clock_info *ptp, struct timespec64 *ts)
> struct stmmac_priv *priv =
> container_of(ptp, struct stmmac_priv, ptp_clock_ops);
> unsigned long flags;
> - u64 ns;
> + u64 ns = 0;
>
> spin_lock_irqsave(&priv->ptp_lock, flags);
> stmmac_get_systime(priv, priv->ptpaddr, &ns);
> --
> 2.21.0
>
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists