1. 06 May, 2022 1 commit
    • Fabio Estevam's avatar
      net: phy: micrel: Do not use kszphy_suspend/resume for KSZ8061 · e333eed6
      Fabio Estevam authored
      Since commit f1131b9c ("net: phy: micrel: use
      kszphy_suspend()/kszphy_resume for irq aware devices") the following
      NULL pointer dereference is observed on a board with KSZ8061:
      
       # udhcpc -i eth0
      udhcpc: started, v1.35.0
      8<--- cut here ---
      Unable to handle kernel NULL pointer dereference at virtual address 00000008
      pgd = f73cef4e
      [00000008] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP ARM
      Modules linked in:
      CPU: 0 PID: 196 Comm: ifconfig Not tainted 5.15.37-dirty #94
      Hardware name: Freescale i.MX6 SoloX (Device Tree)
      PC is at kszphy_config_reset+0x10/0x114
      LR is at kszphy_resume+0x24/0x64
      ...
      
      The KSZ8061 phy_driver structure does not have the .probe/..driver_data
      fields, which means that priv is not allocated.
      
      This causes the NULL pointer dereference inside kszphy_config_reset().
      
      Fix the problem by using the generic suspend/resume functions as before.
      
      Another alternative would be to provide the .probe and .driver_data
      information into the structure, but to be on the safe side, let's
      just restore Ethernet functionality by using the generic suspend/resume.
      
      Cc: stable@vger.kernel.org
      Fixes: f1131b9c ("net: phy: micrel: use kszphy_suspend()/kszphy_resume for irq aware devices")
      Signed-off-by: default avatarFabio Estevam <festevam@denx.de>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20220504143104.1286960-1-festevam@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e333eed6
  2. 05 May, 2022 19 commits
    • Tetsuo Handa's avatar
      net: rds: use maybe_get_net() when acquiring refcount on TCP sockets · 6997fbd7
      Tetsuo Handa authored
      Eric Dumazet is reporting addition on 0 problem at rds_tcp_tune(), for
      delayed works queued in rds_wq might be invoked after a net namespace's
      refcount already reached 0.
      
      Since rds_tcp_exit_net() from cleanup_net() calls flush_workqueue(rds_wq),
      it is guaranteed that we can instead use maybe_get_net() from delayed work
      functions until rds_tcp_exit_net() returns.
      
      Note that I'm not convinced that all works which might access a net
      namespace are already queued in rds_wq by the moment rds_tcp_exit_net()
      calls flush_workqueue(rds_wq). If some race is there, rds_tcp_exit_net()
      will fail to wait for work functions, and kmem_cache_free() could be
      called from net_free() before maybe_get_net() is called from
      rds_tcp_tune().
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Fixes: 3a58f13a ("net: rds: acquire refcount on TCP sockets")
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/41d09faf-bc78-1a87-dfd1-c6d1b5984b61@I-love.SAKURA.ne.jpSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6997fbd7
    • Linus Torvalds's avatar
      Merge tag 'net-5.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 68533eb1
      Linus Torvalds authored
      Pull networking fixes from Paolo Abeni:
       "Including fixes from can, rxrpc and wireguard.
      
        Previous releases - regressions:
      
         - igmp: respect RCU rules in ip_mc_source() and ip_mc_msfilter()
      
         - mld: respect RCU rules in ip6_mc_source() and ip6_mc_msfilter()
      
         - rds: acquire netns refcount on TCP sockets
      
         - rxrpc: enable IPv6 checksums on transport socket
      
         - nic: hinic: fix bug of wq out of bound access
      
         - nic: thunder: don't use pci_irq_vector() in atomic context
      
         - nic: bnxt_en: fix possible bnxt_open() failure caused by wrong RFS
           flag
      
         - nic: mlx5e:
            - lag, fix use-after-free in fib event handler
            - fix deadlock in sync reset flow
      
        Previous releases - always broken:
      
         - tcp: fix insufficient TCP source port randomness
      
         - can: grcan: grcan_close(): fix deadlock
      
         - nfc: reorder destructive operations in to avoid bugs
      
        Misc:
      
         - wireguard: improve selftests reliability"
      
      * tag 'net-5.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (63 commits)
        NFC: netlink: fix sleep in atomic bug when firmware download timeout
        selftests: ocelot: tc_flower_chains: specify conform-exceed action for policer
        tcp: drop the hash_32() part from the index calculation
        tcp: increase source port perturb table to 2^16
        tcp: dynamically allocate the perturb table used by source ports
        tcp: add small random increments to the source port
        tcp: resalt the secret every 10 seconds
        tcp: use different parts of the port_offset for index and offset
        secure_seq: use the 64 bits of the siphash for port offset calculation
        wireguard: selftests: set panic_on_warn=1 from cmdline
        wireguard: selftests: bump package deps
        wireguard: selftests: restore support for ccache
        wireguard: selftests: use newer toolchains to fill out architectures
        wireguard: selftests: limit parallelism to $(nproc) tests at once
        wireguard: selftests: make routing loop test non-fatal
        net/mlx5: Fix matching on inner TTC
        net/mlx5: Avoid double clear or set of sync reset requested
        net/mlx5: Fix deadlock in sync reset flow
        net/mlx5e: Fix trust state reset in reload
        net/mlx5e: Avoid checking offload capability in post_parse action
        ...
      68533eb1
    • Duoming Zhou's avatar
      NFC: netlink: fix sleep in atomic bug when firmware download timeout · 4071bf12
      Duoming Zhou authored
      There are sleep in atomic bug that could cause kernel panic during
      firmware download process. The root cause is that nlmsg_new with
      GFP_KERNEL parameter is called in fw_dnld_timeout which is a timer
      handler. The call trace is shown below:
      
      BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265
      Call Trace:
      kmem_cache_alloc_node
      __alloc_skb
      nfc_genl_fw_download_done
      call_timer_fn
      __run_timers.part.0
      run_timer_softirq
      __do_softirq
      ...
      
      The nlmsg_new with GFP_KERNEL parameter may sleep during memory
      allocation process, and the timer handler is run as the result of
      a "software interrupt" that should not call any other function
      that could sleep.
      
      This patch changes allocation mode of netlink message from GFP_KERNEL
      to GFP_ATOMIC in order to prevent sleep in atomic bug. The GFP_ATOMIC
      flag makes memory allocation operation could be used in atomic context.
      
      Fixes: 9674da87 ("NFC: Add firmware upload netlink command")
      Fixes: 9ea7187c ("NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD")
      Signed-off-by: default avatarDuoming Zhou <duoming@zju.edu.cn>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Link: https://lore.kernel.org/r/20220504055847.38026-1-duoming@zju.edu.cnSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      4071bf12
    • Vladimir Oltean's avatar
      selftests: ocelot: tc_flower_chains: specify conform-exceed action for policer · 5a7c5f70
      Vladimir Oltean authored
      As discussed here with Ido Schimmel:
      https://patchwork.kernel.org/project/netdevbpf/patch/20220224102908.5255-2-jianbol@nvidia.com/
      
      the default conform-exceed action is "reclassify", for a reason we don't
      really understand.
      
      The point is that hardware can't offload that police action, so not
      specifying "conform-exceed" was always wrong, even though the command
      used to work in hardware (but not in software) until the kernel started
      adding validation for it.
      
      Fix the command used by the selftest by making the policer drop on
      exceed, and pass the packet to the next action (goto) on conform.
      
      Fixes: 8cd6b020 ("selftests: ocelot: add some example VCAP IS1, IS2 and ES0 tc offloads")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Link: https://lore.kernel.org/r/20220503121428.842906-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5a7c5f70
    • Jakub Kicinski's avatar
      Merge branch 'insufficient-tcp-source-port-randomness' · ef562489
      Jakub Kicinski authored
      Willy Tarreau says:
      
      ====================
      insufficient TCP source port randomness
      
      In a not-yet published paper, Moshe Kol, Amit Klein, and Yossi Gilad
      report being able to accurately identify a client by forcing it to emit
      only 40 times more connections than the number of entries in the
      table_perturb[] table, which is indexed by hashing the connection tuple.
      The current 2^8 setting allows them to perform that attack with only 10k
      connections, which is not hard to achieve in a few seconds.
      
      Eric, Amit and I have been working on this for a few weeks now imagining,
      testing and eliminating a number of approaches that Amit and his team were
      still able to break or that were found to be too risky or too expensive,
      and ended up with the simple improvements in this series that resists to
      the attack, doesn't degrade the performance, and preserves a reliable port
      selection algorithm to avoid connection failures, including the odd/even
      port selection preference that allows bind() to always find a port quickly
      even under strong connect() stress.
      
      The approach relies on several factors:
        - resalting the hash secret that's used to choose the table_perturb[]
          entry every 10 seconds to eliminate slow attacks and force the
          attacker to forget everything that was learned after this delay.
          This already eliminates most of the problem because if a client
          stays silent for more than 10 seconds there's no link between the
          previous and the next patterns, and 10s isn't yet frequent enough
          to cause too frequent repetition of a same port that may induce a
          connection failure ;
      
        - adding small random increments to the source port. Previously, a
          random 0 or 1 was added every 16 ports. Now a random 0 to 7 is
          added after each port. This means that with the default 32768-60999
          range, a worst case rollover happens after 1764 connections, and
          an average of 3137. This doesn't stop statistical attacks but
          requires significantly more iterations of the same attack to
          confirm a guess.
      
        - increasing the table_perturb[] size from 2^8 to 2^16, which Amit
          says will require 2.6 million connections to be attacked with the
          changes above, making it pointless to get a fingerprint that will
          only last 10 seconds. Due to the size, the table was made dynamic.
      
        - a few minor improvements on the bits used from the hash, to eliminate
          some unfortunate correlations that may possibly have been exploited
          to design future attack models.
      
      These changes were tested under the most extreme conditions, up to
      1.1 million connections per second to one and a few targets, showing no
      performance regression, and only 2 connection failures within 13 billion,
      which is less than 2^-32 and perfectly within usual values.
      
      The series is split into small reviewable changes and was already reviewed
      by Amit and Eric.
      ====================
      
      Link: https://lore.kernel.org/r/20220502084614.24123-1-w@1wt.euSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ef562489
    • Willy Tarreau's avatar
      tcp: drop the hash_32() part from the index calculation · e8161345
      Willy Tarreau authored
      In commit 190cc824 ("tcp: change source port randomizarion at
      connect() time"), the table_perturb[] array was introduced and an
      index was taken from the port_offset via hash_32(). But it turns
      out that hash_32() performs a multiplication while the input here
      comes from the output of SipHash in secure_seq, that is well
      distributed enough to avoid the need for yet another hash.
      Suggested-by: default avatarAmit Klein <aksecurity@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e8161345
    • Willy Tarreau's avatar
      tcp: increase source port perturb table to 2^16 · 4c2c8f03
      Willy Tarreau authored
      Moshe Kol, Amit Klein, and Yossi Gilad reported being able to accurately
      identify a client by forcing it to emit only 40 times more connections
      than there are entries in the table_perturb[] table. The previous two
      improvements consisting in resalting the secret every 10s and adding
      randomness to each port selection only slightly improved the situation,
      and the current value of 2^8 was too small as it's not very difficult
      to make a client emit 10k connections in less than 10 seconds.
      
      Thus we're increasing the perturb table from 2^8 to 2^16 so that the
      same precision now requires 2.6M connections, which is more difficult in
      this time frame and harder to hide as a background activity. The impact
      is that the table now uses 256 kB instead of 1 kB, which could mostly
      affect devices making frequent outgoing connections. However such
      components usually target a small set of destinations (load balancers,
      database clients, perf assessment tools), and in practice only a few
      entries will be visited, like before.
      
      A live test at 1 million connections per second showed no performance
      difference from the previous value.
      Reported-by: default avatarMoshe Kol <moshe.kol@mail.huji.ac.il>
      Reported-by: default avatarYossi Gilad <yossi.gilad@mail.huji.ac.il>
      Reported-by: default avatarAmit Klein <aksecurity@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4c2c8f03
    • Willy Tarreau's avatar
      tcp: dynamically allocate the perturb table used by source ports · e9261476
      Willy Tarreau authored
      We'll need to further increase the size of this table and it's likely
      that at some point its size will not be suitable anymore for a static
      table. Let's allocate it on boot from inet_hashinfo2_init(), which is
      called from tcp_init().
      
      Cc: Moshe Kol <moshe.kol@mail.huji.ac.il>
      Cc: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
      Cc: Amit Klein <aksecurity@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e9261476
    • Willy Tarreau's avatar
      tcp: add small random increments to the source port · ca7af040
      Willy Tarreau authored
      Here we're randomly adding between 0 and 7 random increments to the
      selected source port in order to add some noise in the source port
      selection that will make the next port less predictable.
      
      With the default port range of 32768-60999 this means a worst case
      reuse scenario of 14116/8=1764 connections between two consecutive
      uses of the same port, with an average of 14116/4.5=3137. This code
      was stressed at more than 800000 connections per second to a fixed
      target with all connections closed by the client using RSTs (worst
      condition) and only 2 connections failed among 13 billion, despite
      the hash being reseeded every 10 seconds, indicating a perfectly
      safe situation.
      
      Cc: Moshe Kol <moshe.kol@mail.huji.ac.il>
      Cc: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
      Cc: Amit Klein <aksecurity@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ca7af040
    • Eric Dumazet's avatar
      tcp: resalt the secret every 10 seconds · 4dfa9b43
      Eric Dumazet authored
      In order to limit the ability for an observer to recognize the source
      ports sequence used to contact a set of destinations, we should
      periodically shuffle the secret. 10 seconds looks effective enough
      without causing particular issues.
      
      Cc: Moshe Kol <moshe.kol@mail.huji.ac.il>
      Cc: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
      Cc: Amit Klein <aksecurity@gmail.com>
      Cc: Jason A. Donenfeld <Jason@zx2c4.com>
      Tested-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4dfa9b43
    • Willy Tarreau's avatar
      tcp: use different parts of the port_offset for index and offset · 9e9b70ae
      Willy Tarreau authored
      Amit Klein suggests that we use different parts of port_offset for the
      table's index and the port offset so that there is no direct relation
      between them.
      
      Cc: Jason A. Donenfeld <Jason@zx2c4.com>
      Cc: Moshe Kol <moshe.kol@mail.huji.ac.il>
      Cc: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
      Cc: Amit Klein <aksecurity@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9e9b70ae
    • Willy Tarreau's avatar
      secure_seq: use the 64 bits of the siphash for port offset calculation · b2d05756
      Willy Tarreau authored
      SipHash replaced MD5 in secure_ipv{4,6}_port_ephemeral() via commit
      7cd23e53 ("secure_seq: use SipHash in place of MD5"), but the output
      remained truncated to 32-bit only. In order to exploit more bits from the
      hash, let's make the functions return the full 64-bit of siphash_3u32().
      We also make sure the port offset calculation in __inet_hash_connect()
      remains done on 32-bit to avoid the need for div_u64_rem() and an extra
      cost on 32-bit systems.
      
      Cc: Jason A. Donenfeld <Jason@zx2c4.com>
      Cc: Moshe Kol <moshe.kol@mail.huji.ac.il>
      Cc: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
      Cc: Amit Klein <aksecurity@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b2d05756
    • Jakub Kicinski's avatar
      Merge branch 'wireguard-patches-for-5-18-rc6' · 205557ba
      Jakub Kicinski authored
      Jason A. Donenfeld says:
      
      ====================
      wireguard patches for 5.18-rc6
      
      In working on some other problems, I wound up leaning on the WireGuard
      CI more than usual and uncovered a few small issues with reliability.
      These are fairly low key changes, since they don't impact kernel code
      itself.
      
      One change does stick out in particular, though, which is the "make
      routing loop test non-fatal" commit. I'm not thrilled about doing this,
      but currently [1] remains unsolved, and I'm still working on a real
      solution to that (hopefully for 5.19 or 5.20 if I can come up with a
      good idea...), so for now that test just prints a big red warning
      instead.
      
      [1] https://lore.kernel.org/netdev/YmszSXueTxYOC41G@zx2c4.com/
      ====================
      
      Link: https://lore.kernel.org/r/20220504202920.72908-1-Jason@zx2c4.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      205557ba
    • Jason A. Donenfeld's avatar
      wireguard: selftests: set panic_on_warn=1 from cmdline · 3fc1b11e
      Jason A. Donenfeld authored
      Rather than setting this once init is running, set panic_on_warn from
      the kernel command line, so that it catches splats from WireGuard
      initialization code and the various crypto selftests.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3fc1b11e
    • Jason A. Donenfeld's avatar
      wireguard: selftests: bump package deps · a6b8ea91
      Jason A. Donenfeld authored
      Use newer, more reliable package dependencies. These should hopefully
      reduce flakes. However, we keep the old iputils package, as it
      accumulated bugs after resulting in flakes on slow machines.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a6b8ea91
    • Jason A. Donenfeld's avatar
      wireguard: selftests: restore support for ccache · d261ba6a
      Jason A. Donenfeld authored
      When moving to non-system toolchains, we inadvertantly killed the
      ability to use ccache. So instead, build ccache support into the test
      harness directly.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d261ba6a
    • Jason A. Donenfeld's avatar
      wireguard: selftests: use newer toolchains to fill out architectures · d5d9b29b
      Jason A. Donenfeld authored
      Rather than relying on the system to have cross toolchains available,
      simply download musl.cc's ones and use that libc.so, and then we use it
      to fill in a few missing platforms, such as riscv64, riscv64, powerpc64,
      and s390x.
      
      Since riscv doesn't have a second serial port in its device description,
      we have to use virtio's vport. This is actually the same situation on
      ARM, but we were previously hacking QEMU up to work around this, which
      required a custom QEMU. Instead just do the vport trick on ARM too.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d5d9b29b
    • Jason A. Donenfeld's avatar
      wireguard: selftests: limit parallelism to $(nproc) tests at once · 39f02bf1
      Jason A. Donenfeld authored
      The parallel tests were added to catch queueing issues from multiple
      cores. But what happens in reality when testing tons of processes is
      that these separate threads wind up fighting with the scheduler, and we
      wind up with contention in places we don't care about that decrease the
      chances of hitting a bug. So just do a test with the number of CPU
      cores, rather than trying to scale up arbitrarily.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      39f02bf1
    • Jason A. Donenfeld's avatar
      wireguard: selftests: make routing loop test non-fatal · ae2de669
      Jason A. Donenfeld authored
      I hate to do this, but I still do not have a good solution to actually
      fix this bug across architectures. So just disable it for now, so that
      the CI can still deliver actionable results. This commit adds a large
      red warning, so that at least the failure isn't lost forever, and
      hopefully this can be revisited down the line.
      
      Link: https://lore.kernel.org/netdev/CAHmME9pv1x6C4TNdL6648HydD8r+txpV4hTUXOBVkrapBXH4QQ@mail.gmail.com/
      Link: https://lore.kernel.org/netdev/YmszSXueTxYOC41G@zx2c4.com/
      Link: https://lore.kernel.org/wireguard/CAHmME9rNnBiNvBstb7MPwK-7AmAN0sOfnhdR=eeLrowWcKxaaQ@mail.gmail.com/Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ae2de669
  3. 04 May, 2022 20 commits
    • Linus Torvalds's avatar
      Merge tag 'iomm-fixes-v5.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · a7391ad3
      Linus Torvalds authored
      Pull iommu fixes from Joerg Roedel:
       "IOMMU core:
      
         - Fix for a regression which could cause NULL-ptr dereferences
      
        Arm SMMU:
      
         - Fix off-by-one in SMMUv3 SVA TLB invalidation
      
         - Disable large mappings to workaround nvidia erratum
      
        Intel VT-d:
      
         - Handle PCI stop marker messages in IOMMU driver to meet the
           requirement of I/O page fault handling framework.
      
         - Calculate a feasible mask for non-aligned page-selective IOTLB
           invalidation.
      
        Apple DART IOMMU:
      
         - Fix potential NULL-ptr dereference
      
         - Set module owner"
      
      * tag 'iomm-fixes-v5.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        iommu: Make sysfs robust for non-API groups
        iommu/dart: Add missing module owner to ops structure
        iommu/dart: check return value after calling platform_get_resource()
        iommu/vt-d: Drop stop marker messages
        iommu/vt-d: Calculate mask for non-aligned flushes
        iommu: arm-smmu: disable large page mappings for Nvidia arm-smmu
        iommu/arm-smmu-v3: Fix size calculation in arm_smmu_mm_invalidate_range()
      a7391ad3
    • Linus Torvalds's avatar
      Merge tag 'for-linus-5.17-2' of https://github.com/cminyard/linux-ipmi · 3118d7ab
      Linus Torvalds authored
      Pull IPMI fixes from Corey Minyard:
       "Fix some issues that were reported.
      
        This has been in for-next for a bit (longer than the times would
        indicate, I had to rebase to add some text to the headers) and these
        are fixes that need to go in"
      
      * tag 'for-linus-5.17-2' of https://github.com/cminyard/linux-ipmi:
        ipmi:ipmi_ipmb: Fix null-ptr-deref in ipmi_unregister_smi()
        ipmi: When handling send message responses, don't process the message
      3118d7ab
    • Robin Murphy's avatar
      iommu: Make sysfs robust for non-API groups · 392bf519
      Robin Murphy authored
      Groups created by VFIO backends outside the core IOMMU API should never
      be passed directly into the API itself, however they still expose their
      standard sysfs attributes, so we can still stumble across them that way.
      Take care to consider those cases before jumping into our normal
      assumptions of a fully-initialised core API group.
      
      Fixes: 3f6634d9 ("iommu: Use right way to retrieve iommu_ops")
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Tested-by: default avatarJan Stancek <jstancek@redhat.com>
      Reviewed-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Link: https://lore.kernel.org/r/86ada41986988511a8424e84746dfe9ba7f87573.1651667683.git.robin.murphy@arm.comSigned-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      392bf519
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2022-05-03' of git://git.kernel.org/pub/scm/linux/kernel/g · ad0724b9
      David S. Miller authored
      it/saeed/linux
      
      Saeed Mahameed says:
      
      ====================
      mlx5 fixes 2022-05-03
      
      This series provides bug fixes to mlx5 driver.
      Please pull and let me know if there is any problem.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad0724b9
    • Hector Martin's avatar
      iommu/dart: Add missing module owner to ops structure · 2ac2fab5
      Hector Martin authored
      This is required to make loading this as a module work.
      Signed-off-by: default avatarHector Martin <marcan@marcan.st>
      Fixes: 46d1fb07 ("iommu/dart: Add DART iommu driver")
      Reviewed-by: default avatarSven Peter <sven@svenpeter.dev>
      Link: https://lore.kernel.org/r/20220502092238.30486-1-marcan@marcan.stSigned-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      2ac2fab5
    • Mark Bloch's avatar
      net/mlx5: Fix matching on inner TTC · a042d7f5
      Mark Bloch authored
      The cited commits didn't use proper matching on inner TTC
      as a result distribution of encapsulated packets wasn't symmetric
      between the physical ports.
      
      Fixes: 4c71ce50 ("net/mlx5: Support partial TTC rules")
      Fixes: 8e25a2bc ("net/mlx5: Lag, add support to create TTC tables for LAG port selection")
      Signed-off-by: default avatarMark Bloch <mbloch@nvidia.com>
      Reviewed-by: default avatarMaor Gottlieb <maorg@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      a042d7f5
    • Moshe Shemesh's avatar
      net/mlx5: Avoid double clear or set of sync reset requested · fc3d3db0
      Moshe Shemesh authored
      Double clear of reset requested state can lead to NULL pointer as it
      will try to delete the timer twice. This can happen for example on a
      race between abort from FW and pci error or reset. Avoid such case using
      test_and_clear_bit() to verify only one time reset requested state clear
      flow. Similarly use test_and_set_bit() to verify only one time reset
      requested state set flow.
      
      Fixes: 7dd6df32 ("net/mlx5: Handle sync reset abort event")
      Signed-off-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Reviewed-by: default avatarMaher Sanalla <msanalla@nvidia.com>
      Reviewed-by: default avatarShay Drory <shayd@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      fc3d3db0
    • Moshe Shemesh's avatar
      net/mlx5: Fix deadlock in sync reset flow · cb7786a7
      Moshe Shemesh authored
      The sync reset flow can lead to the following deadlock when
      poll_sync_reset() is called by timer softirq and waiting on
      del_timer_sync() for the same timer. Fix that by moving the part of the
      flow that waits for the timer to reset_reload_work.
      
      It fixes the following kernel Trace:
      RIP: 0010:del_timer_sync+0x32/0x40
      ...
      Call Trace:
       <IRQ>
       mlx5_sync_reset_clear_reset_requested+0x26/0x50 [mlx5_core]
       poll_sync_reset.cold+0x36/0x52 [mlx5_core]
       call_timer_fn+0x32/0x130
       __run_timers.part.0+0x180/0x280
       ? tick_sched_handle+0x33/0x60
       ? tick_sched_timer+0x3d/0x80
       ? ktime_get+0x3e/0xa0
       run_timer_softirq+0x2a/0x50
       __do_softirq+0xe1/0x2d6
       ? hrtimer_interrupt+0x136/0x220
       irq_exit+0xae/0xb0
       smp_apic_timer_interrupt+0x7b/0x140
       apic_timer_interrupt+0xf/0x20
       </IRQ>
      
      Fixes: 3c5193a8 ("net/mlx5: Use del_timer_sync in fw reset flow of halting poll")
      Signed-off-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Reviewed-by: default avatarMaher Sanalla <msanalla@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      cb7786a7
    • Moshe Tal's avatar
      net/mlx5e: Fix trust state reset in reload · b781bff8
      Moshe Tal authored
      Setting dscp2prio during the driver reload can cause dcb ieee app list to
      be not empty after the reload finish and as a result to a conflict between
      the priority trust state reported by the app and the state in the device
      register.
      
      Reset the dcb ieee app list on initialization in case this is
      conflicting with the register status.
      
      Fixes: 2a5e7a13 ("net/mlx5e: Add dcbnl dscp to priority support")
      Signed-off-by: default avatarMoshe Tal <moshet@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      b781bff8
    • Ariel Levkovich's avatar
      net/mlx5e: Avoid checking offload capability in post_parse action · 0e322efd
      Ariel Levkovich authored
      During TC action parsing, the can_offload callback is called
      before calling the action's main parsing callback.
      
      Later on, the can_offload callback is called again before handling
      the action's post_parse callback if exists.
      
      Since the main parsing callback might have changed and set parsing
      params for the rule, following can_offload checks might fail because
      some parsing params were already set.
      
      Specifically, the ct action main parsing sets the ct param in the
      parsing status structure and when the second can_offload for ct action
      is called, before handling the ct post parsing, it will return an error
      since it checks this ct param to indicate multiple ct actions which are
      not supported.
      
      Therefore, the can_offload call is removed from the post parsing
      handling to prevent such cases.
      This is allowed since the first can_offload call will ensure that the
      action can be offloaded and the fact the code reached the post parsing
      handling already means that the action can be offloaded.
      
      Fixes: 8300f225 ("net/mlx5e: Create new flow attr for multi table actions")
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarPaul Blakey <paulb@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      0e322efd
    • Paul Blakey's avatar
      net/mlx5e: CT: Fix queued up restore put() executing after relevant ft release · b069e14f
      Paul Blakey authored
      __mlx5_tc_ct_entry_put() queues release of tuple related to some ct FT,
      if that is the last reference to that tuple, the actual deletion of
      the tuple can happen after the FT is already destroyed and freed.
      
      Flush the used workqueue before destroying the ct FT.
      
      Fixes: a2173131 ("net/mlx5e: CT: manage the lifetime of the ct entry object")
      Reviewed-by: default avatarOz Shlomo <ozsh@nvidia.com>
      Signed-off-by: default avatarPaul Blakey <paulb@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      b069e14f
    • Ariel Levkovich's avatar
      net/mlx5e: TC, fix decap fallback to uplink when int port not supported · e3fdc71b
      Ariel Levkovich authored
      When resolving the decap route device for a tunnel decap rule,
      the result may be an OVS internal port device.
      
      Prior to adding the support for internal port offload, such case
      would result in using the uplink as the default decap route device
      which allowed devices that can't support internal port offload
      to offload this decap rule.
      
      This behavior got broken by adding the internal port offload which
      will fail in case the device can't support internal port offload.
      
      To restore the old behavior, use the uplink device as the decap
      route as before when internal port offload is not supported.
      
      Fixes: b16eb3c8 ("net/mlx5: Support internal port as decap route device")
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      e3fdc71b
    • Ariel Levkovich's avatar
      net/mlx5e: TC, Fix ct_clear overwriting ct action metadata · 087032ee
      Ariel Levkovich authored
      ct_clear action is translated to clearing reg_c metadata
      which holds ct state and zone information using mod header
      actions.
      These actions are allocated during the actions parsing, as
      part of the flow attributes main mod header action list.
      
      If ct action exists in the rule, the flow's main mod header
      is used only in the post action table rule, after the ct tables
      which set the ct info in the reg_c as part of the ct actions.
      
      Therefore, if the original rule has a ct_clear action followed
      by a ct action, the ct action reg_c setting will be done first and
      will be followed by the ct_clear resetting reg_c and overwriting
      the ct info.
      
      Fix this by moving the ct_clear mod header actions allocation from
      the ct action parsing stage to the ct action post parsing stage where
      it is already known if ct_clear is followed by a ct action.
      In such case, we skip the mod header actions allocation for the ct
      clear since the ct action will write to reg_c anyway after clearing it.
      
      Fixes: 806401c2 ("net/mlx5e: CT, Fix multiple allocations and memleak of mod acts")
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarPaul Blakey <paulb@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      087032ee
    • Vlad Buslov's avatar
      net/mlx5e: Lag, Don't skip fib events on current dst · 4a2a664e
      Vlad Buslov authored
      Referenced change added check to skip updating fib when new fib instance
      has same or lower priority. However, new fib instance can be an update on
      same dst address as existing one even though the structure is another
      instance that has different address. Ignoring events on such instances
      causes multipath LAG state to not be correctly updated.
      
      Track 'dst' and 'dst_len' fields of fib event fib_entry_notifier_info
      structure and don't skip events that have the same value of that fields.
      
      Fixes: ad11c4f1 ("net/mlx5e: Lag, Only handle events from highest priority multipath entry")
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      4a2a664e
    • Vlad Buslov's avatar
      net/mlx5e: Lag, Fix fib_info pointer assignment · a6589155
      Vlad Buslov authored
      Referenced change incorrectly sets single path fib_info even when LAG is
      not active. Fix it by moving call to mlx5_lag_fib_set() into conditional
      that verifies LAG state.
      
      Fixes: ad11c4f1 ("net/mlx5e: Lag, Only handle events from highest priority multipath entry")
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      a6589155
    • Vlad Buslov's avatar
      net/mlx5e: Lag, Fix use-after-free in fib event handler · 27b0420f
      Vlad Buslov authored
      Recent commit that modified fib route event handler to handle events
      according to their priority introduced use-after-free[0] in mp->mfi pointer
      usage. The pointer now is not just cached in order to be compared to
      following fib_info instances, but is also dereferenced to obtain
      fib_priority. However, since mlx5 lag code doesn't hold the reference to
      fin_info during whole mp->mfi lifetime, it could be used after fib_info
      instance has already been freed be kernel infrastructure code.
      
      Don't ever dereference mp->mfi pointer. Refactor it to be 'const void*'
      type and cache fib_info priority in dedicated integer. Group
      fib_info-related data into dedicated 'fib' structure that will be further
      extended by following patches in the series.
      
      [0]:
      
      [  203.588029] ==================================================================
      [  203.590161] BUG: KASAN: use-after-free in mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
      [  203.592386] Read of size 4 at addr ffff888144df2050 by task kworker/u20:4/138
      
      [  203.594766] CPU: 3 PID: 138 Comm: kworker/u20:4 Tainted: G    B             5.17.0-rc7+ #6
      [  203.596751] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      [  203.598813] Workqueue: mlx5_lag_mp mlx5_lag_fib_update [mlx5_core]
      [  203.600053] Call Trace:
      [  203.600608]  <TASK>
      [  203.601110]  dump_stack_lvl+0x48/0x5e
      [  203.601860]  print_address_description.constprop.0+0x1f/0x160
      [  203.602950]  ? mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
      [  203.604073]  ? mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
      [  203.605177]  kasan_report.cold+0x83/0xdf
      [  203.605969]  ? mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
      [  203.607102]  mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
      [  203.608199]  ? mlx5_lag_init_fib_work+0x1c0/0x1c0 [mlx5_core]
      [  203.609382]  ? read_word_at_a_time+0xe/0x20
      [  203.610463]  ? strscpy+0xa0/0x2a0
      [  203.611463]  process_one_work+0x722/0x1270
      [  203.612344]  worker_thread+0x540/0x11e0
      [  203.613136]  ? rescuer_thread+0xd50/0xd50
      [  203.613949]  kthread+0x26e/0x300
      [  203.614627]  ? kthread_complete_and_exit+0x20/0x20
      [  203.615542]  ret_from_fork+0x1f/0x30
      [  203.616273]  </TASK>
      
      [  203.617174] Allocated by task 3746:
      [  203.617874]  kasan_save_stack+0x1e/0x40
      [  203.618644]  __kasan_kmalloc+0x81/0xa0
      [  203.619394]  fib_create_info+0xb41/0x3c50
      [  203.620213]  fib_table_insert+0x190/0x1ff0
      [  203.621020]  fib_magic.isra.0+0x246/0x2e0
      [  203.621803]  fib_add_ifaddr+0x19f/0x670
      [  203.622563]  fib_inetaddr_event+0x13f/0x270
      [  203.623377]  blocking_notifier_call_chain+0xd4/0x130
      [  203.624355]  __inet_insert_ifa+0x641/0xb20
      [  203.625185]  inet_rtm_newaddr+0xc3d/0x16a0
      [  203.626009]  rtnetlink_rcv_msg+0x309/0x880
      [  203.626826]  netlink_rcv_skb+0x11d/0x340
      [  203.627626]  netlink_unicast+0x4cc/0x790
      [  203.628430]  netlink_sendmsg+0x762/0xc00
      [  203.629230]  sock_sendmsg+0xb2/0xe0
      [  203.629955]  ____sys_sendmsg+0x58a/0x770
      [  203.630756]  ___sys_sendmsg+0xd8/0x160
      [  203.631523]  __sys_sendmsg+0xb7/0x140
      [  203.632294]  do_syscall_64+0x35/0x80
      [  203.633045]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      [  203.634427] Freed by task 0:
      [  203.635063]  kasan_save_stack+0x1e/0x40
      [  203.635844]  kasan_set_track+0x21/0x30
      [  203.636618]  kasan_set_free_info+0x20/0x30
      [  203.637450]  __kasan_slab_free+0xfc/0x140
      [  203.638271]  kfree+0x94/0x3b0
      [  203.638903]  rcu_core+0x5e4/0x1990
      [  203.639640]  __do_softirq+0x1ba/0x5d3
      
      [  203.640828] Last potentially related work creation:
      [  203.641785]  kasan_save_stack+0x1e/0x40
      [  203.642571]  __kasan_record_aux_stack+0x9f/0xb0
      [  203.643478]  call_rcu+0x88/0x9c0
      [  203.644178]  fib_release_info+0x539/0x750
      [  203.644997]  fib_table_delete+0x659/0xb80
      [  203.645809]  fib_magic.isra.0+0x1a3/0x2e0
      [  203.646617]  fib_del_ifaddr+0x93f/0x1300
      [  203.647415]  fib_inetaddr_event+0x9f/0x270
      [  203.648251]  blocking_notifier_call_chain+0xd4/0x130
      [  203.649225]  __inet_del_ifa+0x474/0xc10
      [  203.650016]  devinet_ioctl+0x781/0x17f0
      [  203.650788]  inet_ioctl+0x1ad/0x290
      [  203.651533]  sock_do_ioctl+0xce/0x1c0
      [  203.652315]  sock_ioctl+0x27b/0x4f0
      [  203.653058]  __x64_sys_ioctl+0x124/0x190
      [  203.653850]  do_syscall_64+0x35/0x80
      [  203.654608]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      [  203.666952] The buggy address belongs to the object at ffff888144df2000
                      which belongs to the cache kmalloc-256 of size 256
      [  203.669250] The buggy address is located 80 bytes inside of
                      256-byte region [ffff888144df2000, ffff888144df2100)
      [  203.671332] The buggy address belongs to the page:
      [  203.672273] page:00000000bf6c9314 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x144df0
      [  203.674009] head:00000000bf6c9314 order:2 compound_mapcount:0 compound_pincount:0
      [  203.675422] flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff)
      [  203.676819] raw: 002ffff800010200 0000000000000000 dead000000000122 ffff888100042b40
      [  203.678384] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
      [  203.679928] page dumped because: kasan: bad access detected
      
      [  203.681455] Memory state around the buggy address:
      [  203.682421]  ffff888144df1f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [  203.683863]  ffff888144df1f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [  203.685310] >ffff888144df2000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  203.686701]                                                  ^
      [  203.687820]  ffff888144df2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  203.689226]  ffff888144df2100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [  203.690620] ==================================================================
      
      Fixes: ad11c4f1 ("net/mlx5e: Lag, Only handle events from highest priority multipath entry")
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      27b0420f
    • Mark Zhang's avatar
      net/mlx5e: Fix the calling of update_buffer_lossy() API · c4d963a5
      Mark Zhang authored
      The arguments of update_buffer_lossy() is in a wrong order. Fix it.
      
      Fixes: 88b3d5c9 ("net/mlx5e: Fix port buffers cell size value")
      Signed-off-by: default avatarMark Zhang <markzhang@nvidia.com>
      Reviewed-by: default avatarMaor Gottlieb <maorg@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      c4d963a5
    • Vlad Buslov's avatar
      net/mlx5e: Don't match double-vlan packets if cvlan is not set · ada09af9
      Vlad Buslov authored
      Currently, match VLAN rule also matches packets that have multiple VLAN
      headers. This behavior is similar to buggy flower classifier behavior that
      has recently been fixed. Fix the issue by matching on
      outer_second_cvlan_tag with value 0 which will cause the HW to verify the
      packet doesn't contain second vlan header.
      
      Fixes: 699e96dd ("net/mlx5e: Support offloading tc double vlan headers match")
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      ada09af9
    • Aya Levin's avatar
      net/mlx5: Fix slab-out-of-bounds while reading resource dump menu · 7ba2d9d8
      Aya Levin authored
      Resource dump menu may span over more than a single page, support it.
      Otherwise, menu read may result in a memory access violation: reading
      outside of the allocated page.
      Note that page format of the first menu page contains menu headers while
      the proceeding menu pages contain only records.
      
      The KASAN logs are as follows:
      BUG: KASAN: slab-out-of-bounds in strcmp+0x9b/0xb0
      Read of size 1 at addr ffff88812b2e1fd0 by task systemd-udevd/496
      
      CPU: 5 PID: 496 Comm: systemd-udevd Tainted: G    B  5.16.0_for_upstream_debug_2022_01_10_23_12 #1
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x57/0x7d
       print_address_description.constprop.0+0x1f/0x140
       ? strcmp+0x9b/0xb0
       ? strcmp+0x9b/0xb0
       kasan_report.cold+0x83/0xdf
       ? strcmp+0x9b/0xb0
       strcmp+0x9b/0xb0
       mlx5_rsc_dump_init+0x4ab/0x780 [mlx5_core]
       ? mlx5_rsc_dump_destroy+0x80/0x80 [mlx5_core]
       ? lockdep_hardirqs_on_prepare+0x286/0x400
       ? raw_spin_unlock_irqrestore+0x47/0x50
       ? aomic_notifier_chain_register+0x32/0x40
       mlx5_load+0x104/0x2e0 [mlx5_core]
       mlx5_init_one+0x41b/0x610 [mlx5_core]
       ....
      The buggy address belongs to the object at ffff88812b2e0000
       which belongs to the cache kmalloc-4k of size 4096
      The buggy address is located 4048 bytes to the right of
       4096-byte region [ffff88812b2e0000, ffff88812b2e1000)
      The buggy address belongs to the page:
      page:000000009d69807a refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88812b2e6000 pfn:0x12b2e0
      head:000000009d69807a order:3 compound_mapcount:0 compound_pincount:0
      flags: 0x8000000000010200(slab|head|zone=2)
      raw: 8000000000010200 0000000000000000 dead000000000001 ffff888100043040
      raw: ffff88812b2e6000 0000000080040000 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88812b2e1e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88812b2e1f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88812b2e1f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                       ^
       ffff88812b2e2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88812b2e2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Fixes: 12206b17 ("net/mlx5: Add support for resource dump")
      Signed-off-by: default avatarAya Levin <ayal@nvidia.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      7ba2d9d8
    • Ariel Levkovich's avatar
      net/mlx5e: Fix wrong source vport matching on tunnel rule · cb0d54cb
      Ariel Levkovich authored
      When OVS internal port is the vtep device, the first decap
      rule is matching on the internal port's vport metadata value
      and then changes the metadata to be the uplink's value.
      
      Therefore, following rules on the tunnel, in chain > 0, should
      avoid matching on internal port metadata and use the uplink
      vport metadata instead.
      
      Select the uplink's metadata value for the source vport match
      in case the rule is in chain greater than zero, even if the tunnel
      route device is internal port.
      
      Fixes: 166f431e ("net/mlx5e: Add indirect tc offload of ovs internal port")
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      cb0d54cb