lkml.org 
[lkml]   [2020]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: linux-next: Tree for Mar 31 (mlx5)
Date
On Tue, 2020-03-31 at 09:39 -0700, Randy Dunlap wrote:
> On 3/31/20 2:10 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > The merge window has opened, so please do not add any material for
> > the
> > next release into your linux-next included trees/branches until
> > after
> > the merge window closes.
> >
> > Changes since 20200330:
> >
>
> on x86_64:
>
> ld: drivers/net/ethernet/mellanox/mlx5/core/main.o: in function
> `mlx5_cleanup_once':
> main.c:(.text+0x1ca): undefined reference to `mlx5_vxlan_destroy'
> ld: main.c:(.text+0x1d2): undefined reference to `mlx5_cleanup_clock'
> ld: drivers/net/ethernet/mellanox/mlx5/core/main.o: in function
> `mlx5_load_one':
> main.c:(.text+0xf44): undefined reference to `mlx5_init_clock'
> ld: main.c:(.text+0xf4c): undefined reference to `mlx5_vxlan_create'
> ld: main.c:(.text+0xfe5): undefined reference to `mlx5_vxlan_destroy'
>
>

This due to a change in behavior of imply keyword in kconfig due to
this patch:

def2fbffe62c00c330c7f41584a356001179c59c is the first bad commit
commit def2fbffe62c00c330c7f41584a356001179c59c
Author: Masahiro Yamada <masahiroy@kernel.org>
Date: Mon Mar 2 15:23:39 2020 +0900

kconfig: allow symbols implied by y to become m

The 'imply' keyword restricts a symbol to y or n, excluding m
when it is implied by y. This is the original behavior since
commit 237e3ad0f195 ("Kconfig: Introduce the "imply" keyword").

However, the author of this feature, Nicolas Pitre, stated that
the 'imply' keyword should not impose any restrictions.
(https://lkml.org/lkml/2020/2/19/714)

I agree, and want to get rid of this tricky behavior.

Suggested-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>

For example in mlx5 we rely on CONFIG_VXLAN to compile in/out mlx5's
vxlan support, the problem occurs when VXLAN=m and MLX5_CORE=y.. prior
to this patch imply restricted VXLAN to y prior to this commit, and a
user who selected MLX5 and VXLAN, regardless of each module state
(y,m),
VXLAN in mlx5 worked.

but now with the change in behavior - even if we fix MLX5 - mlx5's
vxlan will be compiled-in but will not be actually used as VXLAN is not
reachable .. this change in behavior will introduce regression for
those who choose VXLAN=m MLX5_CORE=y.

To be honest this is a very unlikely configuration, but still i wanted
to raise this problem.

I will prepare a patch for mlx5.. where do we post linux-next fixes ?
since this issue doesn't exist in net-next tree.. or should i just wait
for rc1 ?

Thanks,
Saeed.

\
 
 \ /
  Last update: 2020-04-03 01:52    [W:0.080 / U:6.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site