From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750984AbdJTEZ3 (ORCPT ); Fri, 20 Oct 2017 00:25:29 -0400 Received: from smtpbg202.qq.com ([184.105.206.29]:46167 "EHLO smtpbg202.qq.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750737AbdJTEZ1 (ORCPT ); Fri, 20 Oct 2017 00:25:27 -0400 X-QQ-GoodBg: 0 X-QQ-SSF: 00100000000000F0 X-QQ-FEAT: f/3apwfgnQU1ySdl8o3PZBhXs4bxOKvFPhYurYjFOD84NDthvKz5xmBaA2P8R PbIT8mgic5ehDxNrQcjFbocF+T+rwIXMNl9b3GPhOjgIKCrDETkiKJFlfAkJQ6O5A5XPsMA Yhi5zuNRbkO4jZIzeJBNlggqPHalNI7yy6tdFuWXXg4aflvwF8t/AINa9Iz1dA2dCwr7TXm Dgi7k2ggaDfYcn/KnNGF6SKe7ZgpUrbqcfVMiQz+7NOM1v6zi8dizKYxXOUuyxnGOmNJR7z 3CWwSkNgi8VpdIGX/0SJzJeOjVe3eGJ4MCjA== X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 222.92.124.153 X-QQ-STYLE: X-QQ-mid: bizmailfree34t1508473517t6793 From: "=?utf-8?B?6ZmI5Y2O5omN?=" To: "=?utf-8?B?TWF0dCBSZWRmZWFybg==?=" , "=?utf-8?B?VGVqdW4gSGVv?=" Cc: "=?utf-8?B?Q2hyaXN0b3BoIEhlbGx3aWc=?=" , "=?utf-8?B?TWFyZWsgU3p5cHJvd3NraQ==?=" , "=?utf-8?B?Um9iaW4gTXVycGh5?=" , "=?utf-8?B?QW5kcmV3TW9ydG9u?=" , "=?utf-8?B?RnV4aW4gWmhhbmc=?=" , "=?utf-8?B?bGludXgta2VybmVs?=" , "=?utf-8?B?UmFsZiBCYWVjaGxl?=" , "=?utf-8?B?SmFtZXNIb2dhbg==?=" , "=?utf-8?B?bGludXgtbWlwcw==?=" , "=?utf-8?B?SmFtZXMgRSAuIEogLkJvdHRvbWxleQ==?=" , "=?utf-8?B?TWFydGluIEsgLiBQZXRlcnNlbg==?=" , "=?utf-8?B?bGludXgtc2NzaQ==?=" , "=?utf-8?B?bGludXgtaWRl?=" , "=?utf-8?B?c3RhYmxl?=" Subject: Re: [PATCH V8 5/5] libata: Align DMA buffer todma_get_cache_alignment() Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Fri, 20 Oct 2017 12:25:17 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x References: <1508227542-13165-1-git-send-email-chenhc@lemote.com> <1508227542-13165-5-git-send-email-chenhc@lemote.com> <20171018130353.GA1302522@devbig577.frc2.facebook.com> <0ba3dc38-9020-1062-57de-0ada2cfd43a9@mips.com> In-Reply-To: <0ba3dc38-9020-1062-57de-0ada2cfd43a9@mips.com> X-QQ-ReplyHash: 3461816256 X-QQ-SENDSIZE: 520 Feedback-ID: bizmailfree:lemote.com:qybgforeign:qybgforeign1 X-QQ-Bgrelay: 1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v9K4Pacm006940 Hi, Matt, I found that 4ee34ea3a12396f35b26d90a094c75db ("libata: Align ata_device's id on a cacheline") can resolve everything. Because the size of id[ATA_ID_WORDS] is already aligned and devslp_timing needn't to be aligned. So, In V9 of this series I will drop this patch. Why I had problems before? because I used linux-4.4. Huacai ------------------ Original ------------------ From: "Matt Redfearn"; Date: Thu, Oct 19, 2017 03:52 PM To: "Tejun Heo"; "Huacai Chen"; Cc: "Christoph Hellwig"; "Marek Szyprowski"; "Robin Murphy"; "AndrewMorton"; "Fuxin Zhang"; "linux-kernel"; "Ralf Baechle"; "JamesHogan"; "linux-mips"; "James E . J .Bottomley"; "Martin K . Petersen"; "linux-scsi"; "linux-ide"; "stable"; Subject: Re: [PATCH V8 5/5] libata: Align DMA buffer todma_get_cache_alignment() On 18/10/17 14:03, Tejun Heo wrote: > On Tue, Oct 17, 2017 at 04:05:42PM +0800, Huacai Chen wrote: >> In non-coherent DMA mode, kernel uses cache flushing operations to >> maintain I/O coherency, so in ata_do_dev_read_id() the DMA buffer >> should be aligned to ARCH_DMA_MINALIGN. Otherwise, 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 corruption. >> >> Cc: stable@vger.kernel.org >> Signed-off-by: Huacai Chen >> --- >> drivers/ata/libata-core.c | 15 +++++++++++++-- >> 1 file changed, 13 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >> index ee4c1ec..e134955 100644 >> --- a/drivers/ata/libata-core.c >> +++ b/drivers/ata/libata-core.c >> @@ -1833,8 +1833,19 @@ static u32 ata_pio_mask_no_iordy(const struct ata_device *adev) >> unsigned int ata_do_dev_read_id(struct ata_device *dev, >> struct ata_taskfile *tf, u16 *id) >> { >> - return ata_exec_internal(dev, tf, NULL, DMA_FROM_DEVICE, >> - id, sizeof(id[0]) * ATA_ID_WORDS, 0); >> + u16 *devid; >> + int res, size = sizeof(u16) * ATA_ID_WORDS; >> + >> + if (IS_ALIGNED((unsigned long)id, dma_get_cache_alignment(&dev->tdev))) >> + res = ata_exec_internal(dev, tf, NULL, DMA_FROM_DEVICE, id, size, 0); >> + else { >> + devid = kmalloc(size, GFP_KERNEL); >> + res = ata_exec_internal(dev, tf, NULL, DMA_FROM_DEVICE, devid, size, 0); >> + memcpy(id, devid, size); >> + kfree(devid); >> + } >> + >> + return res; > Hmm... I think it'd be a lot better to ensure that the buffers are > aligned properly to begin with. There are only two buffers which are > used for id reading - ata_port->sector_buf and ata_device->id. Both > are embedded arrays but making them separately allocated aligned > buffers shouldn't be difficult. > > Thanks. FWIW, I agree that the buffers used for DMA should be split out from the structure. We ran into this problem on MIPS last year, 4ee34ea3a12396f35b26d90a094c75db95080baa ("libata: Align ata_device's id on a cacheline") partially fixed it, but likely should have also cacheline aligned the following devslp_timing in the struct such that we guarantee that members of the struct not used for DMA do not share the same cacheline as the DMA buffer. Not having this means that architectures, such as MIPS, which in some cases have to perform manual invalidation of DMA buffer can clobber valid adjacent data if it is in the same cacheline. Thanks, Matt