Bug 84661 - [BISECTED]tc filter show from iproute2 does not work correctly on 32bit x86
Summary: [BISECTED]tc filter show from iproute2 does not work correctly on 32bit x86
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-16 11:47 UTC by Anton Farygin
Modified: 2017-01-11 16:49 UTC (History)
7 users (show)

See Also:
Kernel Version: 3.14.17 and 3.16.1
Subsystem:
Regression: No
Bisected commit-id:


Attachments
u32_dump patch for 3.18.10 (569 bytes, patch)
2015-04-15 12:56 UTC, Vitaly Lavrov
Details | Diff

Description Anton Farygin 2014-09-16 11:47:20 UTC
i tested this issue with kernels 3.14.x and 3.16.x. and iproute2-3.16.0

This commit:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=6a031f67c83aa175aedd10d4ae64750415ab57b0
breaking output tc filter show on 32bit systems.

This simple script shows the difference in the work on i586 and x86_64:
-------------------------
#!/bin/sh
dev=$1
tc qdisc add dev $dev root handle 1: htb default fffe
tc filter add dev $dev parent 1:0 protocol ip pref 10 u32
tc filter add dev $dev parent 1:0 protocol ip pref 10 handle 100: u32 divisor 8
tc filter add dev $dev parent 1:0 protocol ip pref 10 u32 ht 800:: match ip dst 10.21.10.0/21 hashkey mask 0x00000700 at 16 link 100:
tc filter show dev $dev
tc filter del dev $dev parent 1:0 protocol ip pref 10 u32 ht 800:: match ip dst 10.21.10.0/21 hashkey mask 0x00000700 at 16 link 100:
tc qdisc del dev $dev root handle 1: htb default fffe
---------------------------

output on i586:

#./script enp0s25
filter parent 1: protocol ip pref 10 u32 
filter parent 1: protocol ip pref 10 u32 fh 100: ht divisor 8 
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 


output on x86_64:
# ./script eth0
filter parent 1: protocol ip pref 10 u32 
filter parent 1: protocol ip pref 10 u32 fh 100: ht divisor 8 
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 link 100: 
  match 0a150800/fffff800 at 16
    hash mask 00000700 at 16
Comment 1 Anton Boyarshinov 2014-09-16 13:15:49 UTC
git bisect start 'net/sched'
# good: [5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52] Linux 3.12
git bisect good 5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52
# bad: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14
git bisect bad 455c6fdbd219161bd09b1165f11699d6d73de11c
# skip: [3627287463b4acddb83d24fabb1e0a304e39565c] net_sched: convert tcf_proto_ops to use struct list_head
git bisect skip 3627287463b4acddb83d24fabb1e0a304e39565c
# skip: [724b9e1d75ab3401aaa081bd4efb440c1b3509db] sch_tbf: Fix potential memory leak in tbf_change().
git bisect skip 724b9e1d75ab3401aaa081bd4efb440c1b3509db
# good: [f663dd9aaf9ed124f25f0f8452edf238f087ad50] net: core: explicitly select a txq before doing l2 forwarding
git bisect good f663dd9aaf9ed124f25f0f8452edf238f087ad50
# bad: [6a031f67c83aa175aedd10d4ae64750415ab57b0] sch_netem: support of 64bit rates
git bisect bad 6a031f67c83aa175aedd10d4ae64750415ab57b0
# skip: [369ba56787d7469c0afda70bb9ff76ad5faaead5] net_sched: init struct tcf_hashinfo at register time
git bisect skip 369ba56787d7469c0afda70bb9ff76ad5faaead5
# skip: [3b69a4c9becde783cd89758075780f9d871ba4b6] act_police: remove unnecessary null pointer check
git bisect skip 3b69a4c9becde783cd89758075780f9d871ba4b6
# good: [8cfd88d6d70735c47b17aef855b4c81dde83c85c] sch_netem: more precise length of packets
git bisect good 8cfd88d6d70735c47b17aef855b4c81dde83c85c
# first bad commit: [6a031f67c83aa175aedd10d4ae64750415ab57b0] sch_netem: support of 64bit rates

But, unfortunatly, reverting this single commit doesn't fix the problem
Comment 2 Anton Farygin 2014-09-19 09:22:13 UTC
this bug also reproduced on fedora nightly livecd
affected all linux kernels from 3.14.0
Comment 3 Daniel Borkmann 2014-12-11 10:32:50 UTC
So, your script is not even using netem not its rate attribute ... I also currently don't see how a header mismatch in this case could be an issue.
Comment 4 Anton Farygin 2014-12-11 10:40:39 UTC
Daniel, 
sc-tool, it does not work on 32bit x86, the script is based on rules there, but simplified for a short test-Case
http://sourceforge.net/projects/sc-tool/

in sc-tool, you can set the speed.
Comment 5 Vitaly Lavrov 2015-04-15 12:56:46 UTC
Created attachment 174081 [details]
u32_dump patch for 3.18.10
Comment 6 Vitaly Lavrov 2015-04-15 13:03:32 UTC
Comment on attachment 174081 [details]
u32_dump patch for 3.18.10

The error occurs only when you print the last "u32" filter on the architecture x86.
Function tcf_action_copy_stats() returns an error if there is no action.
The patch adds a check for the existence of action before calling tcf_action_copy_stats().
Comment 7 白川間瀬流 2017-01-11 16:49:34 UTC
Not 100% sure if this is the same problem, but i still get the problem that tc filter show, shows me nothing.

I did the following:

# tc qdisc add dev enp0s25 handle fff: ingress
# tc filter add dev enp0s25 parent ffff: u32 match u32 0 0 police rate 20mbit burst 100k

the qdisc does show up, the filter not

---8<---
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2 
qdisc pfifo_fast 0: dev enp0s25 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc ingress ffff: dev enp0s25 parent ffff:fff1 ----------------

# tc filter show

---8<---

I'm running an Linux 4.4.41 SMP x86_64.

The rule applied though, the traffic was only 20mbit (as expected)

Note You need to log in before you can comment on or make changes to this bug.