Re: linux-next: Tree for Mar 31 (mlx5)

[Saeed Mahameed]

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@xxxxxxxxxx>
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@xxxxxxxxxxx>
    Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>
    Acked-by: Nicolas Pitre <nico@xxxxxxxxxxx>

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.