RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1165257 - Deleting a tc filter fails with ENOSUP, not ENOENT or EINVAL
Summary: Deleting a tc filter fails with ENOSUP, not ENOENT or EINVAL
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.6
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jiri Pirko
QA Contact: Network QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-18 16:10 UTC by Ondřej Svoboda
Modified: 2015-05-05 01:25 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-27 13:11:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ondřej Svoboda 2014-11-18 16:10:29 UTC 
Description of problem:

On my EL6.6 system running
# /sbin/tc filter del dev eth0 pref 5000
(when no filter exists) returns a different error than on another EL6.6 machine.

RTNETLINK answers: Operation not supported
We have an error talking to the kernel

Does this indicate I am missing some modules? I tried loading all in kernel/net/sched, but this seems not to be enough. Could there be any misconfiguration?

Version-Release number of selected component (if applicable):
kernel-2.6.32-504.1.3.el6.x86_64
iproute-2.6.32-33.el6_6.x86_64

How reproducible:
100%

Additional info:

Other commands seem to work (and they return 0; the modules are not loaded now):
# tc filter show dev eth0
# tc qdisc show dev eth0
qdisc mq 0: root 

This is a list of modules after reboot:
# lsmod
Module                  Size  Used by
nfs                   426740  1 
fscache                55636  1 nfs
bonding               128245  0 
8021q                  25349  1 bonding
garp                    7152  1 8021q
be2iscsi               99578  0 
iscsi_boot_sysfs        9458  1 be2iscsi
bnx2i                  48064  0 
cnic                   57079  1 bnx2i
uio                    10462  1 cnic
cxgb4i                 28361  0 
cxgb4                 104882  1 cxgb4i
cxgb3i                 24491  0 
libcxgbi               52202  2 cxgb4i,cxgb3i
cxgb3                 152890  1 cxgb3i
mdio                    4769  1 cxgb3
ib_iser                32649  0 
rdma_cm                36834  1 ib_iser
ib_cm                  36580  1 rdma_cm
iw_cm                   8516  1 rdma_cm
ib_sa                  23964  2 rdma_cm,ib_cm
ib_mad                 39162  2 ib_cm,ib_sa
ib_core                74355  6 ib_iser,rdma_cm,ib_cm,iw_cm,ib_sa,ib_mad
ib_addr                 6440  1 rdma_cm
iscsi_tcp              10307  0 
libiscsi_tcp           17020  4 cxgb4i,cxgb3i,libcxgbi,iscsi_tcp
libiscsi               49836  8 be2iscsi,bnx2i,cxgb4i,cxgb3i,libcxgbi,ib_iser,iscsi_tcp,libiscsi_tcp
scsi_transport_iscsi    84241  8 be2iscsi,bnx2i,libcxgbi,ib_iser,iscsi_tcp,libiscsi
ebtable_nat             2009  0 
ebtables               18135  1 ebtable_nat
nfsd                  309196  13 
nfs_acl                 2647  2 nfs,nfsd
auth_rpcgss            44949  2 nfs,nfsd
exportfs                4236  1 nfsd
lockd                  73662  2 nfs,nfsd
sunrpc                262768  22 nfs,nfsd,nfs_acl,auth_rpcgss,lockd
acpi_cpufreq            7763  1 
freq_table              4936  1 acpi_cpufreq
mperf                   1557  1 acpi_cpufreq
bridge                 83177  0 
stp                     2218  2 garp,bridge
llc                     5546  3 garp,bridge,stp
ipt_REJECT              2351  1 
nf_conntrack_ipv4       9506  6 
nf_defrag_ipv4          1483  1 nf_conntrack_ipv4
iptable_filter          2793  1 
ip_tables              17831  1 iptable_filter
ip6t_REJECT             4628  2 
nf_conntrack_ipv6       8748  2 
nf_defrag_ipv6         11182  1 nf_conntrack_ipv6
xt_state                1492  8 
nf_conntrack           79758  3 nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state
ip6table_filter         2889  1 
ip6_tables             18732  1 ip6table_filter
ipv6                  317340  108 bonding,cnic,ib_addr,ip6t_REJECT,nf_conntrack_ipv6,nf_defrag_ipv6
dm_round_robin          2525  1 
dm_multipath           17724  2 dm_round_robin
vhost_net              30520  0 
macvtap                10039  1 vhost_net
macvlan                 9969  1 macvtap
tun                    17095  1 vhost_net
kvm_intel              54285  0 
kvm                   333172  1 kvm_intel
microcode             112685  0 
iTCO_wdt                7115  1 
iTCO_vendor_support     3056  1 iTCO_wdt
ipmi_devintf            7729  0 
serio_raw               4594  0 
igb                   197536  0 
dca                     7101  1 igb
i2c_algo_bit            5935  1 igb
i2c_core               31084  2 igb,i2c_algo_bit
ptp                     9614  1 igb
pps_core               11458  1 ptp
sg                     29350  0 
lpc_ich                12803  0 
mfd_core                1895  1 lpc_ich
i7core_edac            17948  0 
edac_core              46581  1 i7core_edac
shpchp                 32778  0 
ext4                  374902  4 
jbd2                   93427  1 ext4
mbcache                 8193  1 ext4
sr_mod                 15177  0 
cdrom                  39085  1 sr_mod
sd_mod                 39069  3 
crc_t10dif              1541  1 sd_mod
ahci                   42215  3 
dm_mirror              14384  0 
dm_region_hash         12085  1 dm_mirror
dm_log                  9930  2 dm_mirror,dm_region_hash
dm_mod                 84209  21 dm_multipath,dm_mirror,dm_log
Comment 2 Jiri Pirko 2014-11-18 16:33:10 UTC 
Can you please provide more info? Is this a regression? If yes, against which version of kernel? The mentioned "other machine" what kernel does that run? What is the error there?
Comment 3 Ondřej Svoboda 2014-11-18 18:28:54 UTC 
(In reply to Jiri Pirko from comment #2)
> Can you please provide more info? Is this a regression? If yes, against
> which version of kernel? The mentioned "other machine" what kernel does that
> run? What is the error there?

I do not think this is a regression, rather a result of hard weathering (testing of experimental versions of VDSM and many dependencies) over the course of almost a year.

Toni, could you please rpm -qa | grep 'kernel'?
(He owns the other EL6.6 machine, which behaves correctly, i.e. giving ENOENT. But I think most EL6.6 systems would do.)
Comment 4 Antoni Segura Puimedon 2014-11-19 07:56:43 UTC 
This is on my el6 machine
    rhel65_01 ~ # rpm -q kernel
    kernel-2.6.32-431.el6.x86_64
    kernel-2.6.32-431.20.3.el6.x86_64
    kernel-2.6.32-504.1.3.el6.x86_64
    rhel65_01 ~ # uname -r
    2.6.32-431.el6.x86_64
    rhel65_01 ~ # /sbin/tc filter del dev eth0 pref 5000
I get the expected EINVAL. On much newer kernels I get the also expected ENODEV
    RTNETLINK answers: Invalid argument
    We have an error talking to the kernel
    rhel65_01 ~ #
Comment 5 Antoni Segura Puimedon 2014-11-19 08:00:13 UTC 
It seems on F20 I was getting the ENODEV, but I checked on other distros I have
lying around (3.17.3) and I am now getting EINVAL:
    ~/c/libnl ❯❯❯ sudo /sbin/tc filter del dev enp0s25 pref 5000
    RTNETLINK answers: Invalid argument
    ~/c/libnl ❯❯❯ uname -r
    3.17.3-1-ARCH
Comment 6 Antoni Segura Puimedon 2014-11-19 08:00:43 UTC 
This is on my el6 machine
    rhel65_01 ~ # rpm -q kernel
    kernel-2.6.32-431.el6.x86_64
    kernel-2.6.32-431.20.3.el6.x86_64
    kernel-2.6.32-504.1.3.el6.x86_64
    rhel65_01 ~ # uname -r
    2.6.32-431.el6.x86_64
    rhel65_01 ~ # /sbin/tc filter del dev eth0 pref 5000
I get the expected EINVAL. On much newer kernels I get the also expected ENODEV
    RTNETLINK answers: Invalid argument
    We have an error talking to the kernel
    rhel65_01 ~ #
Comment 7 Antoni Segura Puimedon 2014-11-19 08:01:32 UTC 
Please ignore comment 6. Glitch in the browser.
Comment 9 Dan Kenigsberg 2015-01-06 10:54:56 UTC 
FWIW, with kernel-3.10.0-123.19.1.el7.x86_64 and iproute-3.10.0-13.el7.x86_64 I see

# /sbin/tc filter del dev enp7s0 pref 5000
RTNETLINK answers: Operation not supported
We have an error talking to the kernel
Comment 10 Dan Kenigsberg 2015-01-06 13:36:24 UTC 
Is this change of semantics expected in el7?
Comment 11 Jiri Pirko 2015-01-07 09:13:34 UTC 
(In reply to Dan Kenigsberg from comment #9)
> FWIW, with kernel-3.10.0-123.19.1.el7.x86_64 and
> iproute-3.10.0-13.el7.x86_64 I see
> 
> # /sbin/tc filter del dev enp7s0 pref 5000
> RTNETLINK answers: Operation not supported
> We have an error talking to the kernel

With what previous versions did you see different output?
Comment 12 Dan Kenigsberg 2015-01-07 10:18:12 UTC 
kernel-2.6.32-504.3.3.el6.x86_64 for example:

# tc filter del dev eth0 pref 5000
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
Note You need to log in before you can comment on or make changes to this bug.