Bug 1273050 - TestOnly: tc-ematch shows a misleading mask of 0x00000000 even when no mask was configured
Summary: TestOnly: tc-ematch shows a misleading mask of 0x00000000 even when no mask w...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iproute
Version: 7.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Andrea Claudi
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On: 1435647
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-19 13:03 UTC by Ido Barkan
Modified: 2020-03-02 17:15 UTC (History)
10 users (show)

Fixed In Version: iproute-4.11.0-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-02 17:15:06 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Ido Barkan 2015-10-19 13:03:56 UTC
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 22:26:36 UTC
Patch sent upstream: http://marc.info/?l=linux-netdev&m=146853067503629&w=2

Comment 4 Phil Sutter 2016-07-21 08:22:52 UTC
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>

Comment 6 Andrea Claudi 2019-07-17 13:08:29 UTC
Hi Dalibor, this ticket is a TestOnly one, which means no action required from devel side (apart from providing devel_ack+) but testing by QA is still missing. So whenever they get capacity for it, they should provide qa_ack+ and it will make it into the next errata and is tested for. Therefore we want to keep this ticket, otherwise the feature is there but we can't (officially) be sure it's working as intended. I'll anyway move this to rhel-7.8.


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