netdev - Re: [net-next PATCH 3/3] qdisc: catch misconfig of attaching qdisc to tx_queue

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: <CAHo-Oozk1AqqR4+9HxLYSGQOQ8Ohs0NaOx=ZV+94JCH-ftxtMw@mail.gmail.com>
Date:   Mon, 7 Nov 2016 22:14:37 -0800
From:   Maciej Żenczykowski <zenczykowski@...il.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Linux NetDev <netdev@...r.kernel.org>, Phil Sutter <phil@....cc>,
        Robert Olsson <robert@...julf.se>,
        Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [net-next PATCH 3/3] qdisc: catch misconfig of attaching qdisc to
 tx_queue_len zero device

Just FYI:

I'm tangentially aware of internal Google code that:
- expects a bonding device running HTB with non-zero txqueuelen
- wants to remove HTB and get a noqueue interface (the normal default
for bonding)

The code currently removes HTB, which gets us to mq, sets txqueuelen
to 0, adds a pfifo, removes the pfifo, which gets us to noqueue.

After this patch this would ?possibly? break (adding pfifo, would
change txqueuelen, so when we remove it we wouldn't end up with
noqueue).

>From what I fuzzily recall, HTB with txquelelen == 0 drops traffic
hard, while pfifo continues to function, hence the ordering...

Obviously our code can be fixed, but I'm worried there's a more
generic backwards compatibility problem here.

(note: this is mostly about 3.11 and 4.3 and might no longer be
relevant with 4.10... maybe the new kernel's default qdisc selection
logic doesn't depend on txqueuelen and checks the flag instead???)