1. 28 Nov, 2016 2 commits
    • Tushar Dave's avatar
      dbri: Fix compiler warning · 16f46050
      Tushar Dave authored
      dbri uses 'u32' for dma handle while invoking kernel DMA APIs,
      instead of using dma_addr_t. This hasn't caused any 'incompatible
      pointer type' warning on SPARC because until now dma_addr_t is of
      type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
      DMA and therefore dma_addr_t became of type u64. This makes
      'incompatible pointer type' warnings inevitable.
      
      e.g.
      sound/sparc/dbri.c: In function ‘snd_dbri_create’:
      sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type
      ./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’
      
      For the record, dbri(sbus) driver never executes on sun4v. Therefore
      even though 64bit DMA is enabled on SPARC, dbri continues to use
      legacy iommu that guarantees DMA address is always in 32bit range.
      
      This patch resolves above compiler warning.
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: default avatarthomas tai <thomas.tai@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16f46050
    • Tushar Dave's avatar
      qlogicpti: Fix compiler warnings · e58566b1
      Tushar Dave authored
      qlogicpti uses '__u32' for dma handle while invoking kernel DMA APIs,
      instead of using dma_addr_t. This hasn't caused any 'incompatible
      pointer type' warning on SPARC because until now dma_addr_t is of
      type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
      DMA and therefore dma_addr_t became of type u64. This makes
      'incompatible pointer type' warnings inevitable.
      
      e.g.
      drivers/scsi/qlogicpti.c: In function ‘qpti_map_queues’:
      drivers/scsi/qlogicpti.c:813: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type
      ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’
      drivers/scsi/qlogicpti.c:822: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type
      ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’
      
      For the record, qlogicpti never executes on sun4v. Therefore even
      though 64bit DMA is enabled on SPARC, qlogicpti continues to use
      legacy iommu that guarantees DMA address is always in 32bit range.
      
      This patch resolves aforementioned compiler warnings.
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: default avatarthomas tai <thomas.tai@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e58566b1
  2. 19 Nov, 2016 1 commit
  3. 18 Nov, 2016 12 commits
    • David S. Miller's avatar
      Merge branch 'sparc-lockdep-small' · 79c3dcba
      David S. Miller authored
      Babu Moger says:
      
      ====================
      Adjust lockdep static allocations for sparc
      
      These patches limit the static allocations for lockdep data structures
      used for debugging locking correctness. For sparc, all the kernel's code,
      data, and bss, must have locked translations in the TLB so that we don't
      get TLB misses on kernel code and data. Current sparc chips have 8 TLB
      entries available that may be locked down, and with a 4mb page size,
      this gives a maximum of 32MB. With PROVE_LOCKING we could go over this
      limit and cause system boot-up problems. These patches limit the static
      allocations so that everything fits in current required size limit.
      
      patch 1 : Adds new config parameter CONFIG_PROVE_LOCKING_SMALL
      Patch 2 : Adjusts the sizes based on the new config parameter
      
      v2-> v3:
         Some more comments from Sam Ravnborg and Peter Zijlstra.
         Defined PROVE_LOCKING_SMALL as invisible and moved the selection to
         arch/sparc/Kconfig.
      
      v1-> v2:
         As suggested by Peter Zijlstra, keeping the default as is.
         Introduced new config variable CONFIG_PROVE_LOCKING_SMALL
         to handle sparc specific case.
      
      v0:
         Initial revision.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      79c3dcba
    • Babu Moger's avatar
      lockdep: Limit static allocations if PROVE_LOCKING_SMALL is defined · e245d99e
      Babu Moger authored
      Reduce the size of data structure for lockdep entries by half if
      PROVE_LOCKING_SMALL if defined. This is used only for sparc.
      Signed-off-by: default avatarBabu Moger <babu.moger@oracle.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e245d99e
    • Babu Moger's avatar
      config: Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc · e6b5f1be
      Babu Moger authored
      This new config parameter limits the space used for "Lock debugging:
      prove locking correctness" by about 4MB. The current sparc systems have
      the limitation of 32MB size for kernel size including .text, .data and
      .bss sections. With PROVE_LOCKING feature, the kernel size could grow
      beyond this limit and causing system boot-up issues. With this option,
      kernel limits the size of the entries of lock_chains, stack_trace etc.,
      so that kernel fits in required size limit. This is not visible to user
      and only used for sparc.
      Signed-off-by: default avatarBabu Moger <babu.moger@oracle.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6b5f1be
    • Tushar Dave's avatar
      sunbmac: Fix compiler warning · 1a9bbcca
      Tushar Dave authored
      sunbmac uses '__u32' for dma handle while invoking kernel DMA APIs,
      instead of using dma_addr_t. This hasn't caused any 'incompatible
      pointer type' warning on SPARC because until now dma_addr_t is of
      type u32. However, recent changes in SPARC ATU (iommu) enables 64bit
      DMA and therefore dma_addr_t becomes of type u64. This makes
      'incompatible pointer type' warnings inevitable.
      
      e.g.
      drivers/net/ethernet/sun/sunbmac.c: In function ‘bigmac_ether_init’:
      drivers/net/ethernet/sun/sunbmac.c:1166: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type
      ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’
      
      This patch resolves above compiler warning.
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: default avatarchris hyser <chris.hyser@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a9bbcca
    • Tushar Dave's avatar
      sunqe: Fix compiler warnings · 266439c9
      Tushar Dave authored
      sunqe uses '__u32' for dma handle while invoking kernel DMA APIs,
      instead of using dma_addr_t. This hasn't caused any 'incompatible
      pointer type' warning on SPARC because until now dma_addr_t is of
      type u32. However, recent changes in SPARC ATU (iommu) enables 64bit
      DMA and therefore dma_addr_t becomes of type u64. This makes
      'incompatible pointer type' warnings inevitable.
      
      e.g.
      drivers/net/ethernet/sun/sunqe.c: In function ‘qec_ether_init’:
      drivers/net/ethernet/sun/sunqe.c:883: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type
      ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’
      drivers/net/ethernet/sun/sunqe.c:885: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type
      ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’
      
      This patch resolves above compiler warnings.
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: default avatarchris hyser <chris.hyser@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      266439c9
    • David S. Miller's avatar
      Merge branch 'sun4v-64bit-DMA' · 49cc0c43
      David S. Miller authored
      Tushar Dave says:
      
      ====================
      sparc: Enable sun4v hypervisor PCI IOMMU v2 APIs and ATU
      
      ATU (Address Translation Unit) is a new IOMMU in SPARC supported with
      sun4v hypervisor PCI IOMMU v2 APIs.
      
      Current SPARC IOMMU supports only 32bit address ranges and one TSB
      per PCIe root complex that has a 2GB per root complex DVMA space
      limit. The limit has become a scalability bottleneck nowadays that
      a typical 10G/40G NIC can consume 500MB DVMA space per instance.
      When DVMA resource is exhausted, devices will not be usable
      since the driver can't allocate DVMA.
      
      For example, we recently experienced legacy IOMMU limitation while
      using i40e driver in system with large number of CPUs (e.g. 128).
      Four ports of i40e, each request 128 QP (Queue Pairs). Each queue has
      512 (default) descriptors. So considering only RX queues (because RX
      premap DMA buffers), i40e takes 4*128*512 number of DMA entries in
      IOMMU table. Legacy IOMMU can have at max (2G/8K)- 1 entries available
      in table. So bringing up four instance of i40e alone saturate existing
      IOMMU resource.
      
      ATU removes bottleneck by allowing guest os to create IOTSB of size
      32G (or more) with 64bit address ranges available in ATU HW. 32G is
      more than enough DVMA space to be shared by all PCIe devices under
      root complex contrast to 2G space provided by legacy IOMMU.
      
      ATU allows PCIe devices to use 64bit DMA addressing. Devices
      which choose to use 32bit DMA mask will continue to work with the
      existing legacy IOMMU.
      
      The patch set is tested on sun4v (T1000, T2000, T3, T4, T5, T7, S7)
      and sun4u SPARC.
      
      Thanks.
      -Tushar
      
      v2->v3:
      - Patch #5 addresses comment by Joe Perches.
       -- use %s, __func__ instead of embedding the function name.
      
      v1->v2:
      - Patch #2 addresses comments by Dave M.
       -- use page allocator to allocate IOTSB.
       -- use true/false with boolean variables.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49cc0c43
    • Tushar Dave's avatar
      sparc64: Enable 64-bit DMA · d30a6b84
      Tushar Dave authored
      ATU 64bit addressing allows PCIe devices with 64bit DMA capabilities
      to use ATU for 64bit DMA.
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: default avatarchris hyser <chris.hyser@oracle.com>
      Acked-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d30a6b84
    • Tushar Dave's avatar
      sparc64: Enable sun4v dma ops to use IOMMU v2 APIs · f08978b0
      Tushar Dave authored
      Add Hypervisor IOMMU v2 APIs pci_iotsb_map(), pci_iotsb_demap() and
      enable sun4v dma ops to use IOMMU v2 API for all PCIe devices with
      64bit DMA mask.
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: default avatarchris hyser <chris.hyser@oracle.com>
      Acked-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f08978b0
    • Tushar Dave's avatar
      sparc64: Bind PCIe devices to use IOMMU v2 service · 5116ab4e
      Tushar Dave authored
      In order to use Hypervisor (HV) IOMMU v2 API for map/demap, each PCIe
      device has to be bound to IOTSB using HV API pci_iotsb_bind().
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: default avatarchris hyser <chris.hyser@oracle.com>
      Acked-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5116ab4e
    • Tushar Dave's avatar
      sparc64: Initialize iommu_map_table and iommu_pool · 31f077dc
      Tushar Dave authored
      Like legacy IOMMU, use common iommu_map_table and iommu_pool for ATU.
      This change initializes iommu_map_table and iommu_pool for ATU.
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: default avatarchris hyser <chris.hyser@oracle.com>
      Reviewed-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31f077dc
    • Tushar Dave's avatar
      sparc64: Add ATU (new IOMMU) support · f0248c15
      Tushar Dave authored
      ATU (Address Translation Unit) is a new IOMMU in SPARC supported with
      Hypervisor IOMMU v2 APIs.
      
      Current SPARC IOMMU supports only 32bit address ranges and one TSB
      per PCIe root complex that has a 2GB per root complex DVMA space
      limit. The limit has become a scalability bottleneck nowadays that
      a typical 10G/40G NIC can consume 300MB-500MB DVMA space per
      instance. When DVMA resource is exhausted, devices will not be usable
      since the driver can't allocate DVMA.
      
      ATU removes bottleneck by allowing guest os to create IOTSB of size
      32G (or more) with 64bit address ranges available in ATU HW. 32G is
      more than enough DVMA space to be shared by all PCIe devices under
      root complex contrast to 2G space provided by legacy IOMMU.
      
      ATU allows PCIe devices to use 64bit DMA addressing. Devices
      which choose to use 32bit DMA mask will continue to work with the
      existing legacy IOMMU.
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: default avatarchris hyser <chris.hyser@oracle.com>
      Acked-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f0248c15
    • Dave Kleikamp's avatar
      sparc64: Add FORCE_MAX_ZONEORDER and default to 13 · c88c545b
      Dave Kleikamp authored
      This change allows ATU (new IOMMU) in SPARC systems to request
      large (32M) contiguous memory during boot for creating IOTSB backing
      store.
      Signed-off-by: default avatarDave Kleikamp <dave.kleikamp@oracle.com>
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c88c545b
  4. 14 Nov, 2016 1 commit
  5. 11 Nov, 2016 2 commits
    • Andreas Larsson's avatar
    • Thomas Tai's avatar
      sparc64: Fix find_node warning if numa node cannot be found · 74a5ed5c
      Thomas Tai authored
      When booting up LDOM, find_node() warns that a physical address
      doesn't match a NUMA node.
      
      WARNING: CPU: 0 PID: 0 at arch/sparc/mm/init_64.c:835
      find_node+0xf4/0x120 find_node: A physical address doesn't
      match a NUMA node rule. Some physical memory will be
      owned by node 0.Modules linked in:
      
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc3 #4
      Call Trace:
       [0000000000468ba0] __warn+0xc0/0xe0
       [0000000000468c74] warn_slowpath_fmt+0x34/0x60
       [00000000004592f4] find_node+0xf4/0x120
       [0000000000dd0774] add_node_ranges+0x38/0xe4
       [0000000000dd0b1c] numa_parse_mdesc+0x268/0x2e4
       [0000000000dd0e9c] bootmem_init+0xb8/0x160
       [0000000000dd174c] paging_init+0x808/0x8fc
       [0000000000dcb0d0] setup_arch+0x2c8/0x2f0
       [0000000000dc68a0] start_kernel+0x48/0x424
       [0000000000dcb374] start_early_boot+0x27c/0x28c
       [0000000000a32c08] tlb_fixup_done+0x4c/0x64
       [0000000000027f08] 0x27f08
      
      It is because linux use an internal structure node_masks[] to
      keep the best memory latency node only. However, LDOM mdesc can
      contain single latency-group with multiple memory latency nodes.
      
      If the address doesn't match the best latency node within
      node_masks[], it should check for an alternative via mdesc.
      The warning message should only be printed if the address
      doesn't match any node_masks[] nor within mdesc. To minimize
      the impact of searching mdesc every time, the last matched
      mask and index is stored in a variable.
      Signed-off-by: default avatarThomas Tai <thomas.tai@oracle.com>
      Reviewed-by: default avatarChris Hyser <chris.hyser@oracle.com>
      Reviewed-by: default avatarLiam Merwick <liam.merwick@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74a5ed5c
  6. 09 Nov, 2016 3 commits
    • Linus Torvalds's avatar
      Merge tag 'sound-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 27bcd37e
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "This became a largish pull-request, as we've got a bunch of pending
        ASoC fixes at this time. One noticeable change is the removal of error
        directive in uapi/sound/asoc.h. We found that the API has been already
        used on Chromebooks, so we need to support it even now.
      
        A slight big LOC is found in Qualcomm lpass driver, but the rest are
        all small and easy fixes for ASoC drivers (sti, sun4i, Realtek codecs,
        Intel, tas571x, etc) in addition to the patches to harden the ALSA
        core proc file accesses"
      
      * tag 'sound-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (26 commits)
        ALSA: info: Return error for invalid read/write
        ALSA: info: Limit the proc text input size
        ASoC: samsung: spdif: Fix DMA filter initialization
        ASoC: sun4i-codec: Enable bus clock after getting GPIO
        ASoC: lpass-cpu: add module licence and description
        ASoC: lpass-platform: Fix broken pcm data usage
        ASoC: sun4i-codec: return error code instead of NULL when create_card fails
        ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0>
        ASoC: samsung: get access to DMA engine early to defer probe properly
        ASoC: da7219: Connect output enable register to DAIOUT
        ASoC: Intel: Skylake: Fix to turn off hdmi power on probe failure
        ASoC: sti-sas: enable fast io for regmap
        ASoC: sti: fix channel status update after playback start
        ASoC: PXA: Brownstone needs I2C
        ASoC: Intel: Skylake: Always acquire runtime pm ref on unload
        ASoC: Intel: Atom: add terminate entry for dmi_system_id tables
        ASoC: rt298: fix jack type detect error
        ASoC: rt5663: fix a debug statement
        ASoC: cs4270: fix DAPM stream name mismatch
        ASoC: Intel: haswell depends on sst-firmware
        ...
      27bcd37e
    • Linus Torvalds's avatar
      Merge tag 'for-linus-4.9-rc4-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux · 3c6106da
      Linus Torvalds authored
      Pull orangefs fix from Mike Marshall:
       "We recently refactored the Orangefs debugfs code. The refactor seemed
        to trigger dan.carpenter@oracle.com's static tester to find a possible
        double-free in the code.
      
        While designing the fix we saw a condition under which the buffer
        being freed could also be overflowed.
      
        We also realized how to rebuild the related debugfs file's "contents"
        (a string) without deleting and re-creating the file.
      
        This fix should eliminate the possible double-free, the potential
        overflow and improve code readability"
      
      * tag 'for-linus-4.9-rc4-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux:
        orangefs: clean up debugfs
      3c6106da
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · ae67e87f
      Linus Torvalds authored
      Pull s390 fixes from Martin Schwidefsky:
       "Two bug fixes
      
         - a memory alignment fix in the s390 only hypfs code
      
         - a fix for the generic percpu code that caused ftrace to break on
           s390. This is not relevant for x86 but for all architectures that
           use the generic percpu code"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        percpu: use notrace variant of preempt_disable/preempt_enable
        s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment
      ae67e87f
  7. 08 Nov, 2016 9 commits
    • Linus Torvalds's avatar
      Merge tag 'iommu-fixes-v4.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · e3a00f68
      Linus Torvalds authored
      Pull IOMMU fixes from Joerg Roedel:
      
       - Four patches from Robin Murphy fix several issues with the recently
         merged generic DT-bindings support for arm-smmu drivers
      
       - A fix for a dead-lock issue in the VT-d driver, which shows up on
         iommu hotplug
      
      * tag 'iommu-fixes-v4.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        iommu/vt-d: Fix dead-locks in disable_dmar_iommu() path
        iommu/arm-smmu: Fix out-of-bounds dereference
        iommu/arm-smmu: Check that iommu_fwspecs are ours
        iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
        iommu/arm-smmu: Work around ARM DMA configuration
      e3a00f68
    • Joerg Roedel's avatar
      iommu/vt-d: Fix dead-locks in disable_dmar_iommu() path · bea64033
      Joerg Roedel authored
      It turns out that the disable_dmar_iommu() code-path tried
      to get the device_domain_lock recursivly, which will
      dead-lock when this code runs on dmar removal. Fix both
      code-paths that could lead to the dead-lock.
      
      Fixes: 55d94043 ('iommu/vt-d: Get rid of domain->iommu_lock')
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      bea64033
    • Robin Murphy's avatar
      iommu/arm-smmu: Fix out-of-bounds dereference · 8c82d6ec
      Robin Murphy authored
      When we iterate a master's config entries, what we generally care
      about is the entry's stream map index, rather than the entry index
      itself, so it's nice to have the iterator automatically assign the
      former from the latter. Unfortunately, booting with KASAN reveals
      the oversight that using a simple comma operator results in the
      entry index being dereferenced before being checked for validity,
      so we always access one element past the end of the fwspec array.
      
      Flip things around so that the check always happens before the index
      may be dereferenced.
      
      Fixes: adfec2e7 ("iommu/arm-smmu: Convert to iommu_fwspec")
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      8c82d6ec
    • Robin Murphy's avatar
      iommu/arm-smmu: Check that iommu_fwspecs are ours · 3c117b54
      Robin Murphy authored
      We seem to have forgotten to check that iommu_fwspecs actually belong to
      us before we go ahead and dereference their private data. Oops.
      
      Fixes: 021bb842 ("iommu/arm-smmu: Wire up generic configuration support")
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      3c117b54
    • Robin Murphy's avatar
      iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s · ec615f43
      Robin Murphy authored
      We now delay installing our per-bus iommu_ops until we know an SMMU has
      successfully probed, as they don't serve much purpose beforehand, and
      doing so also avoids fights between multiple IOMMU drivers in a single
      kernel. However, the upshot of passing the return value of bus_set_iommu()
      back from our probe function is that if there happens to be more than
      one SMMUv3 device in a system, the second and subsequent probes will
      wind up returning -EBUSY to the driver core and getting torn down again.
      
      Avoid re-setting ops if ours are already installed, so that any genuine
      failures stand out.
      
      Fixes: 08d4ca2a ("iommu/arm-smmu: Support non-PCI devices with SMMUv3")
      CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      CC: Hanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      ec615f43
    • Robin Murphy's avatar
      iommu/arm-smmu: Work around ARM DMA configuration · fba4f8e5
      Robin Murphy authored
      The 32-bit ARM DMA configuration code predates the IOMMU core's default
      domain functionality, and instead relies on allocating its own domains
      and attaching any devices using the generic IOMMU binding to them.
      Unfortunately, it does this relatively early on in the creation of the
      device, before we've seen our add_device callback, which leads us to
      attempt to operate on a half-configured master.
      
      To avoid a crash, check for this situation on attach, but refuse to
      play, as there's nothing we can do. This at least allows VFIO to keep
      working for people who update their 32-bit DTs to the generic binding,
      albeit with a few (innocuous) warnings from the DMA layer on boot.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      fba4f8e5
    • Takashi Iwai's avatar
      ALSA: info: Return error for invalid read/write · 6809cd68
      Takashi Iwai authored
      Currently the ALSA proc handler allows read or write even if the proc
      file were write-only or read-only.  It's mostly harmless, does thing
      but allocating memory and ignores the input/output.  But it doesn't
      tell user about the invalid use, and it's confusing and inconsistent
      in comparison with other proc files.
      
      This patch adds some sanity checks and let the proc handler returning
      an -EIO error when the invalid read/write is performed.
      
      Cc: <stable@vger.kernel.org> # v4.2+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6809cd68
    • Takashi Iwai's avatar
      ALSA: info: Limit the proc text input size · 027a9fe6
      Takashi Iwai authored
      The ALSA proc handler allows currently the write in the unlimited size
      until kmalloc() fails.  But basically the write is supposed to be only
      for small inputs, mostly for one line inputs, and we don't have to
      handle too large sizes at all.  Since the kmalloc error results in the
      kernel warning, it's better to limit the size beforehand.
      
      This patch adds the limit of 16kB, which must be large enough for the
      currently existing code.
      
      Cc: stable@vger.kernel.org # v4.2+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      027a9fe6
    • Heiko Carstens's avatar
      percpu: use notrace variant of preempt_disable/preempt_enable · 7f8d61f0
      Heiko Carstens authored
      Commit 345ddcc8 ("ftrace: Have set_ftrace_pid use the bitmap like
      events do") added a couple of this_cpu_read calls to the ftrace code.
      
      On x86 this is not a problem, since it has single instructions to read
      percpu data. Other architectures which use the generic variant now
      have additional preempt_disable and preempt_enable calls in the core
      ftrace code. This may lead to recursive calls and in result to a dead
      machine, e.g. if preemption and debugging options are enabled.
      
      To fix this use the notrace variant of preempt_disable and
      preempt_enable within the generic percpu code.
      Reported-and-bisected-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Tested-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Fixes: 345ddcc8 ("ftrace: Have set_ftrace_pid use the bitmap like events do")
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      7f8d61f0
  8. 07 Nov, 2016 5 commits
  9. 06 Nov, 2016 1 commit
    • Guenter Roeck's avatar
      openrisc: Define __ro_after_init to avoid crash · 2c7a5c5c
      Guenter Roeck authored
      openrisc qemu tests fail with the following crash.
      
      Unable to handle kernel access at virtual address 0xc0300c34
      
      Oops#: 0001
      CPU #: 0
         PC: c016c710    SR: 0000ae67    SP: c1017e04
         GPR00: 00000000 GPR01: c1017e04 GPR02: c0300c34 GPR03: c0300c34
         GPR04: 00000000 GPR05: c0300cb0 GPR06: c0300c34 GPR07: 000000ff
         GPR08: c107f074 GPR09: c0199ef4 GPR10: c1016000 GPR11: 00000000
         GPR12: 00000000 GPR13: c107f044 GPR14: c0473774 GPR15: 07ce0000
         GPR16: 00000000 GPR17: c107ed8a GPR18: 00009600 GPR19: c107f044
         GPR20: c107ee74 GPR21: 00000003 GPR22: c0473770 GPR23: 00000033
         GPR24: 000000bf GPR25: 00000019 GPR26: c046400c GPR27: 00000001
         GPR28: c0464028 GPR29: c1018000 GPR30: 00000006 GPR31: ccf37483
           RES: 00000000 oGPR11: ffffffff
           Process swapper (pid: 1, stackpage=c1001960)
      
           Stack: Stack dump [0xc1017cf8]:
           sp + 00: 0xc1017e04
           sp + 04: 0xc0300c34
           sp + 08: 0xc0300c34
           sp + 12: 0x00000000
      ...
      
      Bisect points to commit d2ec3f77 ("pty: make ptmx file ops read-only
      after init"). Fix by defining __ro_after_init for the openrisc
      architecture, similar to parisc.
      
      Fixes: d2ec3f77 ("pty: make ptmx file ops read-only after init")
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarStafford Horne <shorne@gmail.com>
      2c7a5c5c
  10. 05 Nov, 2016 4 commits