search for: dma_mask

> static inline bool dma_addressing_limited(struct device *dev) > { > - return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) < > - dma_get_required_mask(dev); > + return WARN_ON_ONCE(!dev->dma_mask) ? false : > + min_not_zero(*dev->dma_mask, dev->bus_dma_mask) < > + dma_get_required_mask(dev); This should really use a separate if statement, but I can fix that up when...

When running a 32bit kernel there are still some pci devices capable of 64bit addressing (eg. sound/pci/hda/hda_intel.c) If these drivers are setting: dev->coherent_dma_mask = 0xFFFFFFFFFFFFFFFF why dma_alloc_coherent_mask is returning unsigned long instead of dma_addr_t resulting in truncation of the dma_mask to 32bit if running a 32bit kernel? There are some examples where the dma_alloc_coherent running 32bit kernel can return a machine address bigger than 32bit....

...e() doesn't stop after range_straddles_page_boundary(), but calls spinlock functions, memcpy() and xen_phys_to_bus() as well. This patch introduces the swiotlb-xen:bounced event, which also prints out the following informations to help you find out why bouncing happened: dev_name: 0000:08:00.0 dma_mask=ffffffffffffffff dev_addr=9149f000 size=32768 swiotlb_force=0 If (dev_addr + size + 1) > dma_mask, the buffer is out of the device's DMA range. If swiotlb_force == 1, you should really change the kernel parameters. Otherwise, the buffer is not contiguous in mfn space. Signed-off-by: Zoltan...

...e() doesn't stop after range_straddles_page_boundary(), but calls spinlock functions, memcpy() and xen_phys_to_bus() as well. This patch introduces the swiotlb-xen:bounced event, which also prints out the following informations to help you find out why bouncing happened: dev_name: 0000:08:00.0 dma_mask=ffffffffffffffff dev_addr=9149f000 size=32768 swiotlb_force=0 If (dev_addr + size + 1) > dma_mask, the buffer is out of the device's DMA range. If swiotlb_force == 1, you should really change the kernel parameters. Otherwise, the buffer is not contiguous in mfn space. Signed-off-by: Zoltan...

...e() doesn't stop after range_straddles_page_boundary(), but calls spinlock functions, memcpy() and xen_phys_to_bus() as well. This patch introduces the swiotlb-xen:bounced event, which also prints out the following informations to help you find out why bouncing happened: dev_name: 0000:08:00.0 dma_mask=ffffffffffffffff dev_addr=9149f000 size=32768 swiotlb_force=0 If (dev_addr + size + 1) > dma_mask, the buffer is out of the device's DMA range. If swiotlb_force == 1, you should really change the kernel parameters. Otherwise, the buffer is not contiguous in mfn space. Signed-off-by: Zoltan...

...doesn't stop after range_straddles_page_boundary(), but calls spinlock functions, memcpy() and xen_phys_to_bus() as well. This patch introduces the swiotlb:swiotlb_bounced event, which also prints out the following informations to help you find out why bouncing happened: dev_name: 0000:08:00.0 dma_mask=ffffffffffffffff dev_addr=9149f000 size=32768 swiotlb_force=0 If you use Xen, and (dev_addr + size + 1) > dma_mask, the buffer is out of the device's DMA range. If swiotlb_force == 1, you should really change the kernel parameters. Otherwise, the buffer is not contiguous in mfn space. Sign...

...doesn't stop after range_straddles_page_boundary(), but calls spinlock functions, memcpy() and xen_phys_to_bus() as well. This patch introduces the swiotlb:swiotlb_bounced event, which also prints out the following informations to help you find out why bouncing happened: dev_name: 0000:08:00.0 dma_mask=ffffffffffffffff dev_addr=9149f000 size=32768 swiotlb_force=0 If you use Xen, and (dev_addr + size + 1) > dma_mask, the buffer is out of the device's DMA range. If swiotlb_force == 1, you should really change the kernel parameters. Otherwise, the buffer is not contiguous in mfn space. Sign...

...doesn't stop after range_straddles_page_boundary(), but calls spinlock functions, memcpy() and xen_phys_to_bus() as well. This patch introduces the swiotlb:swiotlb_bounced event, which also prints out the following informations to help you find out why bouncing happened: dev_name: 0000:08:00.0 dma_mask=ffffffffffffffff dev_addr=9149f000 size=32768 swiotlb_force=0 If you use Xen, and (dev_addr + size + 1) > dma_mask, the buffer is out of the device's DMA range. If swiotlb_force == 1, you should really change the kernel parameters. Otherwise, the buffer is not contiguous in mfn space. Sign...

When running a guest featuring a virtio-blk-pci protected with a virtual IOMMU we hit a NULL pointer dereference. This series removes the dma_max_mapping_size() call in virtio_max_dma_size when the device does not have any dma_mask set. A check is also added to early return in dma_addressing_limited() if the dma_mask is NULL. Eric Auger (2): dma-mapping: Protect dma_addressing_limited against NULL dma_mask virtio/virtio_ring: Fix the dma_max_mapping_size call drivers/virtio/virtio_ring.c | 2 +- include/linux/dma-mappi...

.../drivers/virtio/virtio_ring.c >>> @@ -262,7 +262,7 @@ size_t virtio_max_dma_size(struct virtio_device *vdev) >>> { >>> size_t max_segment_size = SIZE_MAX; >>> - if (vring_use_dma_api(vdev)) >>> + if (vring_use_dma_api(vdev) && vdev->dev.dma_mask) >> >> Hmm, might it make sense to roll that check up into vring_use_dma_api() >> itself? After all, if the device has no mask then it's likely that other >> DMA API ops wouldn't really work as expected either. > > Makes sense to me. > I am confused: if...

.../drivers/virtio/virtio_ring.c >>> @@ -262,7 +262,7 @@ size_t virtio_max_dma_size(struct virtio_device *vdev) >>> { >>> size_t max_segment_size = SIZE_MAX; >>> - if (vring_use_dma_api(vdev)) >>> + if (vring_use_dma_api(vdev) && vdev->dev.dma_mask) >> >> Hmm, might it make sense to roll that check up into vring_use_dma_api() >> itself? After all, if the device has no mask then it's likely that other >> DMA API ops wouldn't really work as expected either. > > Makes sense to me. > I am confused: if...

We currently have cases where the dma_addressing_limited() gets called with dma_mask unset. This causes a NULL pointer dereference. Use dma_get_mask() accessor to prevent the crash. Fixes: b866455423e0 ("dma-mapping: add a dma_addressing_limited helper") Signed-off-by: Eric Auger <eric.auger at redhat.com> --- v1 -> v2: - was [PATCH 1/2] dma-mapping: Protect...

We currently have cases where the dma_addressing_limited() gets called with dma_mask unset. This causes a NULL pointer dereference. Use dma_get_mask() accessor to prevent the crash. Fixes: b866455423e0 ("dma-mapping: add a dma_addressing_limited helper") Signed-off-by: Eric Auger <eric.auger at redhat.com> --- v1 -> v2: - was [PATCH 1/2] dma-mapping: Protect...

dma_addressing_limited() should not be called on a device with a NULL dma_mask. If this occurs let's WARN_ON_ONCE and immediately return. Existing call sites are updated separately. Fixes: b866455423e0 ("dma-mapping: add a dma_addressing_limited helper") Signed-off-by: Eric Auger <eric.auger at redhat.com> --- v1 -> v2: - add a WARN_ON_ONCE() - rewor...

..., 26 Apr 2019, Halil Pasic wrote: > @@ -224,6 +228,9 @@ struct subchannel *css_alloc_subchannel(struct subchannel_id schid, > INIT_WORK(&sch->todo_work, css_sch_todo); > sch->dev.release = &css_subchannel_release; > device_initialize(&sch->dev); > + sch->dma_mask = css_dev_dma_mask; > + sch->dev.dma_mask = &sch->dma_mask; > + sch->dev.coherent_dma_mask = sch->dma_mask; Could we do: sch->dev.dma_mask = &sch->dev.coherent_dma_mask; sch->dev.coherent_dma_mask = css_dev_dma_mask; ? > +#define POOL_INIT_PAGES 1 > +sta...

..., 26 Apr 2019, Halil Pasic wrote: > @@ -224,6 +228,9 @@ struct subchannel *css_alloc_subchannel(struct subchannel_id schid, > INIT_WORK(&sch->todo_work, css_sch_todo); > sch->dev.release = &css_subchannel_release; > device_initialize(&sch->dev); > + sch->dma_mask = css_dev_dma_mask; > + sch->dev.dma_mask = &sch->dma_mask; > + sch->dev.coherent_dma_mask = sch->dma_mask; Could we do: sch->dev.dma_mask = &sch->dev.coherent_dma_mask; sch->dev.coherent_dma_mask = css_dev_dma_mask; ? > +#define POOL_INIT_PAGES 1 > +sta...

...rs/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -262,7 +262,7 @@ size_t virtio_max_dma_size(struct virtio_device *vdev) > { > size_t max_segment_size = SIZE_MAX; > > - if (vring_use_dma_api(vdev)) > + if (vring_use_dma_api(vdev) && vdev->dev.dma_mask) Hmm, might it make sense to roll that check up into vring_use_dma_api() itself? After all, if the device has no mask then it's likely that other DMA API ops wouldn't really work as expected either. Robin. > max_segment_size = dma_max_mapping_size(&vdev->dev); > &gt...

...rs/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -262,7 +262,7 @@ size_t virtio_max_dma_size(struct virtio_device *vdev) > { > size_t max_segment_size = SIZE_MAX; > > - if (vring_use_dma_api(vdev)) > + if (vring_use_dma_api(vdev) && vdev->dev.dma_mask) Hmm, might it make sense to roll that check up into vring_use_dma_api() itself? After all, if the device has no mask then it's likely that other DMA API ops wouldn't really work as expected either. Robin. > max_segment_size = dma_max_mapping_size(&vdev->dev); > &gt...

...ion(+), 1 deletion(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 73b4f84cf449..504f2db75eda 100644 --- a/drivers/iommu/amd_iommu.c +++ b/drivers/iommu/amd_iommu.c @@ -326,7 +326,7 @@ static bool check_device(struct device *dev) { int devid; - if (!dev || !dev->dma_mask) + if (!dev) return false; devid = get_device_id(dev); -- 2.17.1

...90/virtio/virtio_ccw.c > index 6d989c360f38..bb7a92316fc8 100644 > --- a/drivers/s390/virtio/virtio_ccw.c > +++ b/drivers/s390/virtio/virtio_ccw.c > @@ -66,7 +66,6 @@ struct virtio_ccw_device { > bool device_lost; > unsigned int config_ready; > void *airq_info; > - u64 dma_mask; > }; > > struct vq_info_block_legacy { > @@ -1255,16 +1254,7 @@ static int virtio_ccw_online(struct ccw_device *cdev) > ret = -ENOMEM; > goto out_free; > } > - > vcdev->vdev.dev.parent = &cdev->dev; > - cdev->dev.dma_mask = &vcdev->dm...