netdev - Re: [PATCH 0/2] net: introduce IFF_NO_QUEUE as successor of zero 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]

Date:	Thu, 13 Aug 2015 12:11:57 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	Jesper Dangaard Brouer <brouer@...hat.com>
Cc:	Phil Sutter <phil@....cc>, netdev@...r.kernel.org,
	alexei.starovoitov@...il.com, davem@...emloft.net, fw@...len.de,
	cwang@...pensource.com, eric.dumazet@...il.com
Subject: Re: [PATCH 0/2] net: introduce IFF_NO_QUEUE as successor of zero
 tx_queue_len

On Thu, 13 Aug 2015 20:40:37 +0200
Jesper Dangaard Brouer <brouer@...hat.com> wrote:

> On Thu, 13 Aug 2015 10:49:50 -0700
> Stephen Hemminger <stephen@...workplumber.org> wrote:
> 
> > On Thu, 13 Aug 2015 19:01:05 +0200
> > Phil Sutter <phil@....cc> wrote:
> > 
> > > Up to now, drivers being aware of the above applying to them set
> > > dev->tx_queue_len to zero to indicate no qdisc should be attached to the
> > > interface they drive and the kernel reacts upon this by assigning the noop
> > > qdisc instead of the default pfifo_fast. This implicit agreement though leads
> > > to an inconvenient situation once a user tries to attach a real qdisc to these
> > > devices, as the formerly special tx_queue_len value becomes a regular one,
> > 
> > So this is a workaround for user ignorance by introducing kernel API complexity.
> > Before user sets qdisc, why don't they set tx queue length?
> 
> Please don't insist on keeping this broke interface... how should users
> know that BEFORE adding a qdisc they MUST change the _device_ tx queue
> length (not zero).

Before setting any qdisc, they should set queue length anyway.

>  Getting "back" to the original state, they MUST
> change the device tx queue len back to zero BEFORE deleting the qdisc,
> such that when assigning the default queue qdisc the system detects
> this device can work without a qdisc.  Changing the tx queue len to
> zero after the qdisc is deleted will have not effect. 
> 
> Listen to the description, that interface is broken. The kernel really
> needs to hide these details from userspace.
> 
> It even allows you to misconfigure the kernel, by tricking the kernel
> into assigning noqueue to physical devices that really need it.

But adding a flag risks breaking external scripts.


--
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