Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3016535imm; Mon, 24 Sep 2018 14:09:46 -0700 (PDT) X-Google-Smtp-Source: ACcGV62DBq83tAxpZ8rFs083pub9KiH4nAcUjBmxphQUxA/9C3vTI94yrmAQYGBZ1Seh9KzxDw3L X-Received: by 2002:a63:306:: with SMTP id 6-v6mr436564pgd.393.1537823386568; Mon, 24 Sep 2018 14:09:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537823386; cv=none; d=google.com; s=arc-20160816; b=f+ad9yVVgaBNtizChp8Cq6DuDWz9G7z7izy5TTfKUKPbE59Wdyg3jd/RM2GMzcYZID iptXXplI73L/IK24NDxNH+FdDlBlabyk2ixYkyAuQFXQB5cUODuogreEJALYD6P7NZQx HQkyF5XbL1U4dz6rCWVxpV34iKvgb7G+gRo/V9D1eEp4K7ilNnSkU09U0ZXO0MjbXAYt Jel8YmC2z/5PrYpuotbA+VyuqQ/SUErfzpyfakzovkP8vDUMZuxOwzLd0fp9gXSDS7D7 Voa059pdRD3m0sRYln9FHn9vx9N9IXxHyPKqYRT2snW2yxCxsg4VT1i38u2+gbyP+quT sn5w== 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=mPr8K+6sp9gKpKbjou9LzZieACzDvEfRFHzlw1LN+rc=; b=ioOq6OvkAelL76yhEqyGEWjl7pUfU464uvdrxGfLwFAFVPkDSAin0rp8B+RJ6PAfTW Zy90thHYTr/ZDwd/ZWfKIAf8qdCbdoMzx706WawYsICDYp+qAvXQPtvpKux+GBMp4iul 1lECcYkieaSCL9PilpGWgx4gRx/4ET1bNACa8vgMwkmo206EQQsfGbrIsSfN0M5Uwdzg Kr4hEl8+zecc2EwEtjQRlW05Oi3jDAJ+scqPM60odbJDZMIbxLMdE8mPvCkTW2c+9/1U STfF9VrZQER9fNZc1mUMnCbAxlyvW76B+gbo9DIUpbNG4z2ToBI4YVzKq0sHacmVFwP+ Yacw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b="jiz1v/yl"; 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 67-v6si333791pgi.606.2018.09.24.14.09.31; Mon, 24 Sep 2018 14:09:46 -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="jiz1v/yl"; 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 S1728423AbeIYDNY (ORCPT + 99 others); Mon, 24 Sep 2018 23:13:24 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:57630 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726227AbeIYDNY (ORCPT ); Mon, 24 Sep 2018 23:13:24 -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=mPr8K+6sp9gKpKbjou9LzZieACzDvEfRFHzlw1LN+rc=; b=jiz1v/ylHErK+5FDaMna2QCUq 4TcO7ki9AqaL4yBAc0fGbIyb/IQS3Ugth9LXIctCurzN9Sb065o/MmylZ0vixckFXKLC39rya3J/o Kc75nCg/xPdvay6qQ7C1XgrML67aKQ0PzkF/vf2OaJi9ImGm2ROW2XPScaD88vyZDRxpflHU+1jCx 90Pue4+dEKX+cuh73WeaX02gURaSTxIaYglwOftgHfI3yaQL1yDhAX8bfmnZFsDq20k8c6J2myUT4 9Bl5NvZiVp/n5s09P2UpKANH8fNvQQKNpGCWLSrFr1wQEhN6BcF/HZN+KFMaEdR2+tUHSZzrsJQ/n aaLzyMOjA==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1g4Y6T-0000eK-9W; Mon, 24 Sep 2018 21:09:13 +0000 Date: Mon, 24 Sep 2018 14:09:13 -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: <20180924210913.GB2542@bombadil.infradead.org> References: <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> <20180924185753.GA32269@bombadil.infradead.org> <1537818978.195115.25.camel@acm.org> <20180924204148.GA2542@bombadil.infradead.org> <1537822441.195115.32.camel@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1537822441.195115.32.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 01:54:01PM -0700, Bart Van Assche wrote: > On Mon, 2018-09-24 at 13:41 -0700, Matthew Wilcox wrote: > > Good job snipping the part of my reply which addressed this. Go read > > DMA-API.txt yourself. Carefully. > > The snipped part did not contradict your claim that "You're not supposed to use > kmalloc memory for DMA." In the DMA-API.txt document however there are multiple > explicit statements that support allocating memory for DMA with kmalloc(). Here > is one example from the DMA-API.txt section about dma_map_single(): > > Not all memory regions in a machine can be mapped by this API. > Further, contiguous kernel virtual space may not be contiguous as > physical memory. Since this API does not provide any scatter/gather > capability, it will fail if the user tries to map a non-physically > contiguous piece of memory. For this reason, memory to be mapped by > this API should be obtained from sources which guarantee it to be > physically contiguous (like kmalloc). Since you're only interested in reading the parts which support your viewpoint, I'll do the work for you. 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).