netdev - Re: [PATCH] geneve: restore vlan bits in xmit path

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: <CALnjE+oUjh_55sFYAXTADfGyLZ2uBE5+7qiFRJtbgrHnoHza8Q@mail.gmail.com>
Date:	Thu, 17 Sep 2015 15:02:13 -0700
From:	Pravin Shelar <pshelar@...ira.com>
To:	"John W. Linville" <linville@...driver.com>
Cc:	Jesse Gross <jesse@...ira.com>, netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH] geneve: restore vlan bits in xmit path

On Thu, Sep 17, 2015 at 1:15 PM, John W. Linville
<linville@...driver.com> wrote:
> On Thu, Sep 17, 2015 at 12:48:56PM -0700, Jesse Gross wrote:
>> On Thu, Sep 17, 2015 at 12:25 PM, John W. Linville
>> <linville@...driver.com> wrote:
>> > On Thu, Sep 17, 2015 at 11:45:58AM -0700, Pravin Shelar wrote:
>> >> On Thu, Sep 17, 2015 at 10:18 AM, John W. Linville
>> >> <linville@...driver.com> wrote:
>> >> > These seem to have been accidentally dropped in commit 371bd1061d29
>> >> > ("geneve: Consolidate Geneve functionality in single module.").
>> >> >
>> >> Geneve should not export vxlan feature. So that it never sees vxlan
>> >> tagged packets. Can you turn off the vlan feature?
>> >
>> > I'm not sure I understand...?  This is vlan, not vxlan.
>>
>> I think he just mean vlan. If you remove the line where
>> dev->vlan_features are set then the core stack will handle this and we
>> don't need to do anything special here.
>
> Is that preferrable to this patch?  Tunneling vlan-tagged frames
> seems weird, but I would hate to disallow it if some crazy person
> wanted to do that...
>

To support vlan-offload in geneve we end up doing same as networking
stack does in case of software fallback for vlan-offload. So by not
setting the feature, we can avoid the duplicate code in geneve module.

> I guess the other way would slightly improve performance, and this
> could be added back later.  What about the VLAN-related bits in
> dev->features and ->hw_features?  Should they go as well?
>
No need to set vlan feature in any of device features.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html