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

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:   Thu, 2 Apr 2020 23:52:24 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "sfr@...b.auug.org.au" <sfr@...b.auug.org.au>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        "linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "nico@...xnic.net" <nico@...xnic.net>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        Leon Romanovsky <leonro@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: linux-next: Tree for Mar 31 (mlx5)

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@...nel.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@...xnic.net>
    Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
    Acked-by: Nicolas Pitre <nico@...xnic.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.