1. 29 4月, 2020 2 次提交
    • G
      iommu/mediatek: Fix MTK_IOMMU dependencies · d1dcb725
      Geert Uytterhoeven 提交于
      If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):
      
          drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
          dma-iommu.c:(.text+0x836): undefined reference to `dma_pgprot'
      
      IOMMU_DMA must not be selected, unless HAS_DMA=y.
      
      Hence fix this by making MTK_IOMMU depend on HAS_DMA.
      While at it, remove the dependency on ARM || ARM64, as that is already
      implied by the dependency on ARCH_MEDIATEK.
      
      Fixes: e93a1695 ("iommu: Enable compile testing for some of drivers")
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Link: https://lore.kernel.org/r/20200410143047.19691-1-geert@linux-m68k.orgSigned-off-by: NJoerg Roedel <jroedel@suse.de>
      d1dcb725
    • K
      iommu: Fix the memory leak in dev_iommu_free() · 5375e874
      Kevin Hao 提交于
      In iommu_probe_device(), we would invoke dev_iommu_free() to free the
      dev->iommu after the ->add_device() returns failure. But after commit
      72acd9df ("iommu: Move iommu_fwspec to struct dev_iommu"), we also
      need to free the iommu_fwspec before the dev->iommu is freed. This fixes
      the following memory leak reported by kmemleak:
        unreferenced object 0xffff000bc836c700 (size 128):
          comm "swapper/0", pid 1, jiffies 4294896304 (age 782.120s)
          hex dump (first 32 bytes):
            00 00 00 00 00 00 00 00 d8 cd 9b ff 0b 00 ff ff  ................
            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          backtrace:
            [<00000000df34077b>] kmem_cache_alloc_trace+0x244/0x4b0
            [<000000000e560ac0>] iommu_fwspec_init+0x7c/0xb0
            [<0000000075eda275>] of_iommu_xlate+0x80/0xe8
            [<00000000728d6bf9>] of_pci_iommu_init+0xb0/0xb8
            [<00000000d001fe6f>] pci_for_each_dma_alias+0x48/0x190
            [<000000006db6bbce>] of_iommu_configure+0x1ac/0x1d0
            [<00000000634745f8>] of_dma_configure+0xdc/0x220
            [<000000002cbc8ba0>] pci_dma_configure+0x50/0x78
            [<00000000cdf6e193>] really_probe+0x8c/0x340
            [<00000000fddddc46>] driver_probe_device+0x60/0xf8
            [<0000000061bcdb51>] __device_attach_driver+0x8c/0xd0
            [<000000009b9ff58e>] bus_for_each_drv+0x80/0xd0
            [<000000004b9c8aa3>] __device_attach+0xec/0x148
            [<00000000a5c13bf3>] device_attach+0x1c/0x28
            [<000000005071e151>] pci_bus_add_device+0x58/0xd0
            [<000000002d4f87d1>] pci_bus_add_devices+0x40/0x90
      
      Fixes: 72acd9df ("iommu: Move iommu_fwspec to struct dev_iommu")
      Signed-off-by: NKevin Hao <haokexin@gmail.com>
      Link: https://lore.kernel.org/r/20200402143749.40500-1-haokexin@gmail.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>
      5375e874
  2. 26 4月, 2020 1 次提交
  3. 25 4月, 2020 3 次提交
    • D
      net: systemport: suppress warnings on failed Rx SKB allocations · 3554e54a
      Doug Berger 提交于
      The driver is designed to drop Rx packets and reclaim the buffers
      when an allocation fails, and the network interface needs to safely
      handle this packet loss. Therefore, an allocation failure of Rx
      SKBs is relatively benign.
      
      However, the output of the warning message occurs with a high
      scheduling priority that can cause excessive jitter/latency for
      other high priority processing.
      
      This commit suppresses the warning messages to prevent scheduling
      problems while retaining the failure count in the statistics of
      the network interface.
      Signed-off-by: NDoug Berger <opendmb@gmail.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3554e54a
    • D
      net: bcmgenet: suppress warnings on failed Rx SKB allocations · ecaeceb8
      Doug Berger 提交于
      The driver is designed to drop Rx packets and reclaim the buffers
      when an allocation fails, and the network interface needs to safely
      handle this packet loss. Therefore, an allocation failure of Rx
      SKBs is relatively benign.
      
      However, the output of the warning message occurs with a high
      scheduling priority that can cause excessive jitter/latency for
      other high priority processing.
      
      This commit suppresses the warning messages to prevent scheduling
      problems while retaining the failure count in the statistics of
      the network interface.
      Signed-off-by: NDoug Berger <opendmb@gmail.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ecaeceb8
    • T
      macsec: avoid to set wrong mtu · 7f327080
      Taehee Yoo 提交于
      When a macsec interface is created, the mtu is calculated with the lower
      interface's mtu value.
      If the mtu of lower interface is lower than the length, which is needed
      by macsec interface, macsec's mtu value will be overflowed.
      So, if the lower interface's mtu is too low, macsec interface's mtu
      should be set to 0.
      
      Test commands:
          ip link add dummy0 mtu 10 type dummy
          ip link add macsec0 link dummy0 type macsec
          ip link show macsec0
      
      Before:
          11: macsec0@dummy0: <BROADCAST,MULTICAST,M-DOWN> mtu 4294967274
      After:
          11: macsec0@dummy0: <BROADCAST,MULTICAST,M-DOWN> mtu 0
      
      Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f327080
  4. 24 4月, 2020 11 次提交
  5. 23 4月, 2020 23 次提交