Re: [RFC/RFT][PATCH] dma-mapping: set default segment_boundary_mask to ULONG_MAX
On Mon, Apr 06, 2020 at 02:48:13PM +0100, Robin Murphy wrote: > On 2020-04-05 1:51 am, Nicolin Chen wrote: > > The default segment_boundary_mask was set to DMA_BIT_MAKS(32) > > a decade ago by referencing SCSI/block subsystem, as a 32-bit > > mask was good enough for most of the devices. > > > > Now more and more drivers set dma_masks above DMA_BIT_MAKS(32) > > while only a handful of them call dma_set_seg_boundary(). This > > means that most drivers have a 4GB segmention boundary because > > DMA API returns a 32-bit default value, though they might not > > really have such a limit. > > > > The default segment_boundary_mask should mean "no limit" since > > the device doesn't explicitly set the mask. But a 32-bit mask > > certainly limits those devices capable of 32+ bits addressing. > > > > And this 32-bit boundary mask might result in a situation that > > when dma-iommu maps a DMA buffer (size > 4GB), iommu_map_sg() > > cuts the IOVA region into discontiguous pieces, and creates a > > faulty IOVA mapping that overlaps some physical memory outside > > the scatter list, which might lead to some random kernel panic > > after DMA overwrites that faulty IOVA space. > > Once again, get rid of this paragraph - it doesn't have much to do with the > *default* value since it describes a behaviour general to any boundary mask. > Plus it effectively says "if a driver uses a DMA-mapped scatterlist > incorrectly, this change can help paper over the bug", which is rather the > opposite of a good justification. Np. Will drop it and resend. > (for example most SATA devices end up with a 64KB boundary mask, such that > padding the IOVAs to provide the appropriate alignment happens very > frequently, and they've been working just fine for years now) Okay. Thanks! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC/RFT][PATCH] dma-mapping: set default segment_boundary_mask to ULONG_MAX
On 2020-04-05 1:51 am, Nicolin Chen wrote: The default segment_boundary_mask was set to DMA_BIT_MAKS(32) a decade ago by referencing SCSI/block subsystem, as a 32-bit mask was good enough for most of the devices. Now more and more drivers set dma_masks above DMA_BIT_MAKS(32) while only a handful of them call dma_set_seg_boundary(). This means that most drivers have a 4GB segmention boundary because DMA API returns a 32-bit default value, though they might not really have such a limit. The default segment_boundary_mask should mean "no limit" since the device doesn't explicitly set the mask. But a 32-bit mask certainly limits those devices capable of 32+ bits addressing. And this 32-bit boundary mask might result in a situation that when dma-iommu maps a DMA buffer (size > 4GB), iommu_map_sg() cuts the IOVA region into discontiguous pieces, and creates a faulty IOVA mapping that overlaps some physical memory outside the scatter list, which might lead to some random kernel panic after DMA overwrites that faulty IOVA space. Once again, get rid of this paragraph - it doesn't have much to do with the *default* value since it describes a behaviour general to any boundary mask. Plus it effectively says "if a driver uses a DMA-mapped scatterlist incorrectly, this change can help paper over the bug", which is rather the opposite of a good justification. (for example most SATA devices end up with a 64KB boundary mask, such that padding the IOVAs to provide the appropriate alignment happens very frequently, and they've been working just fine for years now) Robin. So this patch sets default segment_boundary_mask to ULONG_MAX. Signed-off-by: Nicolin Chen --- include/linux/dma-mapping.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 330ad58fbf4d..ff8cefe85f30 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -736,7 +736,7 @@ static inline unsigned long dma_get_seg_boundary(struct device *dev) { if (dev->dma_parms && dev->dma_parms->segment_boundary_mask) return dev->dma_parms->segment_boundary_mask; - return DMA_BIT_MASK(32); + return ULONG_MAX; } static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC/RFT][PATCH] dma-mapping: set default segment_boundary_mask to ULONG_MAX
The default segment_boundary_mask was set to DMA_BIT_MAKS(32) a decade ago by referencing SCSI/block subsystem, as a 32-bit mask was good enough for most of the devices. Now more and more drivers set dma_masks above DMA_BIT_MAKS(32) while only a handful of them call dma_set_seg_boundary(). This means that most drivers have a 4GB segmention boundary because DMA API returns a 32-bit default value, though they might not really have such a limit. The default segment_boundary_mask should mean "no limit" since the device doesn't explicitly set the mask. But a 32-bit mask certainly limits those devices capable of 32+ bits addressing. And this 32-bit boundary mask might result in a situation that when dma-iommu maps a DMA buffer (size > 4GB), iommu_map_sg() cuts the IOVA region into discontiguous pieces, and creates a faulty IOVA mapping that overlaps some physical memory outside the scatter list, which might lead to some random kernel panic after DMA overwrites that faulty IOVA space. So this patch sets default segment_boundary_mask to ULONG_MAX. Signed-off-by: Nicolin Chen --- include/linux/dma-mapping.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 330ad58fbf4d..ff8cefe85f30 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -736,7 +736,7 @@ static inline unsigned long dma_get_seg_boundary(struct device *dev) { if (dev->dma_parms && dev->dma_parms->segment_boundary_mask) return dev->dma_parms->segment_boundary_mask; - return DMA_BIT_MASK(32); + return ULONG_MAX; } static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask) -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu