Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3221757imu; Sat, 24 Nov 2018 00:26:58 -0800 (PST) X-Google-Smtp-Source: AFSGD/UahKKGWd3ZYbHvajmDlN8UeIudxpkRU8nh8s65Z/q03HttrKPb6GfvB9YI7SQLXMiEV3yC X-Received: by 2002:a17:902:4281:: with SMTP id h1-v6mr19088923pld.114.1543048018083; Sat, 24 Nov 2018 00:26:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543048018; cv=none; d=google.com; s=arc-20160816; b=rS54zWy0LtLSYSrk2xLfu4WpJlx/hyHyhNDMCx+QSGRCezP1GK5r7cxZSWB6u8FyMB xoZ/F/u6Y+zh+nS7aMQW//XhsIXCWpF27qo2GWV4+mTZw0WgkcK7R/1894oIwjHQFpPw bt/BVUq5L7X8b02WDH843tWBk4YBFTaj4NmfoPzExAaORF9bvPt73ude14p2DaPz7efm C/8vMbAB5pM3Xp0cMVPeWiQzxNXz64YNRFmxA5rpKh/d/D3XSMZvF4tW3POKfsIEbRX8 33yY5RxXQz2tYent+ZUEADRk01nEu2KMmpKZHW6jhgYLZrdIbnP8Emx8OYKHQ73XWbWP 9Yig== 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=Kr2iVjRnVQ+3TkcuvdKN061O7dE2ho0ZT6lXDX+5fSw=; b=hQ8Qf7+4tUl9klAzUd/sftuVgXiL3mzySHKWDgZYRIgkPka7xsW4KpNOVjvsIOsaEr TOkwDEk/8JOi0+Xq+IYVwGUhC0bAmqePkxrbIUd7ah57UJEW9QBCXfxFv5nxaVryl8wG XZSxvdh0gQjTEOa+IwFqwGP6jZARB/+ihnrRPj1k1g9jd5uLpFk5D3mVe2/wAquvdM7A JyMYDOpoCSbjXRZChvWVjkJV1l649q5qIfmSul+t928d4F59bDCMh34jP0Cy7HBezQL8 pCdK1l7mR/dage4JFxk34ZlUTd0mcoyRz/Eba5udfHS+WdJ0+o0TYw88etHQ6MI7eU7T itHQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m8si14811672pgd.555.2018.11.24.00.26.44; Sat, 24 Nov 2018 00:26:58 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409490AbeKWVdG (ORCPT + 99 others); Fri, 23 Nov 2018 16:33:06 -0500 Received: from 8bytes.org ([81.169.241.247]:49232 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387655AbeKWVdG (ORCPT ); Fri, 23 Nov 2018 16:33:06 -0500 Received: by theia.8bytes.org (Postfix, from userid 1000) id 7EE16322; Fri, 23 Nov 2018 11:49:18 +0100 (CET) Date: Fri, 23 Nov 2018 11:49:18 +0100 From: Joerg Roedel To: Robin Murphy Cc: Linus Torvalds , linux@armlinux.org.uk, Christoph Hellwig , linux-arch@vger.kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, David Woodhouse , the arch/x86 maintainers , Linux List Kernel Mailing , iommu@lists.linux-foundation.org, jdmason@kudzu.us, xen-devel@lists.xenproject.org, linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com Subject: Re: remove the ->mapping_error method from dma_map_ops V2 Message-ID: <20181123104918.GE1586@8bytes.org> References: <20181122140320.24080-1-hch@lst.de> <20181122170715.GI30658@n2100.armlinux.org.uk> <11829e3c-7302-f821-cf5c-863e5267a17b@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11829e3c-7302-f821-cf5c-863e5267a17b@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 22, 2018 at 05:52:15PM +0000, Robin Murphy wrote: > Unfortunately, with things like the top-down IOVA allocator, and 32-bit > systems in general, "the top 4095" values may well still be valid addresses > - we're relying on a 1-byte mapping of the very top byte of memory/IOVA > space being sufficiently ridiculous that no real code would ever do that, > but even a 4-byte mapping of the top 4 bytes is within the realms of the > plausible (I've definitely seen the USB layer make 8-byte mappings from any > old offset within a page, for example). But we can easily work around that by reserving the top 4k of the first 4GB of IOVA address space in the allocator, no? Then these values are never returned as valid DMA handles. Regards, Joerg