Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp11136402ybi; Thu, 25 Jul 2019 10:35:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqxSt8LMRZD666D4CQBRT+3r+In8tYvXLGB0hK0o8sG6Uk8St8/lY8oQ+/zhH+C0MXlailQk X-Received: by 2002:a17:90a:26a1:: with SMTP id m30mr95803553pje.59.1564076155228; Thu, 25 Jul 2019 10:35:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564076155; cv=none; d=google.com; s=arc-20160816; b=PWFRBTPfy2vwmslgChNJ0mKQwj/jzJg/qVHHfbHbZ2eyPqii7Gx2TodEC+VWhOtKQE +KOoNjY53azdHHsxMlWgsEXxWN90tYgZFxNS+gyze8ZSuUfiNR8SRLdVeMsj7S/fimDF 6Uy/115tesAF27KX64JhTUTby0m6zuEP6BaQnY27KrVg0DoMyG8xhOrdvFiq2IbronoG /qsx2iqX6psUnGT8x/b0g0mePiHNDFSbofTzlteFPcn2JEZyM4MSpM1JTBmhen0Jccut KrrUEc4LjffEfuEgwNRVzk5/j9p6Nhpre6YsoyLQvKbziCDrirY/pzyJjyu+ilH/3wJl SK1Q== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:to:from:subject:dkim-signature; bh=sHoRY+mXic7NkNfPFucr+22Si1CXT/E0fQIjB3vP5E4=; b=SeBTpU3utrpd0N7Go2oqGY/Vq5JUCEG3xHZjIjGpEbH5VIR6Oo+BRTLFm9eg/7YENa dKxkUJDzVfdQK18fA5BkxT4+ZrBq3j00/ldHbFPD1FylPGvMlGxZ8+iOCANfzRDUUAXl 30vLeh6sRVCmDErnyFHqdna/XWTyECR02o6xZfTf5Kvlj25k/3g0Xl2LwKKymkHdJ8iR Ogqh504PX1CPxVVKRh/IG8+wPk62oiQagmEu4yiyTquE6MxfCSQgk+h1ce66p5HGJP1S lEjjO/g0RDwHwArNtGmi7ZNoY3UARikE34AbPGFqB/eUkioIMRN4QOdqxjoSC6ffV7Mf kkzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cumulusnetworks.com header.s=google header.b=Po0NeTTx; 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=cumulusnetworks.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k32si16423621pjb.11.2019.07.25.10.35.40; Thu, 25 Jul 2019 10:35:55 -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=@cumulusnetworks.com header.s=google header.b=Po0NeTTx; 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=cumulusnetworks.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729987AbfGYNVZ (ORCPT + 99 others); Thu, 25 Jul 2019 09:21:25 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:38527 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727466AbfGYNVY (ORCPT ); Thu, 25 Jul 2019 09:21:24 -0400 Received: by mail-wr1-f66.google.com with SMTP id g17so50788329wrr.5 for ; Thu, 25 Jul 2019 06:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=sHoRY+mXic7NkNfPFucr+22Si1CXT/E0fQIjB3vP5E4=; b=Po0NeTTxb+nvdjvmvbUp8u6K6W2wJNfYZoiEEQgVBKy52QdPpqSOmtHg/zMCOS9AS5 xMbWSEyGg0+PXLtHosfvgCZq7V8YPbCVpoMQBn31WOosHTMSX5vlX2/GWwAt67ta0I6Y M0cyXxQMy7L4t7HVFJHileEePEdJtygUT3IGM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sHoRY+mXic7NkNfPFucr+22Si1CXT/E0fQIjB3vP5E4=; b=cxs5XsXBxEZNxTBHl9mTEPi++LHoYtSNQxDgoPvzS7qUElomGWcKYo6GtiK7xQr1x1 ySN9mD1ivu08Pby0Fep0m8rd2fzPN2taRL1DeoNYypjg3HV3cAVSXgJptqfs4pbDTPiV /vND/fELYyCkuMAD3VsZpz5r07w464dYz6J+fTmzQdvPZDur2sRUSoQG7Flo+olnZdCG KOWkr5I3IqlHacNYjI/fB0rv6oRsyvhnvHLYNsgLt6KCEbJb09ZgCwB32vpR4X1tIpo9 0UUkNysyd6uY/UGxjDewbaapuDi86MQAw7Jfb3iMckHHu2qdduRBwRGdHiaHZUQg1ei9 lC7Q== X-Gm-Message-State: APjAAAVhICJXSv+mIDcnASA4asNBGowIHL14zdR28GeWMvo9TG/2djxG eGzwTsIZuDtBgOTBGG4fHyl0PQ== X-Received: by 2002:adf:ce88:: with SMTP id r8mr21287004wrn.42.1564060881337; Thu, 25 Jul 2019 06:21:21 -0700 (PDT) Received: from [192.168.0.107] (84-238-136-197.ip.btc-net.bg. [84.238.136.197]) by smtp.gmail.com with ESMTPSA id y6sm61292070wmd.16.2019.07.25.06.21.20 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 06:21:20 -0700 (PDT) Subject: Re: [PATCH] net: bridge: Allow bridge to joing multicast groups From: Nikolay Aleksandrov To: Horatiu Vultur , roopa@cumulusnetworks.com, davem@davemloft.net, bridge@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, allan.nielsen@microchip.com References: <1564055044-27593-1-git-send-email-horatiu.vultur@microchip.com> <7e7a7015-6072-d884-b2ba-0a51177245ab@cumulusnetworks.com> Message-ID: Date: Thu, 25 Jul 2019 16:21:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <7e7a7015-6072-d884-b2ba-0a51177245ab@cumulusnetworks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/07/2019 16:06, Nikolay Aleksandrov wrote: > On 25/07/2019 14:44, Horatiu Vultur wrote: >> There is no way to configure the bridge, to receive only specific link >> layer multicast addresses. From the description of the command 'bridge >> fdb append' is supposed to do that, but there was no way to notify the >> network driver that the bridge joined a group, because LLADDR was added >> to the unicast netdev_hw_addr_list. >> >> Therefore update fdb_add_entry to check if the NLM_F_APPEND flag is set >> and if the source is NULL, which represent the bridge itself. Then add >> address to multicast netdev_hw_addr_list for each bridge interfaces. >> And then the .ndo_set_rx_mode function on the driver is called. To notify >> the driver that the list of multicast mac addresses changed. >> >> Signed-off-by: Horatiu Vultur >> --- >> net/bridge/br_fdb.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++--- >> 1 file changed, 46 insertions(+), 3 deletions(-) >> > > Hi, > I'm sorry but this patch is wrong on many levels, some notes below. In general > NLM_F_APPEND is only used in vxlan, the bridge does not handle that flag at all. > FDB is only for *unicast*, nothing is joined and no multicast should be used with fdbs. > MDB is used for multicast handling, but both of these are used for forwarding. > The reason the static fdbs are added to the filter is for non-promisc ports, so they can > receive traffic destined for these FDBs for forwarding. > If you'd like to join any multicast group please use the standard way, if you'd like to join > it only on a specific port - join it only on that port (or ports) and the bridge and you'll And obviously this is for the case where you're not enabling port promisc mode (non-default). In general you'll only need to join the group on the bridge to receive traffic for it or add it as an mdb entry to forward it. > have the effect that you're describing. What do you mean there's no way ? > > In addition you're allowing a mix of mcast functions to be called with unicast addresses > and vice versa, it is not that big of a deal because the kernel will simply return an error > but still makes no sense. > > Nacked-by: Nikolay Aleksandrov > >> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c >> index b1d3248..d93746d 100644 >> --- a/net/bridge/br_fdb.c >> +++ b/net/bridge/br_fdb.c >> @@ -175,6 +175,29 @@ static void fdb_add_hw_addr(struct net_bridge *br, const unsigned char *addr) >> } >> } >> >> +static void fdb_add_hw_maddr(struct net_bridge *br, const unsigned char *addr) >> +{ >> + int err; >> + struct net_bridge_port *p; >> + >> + ASSERT_RTNL(); >> + >> + list_for_each_entry(p, &br->port_list, list) { >> + if (!br_promisc_port(p)) { >> + err = dev_mc_add(p->dev, addr); >> + if (err) >> + goto undo; >> + } >> + } >> + >> + return; >> +undo: >> + list_for_each_entry_continue_reverse(p, &br->port_list, list) { >> + if (!br_promisc_port(p)) >> + dev_mc_del(p->dev, addr); >> + } >> +} >> + >> /* When a static FDB entry is deleted, the HW address from that entry is >> * also removed from the bridge private HW address list and updates all >> * the ports with needed information. >> @@ -192,13 +215,27 @@ static void fdb_del_hw_addr(struct net_bridge *br, const unsigned char *addr) >> } >> } >> >> +static void fdb_del_hw_maddr(struct net_bridge *br, const unsigned char *addr) >> +{ >> + struct net_bridge_port *p; >> + >> + ASSERT_RTNL(); >> + >> + list_for_each_entry(p, &br->port_list, list) { >> + if (!br_promisc_port(p)) >> + dev_mc_del(p->dev, addr); >> + } >> +} >> + >> static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f, >> bool swdev_notify) >> { >> trace_fdb_delete(br, f); >> >> - if (f->is_static) >> + if (f->is_static) { >> fdb_del_hw_addr(br, f->key.addr.addr); >> + fdb_del_hw_maddr(br, f->key.addr.addr); > > Walking over all ports again for each static delete is a no-go. > >> + } >> >> hlist_del_init_rcu(&f->fdb_node); >> rhashtable_remove_fast(&br->fdb_hash_tbl, &f->rhnode, >> @@ -843,13 +880,19 @@ static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source, >> fdb->is_local = 1; >> if (!fdb->is_static) { >> fdb->is_static = 1; >> - fdb_add_hw_addr(br, addr); >> + if (flags & NLM_F_APPEND && !source) >> + fdb_add_hw_maddr(br, addr); >> + else >> + fdb_add_hw_addr(br, addr); >> } >> } else if (state & NUD_NOARP) { >> fdb->is_local = 0; >> if (!fdb->is_static) { >> fdb->is_static = 1; >> - fdb_add_hw_addr(br, addr); >> + if (flags & NLM_F_APPEND && !source) >> + fdb_add_hw_maddr(br, addr); >> + else >> + fdb_add_hw_addr(br, addr); >> } >> } else { >> fdb->is_local = 0; >> >