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]

Message-ID: <20150813204037.3c4e68a4@redhat.com>
Date:	Thu, 13 Aug 2015 20:40:37 +0200
From:	Jesper Dangaard Brouer <brouer@...hat.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
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, brouer@...hat.com
Subject: Re: [PATCH 0/2] net: introduce IFF_NO_QUEUE as successor of zero
 tx_queue_len

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

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer
--
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