From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 561CDC4332F for ; Thu, 8 Dec 2022 11:20:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229703AbiLHLUV (ORCPT ); Thu, 8 Dec 2022 06:20:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229878AbiLHLT6 (ORCPT ); Thu, 8 Dec 2022 06:19:58 -0500 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED2A360B74 for ; Thu, 8 Dec 2022 03:19:49 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id v8so1647952edi.3 for ; Thu, 08 Dec 2022 03:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=k0bU1R1P1t7TE4h8T9xV9N/WHr6QjC2yB8WU6NGRZ+0=; b=Le2zQaIxm0lShjTtiqVEcfKoqb0thgfhB6Okru++1BAAjwMQLwkd2PBE6hWCYHWfbw 1myLrH8IitIkgrKFamOCqJiBnvbfTjGEyB3PC/IWOqbvPGH/Xqsxkn/YAwSLc3cOwua7 b8ln5J3V0ytN3/tSFITkLyq9vlrRpQUN7hKxcjVpc9vkpwBKbTorYd8zYHRTUMiBT+4W TkKaAgdXOeqm4N2U1YJINPRZKoPFSOyiA8TAMOrIVPdTc0rgBTnTRLtQJm7XYM2Ptnai hQ5cPeKD8mDIlUdVXMruJR18jortOAYrXITyFS3vfn3HRl74Apm2B3pT87+vZ1xhweij LJJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=k0bU1R1P1t7TE4h8T9xV9N/WHr6QjC2yB8WU6NGRZ+0=; b=Ub8WpmrtzIBdJrBw/X3fyzxzGsA7ff0yNG3d5/jBRGsJFwdgnkVsV/KqHBCWDbrJBY t1CgVC2JLwOd95tIrXW5bypGpSGmDHl9DubgzgQXaZhqoMJ/atTPm6gKQTerNkRH84mN 8tR9lpPLbS5jvxi2ZDjD/n0aEdVVLbVlutFmUCLJg/y4ArlpnjnPLuxA9T+hj+8hqVpb SMepxRSiC+c50Cl20x8DRtsN8V+n6D6cbGWRlFsig9Ah80BVyT8kThUMyYyKx1t8bnVb P2uIUd74JpCAl2WSN12945UaWPJ/c85deHoJwzuD42bOxzxgEcNwOM54Turv+qhcOmfZ 6ULQ== X-Gm-Message-State: ANoB5plKsqoEAV07sLOOdww9HcNA/lM6wqWL7dBmpW7ZAB8vtgm0pxEg Z/ptdMr2DYpIKU+7BQQX5QZl0g== X-Google-Smtp-Source: AA0mqf608/Zb0Asi9NafFpxotWsZOPSAXfg1ZankHlH1z0z+Xql1fL/M6irBYU+U+aqnPpwmg1sm+Q== X-Received: by 2002:a05:6402:1947:b0:462:7b9a:686f with SMTP id f7-20020a056402194700b004627b9a686fmr1528337edz.4.1670498388542; Thu, 08 Dec 2022 03:19:48 -0800 (PST) Received: from localhost (host-213-179-129-39.customer.m-online.net. [213.179.129.39]) by smtp.gmail.com with ESMTPSA id bq4-20020a056402214400b00467481df198sm3255346edb.48.2022.12.08.03.19.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 03:19:47 -0800 (PST) Date: Thu, 8 Dec 2022 12:19:46 +0100 From: Jiri Pirko To: Xin Long Cc: Stephen Hemminger , network dev , davem@davemloft.net, kuba@kernel.org, Eric Dumazet , Paolo Abeni , LiLiang Subject: Re: [PATCH net] team: prevent ipv6 link local address on port devices Message-ID: References: <32ee765d2240163f1cbd5d99db6233f276857ccb.1670262365.git.lucien.xin@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Thu, Dec 08, 2022 at 12:35:48AM CET, lucien.xin@gmail.com wrote: >On Wed, Dec 7, 2022 at 8:31 AM Jiri Pirko wrote: >> >> Tue, Dec 06, 2022 at 10:52:33PM CET, lucien.xin@gmail.com wrote: >> >On Tue, Dec 6, 2022 at 8:32 AM Xin Long wrote: >> >> >> >> On Tue, Dec 6, 2022 at 3:05 AM Jiri Pirko wrote: >> >> > >> >> > Mon, Dec 05, 2022 at 06:46:05PM CET, lucien.xin@gmail.com wrote: >> >> > >The similar fix from commit c2edacf80e15 ("bonding / ipv6: no addrconf >> >> > >for slaves separately from master") is also needed in Team. Otherwise, >> >> > >DAD and RS packets to be sent from the slaves in turn can confuse the >> >> > >switches and cause them to incorrectly update their forwarding tables >> >> > >as Liang noticed in the test with activebackup mode. >> >> > > >> >> > >Note that the patch also sets IFF_MASTER flag for Team dev accordingly >> >> > >while IFF_SLAVE flag is set for port devs. Although IFF_MASTER flag is >> >> > >not really used in Team, it's good to show in 'ip link': >> >> > > >> >> > > eth1: >> >> > > team0: >> >> > > >> >> > >Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") >> >> > >Reported-by: LiLiang >> >> > >Signed-off-by: Xin Long >> >> > >> >> > Nack. Please don't do this. IFF_MASTER and IFF_SLAVE are historical >> >> > flags used by bonding and eql. Should not be used for other devices. >> >> I see. I was wondering why it was not used in Team at the beginning. :) >> >> >> >> > >> >> > addrconf_addr_gen() should not check IFF_SLAVE. It should use: >> >> > netif_is_lag_port() and netif_is_failover_slave() helpers. >> >Hi Jiri, >> > >> >Sorry, it seems not to work with this. >> > >> >As addrconf_addr_gen() is also called in NETDEV_UP event where >> >IFF_TEAM_PORT and IFF_BONDING haven't yet been set before >> >dev_open() when adding the port. >> > >> >If we move IFF_TEAM_PORT setting ahead of dev_open(), it will revert >> >the fix in: >> > >> >commit d7d3c05135f37d8fdf73f9966d27155cada36e56 >> >Author: Jiri Pirko >> >Date: Mon Aug 25 21:38:27 2014 +0200 >> > >> > team: set IFF_TEAM_PORT priv_flag after rx_handler is registered >> > >> >Can we keep IFF_SLAVE here only for no ipv6 addrconf? >> >> So, shouldn't it be rather a new flag specifically for this purpose? >Maybe IFF_NO_ADDRCONF in dev->priv_flags? Sounds fine to me. > >I will give it a try. > >Thanks.