Bug 1273050 - TestOnly: tc-ematch shows a misleading mask of 0x00000000 even when no mask was configured
TestOnly: tc-ematch shows a misleading mask of 0x00000000 even when no mask w...
Status: MODIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iproute (Show other bugs)
7.2
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Timothy Redaelli
BaseOS QE Security Team
: TestOnly
Depends On: 1435647
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-19 09:03 EDT by Ido Barkan
Modified: 2017-10-19 05:14 EDT (History)
8 users (show)

See Also:
Fixed In Version: iproute-4.11.0-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ido Barkan 2015-10-19 09:03:56 EDT
Description of problem:
after configuring a filter using tc-ematch with the following command:
$ tc filter replace dev eno2 protocol all parent 1389: pref 168 basic match 'meta(vlan eq 168)' flowid 1389:a8
the reported filter shows a 0 mask:
$ tc filter show dev eno2
filter parent 1389: protocol all pref 168 basic 
filter parent 1389: protocol all pref 168 basic handle 0x1 flowid 1389:a8 
  meta(vlan mask 0x00000000 eq 168)

This is at best misleading since it is not clear if it means an 'ignore all' mask or a 'no mask' configuration.

Also configuring a filter with a 0 mask produces the same output.
tc filter add dev eno2 protocol all parent 1389: pref 168 basic match 'meta(vlan eq mask 0x00000000 169)' flowid 1389:a

Version-Release number of selected component (if applicable):
$ rpm -q iproute
iproute-3.10.0-54.el7.x86_64
$ uname -r
3.10.0-320.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. tc filter replace dev eno2 protocol all parent 1389: pref 168 basic match 'meta(vlan eq 168)' flowid 1389:a8
2. tc filter show dev eno2
3.

Actual results:
maks reported as 0x00000000

Expected results:
no mask should be reported as none was configured
an entry in the docs explaining the output

Additional info:
Comment 3 Phil Sutter 2016-07-14 18:26:36 EDT
Patch sent upstream: http://marc.info/?l=linux-netdev&m=146853067503629&w=2
Comment 4 Phil Sutter 2016-07-21 04:22:52 EDT
The following patch needs to be backported:

commit 247ace611526e51d9f5a2f4b6e965c59b0f8b739
Author: Phil Sutter <phil@nwl.cc>
Date:   Thu Jul 14 23:10:53 2016 +0200

    tc: ematch: Ignore all-zero mask value when printing filters
    
    The optional mask which may be added to int values is considered by the
    kernel only if it is non-zero, therefore tc should only then also print
    it.
    
    Without this, not passing a mask value like so:
    
    | # tc filter add dev d0 parent 8001: \
    |   basic match meta\(vlan eq 1\) \
    |   classid 8001:1
    
    Would lead to tc printing an all-zero mask later:
    
    | # tc filter show dev d0
    | filter parent 8001: protocol all pref 49151 basic
    | filter parent 8001: protocol all pref 49151 basic handle 0x1 flowid 8001:1
    |   meta(vlan mask 0x00000000 eq 1)
    
    This is obviously confusing as an all-zero mask strictly means to
    eliminate all bits from the value, but the opposite is the case.
    
    Cc: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: Phil Sutter <phil@nwl.cc>

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