From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C2FA4EE0202 for ; Wed, 13 Sep 2023 18:47:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NNhPT9EEDMZKw5LBXQW2eTblj4cJuRtuevk0P+SPmUI=; b=Kiea+P5ACRg4HN gGs8rOkh2QUr0PSIZ/ngnDhFYR6ojNvn05JRRv3QN9mulw5zHsrTeNJ8OODpKnn8DZnYzdaovWUeP lJQVc36cYjQ6CbzkOqSQXJSYQzSydNxpb1PgDSyZRR2nSdsQ0FK07PYgMKCqEfTPVx9TtOm/fdBqC FQrMjYqYDunzd4Y4Iu/ZiUxcefPy0JIgyUZaGhFKSjKzA9AL44u2ydn5CM06N7M55ZZ42lE3JpmPu GyaoEY09QMDcDwrfcYVZ9HrGBz4zVEUZIJeoJRIZmz9FDuwaGftUueyHZ64JUc6/iiJbDbU93LHgM 83J2IYxbKsixArYXrePw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qgUtE-006Yud-0d; Wed, 13 Sep 2023 18:47:04 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qgUtA-006Yt7-2C for linux-arm-kernel@lists.infradead.org; Wed, 13 Sep 2023 18:47:02 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A9E511FB; Wed, 13 Sep 2023 11:47:30 -0700 (PDT) Received: from [10.57.93.239] (unknown [10.57.93.239]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D953D3F5A1; Wed, 13 Sep 2023 11:46:51 -0700 (PDT) Message-ID: <8c8451aa-d0d7-058e-cfc2-7402f9002234@arm.com> Date: Wed, 13 Sep 2023 19:46:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH 8/8] iommu: Improve map/unmap sanity checks Content-Language: en-GB To: Jason Gunthorpe Cc: joro@8bytes.org, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com, heiko@sntech.de, jernej.skrabec@gmail.com, thierry.reding@gmail.com, vdumpa@nvidia.com References: <524db1ec0139c964d26928a6a264945aa66d010c.1694525662.git.robin.murphy@arm.com> From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230913_114700_820582_0C1E990B X-CRM114-Status: GOOD ( 20.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2023-09-13 15:39, Jason Gunthorpe wrote: > On Tue, Sep 12, 2023 at 05:18:44PM +0100, Robin Murphy wrote: >> The current checks for the __IOMMU_DOMAIN_PAGING capability seem a >> bit stifled, since it is quite likely now that a non-paging domain >> won't have a pgsize_bitmap and/or mapping ops, and thus get caught >> by the earlier condition anyway. Swap them around to test the more >> fundamental condition first, then we can reasonably also upgrade >> the other to a WARN_ON, since if a driver does ever expose a paging >> domain without the means to actually page, it's clearly very broken. > >> Signed-off-by: Robin Murphy >> --- >> drivers/iommu/iommu.c | 10 +++++----- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c >> index c83f2e4c56f5..391bcae4d02d 100644 >> --- a/drivers/iommu/iommu.c >> +++ b/drivers/iommu/iommu.c >> @@ -2427,12 +2427,12 @@ static int __iommu_map(struct iommu_domain *domain, unsigned long iova, >> phys_addr_t orig_paddr = paddr; >> int ret = 0; >> >> - if (unlikely(!ops->map_pages || domain->pgsize_bitmap == 0UL)) >> - return -ENODEV; >> - >> if (unlikely(!(domain->type & __IOMMU_DOMAIN_PAGING))) >> return -EINVAL; > > Why isn't this a WARN_ON? The caller is clearly lost its mind if it > is calling map on a non paging domain.. Sure it's a dumb thing to do, however I don't think we can reasonably say without question that an external caller being dumb represents an unexpected and serious loss of internal consistency. >> + if (WARN_ON(!ops->map_pages || domain->pgsize_bitmap == 0UL)) >> + return -ENODEV; >> + > > And these could be moved to after attach so they are not in any fast > path, and eventually to after alloc.. Perhaps, although TBH I can't imagine it making any appreciable difference - they're both values we need to load and use soon anyway, so on a sensible CPU, the additional overhead should only really be a couple of not-taken branch-if-zero instructions, which is nothing at all compared to how much goes on in the main loop and the driver op call itself. Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel