Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2668507imu; Thu, 29 Nov 2018 08:26:50 -0800 (PST) X-Google-Smtp-Source: AFSGD/XLH4yHxZEro9c9m+nWFtDefv+NRnMKczFHo1cY352X9afmm+3FNmUPIE8vlcCRqv0S67xJ X-Received: by 2002:a63:f844:: with SMTP id v4mr1784918pgj.82.1543508810233; Thu, 29 Nov 2018 08:26:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543508810; cv=none; d=google.com; s=arc-20160816; b=CzprtXGeVvk4jf7Shpzty82kl32d53DoVV2DHuBQKX74bKJ8ck8j5FN368YEEoXo9m G0TiydxrNJ6VybDNDdm2rB9rDPcBZoF/G06CkUI1nqfdDkMzEaQWP+iLcRD7rvbjekuL rgLcgDS5BOlnmn5MESQQ3G/urjwhkq8GnPD4Vd29zFWlf+3SD3VxAMNWptmSlmA0WQwj yFhk0ideYVsFREOslGVxj59dSQqsWgGZpcqEBoVw59L5RDRXvcVfgazu7JsYmY3k0+WU 0tqmcSN6idLQc6hvj8H+ZUqE3WRgYUgj2C/5F45aQ415Ylm0GkRPbAPehcEplvOurq4+ A3/w== 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; bh=WjqedKlHnpVklppFITQZKDLh8AWhN6yHkl9YzzbIMCo=; b=Dle6zaDwYU09OrwXyh1SgrhRVJD4dEbKOOrLl55cm0YA4LhLkNFH7eYnUGv2xwHz46 pcxQJKLa+GdA5ZGWmufLcfSUB3fNQ+RWWSdRvygnKmL10QgsBHys2mhTT5wmIS1+WrTN sqKjtbYFPTg8WQGy9gq1KIBC5APrYTm/xbY3kZXspL0mYG/pLN/qLfeJOGbxSofFgZOJ DluVQRzhu1G0Fcxp2K9iZgdJXU1fSplvn5NNLX5BctE86Ey/18w0vnzo9fuMlhiAPMeT MB3+h9sxqRkxH1wuTXHDrTTzKv3n8iW6bPDRuwG6ihLfNEKsO2/KcUzml+4Z1jNKc+D6 4a4g== ARC-Authentication-Results: i=1; mx.google.com; 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 b1si2662787plc.332.2018.11.29.08.26.08; Thu, 29 Nov 2018 08:26:50 -0800 (PST) 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; 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 S1728829AbeK3D3U (ORCPT + 99 others); Thu, 29 Nov 2018 22:29:20 -0500 Received: from verein.lst.de ([213.95.11.211]:44466 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728423AbeK3D3T (ORCPT ); Thu, 29 Nov 2018 22:29:19 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 5722B68B02; Thu, 29 Nov 2018 17:23:23 +0100 (CET) Date: Thu, 29 Nov 2018 17:23:23 +0100 From: Christoph Hellwig To: Linus Torvalds Cc: Russell King - ARM Linux , Christoph Hellwig , linux-arch@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, robin.murphy@arm.com, the arch/x86 maintainers , Linux List Kernel Mailing , iommu@lists.linux-foundation.org, linux-alpha@vger.kernel.org, xen-devel@lists.xenproject.org, David Woodhouse , linux-arm-kernel@lists.infradead.org Subject: Re: remove the ->mapping_error method from dma_map_ops V2 Message-ID: <20181129162323.GA27068@lst.de> References: <11829e3c-7302-f821-cf5c-863e5267a17b@arm.com> <20181123065511.GA17856@lst.de> <20181128074117.GA21126@lst.de> <20181128174545.GJ30658@n2100.armlinux.org.uk> <20181128180841.GM30658@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 28, 2018 at 11:19:15AM -0800, Linus Torvalds wrote: > Let me just paste it back in here: > > "Which is what we ALREADY do for these exact reasons. If the DMA > mappings means that you'd need to add one more page to that list of > reserved pages, then so be it." > > So no, I'm not at all confused. > > Let me re-iterate: the argument that all addresses have to be dma'able is > garbage. > > *Exactly* as with kmalloc and limited virtual addresses, we can limit > physical addresses. We can. At least in theory. The problem is that depending on the crazy mapping from physical and kernel virtual address to dma addresses these might be pages at pretty random places. Look at fun like arch/x86/pci/sta2x11-fixup.c for how ugly these mappings could look. It also means that we might have setup swiotlb on just about every 32-bit architecture, even if it has no real addressing limit except for the one we imposed. I don't really see how this is a win for us just to be able to report more detailed error codes, which would be nice to have, but the lack of which hasn't really harmed us. So as far as I'm concerned I'd go either with the series that we are discussing here, or change the map_page method to return an errno and the dma_addr_t in the argument. As Davem pointed out that can lead to less optimal code, but it would still be better than the indirect call we have. But then again I think the series as posted here might and up much simpler and good enough without opening up this rathole.