Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp614220ybg; Wed, 10 Jun 2020 09:08:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyGARSse73wRrrXIiWGcYQOvwzqdXDPEo5y/N22gytBKLn00tSCC9yDEoeu1XTmrc4rQ+dp X-Received: by 2002:a17:906:1d1a:: with SMTP id n26mr3903158ejh.351.1591805305632; Wed, 10 Jun 2020 09:08:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591805305; cv=none; d=google.com; s=arc-20160816; b=n1Zl3e4EIhTcEtB4K7v/Kbj63l6xOS0OO6U16JaAfCyMMUbCioRZ8BYd86y9eA+6s5 WHRPgK41uBvBmT7574k1QrFPCrYutw0y84bH02FMKCwSlYuMtphXmSTB78cbhHgcUW1/ K3hUMuzJ0Oy4Ba+Vbo0Bpt8TRn1J8MuAQIj6d++BzGRz+MSV5MpFOm1TwOA3SjSzVs+V EcIdr8xlKgQeTQQPZgTb+fgdny05jqkPCtyUdbwlox0NQcZqhLj99tcZF06Awrbw3SIF xE+RH9Etnt+GxL6X2Ql6gxS0F6lAzczMtB88kCQCG2yAp8s6b/lHENL3d+yRfSQNiNQu g0fA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=hEFLHZCE/NRSbTTiz01qJPRDNTmbH27eYBIsolB5pzs=; b=o+D7KX9tfmyOrCqGt+hnLPsM2Pg0z1u/YdO/A2w+GFPAilGKiiJv/uxeeIJrbu5b0C xZp06zKbD08PYilVR8fMf54XmHaIE1eI1D/w2n1l6mL2il8MK/Nb8U/P/TAAIEiPAv+A nvpenIn6jZmMs2+ywXn8Lde68ks6Eo26jgtLVKsv6FZIard40uNfVZWpNFFhrgEp2/B5 fvFohvvrCTcyUk7fjhrCXYZqfFUXgV9B8ziSTUg0I4Vv9Pr8y9zq8pJs1RTjoSfV5nX4 YAnkBfw/XBXRkRAyqsFsPg2QfRSIMsm63mcADtc58N/lXoF0LOlDhPJj7BNElz6zfCT5 8sDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d7si12365edr.520.2020.06.10.09.08.02; Wed, 10 Jun 2020 09:08:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728115AbgFJKMu (ORCPT + 99 others); Wed, 10 Jun 2020 06:12:50 -0400 Received: from foss.arm.com ([217.140.110.172]:56316 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726134AbgFJKMu (ORCPT ); Wed, 10 Jun 2020 06:12:50 -0400 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 0C8511FB; Wed, 10 Jun 2020 03:12:49 -0700 (PDT) Received: from [10.57.9.128] (unknown [10.57.9.128]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D7F7A3F7BB; Wed, 10 Jun 2020 03:12:47 -0700 (PDT) Subject: Re: [PATCH] iommu/iova: Don't BUG on invalid PFNs To: guptap@codeaurora.org Cc: joro@8bytes.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <79df62c92cf61f2b5f717c28d620a283@codeaurora.org> From: Robin Murphy Message-ID: Date: Wed, 10 Jun 2020 11:12:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <79df62c92cf61f2b5f717c28d620a283@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-06-10 10:27, guptap@codeaurora.org wrote: > On 2020-06-02 18:38, Robin Murphy wrote: >> Unlike the other instances which represent a complete loss of >> consistency within the rcache mechanism itself, or a fundamental >> and obvious misconfiguration by an IOMMU driver, the BUG_ON() in >> iova_magazine_free_pfns() can be provoked at more or less any time >> in a "spooky action-at-a-distance" manner by any old device driver >> passing nonsense to dma_unmap_*() which then propagates through to >> queue_iova(). >> >> Not only is this well outside the IOVA layer's control, it's also >> nowhere near fatal enough to justify panicking anyway - all that >> really achieves is to make debugging the offending driver more >> difficult. Let's simply WARN and otherwise ignore bogus PFNs. >> >> Reported-by: Prakash Gupta >> Signed-off-by: Robin Murphy >> --- >>  drivers/iommu/iova.c | 4 +++- >>  1 file changed, 3 insertions(+), 1 deletion(-) >> > > Copying stable@vger.kernel.org Per Documentation/process/stable-kernel-rules.rst, I'm not convinced this meets the criteria for stable, which is why I deliberately left that out. This change isn't fixing any bug in itself, it is merely relaxing a behaviour that only comes into play if a serious and effectively unrecoverable bug has already occurred elsewhere. If Joerg feels like sending it to stable anyway then fair enough, but FYI there is no relevant "Fixes" tag. > You can add > Reviewed-by: Prakash Gupta Thanks, Robin. >> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c >> index 0e6a9536eca6..612cbf668adf 100644 >> --- a/drivers/iommu/iova.c >> +++ b/drivers/iommu/iova.c >> @@ -811,7 +811,9 @@ iova_magazine_free_pfns(struct iova_magazine *mag, >> struct iova_domain *iovad) >>      for (i = 0 ; i < mag->size; ++i) { >>          struct iova *iova = private_find_iova(iovad, mag->pfns[i]); >> >> -        BUG_ON(!iova); >> +        if (WARN_ON(!iova)) >> +            continue; >> + >>          private_free_iova(iovad, iova); >>      }