netdev - Re: Problem with queuing vlan tagged packets after migration from 3.16.0 to 4.9.0

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

Date:   Thu, 17 Jan 2019 22:32:46 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Cong Wang <xiyou.wangcong@...il.com>,
        Bartek Kois <bartek.kois@...il.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Problem with queuing vlan tagged packets after migration from 3.16.0 to 4.9.0

Jamal Hadi Salim <jhs@...atatu.com> writes:

> On 2019-01-05 12:03 a.m., Cong Wang wrote:
>> (Cc'ing Jamal)
>>
>> On Fri, Jan 4, 2019 at 10:11 AM Bartek Kois <bartek.kois@...il.com> wrote:
>>>
>>> Basically my current scenario looks like this:
>>> - router with eth0 as WAN and eth1 as LAN with 10-20 vlans,
>>> - around 1000-2000 ip addresses in differnets subnets behind router (on
>>> the LAN side),
>>> - QoS made with tc + ifb (for upload queuing) + hasing filters (for
>>> performance reasons)
>>>
>>> Moving this to two queuing trees (one on vlan and one on ifbx) per each
>>> vlan makes this really hard to configure, but not impossible as long as
>>> I can redirect single VLAN to ifb (don`t know if that is possible).
>>> Anton suggested to use iptables+ipset but I don`t think that would be a
>>> good idea to do that in scenario with so many queues.
>>
>> Yeah, understood.
>>
>
> Classifying vlans via u32 has been broken for some time (4 years or
> more?). Some change made on general vlan handling (I think patch was
> from Jiri). So someone like Bartek would be in for a suprise
> if hasnt upgraded since.

Definitely more than 4. I was trying to sort pieces of this out maybe 6
years ago.  For a while vlan tags on software devices worked one way and
vlan tags on actual hardware work the way vlan tags work for everything
now.

Since every option involved breaking something we standardized on the
way hardware accelleration handled vlan tags.  Which caused some hiccups
on pure software devices.  That ``fix'' may have gone in after 3.16 and
be why Bartek is seeing issues.  Especially if his router had a very
lame ethernet device that did not support any hardware accelleration.

> vlan info is part of the skb metadata now and not visible
> in the packet data. To extract it youd have to use the inlines
> in include/linux/if_vlan.h(skb_vlan_tag_get() and friends)

Yes, and like you suggest down thread that will now require
a magic directive to read.  The upside is if you don't care about
the vlan tag your offsets are likely to be more constant now.

Eric