1. 25 May, 2021 20 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · f5d28712
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2021-05-26
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 14 non-merge commits during the last 14 day(s) which contain
      a total of 17 files changed, 513 insertions(+), 231 deletions(-).
      
      The main changes are:
      
      1) Fix bpf_skb_change_head() helper to reset mac_len, from Jussi Maki.
      
      2) Fix masking direction swap upon off-reg sign change, from Daniel Borkmann.
      
      3) Fix BPF offloads in verifier by reordering driver callback, from Yinjun Zhang.
      
      4) BPF selftest for ringbuf mmap ro/rw restrictions, from Andrii Nakryiko.
      
      5) Follow-up fixes to nested bprintf per-cpu buffers, from Florent Revest.
      
      6) Fix bpftool sock_release attach point help info, from Liu Jian.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5d28712
    • David S. Miller's avatar
      Merge branch 'mptcp-fixes' · 6dfa87b4
      David S. Miller authored
      Mat Martineau says:
      
      ====================
      MPTCP fixes
      
      Here are a few fixes for the -net tree.
      
      Patch 1 fixes an attempt to access a tcp-specific field that does not
      exist in mptcp sockets.
      
      Patches 2 and 3 remove warning/error log output that could be flooded.
      
      Patch 4 performs more validation on address advertisement echo packets
      to improve RFC 8684 compliance.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6dfa87b4
    • Davide Caratti's avatar
      mptcp: validate 'id' when stopping the ADD_ADDR retransmit timer · d58300c3
      Davide Caratti authored
      when Linux receives an echo-ed ADD_ADDR, it checks the IP address against
      the list of "announced" addresses. In case of a positive match, the timer
      that handles retransmissions is stopped regardless of the 'Address Id' in
      the received packet: this behaviour does not comply with RFC8684 3.4.1.
      
      Fix it by validating the 'Address Id' in received echo-ed ADD_ADDRs.
      Tested using packetdrill, with the following captured output:
      
       unpatched kernel:
      
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0xfd2e62517888fe29,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 1 1.2.3.4,mptcp dss ack 3013740213], length 0
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0xfd2e62517888fe29,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 90 198.51.100.2,mptcp dss ack 3013740213], length 0
              ^^^ retransmission is stopped here, but 'Address Id' is 90
      
       patched kernel:
      
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0x1cf372d59e05f4b8,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 1 1.2.3.4,mptcp dss ack 1672384568], length 0
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0x1cf372d59e05f4b8,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 90 198.51.100.2,mptcp dss ack 1672384568], length 0
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0x1cf372d59e05f4b8,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 1 198.51.100.2,mptcp dss ack 1672384568], length 0
              ^^^ retransmission is stopped here, only when both 'Address Id' and 'IP Address' match
      
      Fixes: 00cfd77b ("mptcp: retransmit ADD_ADDR when timeout")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d58300c3
    • Paolo Abeni's avatar
      mptcp: avoid error message on infinite mapping · 3ed0a585
      Paolo Abeni authored
      Another left-over. Avoid flooding dmesg with useless text,
      we already have a MIB for that event.
      
      Fixes: 648ef4b8 ("mptcp: Implement MPTCP receive path")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ed0a585
    • Paolo Abeni's avatar
      mptcp: drop unconditional pr_warn on bad opt · 3812ce89
      Paolo Abeni authored
      This is a left-over of early day. A malicious peer can flood
      the kernel logs with useless messages, just drop it.
      
      Fixes: f296234c ("mptcp: Add handling of incoming MP_JOIN requests")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3812ce89
    • Paolo Abeni's avatar
      mptcp: avoid OOB access in setsockopt() · 20b5759f
      Paolo Abeni authored
      We can't use tcp_set_congestion_control() on an mptcp socket, as
      such function can end-up accessing a tcp-specific field -
      prior_ssthresh - causing an OOB access.
      
      To allow propagating the correct ca algo on subflow, cache the ca
      name at initialization time.
      
      Additionally avoid overriding the user-selected CA (if any) at
      clone time.
      
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/182
      Fixes: aa1fbd94 ("mptcp: sockopt: add TCP_CONGESTION and TCP_INFO")
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20b5759f
    • Simon Horman's avatar
      nfp: update maintainer and mailing list addresses · bab09fe2
      Simon Horman authored
      Some of Netronome's activities and people have moved over to Corigine,
      including NFP driver maintenance and myself.
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarLouis Peens <louis.peens@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bab09fe2
    • Stefan Chulski's avatar
      net: mvpp2: add buffer header handling in RX · 17f9c1b6
      Stefan Chulski authored
      If Link Partner sends frames larger than RX buffer size, MAC mark it
      as oversize but still would pass it to the Packet Processor.
      In this scenario, Packet Processor scatter frame between multiple buffers,
      but only a single buffer would be returned to the Buffer Manager pool and
      it would not refill the poll.
      
      Patch add handling of oversize error with buffer header handling, so all
      buffers would be returned to the Buffer Manager pool.
      
      Fixes: 3f518509 ("ethernet: Add new driver for Marvell Armada 375 network unit")
      Reported-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarStefan Chulski <stefanc@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17f9c1b6
    • Jiapeng Chong's avatar
      bnx2x: Fix missing error code in bnx2x_iov_init_one() · 65161c35
      Jiapeng Chong authored
      Eliminate the follow smatch warning:
      
      drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1227
      bnx2x_iov_init_one() warn: missing error code 'err'.
      Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
      Signed-off-by: default avatarJiapeng Chong <jiapeng.chong@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65161c35
    • Vlad Buslov's avatar
      net: zero-initialize tc skb extension on allocation · 9453d45e
      Vlad Buslov authored
      Function skb_ext_add() doesn't initialize created skb extension with any
      value and leaves it up to the user. However, since extension of type
      TC_SKB_EXT originally contained only single value tc_skb_ext->chain its
      users used to just assign the chain value without setting whole extension
      memory to zero first. This assumption changed when TC_SKB_EXT extension was
      extended with additional fields but not all users were updated to
      initialize the new fields which leads to use of uninitialized memory
      afterwards. UBSAN log:
      
      [  778.299821] UBSAN: invalid-load in net/openvswitch/flow.c:899:28
      [  778.301495] load of value 107 is not a valid value for type '_Bool'
      [  778.303215] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc7+ #2
      [  778.304933] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      [  778.307901] Call Trace:
      [  778.308680]  <IRQ>
      [  778.309358]  dump_stack+0xbb/0x107
      [  778.310307]  ubsan_epilogue+0x5/0x40
      [  778.311167]  __ubsan_handle_load_invalid_value.cold+0x43/0x48
      [  778.312454]  ? memset+0x20/0x40
      [  778.313230]  ovs_flow_key_extract.cold+0xf/0x14 [openvswitch]
      [  778.314532]  ovs_vport_receive+0x19e/0x2e0 [openvswitch]
      [  778.315749]  ? ovs_vport_find_upcall_portid+0x330/0x330 [openvswitch]
      [  778.317188]  ? create_prof_cpu_mask+0x20/0x20
      [  778.318220]  ? arch_stack_walk+0x82/0xf0
      [  778.319153]  ? secondary_startup_64_no_verify+0xb0/0xbb
      [  778.320399]  ? stack_trace_save+0x91/0xc0
      [  778.321362]  ? stack_trace_consume_entry+0x160/0x160
      [  778.322517]  ? lock_release+0x52e/0x760
      [  778.323444]  netdev_frame_hook+0x323/0x610 [openvswitch]
      [  778.324668]  ? ovs_netdev_get_vport+0xe0/0xe0 [openvswitch]
      [  778.325950]  __netif_receive_skb_core+0x771/0x2db0
      [  778.327067]  ? lock_downgrade+0x6e0/0x6f0
      [  778.328021]  ? lock_acquire+0x565/0x720
      [  778.328940]  ? generic_xdp_tx+0x4f0/0x4f0
      [  778.329902]  ? inet_gro_receive+0x2a7/0x10a0
      [  778.330914]  ? lock_downgrade+0x6f0/0x6f0
      [  778.331867]  ? udp4_gro_receive+0x4c4/0x13e0
      [  778.332876]  ? lock_release+0x52e/0x760
      [  778.333808]  ? dev_gro_receive+0xcc8/0x2380
      [  778.334810]  ? lock_downgrade+0x6f0/0x6f0
      [  778.335769]  __netif_receive_skb_list_core+0x295/0x820
      [  778.336955]  ? process_backlog+0x780/0x780
      [  778.337941]  ? mlx5e_rep_tc_netdevice_event_unregister+0x20/0x20 [mlx5_core]
      [  778.339613]  ? seqcount_lockdep_reader_access.constprop.0+0xa7/0xc0
      [  778.341033]  ? kvm_clock_get_cycles+0x14/0x20
      [  778.342072]  netif_receive_skb_list_internal+0x5f5/0xcb0
      [  778.343288]  ? __kasan_kmalloc+0x7a/0x90
      [  778.344234]  ? mlx5e_handle_rx_cqe_mpwrq+0x9e0/0x9e0 [mlx5_core]
      [  778.345676]  ? mlx5e_xmit_xdp_frame_mpwqe+0x14d0/0x14d0 [mlx5_core]
      [  778.347140]  ? __netif_receive_skb_list_core+0x820/0x820
      [  778.348351]  ? mlx5e_post_rx_mpwqes+0xa6/0x25d0 [mlx5_core]
      [  778.349688]  ? napi_gro_flush+0x26c/0x3c0
      [  778.350641]  napi_complete_done+0x188/0x6b0
      [  778.351627]  mlx5e_napi_poll+0x373/0x1b80 [mlx5_core]
      [  778.352853]  __napi_poll+0x9f/0x510
      [  778.353704]  ? mlx5_flow_namespace_set_mode+0x260/0x260 [mlx5_core]
      [  778.355158]  net_rx_action+0x34c/0xa40
      [  778.356060]  ? napi_threaded_poll+0x3d0/0x3d0
      [  778.357083]  ? sched_clock_cpu+0x18/0x190
      [  778.358041]  ? __common_interrupt+0x8e/0x1a0
      [  778.359045]  __do_softirq+0x1ce/0x984
      [  778.359938]  __irq_exit_rcu+0x137/0x1d0
      [  778.360865]  irq_exit_rcu+0xa/0x20
      [  778.361708]  common_interrupt+0x80/0xa0
      [  778.362640]  </IRQ>
      [  778.363212]  asm_common_interrupt+0x1e/0x40
      [  778.364204] RIP: 0010:native_safe_halt+0xe/0x10
      [  778.365273] Code: 4f ff ff ff 4c 89 e7 e8 50 3f 40 fe e9 dc fe ff ff 48 89 df e8 43 3f 40 fe eb 90 cc e9 07 00 00 00 0f 00 2d 74 05 62 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d 64 05 62 00 f4 c3 cc cc 0f 1f 44 00
      [  778.369355] RSP: 0018:ffffffff84407e48 EFLAGS: 00000246
      [  778.370570] RAX: ffff88842de46a80 RBX: ffffffff84425840 RCX: ffffffff83418468
      [  778.372143] RDX: 000000000026f1da RSI: 0000000000000004 RDI: ffffffff8343af5e
      [  778.373722] RBP: fffffbfff0884b08 R08: 0000000000000000 R09: ffff88842de46bcb
      [  778.375292] R10: ffffed1085bc8d79 R11: 0000000000000001 R12: 0000000000000000
      [  778.376860] R13: ffffffff851124a0 R14: 0000000000000000 R15: dffffc0000000000
      [  778.378491]  ? rcu_eqs_enter.constprop.0+0xb8/0xe0
      [  778.379606]  ? default_idle_call+0x5e/0xe0
      [  778.380578]  default_idle+0xa/0x10
      [  778.381406]  default_idle_call+0x96/0xe0
      [  778.382350]  do_idle+0x3d4/0x550
      [  778.383153]  ? arch_cpu_idle_exit+0x40/0x40
      [  778.384143]  cpu_startup_entry+0x19/0x20
      [  778.385078]  start_kernel+0x3c7/0x3e5
      [  778.385978]  secondary_startup_64_no_verify+0xb0/0xbb
      
      Fix the issue by providing new function tc_skb_ext_alloc() that allocates
      tc skb extension and initializes its memory to 0 before returning it to the
      caller. Change all existing users to use new API instead of calling
      skb_ext_add() directly.
      
      Fixes: 038ebb1a ("net/sched: act_ct: fix miss set mru for ovs after defrag in act_ct")
      Fixes: d29334c1 ("net/sched: act_api: fix miss set post_ct for ovs after do conntrack in act_ct")
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Acked-by: default avatarCong Wang <cong.wang@bytedance.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9453d45e
    • Yang Li's avatar
      net: hns: Fix kernel-doc · c1cf1afd
      Yang Li authored
      Fix function name in hns_ethtool.c kernel-doc comment
      to remove these warnings found by clang_w1.
      
      drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:202: warning: expecting
      prototype for hns_nic_set_link_settings(). Prototype was for
      hns_nic_set_link_ksettings() instead.
      drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:837: warning: expecting
      prototype for get_ethtool_stats(). Prototype was for
      hns_get_ethtool_stats() instead.
      drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:894: warning:
      expecting prototype for get_strings(). Prototype was for
      hns_get_strings() instead.
      Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
      Fixes: 'commit 262b38cd ("net: ethernet: hisilicon: hns: use phydev
      from struct net_device")'
      Signed-off-by: default avatarYang Li <yang.lee@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1cf1afd
    • Xin Long's avatar
      sctp: fix the proc_handler for sysctl encap_port · b2540cdc
      Xin Long authored
      proc_dointvec() cannot do min and max check for setting a value
      when extra1/extra2 is set, so change it to proc_dointvec_minmax()
      for sysctl encap_port.
      
      Fixes: e8a3001c ("sctp: add encap_port for netns sock asoc and transport")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b2540cdc
    • Xin Long's avatar
      sctp: add the missing setting for asoc encap_port · 297739bd
      Xin Long authored
      This patch is to add the missing setting back for asoc encap_port.
      
      Fixes: 8dba2960 ("sctp: add SCTP_REMOTE_UDP_ENCAPS_PORT sockopt")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      297739bd
    • Daniel Borkmann's avatar
      bpf, selftests: Adjust few selftest result_unpriv outcomes · 1bad6fd5
      Daniel Borkmann authored
      Given we don't need to simulate the speculative domain for registers with
      immediates anymore since the verifier uses direct imm-based rewrites instead
      of having to mask, we can also lift a few cases that were previously rejected.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      1bad6fd5
    • Daniel Borkmann's avatar
      bpf: No need to simulate speculative domain for immediates · a7036191
      Daniel Borkmann authored
      In 801c6058 ("bpf: Fix leakage of uninitialized bpf stack under
      speculation") we replaced masking logic with direct loads of immediates
      if the register is a known constant. Given in this case we do not apply
      any masking, there is also no reason for the operation to be truncated
      under the speculative domain.
      
      Therefore, there is also zero reason for the verifier to branch-off and
      simulate this case, it only needs to do it for unknown but bounded scalars.
      As a side-effect, this also enables few test cases that were previously
      rejected due to simulation under zero truncation.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarPiotr Krysiuk <piotras@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      a7036191
    • Daniel Borkmann's avatar
      bpf: Fix mask direction swap upon off reg sign change · bb01a1bb
      Daniel Borkmann authored
      Masking direction as indicated via mask_to_left is considered to be
      calculated once and then used to derive pointer limits. Thus, this
      needs to be placed into bpf_sanitize_info instead so we can pass it
      to sanitize_ptr_alu() call after the pointer move. Piotr noticed a
      corner case where the off reg causes masking direction change which
      then results in an incorrect final aux->alu_limit.
      
      Fixes: 7fedb63a ("bpf: Tighten speculative pointer arithmetic mask")
      Reported-by: default avatarPiotr Krysiuk <piotras@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarPiotr Krysiuk <piotras@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      bb01a1bb
    • Daniel Borkmann's avatar
      bpf: Wrap aux data inside bpf_sanitize_info container · 3d0220f6
      Daniel Borkmann authored
      Add a container structure struct bpf_sanitize_info which holds
      the current aux info, and update call-sites to sanitize_ptr_alu()
      to pass it in. This is needed for passing in additional state
      later on.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarPiotr Krysiuk <piotras@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      3d0220f6
    • Daniel Borkmann's avatar
      bpf: Fix BPF_LSM kconfig symbol dependency · 5c9d706f
      Daniel Borkmann authored
      Similarly as 6bdacdb4 ("bpf: Fix BPF_JIT kconfig symbol dependency") we
      need to detangle the hard BPF_LSM dependency on NET. This was previously
      implicit by its dependency on BPF_JIT which itself was dependent on NET (but
      without any actual/real hard dependency code-wise). Given the latter was
      lifted, so should be the former as BPF_LSMs could well exist on net-less
      systems. This therefore also fixes a randconfig build error recently reported
      by Randy:
      
        ld: kernel/bpf/bpf_lsm.o: in function `bpf_lsm_func_proto':
        bpf_lsm.c:(.text+0x1a0): undefined reference to `bpf_sk_storage_get_proto'
        ld: bpf_lsm.c:(.text+0x1b8): undefined reference to `bpf_sk_storage_delete_proto'
        [...]
      
      Fixes: b24abcff ("bpf, kconfig: Add consolidated menu entry for bpf with core options")
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      5c9d706f
    • Jussi Maki's avatar
      selftests/bpf: Add test for l3 use of bpf_redirect_peer · 6fd5fb63
      Jussi Maki authored
      Add a test case for using bpf_skb_change_head() in combination with
      bpf_redirect_peer() to redirect a packet from a L3 device to veth and back.
      
      The test uses a BPF program that adds L2 headers to the packet coming
      from a L3 device and then calls bpf_redirect_peer() to redirect the packet
      to a veth device. The test fails as skb->mac_len is not set properly and
      thus the ethernet headers are not properly skb_pull'd in cls_bpf_classify(),
      causing tcp_v4_rcv() to point the TCP header into middle of the IP header.
      Signed-off-by: default avatarJussi Maki <joamaki@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20210525102955.2811090-1-joamaki@gmail.com
      6fd5fb63
    • Liu Jian's avatar
      bpftool: Add sock_release help info for cgroup attach/prog load command · a8deba85
      Liu Jian authored
      The help information was not added at the time when the function got added.
      Fix this and add the missing information to its cli, documentation and bash
      completion.
      
      Fixes: db94cc0b ("bpftool: Add support for BPF_CGROUP_INET_SOCK_RELEASE")
      Signed-off-by: default avatarLiu Jian <liujian56@huawei.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20210525014139.323859-1-liujian56@huawei.com
      a8deba85
  2. 24 May, 2021 19 commits
    • George McCollister's avatar
      net: dsa: microchip: enable phy errata workaround on 9567 · 8c42a497
      George McCollister authored
      Also enable phy errata workaround on 9567 since has the same errata as
      the 9477 according to the manufacture's documentation.
      Signed-off-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c42a497
    • Pavel Skripkin's avatar
      net: usb: fix memory leak in smsc75xx_bind · 46a8b29c
      Pavel Skripkin authored
      Syzbot reported memory leak in smsc75xx_bind().
      The problem was is non-freed memory in case of
      errors after memory allocation.
      
      backtrace:
        [<ffffffff84245b62>] kmalloc include/linux/slab.h:556 [inline]
        [<ffffffff84245b62>] kzalloc include/linux/slab.h:686 [inline]
        [<ffffffff84245b62>] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460
        [<ffffffff82b5b2e6>] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728
      
      Fixes: d0cad871 ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
      Cc: stable@kernel.vger.org
      Reported-and-tested-by: syzbot+b558506ba8165425fee2@syzkaller.appspotmail.com
      Signed-off-by: default avatarPavel Skripkin <paskripkin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      46a8b29c
    • George McCollister's avatar
      net: hsr: fix mac_len checks · 48b491a5
      George McCollister authored
      Commit 2e9f6093 ("net: hsr: check skb can contain struct hsr_ethhdr
      in fill_frame_info") added the following which resulted in -EINVAL
      always being returned:
      	if (skb->mac_len < sizeof(struct hsr_ethhdr))
      		return -EINVAL;
      
      mac_len was not being set correctly so this check completely broke
      HSR/PRP since it was always 14, not 20.
      
      Set mac_len correctly and modify the mac_len checks to test in the
      correct places since sometimes it is legitimately 14.
      
      Fixes: 2e9f6093 ("net: hsr: check skb can contain struct hsr_ethhdr in fill_frame_info")
      Signed-off-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48b491a5
    • Saubhik Mukherjee's avatar
      net: appletalk: cops: Fix data race in cops_probe1 · a4dd4fc6
      Saubhik Mukherjee authored
      In cops_probe1(), there is a write to dev->base_addr after requesting an
      interrupt line and registering the interrupt handler cops_interrupt().
      The handler might be called in parallel to handle an interrupt.
      cops_interrupt() tries to read dev->base_addr leading to a potential
      data race. So write to dev->base_addr before calling request_irq().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarSaubhik Mukherjee <saubhik.mukherjee@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4dd4fc6
    • David S. Miller's avatar
      Merge branch 'sja1105-fixes' · 93c5d741
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Fixes for SJA1105 DSA driver
      
      This series contains some minor fixes in the sja1105 driver:
      - improved error handling in the probe path
      - rejecting an invalid phy-mode specified in the device tree
      - register access fix for SJA1105P/Q/R/S for the virtual links through
        the dynamic reconfiguration interface
      - handling 2 bridge VLANs where the second is supposed to overwrite the
        first
      - making sure that the lack of a pvid results in the actual dropping of
        untagged traffic
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93c5d741
    • Vladimir Oltean's avatar
      net: dsa: sja1105: update existing VLANs from the bridge VLAN list · b38e659d
      Vladimir Oltean authored
      When running this sequence of operations:
      
      ip link add br0 type bridge vlan_filtering 1
      ip link set swp4 master br0
      bridge vlan add dev swp4 vid 1
      
      We observe the traffic sent on swp4 is still untagged, even though the
      bridge has overwritten the existing VLAN entry:
      
      port    vlan ids
      swp4     1 PVID
      
      br0      1 PVID Egress Untagged
      
      This happens because we didn't consider that the 'bridge vlan add'
      command just overwrites VLANs like it's nothing. We treat the 'vid 1
      pvid untagged' and the 'vid 1' as two separate VLANs, and the first
      still has precedence when calling sja1105_build_vlan_table. Obviously
      there is a disagreement regarding semantics, and we end up doing
      something unexpected from the PoV of the bridge.
      
      Let's actually consider an "existing VLAN" to be one which is on the
      same port, and has the same VLAN ID, as one we already have, and update
      it if it has different flags than we do.
      
      The first blamed commit is the one introducing the bug, the second one
      is the latest on top of which the bugfix still applies.
      
      Fixes: ec5ae610 ("net: dsa: sja1105: save/restore VLANs using a delta commit method")
      Fixes: 5899ee36 ("net: dsa: tag_8021q: add a context structure")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b38e659d
    • Vladimir Oltean's avatar
      net: dsa: sja1105: use 4095 as the private VLAN for untagged traffic · ed040abc
      Vladimir Oltean authored
      One thing became visible when writing the blamed commit, and that was
      that STP and PTP frames injected by net/dsa/tag_sja1105.c using the
      deferred xmit mechanism are always classified to the pvid of the CPU
      port, regardless of whatever VLAN there might be in these packets.
      
      So a decision needed to be taken regarding the mechanism through which
      we should ensure that delivery of STP and PTP traffic is possible when
      we are in a VLAN awareness mode that involves tag_8021q. This is because
      tag_8021q is not concerned with managing the pvid of the CPU port, since
      as far as tag_8021q is concerned, no traffic should be sent as untagged
      from the CPU port. So we end up not actually having a pvid on the CPU
      port if we only listen to tag_8021q, and unless we do something about it.
      
      The decision taken at the time was to keep VLAN 1 in the list of
      priv->dsa_8021q_vlans, and make it a pvid of the CPU port. This ensures
      that STP and PTP frames can always be sent to the outside world.
      
      However there is a problem. If we do the following while we are in
      the best_effort_vlan_filtering=true mode:
      
      ip link add br0 type bridge vlan_filtering 1
      ip link set swp2 master br0
      bridge vlan del dev swp2 vid 1
      
      Then untagged and pvid-tagged frames should be dropped. But we observe
      that they aren't, and this is because of the precaution we took that VID
      1 is always installed on all ports.
      
      So clearly VLAN 1 is not good for this purpose. What about VLAN 0?
      Well, VLAN 0 is managed by the 8021q module, and that module wants to
      ensure that 802.1p tagged frames are always received by a port, and are
      always transmitted as VLAN-tagged (with VLAN ID 0). Whereas we want our
      STP and PTP frames to be untagged if the stack sent them as untagged -
      we don't want the driver to just decide out of the blue that it adds
      VID 0 to some packets.
      
      So what to do?
      
      Well, there is one other VLAN that is reserved, and that is 4095:
      $ ip link add link swp2 name swp2.4095 type vlan id 4095
      Error: 8021q: Invalid VLAN id.
      $ bridge vlan add dev swp2 vid 4095
      Error: bridge: Vlan id is invalid.
      
      After we made this change, VLAN 1 is indeed forwarded and/or dropped
      according to the bridge VLAN table, there are no further alterations
      done by the sja1105 driver.
      
      Fixes: ec5ae610 ("net: dsa: sja1105: save/restore VLANs using a delta commit method")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed040abc
    • Vladimir Oltean's avatar
      net: dsa: sja1105: error out on unsupported PHY mode · 6729188d
      Vladimir Oltean authored
      The driver continues probing when a port is configured for an
      unsupported PHY interface type, instead it should stop.
      
      Fixes: 8aa9ebcc ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6729188d
    • Vladimir Oltean's avatar
      net: dsa: sja1105: add error handling in sja1105_setup() · cec279a8
      Vladimir Oltean authored
      If any of sja1105_static_config_load(), sja1105_clocking_setup() or
      sja1105_devlink_setup() fails, we can't just return in the middle of
      sja1105_setup() or memory will leak. Add a cleanup path.
      
      Fixes: 0a7bdbc2 ("net: dsa: sja1105: move devlink param code to sja1105_devlink.c")
      Fixes: 8aa9ebcc ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cec279a8
    • Vladimir Oltean's avatar
      net: dsa: sja1105: call dsa_unregister_switch when allocating memory fails · dc596e3f
      Vladimir Oltean authored
      Unlike other drivers which pretty much end their .probe() execution with
      dsa_register_switch(), the sja1105 does some extra stuff. When that
      fails with -ENOMEM, the driver is quick to return that, forgetting to
      call dsa_unregister_switch(). Not critical, but a bug nonetheless.
      
      Fixes: 4d752508 ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc")
      Fixes: a68578c2 ("net: dsa: Make deferred_xmit private to sja1105")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc596e3f
    • Vladimir Oltean's avatar
      net: dsa: sja1105: fix VL lookup command packing for P/Q/R/S · ba61cf16
      Vladimir Oltean authored
      At the beginning of the sja1105_dynamic_config.c file there is a diagram
      of the dynamic config interface layout:
      
       packed_buf
      
       |
       V
       +-----------------------------------------+------------------+
       |              ENTRY BUFFER               |  COMMAND BUFFER  |
       +-----------------------------------------+------------------+
      
       <----------------------- packed_size ------------------------>
      
      So in order to pack/unpack the command bits into the buffer,
      sja1105_vl_lookup_cmd_packing must first advance the buffer pointer by
      the length of the entry. This is similar to what the other *cmd_packing
      functions do.
      
      This bug exists because the command packing function for P/Q/R/S was
      copied from the E/T generation, and on E/T, the command was actually
      embedded within the entry buffer itself.
      
      Fixes: 94f94d4a ("net: dsa: sja1105: add static tables for virtual links")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba61cf16
    • Johan Hovold's avatar
      net: hso: fix control-request directions · 1a6e9a9c
      Johan Hovold authored
      The direction of the pipe argument must match the request-type direction
      bit or control requests may fail depending on the host-controller-driver
      implementation.
      
      Fix the tiocmset and rfkill requests which erroneously used
      usb_rcvctrlpipe().
      
      Fixes: 72dc1c09 ("HSO: add option hso driver")
      Cc: stable@vger.kernel.org      # 2.6.27
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a6e9a9c
    • Hayes Wang's avatar
      r8152: check the informaton of the device · 1a44fb38
      Hayes Wang authored
      Verify some fields of the USB descriptor to make sure the driver
      could be used by the device.
      
      Besides, remove the check of endpoint number in rtl8152_probe().
      usb_find_common_endpoints() includes it.
      
      BugLink: https://syzkaller.appspot.com/bug?id=912c9c373656996801b4de61f1e3cb326fe940aa
      Reported-by: syzbot+95afd23673f5dd295c57@syzkaller.appspotmail.com
      Fixes: c2198943 ("r8152: search the configuration of vendor mode")
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Reviewed-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a44fb38
    • Taehee Yoo's avatar
      sch_dsmark: fix a NULL deref in qdisc_reset() · 9b76eade
      Taehee Yoo authored
      If Qdisc_ops->init() is failed, Qdisc_ops->reset() would be called.
      When dsmark_init(Qdisc_ops->init()) is failed, it possibly doesn't
      initialize dsmark_qdisc_data->q. But dsmark_reset(Qdisc_ops->reset())
      uses dsmark_qdisc_data->q pointer wihtout any null checking.
      So, panic would occur.
      
      Test commands:
          sysctl net.core.default_qdisc=dsmark -w
          ip link add dummy0 type dummy
          ip link add vw0 link dummy0 type virt_wifi
          ip link set vw0 up
      
      Splat looks like:
      KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
      CPU: 3 PID: 684 Comm: ip Not tainted 5.12.0+ #910
      RIP: 0010:qdisc_reset+0x2b/0x680
      Code: 1f 44 00 00 48 b8 00 00 00 00 00 fc ff df 41 57 41 56 41 55 41 54
      55 48 89 fd 48 83 c7 18 53 48 89 fa 48 c1 ea 03 48 83 ec 20 <80> 3c 02
      00 0f 85 09 06 00 00 4c 8b 65 18 0f 1f 44 00 00 65 8b 1d
      RSP: 0018:ffff88800fda6bf8 EFLAGS: 00010282
      RAX: dffffc0000000000 RBX: ffff8880050ed800 RCX: 0000000000000000
      RDX: 0000000000000003 RSI: ffffffff99e34100 RDI: 0000000000000018
      RBP: 0000000000000000 R08: fffffbfff346b553 R09: fffffbfff346b553
      R10: 0000000000000001 R11: fffffbfff346b552 R12: ffffffffc0824940
      R13: ffff888109e83800 R14: 00000000ffffffff R15: ffffffffc08249e0
      FS:  00007f5042287680(0000) GS:ffff888119800000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000055ae1f4dbd90 CR3: 0000000006760002 CR4: 00000000003706e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ? rcu_read_lock_bh_held+0xa0/0xa0
       dsmark_reset+0x3d/0xf0 [sch_dsmark]
       qdisc_reset+0xa9/0x680
       qdisc_destroy+0x84/0x370
       qdisc_create_dflt+0x1fe/0x380
       attach_one_default_qdisc.constprop.41+0xa4/0x180
       dev_activate+0x4d5/0x8c0
       ? __dev_open+0x268/0x390
       __dev_open+0x270/0x390
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b76eade
    • Aditya Srivastava's avatar
      NFC: nfcmrvl: fix kernel-doc syntax in file headers · 4dd649d1
      Aditya Srivastava authored
      The opening comment mark '/**' is used for highlighting the beginning of
      kernel-doc comments.
      The header for drivers/nfc/nfcmrvl follows this syntax, but the content
      inside does not comply with kernel-doc.
      
      This line was probably not meant for kernel-doc parsing, but is parsed
      due to the presence of kernel-doc like comment syntax(i.e, '/**'), which
      causes unexpected warnings from kernel-doc.
      For e.g., running scripts/kernel-doc -none on drivers/nfc/nfcmrvl/spi.c
      causes warning:
      warning: expecting prototype for Marvell NFC(). Prototype was for SPI_WAIT_HANDSHAKE() instead
      
      Provide a simple fix by replacing such occurrences with general comment
      format, i.e. '/*', to prevent kernel-doc from parsing it.
      Signed-off-by: default avatarAditya Srivastava <yashsri421@gmail.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4dd649d1
    • DENG Qingfang's avatar
      net: dsa: mt7530: fix VLAN traffic leaks · 474a2dda
      DENG Qingfang authored
      PCR_MATRIX field was set to all 1's when VLAN filtering is enabled, but
      was not reset when it is disabled, which may cause traffic leaks:
      
      	ip link add br0 type bridge vlan_filtering 1
      	ip link add br1 type bridge vlan_filtering 1
      	ip link set swp0 master br0
      	ip link set swp1 master br1
      	ip link set br0 type bridge vlan_filtering 0
      	ip link set br1 type bridge vlan_filtering 0
      	# traffic in br0 and br1 will start leaking to each other
      
      As port_bridge_{add,del} have set up PCR_MATRIX properly, remove the
      PCR_MATRIX write from mt7530_port_set_vlan_aware.
      
      Fixes: 83163f7d ("net: dsa: mediatek: add VLAN support for MT7530")
      Signed-off-by: default avatarDENG Qingfang <dqfext@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      474a2dda
    • David S. Miller's avatar
      Merge branch 'fq_pie-fixes' · 835744e8
      David S. Miller authored
      Davide Caratti says:
      
      ====================
      two fixes for the fq_pie scheduler
      
      - patch 1/2 restores the possibility to use 65536 flows with fq_pie,
        preserving the fix for an endless loop in the control plane
      - patch 2/2 fixes an OOB access that can be observed in the traffic
        path of fq_pie scheduler, when the classification selects a flow
        beyond the allocated space.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      835744e8
    • Davide Caratti's avatar
      net/sched: fq_pie: fix OOB access in the traffic path · e70f7a11
      Davide Caratti authored
      the following script:
      
        # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2
        # tc qdisc add dev eth0 clsact
        # tc filter add dev eth0 egress matchall action skbedit priority 0x10002
        # ping 192.0.2.2 -I eth0 -c2 -w1 -q
      
      produces the following splat:
      
       BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
       Read of size 4 at addr ffff888171306924 by task ping/942
      
       CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ #441
       Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
       Call Trace:
        dump_stack+0x92/0xc1
        print_address_description.constprop.7+0x1a/0x150
        kasan_report.cold.13+0x7f/0x111
        fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
        __dev_queue_xmit+0x1034/0x2b10
        ip_finish_output2+0xc62/0x2120
        __ip_finish_output+0x553/0xea0
        ip_output+0x1ca/0x4d0
        ip_send_skb+0x37/0xa0
        raw_sendmsg+0x1c4b/0x2d00
        sock_sendmsg+0xdb/0x110
        __sys_sendto+0x1d7/0x2b0
        __x64_sys_sendto+0xdd/0x1b0
        do_syscall_64+0x3c/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xae
       RIP: 0033:0x7fe69735c3eb
       Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89
       RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
       RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb
       RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003
       RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010
       R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260
       R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0
      
       Allocated by task 917:
        kasan_save_stack+0x19/0x40
        __kasan_kmalloc+0x7f/0xa0
        __kmalloc_node+0x139/0x280
        fq_pie_init+0x555/0x8e8 [sch_fq_pie]
        qdisc_create+0x407/0x11b0
        tc_modify_qdisc+0x3c2/0x17e0
        rtnetlink_rcv_msg+0x346/0x8e0
        netlink_rcv_skb+0x120/0x380
        netlink_unicast+0x439/0x630
        netlink_sendmsg+0x719/0xbf0
        sock_sendmsg+0xe2/0x110
        ____sys_sendmsg+0x5ba/0x890
        ___sys_sendmsg+0xe9/0x160
        __sys_sendmsg+0xd3/0x170
        do_syscall_64+0x3c/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xae
      
       The buggy address belongs to the object at ffff888171306800
        which belongs to the cache kmalloc-256 of size 256
       The buggy address is located 36 bytes to the right of
        256-byte region [ffff888171306800, ffff888171306900)
       The buggy address belongs to the page:
       page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306
       head:00000000bcfb624e order:1 compound_mapcount:0
       flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
       raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40
       raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
       page dumped because: kasan: bad access detected
      
       Memory state around the buggy address:
        ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
       >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                      ^
        ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a
      valid flow: it's an address beyond the allocated memory.
      
      Fixes: ec97ecf1 ("net: sched: add Flow Queue PIE packet scheduler")
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e70f7a11
    • Davide Caratti's avatar
      net/sched: fq_pie: re-factor fix for fq_pie endless loop · 3a62fed2
      Davide Caratti authored
      the patch that fixed an endless loop in_fq_pie_init() was not considering
      that 65535 is a valid class id. The correct bugfix for this infinite loop
      is to change 'idx' to become an u32, like Colin proposed in the past [1].
      
      Fix this as follows:
       - restore 65536 as maximum possible values of 'flows_cnt'
       - use u32 'idx' when iterating on 'q->flows'
       - fix the TDC selftest
      
      This reverts commit bb2f930d.
      
      [1] https://lore.kernel.org/netdev/20210407163808.499027-1-colin.king@canonical.com/
      
      CC: Colin Ian King <colin.king@canonical.com>
      CC: stable@vger.kernel.org
      Fixes: bb2f930d ("net/sched: fix infinite loop in sch_fq_pie")
      Fixes: ec97ecf1 ("net: sched: add Flow Queue PIE packet scheduler")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a62fed2
  3. 23 May, 2021 1 commit