[[net-next] lo uses DEPRECATED zero tx_queue_len - convert driver to use IFF_NO_QUEUE instead

[[net-next] lo uses DEPRECATED zero tx_queue_len - convert driver to use IFF_NO_QUEUE instead

[Geert Uytterhoeven]

I don't know if this was reported before (I'm not subscribed to netdev), but
Google couldn't find it:

lo uses DEPRECATED zero tx_queue_len - convert driver to use
IFF_NO_QUEUE instead

Presumably introduced by
commit 906470c19da771e638e7c8e16e16c31995b139cc
Author: Phil Sutter <phil@nwl.cc>
Date:   Tue Aug 18 10:30:48 2015 +0200

    net: warn if drivers set tx_queue_len = 0

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [[net-next] lo uses DEPRECATED zero tx_queue_len - convert driver to use IFF_NO_QUEUE instead

[Phil Sutter]

On Tue, Aug 25, 2015 at 01:16:41PM +0200, Geert Uytterhoeven wrote:
> I don't know if this was reported before (I'm not subscribed to netdev), but
> Google couldn't find it:
> 
> lo uses DEPRECATED zero tx_queue_len - convert driver to use
> IFF_NO_QUEUE instead

This is fixed by commit e65db2b ("net: loopback: convert to using
IFF_NO_QUEUE"), part of a bigger series converting drivers (see here:
http://lists.openwall.net/netdev/2015/08/18/52).

Cheers, Phil

Re: [[net-next] lo uses DEPRECATED zero tx_queue_len - convert driver to use IFF_NO_QUEUE instead

[Geert Uytterhoeven]

Hi Phil,

On Wed, Aug 26, 2015 at 11:34 AM, Phil Sutter <phil@nwl.cc> wrote:
> On Tue, Aug 25, 2015 at 01:16:41PM +0200, Geert Uytterhoeven wrote:
>> I don't know if this was reported before (I'm not subscribed to netdev), but
>> Google couldn't find it:
>>
>> lo uses DEPRECATED zero tx_queue_len - convert driver to use
>> IFF_NO_QUEUE instead
>
> This is fixed by commit e65db2b ("net: loopback: convert to using
> IFF_NO_QUEUE"), part of a bigger series converting drivers (see here:
> http://lists.openwall.net/netdev/2015/08/18/52).

Strange, that commit is included in my tree, which is based on
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/
and includes net-next?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [[net-next] lo uses DEPRECATED zero tx_queue_len - convert driver to use IFF_NO_QUEUE instead

[Phil Sutter]

Hi Geert,

On Wed, Aug 26, 2015 at 12:16:47PM +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 26, 2015 at 11:34 AM, Phil Sutter <phil@nwl.cc> wrote:
> > On Tue, Aug 25, 2015 at 01:16:41PM +0200, Geert Uytterhoeven wrote:
> >> I don't know if this was reported before (I'm not subscribed to netdev), but
> >> Google couldn't find it:
> >>
> >> lo uses DEPRECATED zero tx_queue_len - convert driver to use
> >> IFF_NO_QUEUE instead
> >
> > This is fixed by commit e65db2b ("net: loopback: convert to using
> > IFF_NO_QUEUE"), part of a bigger series converting drivers (see here:
> > http://lists.openwall.net/netdev/2015/08/18/52).
> 
> Strange, that commit is included in my tree, which is based on
> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/
> and includes net-next?

I'm sorry, the above statement was too quickly put. Florian Westphal
confirmed the problem you are seeing privately, and I can follow from
looking at the code. Obviously I failed to notice that by using
alloc_netdev instead of alloc_etherdev, there is a way for drivers to
circumvent ether_setup completely which leaves tx_queue_len
uninitialized (i.e., 0) and therefore triggers the warning.

I'm yet unsure how to properly fix this issue, but moving the check to a
more appropriate place is certainly advisable.

Thanks for pointing this out,

Phil