Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4055762yba; Tue, 9 Apr 2019 10:10:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqwM5PGnG5w27JLuN2IaqBWY6FGniAOwYgvYVBeyFpl8X4O0LxZRDIHkHCWJ96ZWXoYrv3e5 X-Received: by 2002:a65:4083:: with SMTP id t3mr9706209pgp.332.1554829822975; Tue, 09 Apr 2019 10:10:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554829822; cv=none; d=google.com; s=arc-20160816; b=pDPmmLX59nYvcpHDc+MzQDQSXAQ9J1H52RtP0jz1ZVWGZ70bET6lI5UiHs4PmWSkmj erOssvQwA/JVCIDaKP+q2DkPdCu9def8gKvG+jxO4OWzBfvwUKMqtj6A0NZXL47U0wv+ HqzjNoyhK6mZMcg65nVrodFYq9FEEbadNVg5tOfjolKEZMUKFdaW8Vq7Kwp+225tf4d8 rrcYVjP0pGuxdT6J95SAvGsfSElW9ZuHon3j4V5mIdJPpSU/mH+vX1Td+wdy/N/NZrn8 5tURHeZr6M1ooGmpC7OaVh3TMnVacmKAHMoYUtKxhieESGLoMH75jzvHyREJd3vnhUMf r4Rg== 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=ML82MirYE+c0FfwHib3k9HIR8b//jLKmZClWx+IU7pU=; b=rCSjJOHNxG2jo4lpmTWC5qE8joCt6aQXaDr4Uwpl628CECCp+mbhe5ACeCjm2Djzpi FF5VyUlOMjOxmjCIfF6GhykLPrkMr+xGiHCR5y8ZaXWR+cpDH6N81/OK3tekUv5NRc9h VvSkK2EuRjTrQGX0f291c2MtBo4XBFOwS6BeehWr3UDAmMEbHFTmGKHFjrwomWYM5MWn 7L6kwRJF8r0fIOV/J3CUfqceJ+ISqYsyAoCFF2/gBnhTEbh6eFa1IE/5JUmjMQkaMxRt l1qFTzvb9KTj0ozQXTUTjzCa787B9Bgv0sRwl+n0xV0mTgRvfb6pwyyb/g07WYX3GRlb BGSg== 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 d9si28070470pgp.336.2019.04.09.10.10.04; Tue, 09 Apr 2019 10:10:22 -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; 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 S1726530AbfDIRJ0 (ORCPT + 99 others); Tue, 9 Apr 2019 13:09:26 -0400 Received: from verein.lst.de ([213.95.11.211]:51734 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726456AbfDIRJ0 (ORCPT ); Tue, 9 Apr 2019 13:09:26 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id B96E768B02; Tue, 9 Apr 2019 19:09:13 +0200 (CEST) Date: Tue, 9 Apr 2019 19:09:13 +0200 From: Christoph Hellwig To: Robin Murphy Cc: Christoph Hellwig , Joerg Roedel , Catalin Marinas , Will Deacon , Tom Lendacky , iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 02/21] arm64/iommu: improve mmap bounds checking Message-ID: <20190409170913.GA14679@lst.de> References: <20190327080448.5500-1-hch@lst.de> <20190327080448.5500-3-hch@lst.de> <3629087c-a8cb-d66e-840b-cfee125bdf4c@arm.com> <20190407065923.GA9086@lst.de> <45672f18-c741-601d-6bb2-92f50b77e981@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45672f18-c741-601d-6bb2-92f50b77e981@arm.com> 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 Tue, Apr 09, 2019 at 04:12:51PM +0100, Robin Murphy wrote: > On 07/04/2019 07:59, Christoph Hellwig wrote: >> On Fri, Apr 05, 2019 at 06:30:52PM +0100, Robin Murphy wrote: >>> On 27/03/2019 08:04, Christoph Hellwig wrote: >>>> The nr_pages checks should be done for all mmap requests, not just those >>>> using remap_pfn_range. >>> >>> Hmm, the logic in iommu_dma_mmap() inherently returns an error for the "off >>>> = nr_pages" case already. It's also supposed to be robust against the >>> "vma_pages(vma) > nr_pages - off" condition, although by making the partial >>> mapping and treating it as a success, rather than doing nothing and >>> returning an error. What's the exact motivation here? >> >> Have one error check at the front of the function that is identical >> to the mmap checks in the other dma_map_ops instances so that: >> >> a) we get the same error behavior for partial requests everywhere >> b) we can lift these checks into common code in the next round. >> > > Fair enough, but in that case why isn't the dma_mmap_from_coherent() path > also covered? dma_mmap_from_coherent currently duplicates those checks itself, and because of that the other callers also don't include it in their checks. I don't actually like that situation and have patches to refactor and clean up that whole mess by also moving the dma coherent mmap to common code, and share the checks that I plan to also lift. But for now I'm holding these back as they would conflict with this series and I'm not sure if it will go in and if yes if that is through the dma-mapping or iommu tree.