Skip to content
  1. Mar 11, 2022
  2. Mar 10, 2022
    • Jakub Kicinski's avatar
      Merge branch 'selftests-pmtu-sh-fix-cleanup-of-processes-launched-in-subshell' · 5f147476
      Jakub Kicinski authored
      Guillaume Nault says:
      
      ====================
      selftests: pmtu.sh: Fix cleanup of processes launched in subshell.
      
      Depending on the options used, pmtu.sh may launch tcpdump and nettest
      processes in the background. However it fails to clean them up after
      the tests complete.
      
      Patch 1 allows the cleanup() function to read the list of PIDs launched
      by the tests.
      Patch 2 fixes the way the nettest PIDs are retrieved.
      ====================
      
      Link: https://lore.kernel.org/r/cover.1646776561.git.gnault@redhat.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5f147476
    • Guillaume Nault's avatar
      selftests: pmtu.sh: Kill nettest processes launched in subshell. · 94a4a4fe
      Guillaume Nault authored
      When using "run_cmd <command> &", then "$!" refers to the PID of the
      subshell used to run <command>, not the command itself. Therefore
      nettest_pids actually doesn't contain the list of the nettest commands
      running in the background. So cleanup() can't kill them and the nettest
      processes run until completion (fortunately they have a 5s timeout).
      
      Fix this by defining a new command for running processes in the
      background, for which "$!" really refers to the PID of the command run.
      
      Also, double quote variables on the modified lines, to avoid shellcheck
      warnings.
      
      Fixes: ece1278a
      
       ("selftests: net: add ESP-in-UDP PMTU test")
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Reviewed-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      94a4a4fe
    • Guillaume Nault's avatar
      selftests: pmtu.sh: Kill tcpdump processes launched by subshell. · 18dfc667
      Guillaume Nault authored
      The cleanup() function takes care of killing processes launched by the
      test functions. It relies on variables like ${tcpdump_pids} to get the
      relevant PIDs. But tests are run in their own subshell, so updated
      *_pids values are invisible to other shells. Therefore cleanup() never
      sees any process to kill:
      
      $ ./tools/testing/selftests/net/pmtu.sh -t pmtu_ipv4_exception
      TEST: ipv4: PMTU exceptions                                         [ OK ]
      TEST: ipv4: PMTU exceptions - nexthop objects                       [ OK ]
      
      $ pgrep -af tcpdump
      6084 tcpdump -s 0 -i veth_A-R1 -w pmtu_ipv4_exception_veth_A-R1.pcap
      6085 tcpdump -s 0 -i veth_R1-A -w pmtu_ipv4_exception_veth_R1-A.pcap
      6086 tcpdump -s 0 -i veth_R1-B -w pmtu_ipv4_exception_veth_R1-B.pcap
      6087 tcpdump -s 0 -i veth_B-R1 -w pmtu_ipv4_exception_veth_B-R1.pcap
      6088 tcpdump -s 0 -i veth_A-R2 -w pmtu_ipv4_exception_veth_A-R2.pcap
      6089 tcpdump -s 0 -i veth_R2-A -w pmtu_ipv4_exception_veth_R2-A.pcap
      6090 tcpdump -s 0 -i veth_R2-B -w pmtu_ipv4_exception_veth_R2-B.pcap
      6091 tcpdump -s 0 -i veth_B-R2 -w pmtu_ipv4_exception_veth_B-R2.pcap
      6228 tcpdump -s 0 -i veth_A-R1 -w pmtu_ipv4_exception_veth_A-R1.pcap
      6229 tcpdump -s 0 -i veth_R1-A -w pmtu_ipv4_exception_veth_R1-A.pcap
      6230 tcpdump -s 0 -i veth_R1-B -w pmtu_ipv4_exception_veth_R1-B.pcap
      6231 tcpdump -s 0 -i veth_B-R1 -w pmtu_ipv4_exception_veth_B-R1.pcap
      6232 tcpdump -s 0 -i veth_A-R2 -w pmtu_ipv4_exception_veth_A-R2.pcap
      6233 tcpdump -s 0 -i veth_R2-A -w pmtu_ipv4_exception_veth_R2-A.pcap
      6234 tcpdump -s 0 -i veth_R2-B -w pmtu_ipv4_exception_veth_R2-B.pcap
      6235 tcpdump -s 0 -i veth_B-R2 -w pmtu_ipv4_exception_veth_B-R2.pcap
      
      Fix this by running cleanup() in the context of the test subshell.
      Now that each test cleans the environment after completion, there's no
      need for calling cleanup() again when the next test starts. So let's
      drop it from the setup() function. This is okay because cleanup() is
      also called when pmtu.sh starts, so even the first test starts in a
      clean environment.
      
      Also, use tcpdump's immediate mode. Otherwise it might not have time to
      process buffered packets, resulting in missing packets or even empty
      pcap files for short tests.
      
      Note: PAUSE_ON_FAIL is still evaluated before cleanup(), so one can
      still inspect the test environment upon failure when using -p.
      
      Fixes: a92a0a7b
      
       ("selftests: pmtu: Simplify cleanup and namespace names")
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Reviewed-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      18dfc667
    • Pavel Skripkin's avatar
      NFC: port100: fix use-after-free in port100_send_complete · f80cfe2f
      Pavel Skripkin authored
      
      
      Syzbot reported UAF in port100_send_complete(). The root case is in
      missing usb_kill_urb() calls on error handling path of ->probe function.
      
      port100_send_complete() accesses devm allocated memory which will be
      freed on probe failure. We should kill this urbs before returning an
      error from probe function to prevent reported use-after-free
      
      Fail log:
      
      BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
      Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26
      ...
      Call Trace:
       <TASK>
       __dump_stack lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
       print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
       __kasan_report mm/kasan/report.c:442 [inline]
       kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
       port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
       __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670
      
      ...
      
      Allocated by task 1255:
       kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
       kasan_set_track mm/kasan/common.c:45 [inline]
       set_alloc_info mm/kasan/common.c:436 [inline]
       ____kasan_kmalloc mm/kasan/common.c:515 [inline]
       ____kasan_kmalloc mm/kasan/common.c:474 [inline]
       __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
       alloc_dr drivers/base/devres.c:116 [inline]
       devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823
       devm_kzalloc include/linux/device.h:209 [inline]
       port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502
      
      Freed by task 1255:
       kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
       kasan_set_track+0x21/0x30 mm/kasan/common.c:45
       kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
       ____kasan_slab_free mm/kasan/common.c:366 [inline]
       ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328
       kasan_slab_free include/linux/kasan.h:236 [inline]
       __cache_free mm/slab.c:3437 [inline]
       kfree+0xf8/0x2b0 mm/slab.c:3794
       release_nodes+0x112/0x1a0 drivers/base/devres.c:501
       devres_release_all+0x114/0x190 drivers/base/devres.c:530
       really_probe+0x626/0xcc0 drivers/base/dd.c:670
      
      Reported-and-tested-by: default avatar <syzbot+16bcb127fb73baeecb14@syzkaller.appspotmail.com>
      Fixes: 0347a6ab
      
       ("NFC: port100: Commands mechanism implementation")
      Signed-off-by: default avatarPavel Skripkin <paskripkin@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Link: https://lore.kernel.org/r/20220308185007.6987-1-paskripkin@gmail.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f80cfe2f
    • Ben Ben-Ishay's avatar
      net/mlx5e: SHAMPO, reduce TIR indication · 99a2b9be
      Ben Ben-Ishay authored
      SHAMPO is an RQ / WQ feature, an indication was added to the TIR in the
      first place to enforce suitability between connected TIR and RQ, this
      enforcement does not exist in current the Firmware implementation and was
      redundant in the first place.
      
      Fixes: 83439f3c
      
       ("net/mlx5e: Add HW-GRO offload")
      Signed-off-by: default avatarBen Ben-Ishay <benishay@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      99a2b9be
    • Roi Dayan's avatar
      net/mlx5e: Lag, Only handle events from highest priority multipath entry · ad11c4f1
      Roi Dayan authored
      There could be multiple multipath entries but changing the port affinity
      for each one doesn't make much sense and there should be a default one.
      So only track the entry with lowest priority value.
      The commit doesn't affect existing users with a single entry.
      
      Fixes: 544fe7c2
      
       ("net/mlx5e: Activate HW multipath and handle port affinity based on FIB events")
      Signed-off-by: default avatarRoi Dayan <roid@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      ad11c4f1
    • Dima Chumak's avatar
      net/mlx5: Fix offloading with ESWITCH_IPV4_TTL_MODIFY_ENABLE · 39bab83b
      Dima Chumak authored
      Only prio 1 is supported for nic mode when there is no ignore flow level
      support in firmware. But for switchdev mode, which supports fixed number
      of statically pre-allocated prios, this restriction is not relevant so
      it can be relaxed.
      
      Fixes: d671e109
      
       ("net/mlx5: Fix tc max supported prio for nic mode")
      Signed-off-by: default avatarDima Chumak <dchumak@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      39bab83b
    • Moshe Shemesh's avatar
      net/mlx5: Fix a race on command flush flow · 063bd355
      Moshe Shemesh authored
      Fix a refcount use after free warning due to a race on command entry.
      Such race occurs when one of the commands releases its last refcount and
      frees its index and entry while another process running command flush
      flow takes refcount to this command entry. The process which handles
      commands flush may see this command as needed to be flushed if the other
      process released its refcount but didn't release the index yet. Fix it
      by adding the needed spin lock.
      
      It fixes the following warning trace:
      
      refcount_t: addition on 0; use-after-free.
      WARNING: CPU: 11 PID: 540311 at lib/refcount.c:25 refcount_warn_saturate+0x80/0xe0
      ...
      RIP: 0010:refcount_warn_saturate+0x80/0xe0
      ...
      Call Trace:
       <TASK>
       mlx5_cmd_trigger_completions+0x293/0x340 [mlx5_core]
       mlx5_cmd_flush+0x3a/0xf0 [mlx5_core]
       enter_error_state+0x44/0x80 [mlx5_core]
       mlx5_fw_fatal_reporter_err_work+0x37/0xe0 [mlx5_core]
       process_one_work+0x1be/0x390
       worker_thread+0x4d/0x3d0
       ? rescuer_thread+0x350/0x350
       kthread+0x141/0x160
       ? set_kthread_struct+0x40/0x40
       ret_from_fork+0x1f/0x30
       </TASK>
      
      Fixes: 50b2412b
      
       ("net/mlx5: Avoid possible free of command entry while timeout comp handler")
      Signed-off-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Reviewed-by: default avatarEran Ben Elisha <eranbe@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      063bd355
    • Mohammad Kabat's avatar
      net/mlx5: Fix size field in bufferx_reg struct · ac77998b
      Mohammad Kabat authored
      According to HW spec the field "size" should be 16 bits
      in bufferx register.
      
      Fixes: e281682b
      
       ("net/mlx5_core: HW data structs/types definitions cleanup")
      Signed-off-by: default avatarMohammad Kabat <mohammadkab@nvidia.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      ac77998b
  3. Mar 09, 2022
  4. Mar 08, 2022
  5. Mar 07, 2022
  6. Mar 06, 2022