linux-toradex.git/net/sched/sch_api.c, branch v4.9.119

net_sched: avoid matching qdisc with zero handle

2017-11-18T10:22:23+00:00

[ Upstream commit 50317fce2cc70a2bbbc4b42c31bbad510382a53c ]

Davide found the following script triggers a NULL pointer
dereference:

ip l a name eth0 type dummy
tc q a dev eth0 parent :1 handle 1: htb

This is because for a freshly created netdevice noop_qdisc
is attached and when passing 'parent :1', kernel actually
tries to match the major handle which is 0 and noop_qdisc
has handle 0 so is matched by mistake. Commit 69012ae425d7
tries to fix a similar bug but still misses this case.

Handle 0 is not a valid one, should be just skipped. In
fact, kernel uses it as TC_H_UNSPEC.

Fixes: 69012ae425d7 ("net: sched: fix handling of singleton qdiscs with qdisc_hash")
Fixes: 59cc1f61f09c ("net: sched:convert qdisc linked list to hashtable")
Reported-by: Davide Caratti 
Cc: Jiri Kosina 
Cc: Eric Dumazet 
Cc: Jamal Hadi Salim 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net_sched: remove warning from qdisc_hash_add

2017-08-30T08:21:39+00:00

[ Upstream commit c90e95147c27b1780e76c6e8fea1b5c78d7d387f ]

It was added in commit e57a784d8cae ("pkt_sched: set root qdisc
before change() in attach_default_qdiscs()") to hide duplicates
from "tc qdisc show" for incative deivices.

After 59cc1f61f ("net: sched: convert qdisc linked list to hashtable")
it triggered when classful qdisc is added to inactive device because
default qdiscs are added before switching root qdisc.

Anyway after commit ea3274695353 ("net: sched: avoid duplicates in
qdisc dump") duplicates are filtered right in dumper.

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: sched: Fix one possible panic when no destroy callback

2017-07-21T05:42:17+00:00

commit c1a4872ebfb83b1af7144f7b29ac8c4b344a12a8 upstream.

When qdisc fail to init, qdisc_create would invoke the destroy callback
to cleanup. But there is no check if the callback exists really. So it
would cause the panic if there is no real destroy callback like the qdisc
codel, fq, and so on.

Take codel as an example following:
When a malicious user constructs one invalid netlink msg, it would cause
codel_init->codel_change->nla_parse_nested failed.
Then kernel would invoke the destroy callback directly but qdisc codel
doesn't define one. It causes one panic as a result.

Now add one the check for destroy to avoid the possible panic.

Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
Signed-off-by: Gao Feng 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net_sched: fix error recovery at qdisc creation

2017-07-21T05:42:17+00:00

commit 87b60cfacf9f17cf71933c6e33b66e68160af71d upstream.

Dmitry reported uses after free in qdisc code [1]

The problem here is that ops->init() can return an error.

qdisc_create_dflt() then call ops->destroy(),
while qdisc_create() does _not_ call it.

Four qdisc chose to call their own ops->destroy(), assuming their caller
would not.

This patch makes sure qdisc_create() calls ops->destroy()
and fixes the four qdisc to avoid double free.

[1]
BUG: KASAN: use-after-free in mq_destroy+0x242/0x290 net/sched/sch_mq.c:33 at addr ffff8801d415d440
Read of size 8 by task syz-executor2/5030
CPU: 0 PID: 5030 Comm: syz-executor2 Not tainted 4.3.5-smp-DEV #119
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
 0000000000000046 ffff8801b435b870 ffffffff81bbbed4 ffff8801db000400
 ffff8801d415d440 ffff8801d415dc40 ffff8801c4988510 ffff8801b435b898
 ffffffff816682b1 ffff8801b435b928 ffff8801d415d440 ffff8801c49880c0
Call Trace:
 [] __dump_stack lib/dump_stack.c:15 [inline]
 [] dump_stack+0x6c/0x98 lib/dump_stack.c:51
 [] kasan_object_err+0x21/0x70 mm/kasan/report.c:158
 [] print_address_description mm/kasan/report.c:196 [inline]
 [] kasan_report_error+0x1b4/0x4b0 mm/kasan/report.c:285
 [] kasan_report mm/kasan/report.c:305 [inline]
 [] __asan_report_load8_noabort+0x43/0x50 mm/kasan/report.c:326
 [] mq_destroy+0x242/0x290 net/sched/sch_mq.c:33
 [] qdisc_destroy+0x12d/0x290 net/sched/sch_generic.c:953
 [] qdisc_create_dflt+0xf0/0x120 net/sched/sch_generic.c:848
 [] attach_default_qdiscs net/sched/sch_generic.c:1029 [inline]
 [] dev_activate+0x6ad/0x880 net/sched/sch_generic.c:1064
 [] __dev_open+0x221/0x320 net/core/dev.c:1403
 [] __dev_change_flags+0x15e/0x3e0 net/core/dev.c:6858
 [] dev_change_flags+0x8e/0x140 net/core/dev.c:6926
 [] dev_ifsioc+0x446/0x890 net/core/dev_ioctl.c:260
 [] dev_ioctl+0x1ba/0xb80 net/core/dev_ioctl.c:546
 [] sock_do_ioctl+0x99/0xb0 net/socket.c:879
 [] sock_ioctl+0x2a0/0x390 net/socket.c:958
 [] vfs_ioctl fs/ioctl.c:44 [inline]
 [] do_vfs_ioctl+0x8a8/0xe50 fs/ioctl.c:611
 [] SYSC_ioctl fs/ioctl.c:626 [inline]
 [] SyS_ioctl+0x94/0xc0 fs/ioctl.c:617
 [] entry_SYSCALL_64_fastpath+0x12/0x17

Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net sched: stylistic cleanups

2016-09-20T02:04:14+00:00

Signed-off-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller

net: sched: avoid duplicates in qdisc dump

2016-08-19T04:19:08+00:00

tc_dump_qdisc() performs dumping of the per-device qdiscs in two phases;
first, the "standard" dev->qdisc is being dumped. Second, if there is/are
ingress queue(s), they are being dumped as well.

After conversion of netdevice's qdisc linked-list into hashtable, these
two sets are not in two disjunctive sets/lists any more, but are both
"reachable" directly from netdevice's hashtable. As a consequence, the
"full-depth" dump of the ingress qdiscs results in immediately hitting the
netdevice hashtable again, and duplicating the dump that has already been
performed for dev->qdisc.
What in fact needs to be dumped in case of ingress queue is "just" the
top-level ingress qdisc, as everything else has been dumped already.

Fix this by extending tc_dump_qdisc_root() in a way that it can be instructed
whether it should (while performing the "full" per-netdev qdisc dump) perform
the whole recursion, or just dump "additional" top-level (ingress) qdiscs
without performing any kind of recursion.

This fixes duplicate dumps such as

	qdisc mq 0: root
	qdisc pfifo_fast 0: parent :4 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
	qdisc pfifo_fast 0: parent :3 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
	qdisc pfifo_fast 0: parent :2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
	qdisc pfifo_fast 0: parent :1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
	qdisc clsact ffff: parent ffff:fff1
	qdisc pfifo_fast 0: parent :4 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
	qdisc pfifo_fast 0: parent :3 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
	qdisc pfifo_fast 0: parent :2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
	qdisc pfifo_fast 0: parent :1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Fixes: 59cc1f61f ("net: sched: convert qdisc linked list to hashtable")
Reported-by: Daniel Borkmann 
Tested-by: Daniel Borkmann 
Signed-off-by: Jiri Kosina 
Signed-off-by: David S. Miller

net: sched: fix handling of singleton qdiscs with qdisc_hash

2016-08-19T04:19:08+00:00

qdisc_match_from_root() is now iterating over per-netdevice qdisc
hashtable instead of going through a linked-list of qdiscs (independently
on the actual underlying netdev), which was the case before the switch to
hashtable for qdiscs.

For singleton qdiscs, there is no underlying netdev associated though, and
therefore dumping a singleton qdisc will panic, as qdisc_dev(root) will
always be NULL.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000410
 IP: [] qdisc_match_from_root+0x2c/0x70
 PGD 1aceba067 PUD 1aceb7067 PMD 0
 Oops: 0000 [#1] PREEMPT SMP
[ ... ]
 task: ffff8801ec996e00 task.stack: ffff8801ec934000
 RIP: 0010:[]  [] qdisc_match_from_root+0x2c/0x70
 RSP: 0018:ffff8801ec937ab0  EFLAGS: 00010203
 RAX: 0000000000000408 RBX: ffff88025e612000 RCX: ffffffffffffffd8
 RDX: 0000000000000000 RSI: 00000000ffff0000 RDI: ffffffff81cf8100
 RBP: ffff8801ec937ab0 R08: 000000000001c160 R09: ffff8802668032c0
 R10: ffffffff81cf8100 R11: 0000000000000030 R12: 00000000ffff0000
 R13: ffff88025e612000 R14: ffffffff81cf3140 R15: 0000000000000000
 FS:  00007f24b9af6740(0000) GS:ffff88026f280000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000410 CR3: 00000001aceec000 CR4: 00000000001406e0
 Stack:
  ffff8801ec937ad0 ffffffff81681210 ffff88025dd51a00 00000000fffffff1
  ffff8801ec937b88 ffffffff81681e4e ffffffff81c42bc0 ffff880262431500
  ffffffff81cf3140 ffff88025dd51a10 ffff88025dd51a24 00000000ec937b38
 Call Trace:
  [] qdisc_lookup+0x40/0x50
  [] tc_modify_qdisc+0x21e/0x550
  [] rtnetlink_rcv_msg+0x95/0x220
  [] ? __kmalloc_track_caller+0x172/0x230
  [] ? rtnl_newlink+0x870/0x870
  [] netlink_rcv_skb+0xa7/0xc0
  [] rtnetlink_rcv+0x28/0x30
  [] netlink_unicast+0x15b/0x210
  [] netlink_sendmsg+0x319/0x390
  [] sock_sendmsg+0x38/0x50
  [] ___sys_sendmsg+0x256/0x260
  [] ? __pagevec_lru_add_fn+0x135/0x280
  [] ? pagevec_lru_move_fn+0xd0/0xf0
  [] ? trace_event_raw_event_mm_lru_insertion+0x180/0x180
  [] ? __lru_cache_add+0x75/0xb0
  [] ? _raw_spin_unlock+0x16/0x40
  [] ? handle_mm_fault+0x39f/0x1160
  [] __sys_sendmsg+0x45/0x80
  [] SyS_sendmsg+0x12/0x20
  [] do_syscall_64+0x57/0xb0

Fix this by special-casing singleton qdiscs (those that don't have
underlying netdevice) and introduce immediate handling of those rather
than trying to go over an underlying netdevice. We're in the same
situation in tc_dump_qdisc_root() and tc_dump_tclass_root().

Ultimately, this will have to be slightly reworked so that we are actually
able to show singleton qdiscs (noop) in the dump properly; but we're not
currently doing that anyway, so no regression there, and better do this in
a gradual manner.

Fixes: 59cc1f61f ("net: sched: convert qdisc linked list to hashtable")
Reported-by: Daniel Borkmann 
Tested-by: Daniel Borkmann 
Reported-by: David Ahern 
Tested-by: David Ahern 
Signed-off-by: Jiri Kosina 
Signed-off-by: David S. Miller

net: sched: convert qdisc linked list to hashtable

2016-08-11T00:19:02+00:00

Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linked list by qdisc_match_from_root() is rather
expensive.

The ultimate goal is to get rid of hidden qdiscs completely, which will
bring much more determinism in user experience.

Reviewed-by: Cong Wang 
Signed-off-by: Jiri Kosina 
Signed-off-by: David S. Miller

sched: remove NET_XMIT_POLICED

2016-06-13T02:02:11+00:00

sch_atm returns this when TC_ACT_SHOT classification occurs.

But all other schedulers that use tc_classify
(htb, hfsc, drr, fq_codel ...) return NET_XMIT_SUCCESS | __BYPASS
in this case so just do that in atm.

BATMAN uses it as an intermediate return value to signal
forwarding vs. buffering, but it did not return POLICED to
callers outside of BATMAN.

Reviewed-by: Sven Eckelmann 
Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller

net_sched: remove generic throttled management

2016-06-11T06:58:21+00:00

__QDISC_STATE_THROTTLED bit manipulation is rather expensive
for HTB and few others.

I already removed it for sch_fq in commit f2600cf02b5b
("net: sched: avoid costly atomic operation in fq_dequeue()")
and so far nobody complained.

When one ore more packets are stuck in one or more throttled
HTB class, a htb dequeue() performs two atomic operations
to clear/set __QDISC_STATE_THROTTLED bit, while root qdisc
lock is held.

Removing this pair of atomic operations bring me a 8 % performance
increase on 200 TCP_RR tests, in presence of throttled classes.

This patch has no side effect, since nothing actually uses
disc_is_throttled() anymore.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller