1. 09 Sep, 2019 1 commit
    • Matthias Lange's avatar
      virtio_ring: fix unmap of indirect descriptors · cf8f1696
      Matthias Lange authored
      
      
      The function virtqueue_add_split() DMA-maps the scatterlist buffers. In
      case a mapping error occurs the already mapped buffers must be unmapped.
      This happens by jumping to the 'unmap_release' label.
      
      In case of indirect descriptors the release is wrong and may leak kernel
      memory. Because the implementation assumes that the head descriptor is
      already mapped it starts iterating over the descriptor list starting
      from the head descriptor. However for indirect descriptors the head
      descriptor is never mapped in case of an error.
      
      The fix is to initialize the start index with zero in case of indirect
      descriptors and use the 'desc' pointer directly for iterating over the
      descriptor chain.
      Signed-off-by: default avatarMatthias Lange <matthias.lange@kernkonzept.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      cf8f1696
  2. 24 May, 2019 1 commit
  3. 12 May, 2019 2 commits
  4. 08 Apr, 2019 1 commit
    • Cornelia Huck's avatar
      virtio: Honour 'may_reduce_num' in vring_create_virtqueue · cf94db21
      Cornelia Huck authored
      vring_create_virtqueue() allows the caller to specify via the
      may_reduce_num parameter whether the vring code is allowed to
      allocate a smaller ring than specified.
      
      However, the split ring allocation code tries to allocate a
      smaller ring on allocation failure regardless of what the
      caller specified. This may cause trouble for e.g. virtio-pci
      in legacy mode, which does not support ring resizing. (The
      packed ring code does not resize in any case.)
      
      Let's fix this by bailing out immediately in the split ring code
      if the requested size cannot be allocated and may_reduce_num has
      not been specified.
      
      While at it, fix a typo in the usage instructions.
      
      Fixes: 2a2d1382
      
       ("virtio: Add improved queue allocation API")
      Cc: stable@vger.kernel.org # v4.6+
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reviewed-by: default avatarJens Freimann <jfreimann@redhat.com>
      cf94db21
  5. 06 Mar, 2019 1 commit
  6. 05 Feb, 2019 1 commit
  7. 24 Jan, 2019 1 commit
    • Tiwei Bie's avatar
      virtio: support VIRTIO_F_ORDER_PLATFORM · 45383fb0
      Tiwei Bie authored
      
      
      This patch introduces the support for VIRTIO_F_ORDER_PLATFORM.
      If this feature is negotiated, the driver must use the barriers
      suitable for hardware devices. Otherwise, the device and driver
      are assumed to be implemented in software, that is they can be
      assumed to run on identical CPUs in an SMP configuration. Thus
      a weaker form of memory barriers is sufficient to yield better
      performance.
      
      It is recommended that an add-in card based PCI device offers
      this feature for portability. The device will fail to operate
      further or will operate in a slower emulation mode if this
      feature is offered but not accepted.
      Signed-off-by: default avatarTiwei Bie <tiwei.bie@intel.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      45383fb0
  8. 27 Nov, 2018 11 commits
  9. 12 Jun, 2018 1 commit
    • Kees Cook's avatar
      treewide: kmalloc() -> kmalloc_array() · 6da2ec56
      Kees Cook authored
      
      
      The kmalloc() function has a 2-factor argument form, kmalloc_array(). This
      patch replaces cases of:
      
              kmalloc(a * b, gfp)
      
      with:
              kmalloc_array(a * b, gfp)
      
      as well as handling cases of:
      
              kmalloc(a * b * c, gfp)
      
      with:
      
              kmalloc(array3_size(a, b, c), gfp)
      
      as it's slightly less ugly than:
      
              kmalloc_array(array_size(a, b), c, gfp)
      
      This does, however, attempt to ignore constant size factors like:
      
              kmalloc(4 * 1024, gfp)
      
      though any constants defined via macros get caught up in the conversion.
      
      Any factors with a sizeof() of "unsigned char", "char", and "u8" were
      dropped, since they're redundant.
      
      The tools/ directory was manually excluded, since it has its own
      implementation of kmalloc().
      
      The Coccinelle script used for this was:
      
      // Fix redundant parens around sizeof().
      @@
      type TYPE;
      expression THING, E;
      @@
      
      (
        kmalloc(
      -	(sizeof(TYPE)) * E
      +	sizeof(TYPE) * E
        , ...)
      |
        kmalloc(
      -	(sizeof(THING)) * E
      +	sizeof(THING) * E
        , ...)
      )
      
      // Drop single-byte sizes and redundant parens.
      @@
      expression COUNT;
      typedef u8;
      typedef __u8;
      @@
      
      (
        kmalloc(
      -	sizeof(u8) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(__u8) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(char) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(unsigned char) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(u8) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(__u8) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(char) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(unsigned char) * COUNT
      +	COUNT
        , ...)
      )
      
      // 2-factor product with sizeof(type/expression) and identifier or constant.
      @@
      type TYPE;
      expression THING;
      identifier COUNT_ID;
      constant COUNT_CONST;
      @@
      
      (
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (COUNT_ID)
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * COUNT_ID
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * COUNT_CONST
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (COUNT_ID)
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * COUNT_ID
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * COUNT_CONST
      +	COUNT_CONST, sizeof(THING)
        , ...)
      )
      
      // 2-factor product, only identifiers.
      @@
      identifier SIZE, COUNT;
      @@
      
      - kmalloc
      + kmalloc_array
        (
      -	SIZE * COUNT
      +	COUNT, SIZE
        , ...)
      
      // 3-factor product with 1 sizeof(type) or sizeof(expression), with
      // redundant parens removed.
      @@
      expression THING;
      identifier STRIDE, COUNT;
      type TYPE;
      @@
      
      (
        kmalloc(
      -	sizeof(TYPE) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      )
      
      // 3-factor product with 2 sizeof(variable), with redundant parens removed.
      @@
      expression THING1, THING2;
      identifier COUNT;
      type TYPE1, TYPE2;
      @@
      
      (
        kmalloc(
      -	sizeof(TYPE1) * sizeof(TYPE2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        kmalloc(
      -	sizeof(THING1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(THING1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      )
      
      // 3-factor product, only identifiers, with redundant parens removed.
      @@
      identifier STRIDE, SIZE, COUNT;
      @@
      
      (
        kmalloc(
      -	(COUNT) * STRIDE * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * STRIDE * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      )
      
      // Any remaining multi-factor products, first at least 3-factor products,
      // when they're not all constants...
      @@
      expression E1, E2, E3;
      constant C1, C2, C3;
      @@
      
      (
        kmalloc(C1 * C2 * C3, ...)
      |
        kmalloc(
      -	(E1) * E2 * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	(E1) * (E2) * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	(E1) * (E2) * (E3)
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	E1 * E2 * E3
      +	array3_size(E1, E2, E3)
        , ...)
      )
      
      // And then all remaining 2 factors products when they're not all constants,
      // keeping sizeof() as the second factor argument.
      @@
      expression THING, E1, E2;
      type TYPE;
      constant C1, C2, C3;
      @@
      
      (
        kmalloc(sizeof(THING) * C2, ...)
      |
        kmalloc(sizeof(TYPE) * C2, ...)
      |
        kmalloc(C1 * C2 * C3, ...)
      |
        kmalloc(C1 * C2, ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (E2)
      +	E2, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * E2
      +	E2, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (E2)
      +	E2, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * E2
      +	E2, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	(E1) * E2
      +	E1, E2
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	(E1) * (E2)
      +	E1, E2
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	E1 * E2
      +	E1, E2
        , ...)
      )
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      6da2ec56
  10. 06 Apr, 2018 1 commit
    • Randy Dunlap's avatar
      headers: untangle kmemleak.h from mm.h · 514c6032
      Randy Dunlap authored
      Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious
      reason.  It looks like it's only a convenience, so remove kmemleak.h
      from slab.h and add <linux/kmemleak.h> to any users of kmemleak_* that
      don't already #include it.  Also remove <linux/kmemleak.h> from source
      files that do not use it.
      
      This is tested on i386 allmodconfig and x86_64 allmodconfig.  It would
      be good to run it through the 0day bot for other $ARCHes.  I have
      neither the horsepower nor the storage space for the other $ARCHes.
      
      Update: This patch has been extensively build-tested by both the 0day
      bot & kisskb/ozlabs build farms.  Both of them reported 2 build failures
      for which patches are included here (in v2).
      
      [ slab.h is the second most used header file after module.h; kernel.h is
        right there with slab.h. There could be some minor error in the
        counting due to some #includes having comments after them and I didn't
        combine all of those. ]
      
      [akpm@linux-foundation.org: security/key...
      514c6032
  11. 01 Mar, 2018 1 commit
  12. 25 Aug, 2017 1 commit
  13. 24 Jul, 2017 1 commit
  14. 02 May, 2017 2 commits
  15. 03 Feb, 2017 1 commit
    • Michael S. Tsirkin's avatar
      Revert "vring: Force use of DMA API for ARM-based systems with legacy devices" · 0d5415b4
      Michael S. Tsirkin authored
      This reverts commit c7070619.
      
      This has been shown to regress on some ARM systems:
      
      by forcing on DMA API usage for ARM systems, we have inadvertently
      kicked open a hornets' nest in terms of cache-coherency. Namely that
      unless the virtio device is explicitly described as capable of coherent
      DMA by firmware, the DMA APIs on ARM and other DT-based platforms will
      assume it is non-coherent. This turns out to cause a big problem for the
      likes of QEMU and kvmtool, which generate virtio-mmio devices in their
      guest DTs but neglect to add the often-overlooked "dma-coherent"
      property; as a result, we end up with the guest making non-cacheable
      accesses to the vring, the host doing so cacheably, both talking past
      each other and things going horribly wrong.
      
      We are working on a safer work-around.
      
      Fixes: c7070619
      
       ("vring: Force use of DMA API for ARM-based systems with legacy devices")
      Reported-by: Robin Murphy's avatarRobin Murphy <robin.murphy@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      0d5415b4
  16. 24 Jan, 2017 1 commit
    • Will Deacon's avatar
      vring: Force use of DMA API for ARM-based systems with legacy devices · c7070619
      Will Deacon authored
      Booting Linux on an ARM fastmodel containing an SMMU emulation results
      in an unexpected I/O page fault from the legacy virtio-blk PCI device:
      
      [    1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
      [    1.211800] arm-smmu-v3 2b400000.smmu:	0x00000000fffff010
      [    1.211880] arm-smmu-v3 2b400000.smmu:	0x0000020800000000
      [    1.211959] arm-smmu-v3 2b400000.smmu:	0x00000008fa081002
      [    1.212075] arm-smmu-v3 2b400000.smmu:	0x0000000000000000
      [    1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
      [    1.212234] arm-smmu-v3 2b400000.smmu:	0x00000000fffff010
      [    1.212314] arm-smmu-v3 2b400000.smmu:	0x0000020800000000
      [    1.212394] arm-smmu-v3 2b400000.smmu:	0x00000008fa081000
      [    1.212471] arm-smmu-v3 2b400000.smmu:	0x0000000000000000
      
      <system hangs failing to read partition table>
      
      This is because the legacy virtio-blk device is behind an SMMU, so we
      have consequently swizzled its DMA ops and configured the SMMU to
      translate accesses. This then requires the vring code to use the DMA API
      to establish translations, otherwise all transactions will result in
      fatal faults and termination.
      
      Given that ARM-based systems only see an SMMU if one is really present
      (the topology is all described by firmware tables such as device-tree or
      IORT), then we can safely use the DMA API for all legacy virtio devices.
      Modern devices can advertise the prescense of an IOMMU using the
      VIRTIO_F_IOMMU_PLATFORM feature flag.
      
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: <stable@vger.kernel.org>
      Fixes: 876945db
      
       ("arm64: Hook up IOMMU dma_ops")
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      c7070619
  17. 15 Dec, 2016 2 commits
    • Felipe Franciosi's avatar
      virtio_ring: fix description of virtqueue_get_buf · 0c7eaf59
      Felipe Franciosi authored
      
      
      The device (not the driver) populates the used ring and includes the len
      of how much data was written.
      Signed-off-by: default avatarFelipe Franciosi <felipe@nutanix.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      0c7eaf59
    • Gonglei's avatar
      virtio_ring: fix complaint by sparse · c60923cb
      Gonglei authored
      
      
       # make C=2 CF="-D__CHECK_ENDIAN__" ./drivers/virtio/
      
      drivers/virtio/virtio_ring.c:423:19: warning: incorrect type in assignment (different base types)
      drivers/virtio/virtio_ring.c:423:19:    expected unsigned int [unsigned] [assigned] i
      drivers/virtio/virtio_ring.c:423:19:    got restricted __virtio16 [usertype] next
      drivers/virtio/virtio_ring.c:423:19: warning: incorrect type in assignment (different base types)
      drivers/virtio/virtio_ring.c:423:19:    expected unsigned int [unsigned] [assigned] i
      drivers/virtio/virtio_ring.c:423:19:    got restricted __virtio16 [usertype] next
      drivers/virtio/virtio_ring.c:423:19: warning: incorrect type in assignment (different base types)
      drivers/virtio/virtio_ring.c:423:19:    expected unsigned int [unsigned] [assigned] i
      drivers/virtio/virtio_ring.c:423:19:    got restricted __virtio16 [usertype] next
      drivers/virtio/virtio_ring.c:604:39: warning: incorrect type in initializer (different base types)
      drivers/virtio/virtio_ring.c:604:39:    expected unsigned short [unsigned] [usertype] nextflag
      drivers/virtio/virtio_ring.c:604:39:    got restricted __virtio16
      drivers/virtio/virtio_ring.c:612:33: warning: restricted __virtio16 degrades to integer
      Signed-off-by: default avatarGonglei <arei.gonglei@huawei.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      c60923cb
  18. 30 Oct, 2016 2 commits
  19. 09 Sep, 2016 1 commit
  20. 09 Aug, 2016 2 commits
  21. 01 Aug, 2016 1 commit
    • Michael S. Tsirkin's avatar
      virtio: new feature to detect IOMMU device quirk · 1a937693
      Michael S. Tsirkin authored
      
      
      The interaction between virtio and IOMMUs is messy.
      
      On most systems with virtio, physical addresses match bus addresses,
      and it doesn't particularly matter which one we use to program
      the device.
      
      On some systems, including Xen and any system with a physical device
      that speaks virtio behind a physical IOMMU, we must program the IOMMU
      for virtio DMA to work at all.
      
      On other systems, including SPARC and PPC64, virtio-pci devices are
      enumerated as though they are behind an IOMMU, but the virtio host
      ignores the IOMMU, so we must either pretend that the IOMMU isn't
      there or somehow map everything as the identity.
      
      Add a feature bit to detect that quirk: VIRTIO_F_IOMMU_PLATFORM.
      
      Any device with this feature bit set to 0 needs a quirk and has to be
      passed physical addresses (as opposed to bus addresses) even though
      the device is behind an IOMMU.
      
      Note: it has to be a per-device quirk because for example, there could
      be a mix of passed-through and virtual virtio devices. As another
      example, some devices could be implemented by an out of process
      hypervisor backend (in case of qemu vhost, or vhost-user) and so support
      for an IOMMU needs to be coded up separately.
      
      It would be cleanest to handle this in IOMMU core code, but that needs
      per-device DMA ops. While we are waiting for that to be implemented, use
      a work-around in virtio core.
      
      Note: a "noiommu" feature is a quirk - add a wrapper to make
      that clear.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      1a937693
  22. 01 May, 2016 1 commit
  23. 02 Mar, 2016 3 commits