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.