Re: [PATCH] can: rockchip_canfd: fix return type of rkcanfd_start_xmit()

[Nathan Chancellor <nathan@kernel.org>]

Hi Marc,

On Tue, Sep 10, 2024 at 11:56:56AM +0200, Marc Kleine-Budde wrote:
> On 09.09.2024 15:35:46, Simon Horman wrote:
> > On Mon, Sep 09, 2024 at 10:57:06AM +0200, Marc Kleine-Budde wrote:
> > > On 09.09.2024 09:44:48, Simon Horman wrote:
> > > > On Fri, Sep 06, 2024 at 01:26:41PM -0700, Nathan Chancellor wrote:
> > > > > With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
> > > > > indirect call targets are validated against the expected function
> > > > > pointer prototype to make sure the call target is valid to help mitigate
> > > > > ROP attacks. If they are not identical, there is a failure at run time,
> > > > > which manifests as either a kernel panic or thread getting killed. A
> > > > > warning in clang aims to catch these at compile time, which reveals:
> > > > > 
> > > > >   drivers/net/can/rockchip/rockchip_canfd-core.c:770:20: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
> > > > >     770 |         .ndo_start_xmit = rkcanfd_start_xmit,
> > > > >         |                           ^~~~~~~~~~~~~~~~~~
> > > > > 
> > > > > ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
> > > > > 'netdev_tx_t', not 'int' (although the types are ABI compatible). Adjust
> > > > > the return type of rkcanfd_start_xmit() to match the prototype's to
> > > > > resolve the warning.
> > > > > 
> > > > > Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller")
> > > > > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > > > 
> > > > Thanks, I was able to reproduce this problem at build time
> > > > and that your patch addresses it.
> > > 
> > > FTR: the default clang in Debian unstable, clang-16.0.6 doesn't support
> > > this. With clang-20 from experimental it works, haven't checked older
> > > versions, though.
> > 
> > FTR: I checked using 18.1.8 from here [1][2].
> > 
> > [1] https://mirrors.edge.kernel.org/pub/tools/llvm/
> > [2] https://mirrors.edge.kernel.org/pub/tools/llvm/files/
> 
> I was a bit hasty yesterday, clang-20 and W=1 produces these errors:
> 
> | include/linux/vmstat.h:517:36: error: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Werror,-Wenum-enum-conversion]
> |   517 |         return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
> |       |                               ~~~~~~~~~~~ ^ ~~~
> | 1 error generated.

Unfortunately, this is a completely tangential issue. You can see some
backstory behind it in commit 75b5ab134bb5 ("kbuild: Move
-Wenum-{compare-conditional,enum-conversion} into W=1"). To be honest, I
should consider moving that to W=2...

> However I fail to reproduce the ndo_start_xmit problem. Even with 18.1.8
> from kernel.org.
> 
> 
> The following command (ARCH is unset, compiling x86 -> x86) produces the
> above shown "vmstat.h" problems....
> 
> | $ make LLVM=1 LLVM_IAS=1 LLVM_SUFFIX=-20 drivers/net/can/rockchip/  W=1 CONFIG_WERROR=0

FYI, you could shorten this to just:

  $ make LLVM=-20 drivers/net/can/rockchip/ W=1 CONFIG_WERROR=0

As LLVM_SUFFIX will be set through LLVM and LLVM_IAS has defaulted to 1
since 5.15.

Does CONFIG_WERROR=0 work? It seems like it is still present above.

> ... but not the ndo_start_xmit problem.
> 
> 
> Am I missing a vital .config option?

No, I might not have made it clear in this commit message but this
warning is not on by default. I am looking to turn it on at some point
so I keep up with the warnings that it produces but there is one
subsystem that has several instances and I am unsure of how to solve
them to the maintainer's satisfaction. You can test it by adding

  KCFLAGS=-Wincompatible-function-pointer-types-strict

to your make command above and it should reproduce.

Cheers,
Nathan