netdev - Re: [RFC PATCH net-next 5/5] bridge: vlan lwt dst_metadata hooks in ingress and egress 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: <5884CF65.3030705@cumulusnetworks.com>
Date:   Sun, 22 Jan 2017 07:27:33 -0800
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
CC:     netdev@...r.kernel.org, davem@...emloft.net,
        stephen@...workplumber.org, tgraf@...g.ch,
        hannes@...essinduktion.org, jbenc@...hat.com, pshelar@....org,
        dsa@...ulusnetworks.com, hadi@...atatu.com
Subject: Re: [RFC PATCH net-next 5/5] bridge: vlan lwt dst_metadata hooks
 in ingress and egress paths

On 1/22/17, 4:15 AM, Nikolay Aleksandrov wrote:
> On 21/01/17 06:46, Roopa Prabhu wrote:
>> From: Roopa Prabhu <roopa@...ulusnetworks.com>
>>
>> - ingress hook:
>>     - if port is a lwt tunnel port, use tunnel info in
>>       attached dst_metadata to map it to a local vlan
>> - egress hook:
>>     - if port is a lwt tunnel port, use tunnel info attached to
>>       vlan to set dst_metadata on the skb
>>
>> CC: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
>> Signed-off-by: Roopa Prabhu <roopa@...ulusnetworks.com>
>> ---
>> CC'ing Nikolay for some more eyes as he has been trying to keep the
>> bridge driver fast path lite.
>>
>>  net/bridge/br_input.c   |    4 ++++
>>  net/bridge/br_private.h |    4 ++++
>>  net/bridge/br_vlan.c    |   55 +++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 63 insertions(+)
>>
>> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
>> index 83f356f..96602a1 100644
>> --- a/net/bridge/br_input.c
>> +++ b/net/bridge/br_input.c
>> @@ -262,6 +262,10 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>>  		return RX_HANDLER_CONSUMED;
>>  
>>  	p = br_port_get_rcu(skb->dev);
>> +	if (p->flags & BR_LWT_VLAN) {
>> +		if (br_handle_ingress_vlan_tunnel(skb, p, nbp_vlan_group_rcu(p)))
>> +			goto drop;
>> +	}
> Is there any reason to do this so early (perhaps netfilter?) ? If not, you can push it to the vlan __allowed_ingress
> (and rename that function to something else, it does a hundred additional things)
> and avoid this check for all packets if vlans are disabled, thus people using non-vlan filtering
> bridge won't have an additional test in their fast path
>
>
yes, forgot to mention it in the commit log. I had it close to __allowed_ingress in my first version...had to move it up here
because br_nf_pre_routing/br_nf_pre_routing_finish reset the dst...and hence already late..