Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2554120ybb; Mon, 30 Mar 2020 08:23:21 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtv7WIJ9ya87TxY2csoE30nYRkz84e97VzjCruKav6IB8bb2i0ZrsIZk0fkhgsqOoILHti6 X-Received: by 2002:a05:6830:1aca:: with SMTP id r10mr8496152otc.330.1585581801442; Mon, 30 Mar 2020 08:23:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585581801; cv=none; d=google.com; s=arc-20160816; b=qJtF3ea5iM3MTYBrEOJ/MGgO2JljAw5SZ2r4W6ffqvjMB4w0A4ydjG5fwouQgRxHhd EDCTYysgoQ1LOqv7Cpq8h4LfUmvg+ahNP6YbuVAUVp/uJ3qhVxMerEj7HMi0PChO25cb 7KCf4Kt8BX+VT4T69rgR0Ui5KNLzugSWt0f9k8qWHq8BV8uf7H3bed51ainU65+Naabm GB1AJ9h6u4WygrrAaV0znuFRVmg8C8TV+vOpkvIF7kyONCRAFCQ4BCl+kxLOSO7gnd4H 8FAzcYWYuHJ3HrdSjowOpP5OROaw/I1S50NkatGsDZapmDJQNxJd1p/5VVGq5Zq2Gdbk PH9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=lRom6IvNpMgMUyWIXFy7ykYjVqfYVBjHnLgbEROmr7Y=; b=sJWoDNx2bvBVNHMDtOj2cDbUjEkYAISrhUOYVW7ruBCVRKG7QPm1zG4Ngmv/27aL3C +2AlnJYC8jOAV9sZfPIDi3lPhWv3fUcB9yFYEd0ZSX37CN4Q/QZFdjF7JprHpsDHYN1/ udqUoGEj5Xv1FlPu/Ly6kxdffc9DhVkW5ldBWMU95w15021+B+9vyeFzOQ4vf45K+kPb UynIkbeZUUdPZMFNnTekwCbfoTy3QrWu68YLCVGKi1rXEMHyBDKZJbfx6bg1uNHOFV8Q ihSv9JfyKOuMZS2J0UmImejGAV/4WuJvjqB4NWQAuXQCFVWQgMTVaWcU3eo7Nzp6atGV pBmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JAynNsaB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g3si6442969oiy.151.2020.03.30.08.23.07; Mon, 30 Mar 2020 08:23:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JAynNsaB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728802AbgC3PWr (ORCPT + 99 others); Mon, 30 Mar 2020 11:22:47 -0400 Received: from us-smtp-delivery-74.mimecast.com ([63.128.21.74]:46024 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726497AbgC3PWr (ORCPT ); Mon, 30 Mar 2020 11:22:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585581765; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lRom6IvNpMgMUyWIXFy7ykYjVqfYVBjHnLgbEROmr7Y=; b=JAynNsaBQVqR0mhChg1qM+I8Aj03UmGub3j8vieApbOTgYUW6XLIRuNsGmNTf7w94XLy07 tF2kEnrXAaAKZ63/hvcs55ZrQDL86Te+osgMOUHRNd08+GJlih1zp1Iq9bt85oCz2ifJtw RG7vgWaqw8i3JYxPJaCdt1Iget2ACMA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-76-AL9jF58FPxaF4ryRWIYmBw-1; Mon, 30 Mar 2020 11:22:42 -0400 X-MC-Unique: AL9jF58FPxaF4ryRWIYmBw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 076B0800D5E; Mon, 30 Mar 2020 15:22:41 +0000 (UTC) Received: from hp-dl360pgen8-07.khw2.lab.eng.bos.redhat.com (hp-dl360pgen8-07.khw2.lab.eng.bos.redhat.com [10.16.210.135]) by smtp.corp.redhat.com (Postfix) with ESMTP id A953019925; Mon, 30 Mar 2020 15:22:37 +0000 (UTC) From: Jarod Wilson To: linux-kernel@vger.kernel.org Cc: Jarod Wilson , Moshe Levi , Stephen Hemminger , Marcelo Ricardo Leitner , netdev@vger.kernel.org Subject: [PATCH net v2] ipv6: don't auto-add link-local address to lag ports Date: Mon, 30 Mar 2020 11:22:19 -0400 Message-Id: <20200330152219.58296-1-jarod@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bonding slave and team port devices should not have link-local addresses automatically added to them, as it can interfere with openvswitch being able to properly add tc ingress. Basic reproducer, courtesy of Marcelo: $ ip link add name bond0 type bond $ ip link set dev ens2f0np0 master bond0 $ ip link set dev ens2f1np2 master bond0 $ ip link set dev bond0 up $ ip a s 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens2f0np0: mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff 5: ens2f1np2: mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff 11: bond0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::20f:53ff:fe2f:ea40/64 scope link valid_lft forever preferred_lft forever (above trimmed to relevant entries, obviously) $ sysctl net.ipv6.conf.ens2f0np0.addr_gen_mode=3D0 net.ipv6.conf.ens2f0np0.addr_gen_mode =3D 0 $ sysctl net.ipv6.conf.ens2f1np2.addr_gen_mode=3D0 net.ipv6.conf.ens2f1np2.addr_gen_mode =3D 0 $ ip a l ens2f0np0 2: ens2f0np0: mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative valid_lft forever preferred_lft forever $ ip a l ens2f1np2 5: ens2f1np2: mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative valid_lft forever preferred_lft forever Looks like addrconf_sysctl_addr_gen_mode() bypasses the original "is this a slave interface?" check added by commit c2edacf80e15, and results in an address getting added, while w/the proposed patch added, no address gets added. This simply adds the same gating check to another code path, and thus should prevent the same devices from erroneously obtaining an ipv6 link-local address. Fixes: d35a00b8e33d ("net/ipv6: allow sysctl to change link-local address= generation mode") Reported-by: Moshe Levi CC: Stephen Hemminger CC: Marcelo Ricardo Leitner CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson --- net/ipv6/addrconf.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 46d614b611db..2a8175de8578 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -3296,6 +3296,10 @@ static void addrconf_addr_gen(struct inet6_dev *id= ev, bool prefix_route) if (netif_is_l3_master(idev->dev)) return; =20 + /* no link local addresses on devices flagged as slaves */ + if (idev->dev->flags & IFF_SLAVE) + return; + ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0); =20 switch (idev->cnf.addr_gen_mode) { --=20 2.20.1