netdev - Re: [PATCH net-next 2/4] net: bridge: rearrange flood vs unicast receive paths

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <FE62FD91-E4D1-44B6-A4D7-66E86C09A5FA@cumulusnetworks.com>
Date:	Fri, 15 Jul 2016 10:37:54 -0700
From:	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:	Cong Wang <xiyou.wangcong@...il.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	David Miller <davem@...emloft.net>,
	bridge@...ts.linux-foundation.org
Subject: Re: [PATCH net-next 2/4] net: bridge: rearrange flood vs unicast receive paths


> On Jul 15, 2016, at 10:35 AM, Cong Wang <xiyou.wangcong@...il.com> wrote:
> 
> On Wed, Jul 13, 2016 at 8:10 PM, Nikolay Aleksandrov
> <nikolay@...ulusnetworks.com> wrote:
>> This patch removes one conditional from the unicast path by using the fact
>> that skb is NULL only when the packet is multicast or is local.
>> 
>> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
>> ---
>> net/bridge/br_input.c | 29 ++++++++++++++---------------
>> 1 file changed, 14 insertions(+), 15 deletions(-)
>> 
>> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
>> index 0b6d32619468..c20c5be6fc22 100644
>> --- a/net/bridge/br_input.c
>> +++ b/net/bridge/br_input.c
>> @@ -134,10 +134,10 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
>>        struct net_bridge_port *p = br_port_get_rcu(skb->dev);
>>        const unsigned char *dest = eth_hdr(skb)->h_dest;
>>        struct net_bridge_fdb_entry *dst = NULL;
>> +       bool mcast_hit = false, unicast = true;
>>        struct net_bridge_mdb_entry *mdst;
>>        struct net_bridge *br;
>>        struct sk_buff *skb2;
>> -       bool unicast = true;
>>        u16 vid = 0;
>> 
>>        if (!p || p->state == BR_STATE_DISABLED)
>> @@ -177,30 +177,29 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
>>                if ((mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) &&
>>                    br_multicast_querier_exists(br, eth_hdr(skb))) {
>>                        if ((mdst && mdst->mglist) ||
>> -                           br_multicast_is_router(br))
>> +                           br_multicast_is_router(br)) {
>>                                skb2 = skb;
>> -                       br_multicast_forward(mdst, skb, skb2);
>> -                       skb = NULL;
>> -                       if (!skb2)
>> -                               goto out;
>> +                               br->dev->stats.multicast++;
>> +                       }
>> +                       mcast_hit = true;
>>                } else {
>>                        skb2 = skb;
>> +                       br->dev->stats.multicast++;
>>                }
>>                unicast = false;
>> -               br->dev->stats.multicast++;
> 
> 
> Looks like you change the unconditional increment of this counter,
> is this intended?

Oops +CC all, mixed the reply list.

Yes, this counter must increment only when the packet is going to be locally received as you can see before
there was an unconditional jump if the packet was not going to be locally received (if !skb2, goto).
This is exactly one of the confusing cases trying to avoid with these skb0/skb2 variables..

Cheers,
Nik