[PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN in non-coherent DMA mode

[PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN in non-coherent DMA mode

[Huacai Chen]

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(-)

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);
 
-- 
2.7.0

Re: [PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN in non-coherent DMA mode

[Christoph Hellwig]

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);

Re: [PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN in non-coherent DMA mode

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 3003 bytes --]

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

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 12226 bytes --]

Re: [PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN innon-coherent DMA mode

[陈华才]

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);

Re: [PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN innon-coherent DMA mode

[Christoph Hellwig]

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.