1. 02 Jan, 2023 2 commits
    • Jozsef Kadlecsik's avatar
      netfilter: ipset: Rework long task execution when adding/deleting entries · 5e29dc36
      Jozsef Kadlecsik authored
      When adding/deleting large number of elements in one step in ipset, it can
      take a reasonable amount of time and can result in soft lockup errors. The
      patch 5f7b51bf ("netfilter: ipset: Limit the maximal range of
      consecutive elements to add/delete") tried to fix it by limiting the max
      elements to process at all. However it was not enough, it is still possible
      that we get hung tasks. Lowering the limit is not reasonable, so the
      approach in this patch is as follows: rely on the method used at resizing
      sets and save the state when we reach a smaller internal batch limit,
      unlock/lock and proceed from the saved state. Thus we can avoid long
      continuous tasks and at the same time removed the limit to add/delete large
      number of elements in one step.
      
      The nfnl mutex is held during the whole operation which prevents one to
      issue other ipset commands in parallel.
      
      Fixes: 5f7b51bf ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete")
      Reported-by: syzbot+9204e7399656300bf271@syzkaller.appspotmail.com
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@netfilter.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      5e29dc36
    • Jozsef Kadlecsik's avatar
      netfilter: ipset: fix hash:net,port,net hang with /0 subnet · a31d47be
      Jozsef Kadlecsik authored
      The hash:net,port,net set type supports /0 subnets. However, the patch
      commit 5f7b51bf titled "netfilter: ipset: Limit the maximal range
      of consecutive elements to add/delete" did not take into account it and
      resulted in an endless loop. The bug is actually older but the patch
      5f7b51bf brings it out earlier.
      
      Handle /0 subnets properly in hash:net,port,net set types.
      
      Fixes: 5f7b51bf ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete")
      Reported-by: default avatarМарк Коренберг <socketpair@gmail.com>
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@netfilter.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      a31d47be
  2. 22 Dec, 2022 1 commit
  3. 21 Dec, 2022 4 commits
  4. 20 Dec, 2022 8 commits
  5. 19 Dec, 2022 19 commits
  6. 18 Dec, 2022 1 commit
    • David S. Miller's avatar
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue · 89529367
      David S. Miller authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2022-12-15 (igc)
      
      Muhammad Husaini Zulkifli says:
      
      This patch series fixes bugs for the Time-Sensitive Networking(TSN)
      Qbv Scheduling features.
      
      An overview of each patch series is given below:
      
      Patch 1: Using a first flag bit to schedule a packet to the next cycle if
      packet cannot fit in current Qbv cycle.
      Patch 2: Enable strict cycle for Qbv scheduling.
      Patch 3: Prevent user to set basetime less than zero during tc config.
      Patch 4: Allow the basetime enrollment with zero value.
      Patch 5: Calculate the new end time value to exclude the time interval that
      exceed the cycle time as user can specify the cycle time in tc config.
      Patch 6: Resolve the HW bugs where the gate is not fully closed.
      ---
      This contains the net patches from this original pull request:
      https://lore.kernel.org/netdev/20221205212414.3197525-1-anthony.l.nguyen@intel.com/
      
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89529367
  7. 17 Dec, 2022 3 commits
  8. 16 Dec, 2022 2 commits
    • Jakub Kicinski's avatar
      Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 13e3c779
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2022-12-16
      
      We've added 7 non-merge commits during the last 2 day(s) which contain
      a total of 9 files changed, 119 insertions(+), 36 deletions(-).
      
      1) Fix for recent syzkaller XDP dispatcher update splat, from Jiri Olsa.
      
      2) Fix BPF program refcount leak in LSM attachment failure path,
         from Milan Landaverde.
      
      3) Fix BPF program type in map compatibility check for fext,
         from Toke Høiland-Jørgensen.
      
      4) Fix a BPF selftest compilation error under !CONFIG_SMP config,
         from Yonghong Song.
      
      5) Fix CI to enable CONFIG_FUNCTION_ERROR_INJECTION after it got changed
         to a prompt, from Song Liu.
      
      6) Various BPF documentation fixes for socket local storage,
         from Donald Hunter.
      
      * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
        selftests/bpf: Add a test for using a cpumap from an freplace-to-XDP program
        bpf: Resolve fext program type when checking map compatibility
        bpf: Synchronize dispatcher update with bpf_dispatcher_xdp_func
        bpf: prevent leak of lsm program after failed attach
        selftests/bpf: Select CONFIG_FUNCTION_ERROR_INJECTION
        selftests/bpf: Fix a selftest compilation error with CONFIG_SMP=n
        docs/bpf: Reword docs for BPF_MAP_TYPE_SK_STORAGE
      ====================
      
      Link: https://lore.kernel.org/r/20221216174540.16598-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      13e3c779
    • Eelco Chaudron's avatar
      openvswitch: Fix flow lookup to use unmasked key · 68bb1010
      Eelco Chaudron authored
      The commit mentioned below causes the ovs_flow_tbl_lookup() function
      to be called with the masked key. However, it's supposed to be called
      with the unmasked key. This due to the fact that the datapath supports
      installing wider flows, and OVS relies on this behavior. For example
      if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
      flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
      128.0.0.0) is allowed to be added.
      
      However, if we try to add a wildcard rule, the installation fails:
      
      $ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
        ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
      $ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
        ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
      ovs-vswitchd: updating flow table (File exists)
      
      The reason is that the key used to determine if the flow is already
      present in the system uses the original key ANDed with the mask.
      This results in the IP address not being part of the (miniflow) key,
      i.e., being substituted with an all-zero value. When doing the actual
      lookup, this results in the key wrongfully matching the first flow,
      and therefore the flow does not get installed.
      
      This change reverses the commit below, but rather than having the key
      on the stack, it's allocated.
      
      Fixes: 190aa3e7 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
      Signed-off-by: default avatarEelco Chaudron <echaudro@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68bb1010