1. 05 May, 2022 29 commits
  2. 04 May, 2022 11 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 branch 'mlxsw-updates' · a37f37a2
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Various updates
      
      Patches #1-#3 add missing topology diagrams in selftests and perform
      small cleanups.
      
      Patches #4-#5 make small adjustments in QoS configuration. See detailed
      description in the commit messages.
      
      Patches #6-#8 reduce the number of background EMAD transactions. The
      driver periodically queries the device (via EMAD transactions) about
      updates that cannot happen in certain situations. This can negatively
      impact the latency of time critical transactions, as the device is busy
      processing other transactions.
      
      Before:
      
       # perf stat -a -e devlink:devlink_hwmsg -- sleep 10
      
        Performance counter stats for 'system wide':
      
                      452      devlink:devlink_hwmsg
      
             10.009736160 seconds time elapsed
      
      After:
      
       # perf stat -a -e devlink:devlink_hwmsg -- sleep 10
      
        Performance counter stats for 'system wide':
      
                        0      devlink:devlink_hwmsg
      
             10.001726333 seconds time elapsed
      
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a37f37a2
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Only query neighbour activity when necessary · cff94376
      Ido Schimmel authored
      The driver periodically queries the device for activity of neighbour
      entries in order to report it to the kernel's neighbour table.
      
      Avoid unnecessary activity query when no neighbours are installed. Use
      an atomic variable to track the number of neighbours, as it is read
      without any locks.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cff94376
    • Ido Schimmel's avatar
      mlxsw: spectrum_switchdev: Only query FDB notifications when necessary · b8950003
      Ido Schimmel authored
      The driver periodically queries the device for FDB notifications (e.g.,
      learned, aged-out) in order to update the bridge driver. These
      notifications can only be generated when bridges are offloaded to the
      device.
      
      Avoid unnecessary queries by starting to query upon installation of the
      first bridge and stop querying upon removal of the last bridge.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8950003
    • Ido Schimmel's avatar
      mlxsw: spectrum_acl: Do not report activity for multicast routes · d1314096
      Ido Schimmel authored
      The driver periodically queries the device for activity of ACL rules in
      order to report it to tc upon 'FLOW_CLS_STATS'.
      
      In Spectrum-2 and later ASICs, multicast routes are programmed as ACL
      rules, but unlike rules installed by tc, their activity is of no
      interest.
      
      Avoid unnecessary activity query for such rules by always reporting them
      as inactive.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1314096
    • Petr Machata's avatar
      mlxsw: Treat LLDP packets as control · 0106668c
      Petr Machata authored
      When trapping packets for on-CPU processing, Spectrum machines
      differentiate between control and non-control traps. Traffic trapped
      through non-control traps is treated as data and kept in shared buffer in
      pools 0-4. Traffic trapped through control traps is kept in the dedicated
      control buffer 9. The advantage of marking traps as control is that
      pressure in the data plane does not prevent the control traffic to be
      processed.
      
      When the LLDP trap was introduced, it was marked as a control trap. But
      then in commit aed4b572 ("mlxsw: spectrum: PTP: Hook into packet
      receive path"), PTP traps were introduced. Because Ethernet-encapsulated
      PTP packets look to the Spectrum-1 ASIC as LLDP traffic and are trapped
      under the LLDP trap, this trap was reconfigured as non-control, in sync
      with the PTP traps.
      
      There is however no requirement that PTP traffic be handled as data.
      Besides, the usual encapsulation for PTP traffic is UDP, not bare Ethernet,
      and that is in deployments that even need PTP, which is far less common
      than LLDP. This is reflected by the default policer, which was not bumped
      up to the 19Kpps / 24Kpps that is the expected load of a PTP-enabled
      Spectrum-1 switch.
      
      Marking of LLDP trap as non-control was therefore probably misguided. In
      this patch, change it back to control.
      Reported-by: default avatarMaksym Yaremchuk <maksymy@nvidia.com>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0106668c
    • Petr Machata's avatar
      mlxsw: spectrum_dcb: Do not warn about priority changes · b6b58456
      Petr Machata authored
      The idea behind the warnings is that the user would get warned in case when
      more than one priority is configured for a given DSCP value on a netdevice.
      
      The warning is currently wrong, because dcb_ieee_getapp_mask() returns
      the first matching entry, not all of them, and the warning will then claim
      that some priority is "current", when in fact it is not.
      
      But more importantly, the warning is misleading in general. Consider the
      following commands:
      
       # dcb app flush dev swp19 dscp-prio
       # dcb app add dev swp19 dscp-prio 24:3
       # dcb app replace dev swp19 dscp-prio 24:2
      
      The last command will issue the following warning:
      
       mlxsw_spectrum3 0000:07:00.0 swp19: Ignoring new priority 2 for DSCP 24 in favor of current value of 3
      
      The reason is that the "replace" command works by first adding the new
      value, and then removing all old values. This is the only way to make the
      replacement without causing the traffic to be prioritized to whatever the
      chip defaults to. The warning is issued in response to adding the new
      priority, and then no warning is shown when the old priority is removed.
      The upshot is that the canonical way to change traffic prioritization
      always produces a warning about ignoring the new priority, but what gets
      configured is in fact what the user intended.
      
      An option to just emit warning every time that the prioritization changes
      just to make it clear that it happened is obviously unsatisfactory.
      
      Therefore, in this patch, remove the warnings.
      Reported-by: default avatarMaksym Yaremchuk <maksymy@nvidia.com>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6b58456
    • Petr Machata's avatar
      selftests: router.sh: Add a diagram · faa7521a
      Petr Machata authored
      It is customary for selftests to have a comment with a topology diagram,
      which serves to illustrate the situation in which the test is done. This
      selftest lacks it. Add it.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      faa7521a
    • Petr Machata's avatar
      selftests: router_vid_1: Add a diagram, fix coding style · 5ade50e2
      Petr Machata authored
      It is customary for selftests to have a comment with a topology diagram,
      which serves to illustrate the situation in which the test is done. This
      selftest lacks it. Add it.
      
      While at it, fix the list of tests so that the test names are enumerated
      one at a line.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ade50e2