| Message ID | 1505708574-5281-1-git-send-email-chenhc@lemote.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
Please send all patches in the series to the same to and cc lists. On Mon, Sep 18, 2017 at 12:22:54PM +0800, Huacai Chen wrote: > In non-coherent DMA mode, kernel uses cache flushing operations to > maintain I/O coherency, so scsi's block queue should be aligned to > ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least > on MIPS: > > Step 1, dma_map_single > Step 2, cache_invalidate (no writeback) > Step 3, dma_from_device > Step 4, dma_unmap_single > > If a DMA buffer and a kernel structure share a same cache line, and if > the kernel structure has dirty data, cache_invalidate (no writeback) > will cause data lost. And as said before we must _always_ align to dma_get_cache_alignment. This is even documented in Documentation/DMA-API.txt: ------------------------------ snip ------------------------------ int dma_get_cache_alignment(void) Returns the processor cache alignment. This is the absolute minimum alignment *and* width that you must observe when either mapping memory or doing partial flushes. ------------------------------ snip ------------------------------ > + if (device_is_coherent(dev)) > + blk_queue_dma_alignment(q, 0x04 - 1); > + else > + blk_queue_dma_alignment(q, dma_get_cache_alignment() - 1); So as said before this should become something like: blk_queue_dma_alignment(q, max(0x04, dma_get_cache_alignment()) - 1);
Hi Huacai,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.14-rc1 next-20170915]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Huacai-Chen/dma-mapping-Introduce-device_is_coherent-as-a-helper/20170918-122824
config: m68k-sun3_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All errors (new ones prefixed by >>):
drivers/scsi/scsi_lib.c: In function '__scsi_init_queue':
>> drivers/scsi/scsi_lib.c:2139:2: error: implicit declaration of function 'device_is_coherent' [-Werror=implicit-function-declaration]
if (device_is_coherent(dev))
^
drivers/scsi/scsi_lib.c:2142:3: error: implicit declaration of function 'dma_get_cache_alignment' [-Werror=implicit-function-declaration]
blk_queue_dma_alignment(q, dma_get_cache_alignment() - 1);
^
cc1: some warnings being treated as errors
vim +/device_is_coherent +2139 drivers/scsi/scsi_lib.c
2103
2104 void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
2105 {
2106 struct device *dev = shost->dma_dev;
2107
2108 queue_flag_set_unlocked(QUEUE_FLAG_SCSI_PASSTHROUGH, q);
2109
2110 /*
2111 * this limit is imposed by hardware restrictions
2112 */
2113 blk_queue_max_segments(q, min_t(unsigned short, shost->sg_tablesize,
2114 SG_MAX_SEGMENTS));
2115
2116 if (scsi_host_prot_dma(shost)) {
2117 shost->sg_prot_tablesize =
2118 min_not_zero(shost->sg_prot_tablesize,
2119 (unsigned short)SCSI_MAX_PROT_SG_SEGMENTS);
2120 BUG_ON(shost->sg_prot_tablesize < shost->sg_tablesize);
2121 blk_queue_max_integrity_segments(q, shost->sg_prot_tablesize);
2122 }
2123
2124 blk_queue_max_hw_sectors(q, shost->max_sectors);
2125 blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
2126 blk_queue_segment_boundary(q, shost->dma_boundary);
2127 dma_set_seg_boundary(dev, shost->dma_boundary);
2128
2129 blk_queue_max_segment_size(q, dma_get_max_seg_size(dev));
2130
2131 if (!shost->use_clustering)
2132 q->limits.cluster = 0;
2133
2134 /*
2135 * set a reasonable default alignment on word/cacheline boundaries:
2136 * the host and device may alter it using
2137 * blk_queue_update_dma_alignment() later.
2138 */
> 2139 if (device_is_coherent(dev))
2140 blk_queue_dma_alignment(q, 0x04 - 1);
2141 else
2142 blk_queue_dma_alignment(q, dma_get_cache_alignment() - 1);
2143 }
2144 EXPORT_SYMBOL_GPL(__scsi_init_queue);
2145
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi, Christoph, I don't think dma_get_cache_alignment is the "absolute minimum alignment" in all cases. At least on MIPS/Loongson, if we use I/O coherent mode (Cached DMA mode), align block queue to 4Bytes is enough. If we align block queue to dma_get_cache_alignment in I/O coherent mode, there are peformance lost because we cannot use zero-copy in most cases (user buffers are usually not aligned). Huacai ------------------ Original ------------------ From: "Christoph Hellwig"<hch@infradead.org>; Date: Mon, Sep 18, 2017 01:20 PM To: "Huacai Chen"<chenhc@lemote.com>; Cc: "James E . J . Bottomley"<jejb@linux.vnet.ibm.com>; "Martin K . Petersen"<martin.petersen@oracle.com>; "Andrew Morton"<akpm@linux-foundation.org>; "Fuxin Zhang"<zhangfx@lemote.com>; "linux-scsi"<linux-scsi@vger.kernel.org>; "linux-kernel"<linux-kernel@vger.kernel.org>; "stable"<stable@vger.kernel.org>; Subject: Re: [PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN innon-coherent DMA mode Please send all patches in the series to the same to and cc lists. On Mon, Sep 18, 2017 at 12:22:54PM +0800, Huacai Chen wrote: > In non-coherent DMA mode, kernel uses cache flushing operations to > maintain I/O coherency, so scsi's block queue should be aligned to > ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least > on MIPS: > > Step 1, dma_map_single > Step 2, cache_invalidate (no writeback) > Step 3, dma_from_device > Step 4, dma_unmap_single > > If a DMA buffer and a kernel structure share a same cache line, and if > the kernel structure has dirty data, cache_invalidate (no writeback) > will cause data lost. And as said before we must _always_ align to dma_get_cache_alignment. This is even documented in Documentation/DMA-API.txt: ------------------------------ snip ------------------------------ int dma_get_cache_alignment(void) Returns the processor cache alignment. This is the absolute minimum alignment *and* width that you must observe when either mapping memory or doing partial flushes. ------------------------------ snip ------------------------------ > + if (device_is_coherent(dev)) > + blk_queue_dma_alignment(q, 0x04 - 1); > + else > + blk_queue_dma_alignment(q, dma_get_cache_alignment() - 1); So as said before this should become something like: blk_queue_dma_alignment(q, max(0x04, dma_get_cache_alignment()) - 1);
On Mon, Sep 18, 2017 at 03:03:30PM +0800, 陈华才 wrote:
> I don't think dma_get_cache_alignment is the "absolute minimum alignment" in all cases. At least on MIPS/Loongson, if we use I/O coherent mode (Cached DMA mode), align block queue to 4Bytes is enough. If we align block queue to dma_get_cache_alignment in I/O coherent mode, there are peformance lost because we cannot use zero-copy in most cases (user buffers are usually not aligned).
If you systems is I/O coherent it should report 1 ARCH_DMA_MINALIGN /
dma_get_cache_alignment().
Note that many drivers only support 512 byte aligned mappings for
block I/O and they've done pretty fine so far.
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 9cf6a80..d5059b9 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -2132,11 +2132,14 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q) q->limits.cluster = 0; /* - * set a reasonable default alignment on word boundaries: the - * host and device may alter it using + * set a reasonable default alignment on word/cacheline boundaries: + * the host and device may alter it using * blk_queue_update_dma_alignment() later. */ - blk_queue_dma_alignment(q, 0x03); + if (device_is_coherent(dev)) + blk_queue_dma_alignment(q, 0x04 - 1); + else + blk_queue_dma_alignment(q, dma_get_cache_alignment() - 1); } EXPORT_SYMBOL_GPL(__scsi_init_queue);
In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so scsi's block queue should be aligned to ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least on MIPS: Step 1, dma_map_single Step 2, cache_invalidate (no writeback) Step 3, dma_from_device Step 4, dma_unmap_single If a DMA buffer and a kernel structure share a same cache line, and if the kernel structure has dirty data, cache_invalidate (no writeback) will cause data lost. Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen <chenhc@lemote.com> --- drivers/scsi/scsi_lib.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)