]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'bpf-flow-dissector-fix-port-ranges'
authorDaniel Borkmann <daniel@iogearbox.net>
Mon, 27 Jan 2020 10:25:07 +0000 (11:25 +0100)
committerDaniel Borkmann <daniel@iogearbox.net>
Mon, 27 Jan 2020 10:25:12 +0000 (11:25 +0100)
commit4ef685d4f86a3d85917b6c17355fb168ce70d431
treed8a90788a7a29307fd509bbf2761f024b4a902f8
parent95ec6c4219fa04120c3b15a3e42addafde9056d7
parent239257de1f1be583dba7e307621297500c23de17
Merge branch 'bpf-flow-dissector-fix-port-ranges'

Yoshiki Komachi says:

====================
When I tried a test based on the selftest program for BPF flow dissector
(test_flow_dissector.sh), I observed unexpected result as below:

$ tc filter add dev lo parent ffff: protocol ip pref 1337 flower ip_proto \
udp src_port 8-10 action drop
$ tools/testing/selftests/bpf/test_flow_dissector -i 4 -f 9 -F
inner.dest4: 127.0.0.1
inner.source4: 127.0.0.3
pkts: tx=10 rx=10

The last rx means the number of received packets. I expected rx=0 in this
test (i.e., all received packets should have been dropped), but it resulted
in acceptance.

Although the previous commit 1bd2993626ae ("cls_flower: Fix the behavior
using port ranges with hw-offload") added new flag and field toward filtering
based on port ranges with hw-offload, it missed applying for BPF flow dissector
then. As a result, BPF flow dissector currently stores data extracted from
packets in incorrect field used for exact match whenever packets are classified
by filters based on port ranges. Thus, they never match rules in such cases
because flow dissector gives rise to generating incorrect flow keys.

This series fixes the issue by replacing incorrect flag and field with new
ones in BPF flow dissector, and adds a test for filtering based on specified
port ranges to the existing selftest program.

Changes in v2:
 - set key_ports to NULL at the top of __skb_flow_bpf_to_target()
====================

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>