Skip to content

L
linux
Switch branch/tag
  1. 20 Oct, 2021 3 commits
    • Guangbin Huang's avatar
      net: hns3: reset DWRR of unused tc to zero · b63fcaab
      Guangbin Huang authored 
      Currently, DWRR of tc will be initialized to a fixed value when this tc
is enabled, but it is not been reset to 0 when this tc is disabled. It
cause a problem that the DWRR of unused tc is not 0 after using tc tool
to add and delete multi-tc parameters.

For examples, after enabling 4 TCs and restoring to 1 TC by follow
tc commands:

$ tc qdisc add dev eth0 root mqprio num_tc 4 map 0 1 2 3 0 1 2 3 queues \
  8@0 8@8 8@16 8@24 hw 1 mode channel
$ tc qdisc del dev eth0 root

Now there is just one TC is enabled for eth0, but the tc info querying by
debugfs is shown as follow:

$ cat /mnt/hns3/0000:7d:00.0/tm/tc_sch_info
enabled tc number: 1
weight_offset: 14
TC    MODE  WEIGHT
0     dwrr    100
1     dwrr    100
2     dwrr    100
3     dwrr    100
4     dwrr      0
5     dwrr      0
6     dwrr      0
7     dwrr      0

This patch fixes it by resetting DWRR of tc to 0 when tc is disabled.

Fixes: 84844054 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver")
Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b63fcaab
    • Jiaran Zhang's avatar
      net: hns3: Add configuration of TM QCN error event · 60484103
      Jiaran Zhang authored 
      Add configuration of interrupt type and fifo interrupt enable of TM QCN
error event if enabled, otherwise this event will not be reported when
there is error.

Fixes: d914971d ("net: hns3: remove redundant query in hclge_config_tm_hw_err_int()")
Signed-off-by: default avatarJiaran Zhang <zhangjiaran@huawei.com>
Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60484103
    • Eugene Crosser's avatar
      vrf: Revert "Reset skb conntrack connection..." · 55161e67
      Eugene Crosser authored 
      This reverts commit 09e856d5.

When an interface is enslaved in a VRF, prerouting conntrack hook is
called twice: once in the context of the original input interface, and
once in the context of the VRF interface. If no special precausions are
taken, this leads to creation of two conntrack entries instead of one,
and breaks SNAT.

Commit above was intended to avoid creation of extra conntrack entries
when input interface is enslaved in a VRF. It did so by resetting
conntrack related data associated with the skb when it enters VRF context.

However it breaks netfilter operation. Imagine a use case when conntrack
zone must be assigned based on the original input interface, rather than
VRF interface (that would make original interfaces indistinguishable). One
could create netfilter rules similar to these:

        chain rawprerouting {
                type filter hook prerouting priority raw;
                iif realiface1 ct zone set 1 return
                iif realiface2 ct zone set 2 return
        }

This works before the mentioned commit, but not after: zone assignment
is "forgotten", and any subsequent NAT or filtering that is dependent
on the conntrack zone does not work.

Here is a reproducer script that demonstrates the difference in behaviour.

==========
#!/bin/sh

# This script demonstrates unexpected change of nftables behaviour
# caused by commit 09e856d5 ""vrf: Reset skb conntrack
# connection on VRF rcv"
# https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09e856d54bda5f288ef8437a90ab2b9b3eab83d1
#
# Before the commit, it was possible to assign conntrack zone to a
# packet (or mark it for `notracking`) in the prerouting chanin, raw
# priority, based on the `iif` (interface from which the packet
# arrived).
# After the change, # if the interface is enslaved in a VRF, such
# assignment is lost. Instead, assignment based on the `iif` matching
# the VRF master interface is honored. Thus it is impossible to
# distinguish packets based on the original interface.
#
# This script demonstrates this change of behaviour: conntrack zone 1
# or 2 is assigned depending on the match with the original interface
# or the vrf master interface. It can be observed that conntrack entry
# appears in different zone in the kernel versions before and after
# the commit.

IPIN=172.30.30.1
IPOUT=172.30.30.2
PFXL=30

ip li sh vein >/dev/null 2>&1 && ip li del vein
ip li sh tvrf >/dev/null 2>&1 && ip li del tvrf
nft list table testct >/dev/null 2>&1 && nft delete table testct

ip li add vein type veth peer veout
ip li add tvrf type vrf table 9876
ip li set veout master tvrf
ip li set vein up
ip li set veout up
ip li set tvrf up
/sbin/sysctl -w net.ipv4.conf.veout.accept_local=1
/sbin/sysctl -w net.ipv4.conf.veout.rp_filter=0
ip addr add $IPIN/$PFXL dev vein
ip addr add $IPOUT/$PFXL dev veout

nft -f - <<__END__
table testct {
	chain rawpre {
		type filter hook prerouting priority raw;
		iif { veout, tvrf } meta nftrace set 1
		iif veout ct zone set 1 return
		iif tvrf ct zone set 2 return
		notrack
	}
	chain rawout {
		type filter hook output priority raw;
		notrack
	}
}
__END__

uname -rv
conntrack -F
ping -W 1 -c 1 -I vein $IPOUT
conntrack -L
Signed-off-by: default avatarEugene Crosser <crosser@average.org>
Acked-by: default avatarDavid Ahern <dsahern@kernel.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      55161e67
  3. 19 Oct, 2021 5 commits
  5. 18 Oct, 2021 12 commits
  7. 17 Oct, 2021 11 commits
  9. 16 Oct, 2021 3 commits
    • Nikolay Aleksandrov's avatar
      net: bridge: mcast: use multicast_membership_interval for IGMPv3 · fac3cb82
      Nikolay Aleksandrov authored 
      When I added IGMPv3 support I decided to follow the RFC for computing
the GMI dynamically:
" 8.4. Group Membership Interval

   The Group Membership Interval is the amount of time that must pass
   before a multicast router decides there are no more members of a
   group or a particular source on a network.

   This value MUST be ((the Robustness Variable) times (the Query
   Interval)) plus (one Query Response Interval)."

But that actually is inconsistent with how the bridge used to compute it
for IGMPv2, where it was user-configurable that has a correct default value
but it is up to user-space to maintain it. This would make it consistent
with the other timer values which are also maintained correct by the user
instead of being dynamically computed. It also changes back to the previous
user-expected GMI behaviour for IGMPv3 queries which were supported before
IGMPv3 was added. Note that to properly compute it dynamically we would
need to add support for "Robustness Variable" which is currently missing.
Reported-by: default avatarHangbin Liu <liuhangbin@gmail.com>
Fixes: 0436862e ("net: bridge: mcast: support for IGMPv3/MLDv2 ALLOW_NEW_SOURCES report")
Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fac3cb82
    • Stefano Garzarella's avatar
      vsock_diag_test: remove free_sock_stat() call in test_no_sockets · ba95a622
      Stefano Garzarella authored 
      In `test_no_sockets` we don't expect any sockets, indeed
check_no_sockets() prints an error and exits if `sockets` list is
not empty, so free_sock_stat() call is unnecessary since it would
only be called when the `sockets` list is empty.

This was discovered by a strange warning printed by gcc v11.2.1:
  In file included from ../../include/linux/list.h:7,
                   from vsock_diag_test.c:18:
  vsock_diag_test.c: In function ‘test_no_sockets’:
  ../../include/linux/kernel.h:35:45: error: array subscript ‘struct vsock_stat[0]’ is partly outside array bound
  s of ‘struct list_head[1]’ [-Werror=array-bounds]
     35 |         const typeof(((type *)0)->member) * __mptr = (ptr);     \
        |                                             ^~~~~~
  ../../include/linux/list.h:352:9: note: in expansion of macro ‘container_of’
    352 |         container_of(ptr, type, member)
        |         ^~~~~~~~~~~~
  ../../include/linux/list.h:393:9: note: in expansion of macro ‘list_entry’
    393 |         list_entry((pos)->member.next, typeof(*(pos)), member)
        |         ^~~~~~~~~~
  ../../include/linux/list.h:522:21: note: in expansion of macro ‘list_next_entry’
    522 |                 n = list_next_entry(pos, member);                       \
        |                     ^~~~~~~~~~~~~~~
  vsock_diag_test.c:325:9: note: in expansion of macro ‘list_for_each_entry_safe’
    325 |         list_for_each_entry_safe(st, next, sockets, list) {
        |         ^~~~~~~~~~~~~~~~~~~~~~~~
  In file included from vsock_diag_test.c:18:
  vsock_diag_test.c:333:19: note: while referencing ‘sockets’
    333 |         LIST_HEAD(sockets);
        |                   ^~~~~~~
  ../../include/linux/list.h:23:26: note: in definition of macro ‘LIST_HEAD’
     23 |         struct list_head name = LIST_HEAD_INIT(name)

It seems related to some compiler optimization and assumption
about the empty `sockets` list, since this warning is printed
only with -02 or -O3. Also removing `exit(1)` from
check_no_sockets() makes the warning disappear since in that
case free_sock_stat() can be reached also when the list is
not empty.
Reported-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
Link: https://lore.kernel.org/r/20211014152045.173872-1-sgarzare@redhat.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ba95a622
    • Jakub Kicinski's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue · 2151135a
      Jakub Kicinski authored 
      Tony Nguyen says:

====================
Intel Wired LAN Driver Updates 2021-10-14

Brett ensures RDMA nodes are removed during release and rebuild. He also
corrects fw.mgmt.api to include the patch number for proper
identification.

Dave stops ida_free() being called when an IDA has not been allocated.

Michal corrects the order of parameters being provided and the number of
entries skipped for UDP tunnels.
====================

Link: https://lore.kernel.org/r/20211014181953.3538330-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2151135a
  11. 15 Oct, 2021 6 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7