Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2937516imm; Mon, 24 Sep 2018 12:34:42 -0700 (PDT) X-Google-Smtp-Source: ACcGV63B2WKEp8fiTtZ27XlsysQepXN5Mx8+0rRtHMO52h27n4wch531RXEI4J8wf37yuNkCcf+g X-Received: by 2002:a63:7c5e:: with SMTP id l30-v6mr231274pgn.45.1537817682166; Mon, 24 Sep 2018 12:34:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537817682; cv=none; d=google.com; s=arc-20160816; b=hCYl75KlMMizgzzn8AOHBVsDdBx3NnnT7UHhyDhOe8XyIi5lZfprZ32JUnjZ3hClIA CQi9xemV9/FWGnme0QF3TaXMyIier5GIJQUxZRxNwAS77mLJ3dape62858M8m0aJk6oh n9QgFaIOwnIqU3j9rGxVPajbbVldFQ2vgqd1vKtDzJthQoop9psClQ5irs4xh/K8+Xwl ByVz+gMu/S5wVS8MtDUCYejIh+2zDk89nN9l3D3on3412Jh9WWcHxVo7a3AsSv2bP0Wa Llm+LXhGbEds6TJSApAlk6om9Q16Mj32BlxHP+WNS7BH4u669CWs0ihHyEtner+bX20q k5ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=k7iQCXwMvlhTNvfq6aPrxiTLrLx04wD5o2gOyZQCUnI=; b=Y3gK5lv5HxwKsqVQe2HSeIxIVsxJjqttyVnbYZ7YnFrdZkNvdWI+AHEzX/WBHUAYel 3xYC3Y0FztJBmdxSvyMafN60pHvLiYaso70BC9sSHOkXo1R5eyPTHhkuKeRK3pJ9Lak9 DePUmFSKUPUxG2cQMbBSAVO5m5AVR+zM+zhCXpMAjJEXKfDRgr/CZMftmzt2ZEUXck+O nhCU8xzXAcPCt4WB6m+LulqEJdPisuo7ycC2F7Hr+oeA9FHERybR19wYPGbHENbdH8wl pn2a37twgce/YqnfUIoNAg/b6Y/y+W2XZeu1QdXLcV9ULin5gKvG0kxnymTxEXGKfM8t m8ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=IvcNmsaI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w11-v6si142677pgm.616.2018.09.24.12.34.26; Mon, 24 Sep 2018 12:34:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=IvcNmsaI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730854AbeIYBBb (ORCPT + 99 others); Mon, 24 Sep 2018 21:01:31 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:58740 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727477AbeIYBBb (ORCPT ); Mon, 24 Sep 2018 21:01:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=k7iQCXwMvlhTNvfq6aPrxiTLrLx04wD5o2gOyZQCUnI=; b=IvcNmsaIWJB7U+vnVoPprpgaZ Rh+p0blwp3P4hvb+SmnSOmI8TuUd09L9g3D5fmhCNfo0b9o4koeEY3PN+8UizNuYBgTvrQNLHl6ZO IWRXQ0MqHaKq4tvLRbuQaOA07K+B0Ta6LjoEb2idpQMV736CUOznrKzakj1xqXKHcpFJslkKYLS7f +nlMTB8INvmiCWUDBXmjnSsupA+hYQJhE3XEgbUyrRF4mDobuEeCt9Q6sPUHlIjEULe68Ukizr+99 YEHbNXmNUXgH0r6TabxeLU5/bc1oksLZxqvSM79yYU6n9fbTNxoXr6Yl4xkSdkVV2bYPnxHeqw0g9 9WePqATsA==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1g4W3O-0007B1-2b; Mon, 24 Sep 2018 18:57:54 +0000 Date: Mon, 24 Sep 2018 11:57:53 -0700 From: Matthew Wilcox To: Bart Van Assche Cc: Andrey Ryabinin , Ming Lei , Vitaly Kuznetsov , Christoph Hellwig , Ming Lei , linux-block , linux-mm , Linux FS Devel , "open list:XFS FILESYSTEM" , Dave Chinner , Linux Kernel Mailing List , Jens Axboe , Christoph Lameter , Linus Torvalds , Greg Kroah-Hartman Subject: Re: block: DMA alignment of IO buffer allocated from slab Message-ID: <20180924185753.GA32269@bombadil.infradead.org> References: <87h8ij0zot.fsf@vitty.brq.redhat.com> <20180923224206.GA13618@ming.t460p> <38c03920-0fd0-0a39-2a6e-70cd8cb4ef34@virtuozzo.com> <20a20568-5089-541d-3cee-546e549a0bc8@acm.org> <12eee877-affa-c822-c9d5-fda3aa0a50da@virtuozzo.com> <1537801706.195115.7.camel@acm.org> <1537804720.195115.9.camel@acm.org> <10c706fd-2252-f11b-312e-ae0d97d9a538@virtuozzo.com> <1537805984.195115.14.camel@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1537805984.195115.14.camel@acm.org> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 24, 2018 at 09:19:44AM -0700, Bart Van Assche wrote: > That means that two buffers allocated with kmalloc() may share a cache line on > x86-64. Since it is allowed to use a buffer allocated by kmalloc() for DMA, can > this lead to data corruption, e.g. if the CPU writes into one buffer allocated > with kmalloc() and a device performs a DMA write to another kmalloc() buffer and > both write operations affect the same cache line? You're not supposed to use kmalloc memory for DMA. This is why we have dma_alloc_coherent() and friends. Also, from DMA-API.txt: Memory coherency operates at a granularity called the cache line width. In order for memory mapped by this API to operate correctly, the mapped region must begin exactly on a cache line boundary and end exactly on one (to prevent two separately mapped regions from sharing a single cache line). Since the cache line size may not be known at compile time, the API will not enforce this requirement. Therefore, it is recommended that driver writers who don't take special care to determine the cache line size at run time only map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries).