Bug 60669

Summary: Kernel panic when using negative priority for HTB class
Product: Networking Reporter: _Vi (vi0oss)
Component: OtherAssignee: Stephen Hemminger (stephen)
Status: NEW ---    
Severity: normal CC: szg00000
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.11.0-rc2+ Subsystem:
Regression: No Bisected commit-id:
Attachments: Kernel panic output
Kernel panic output 2, now not using netconsole's interface for the test itself
HTB prio unsigned fix

Description _Vi 2013-07-31 19:18:49 UTC 
Created attachment 107064 [details]
Kernel panic output

I'm trying to use HTB qdisc. Using something like this commands:

tc qdisc add dev eth1 root handle 55: htb default 1
tc class add dev eth1 parent 55: classid 55:1 htb rate 50000000
tc class add dev eth1 parent 55: classid 55:2 htb rate 50000000 prio -1
tc class add dev eth1 parent 55: classid 55:3 htb rate 50000000
iptables -t mangle -A OUTPUT -p icmp -j CLASSIFY --set-class 55:2
iptables -t mangle -A OUTPUT -p tcp --dport 5555 -j CLASSIFY --set-class 55:3
ifconfig eth1 192.168.98.2 up
cat /dev/zero | nc 192.168.98.2 5555&
cat /dev/zero | nc 192.168.98.2 5556&

The network connection shall be be fully loaded (so classes compete with each other).

The "+" in kernel version is because of I am using a patch from bug 58691 (should be unrelated with iptables or traffic shaping).
Comment 1 _Vi 2013-07-31 19:20:09 UTC 
Created attachment 107065 [details]
Kernel panic output 2, now not using netconsole's interface for the test itself
Comment 2 _Vi 2013-08-01 09:38:28 UTC 
Reproducible on 3.11.0-rc3

Looks like negative priority value is essential for the kernel panic.
Comment 3 Stephen Hemminger 2013-08-02 04:22:54 UTC 
You must be using old version of iproute2.
With current version the tc command does not allow negative priorities.

+ tc qdisc add dev eth1 root handle 55: htb default 1
+ tc class add dev eth1 parent 55: classid 55:1 htb rate 50000000
+ tc class add dev eth1 parent 55: classid 55:2 htb rate 50000000 prio -1
Illegal "prio"
Comment 4 _Vi 2013-08-02 08:27:18 UTC 
Maybe, but the kernel still should check for it.

As far as I understand, CAP_NET_ADMIN is not expected to be able to crash kernel.
Comment 5 Stephen Hemminger 2013-08-02 16:00:36 UTC 
Created attachment 107081 [details]
HTB prio unsigned fix