Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp28723608rwd; Wed, 5 Jul 2023 01:32:19 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5QPsShGfZASV/qYXLia9+UwMkWJ5rjcJ5ncvbPqJrtetSBE+92wEtPesE4cGBHYvtpuTZo X-Received: by 2002:a05:6a20:3d83:b0:12d:130c:3ee3 with SMTP id s3-20020a056a203d8300b0012d130c3ee3mr14954519pzi.44.1688545938920; Wed, 05 Jul 2023 01:32:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688545938; cv=none; d=google.com; s=arc-20160816; b=hmiQJKhyBh3SknA70DeO07p7H71Fqow1qTryTj5Ew666NmAKEF6tuX1znqJnodtNC0 FLlj5yVGI3y0Rb4RHzYh36EbHxHW7jywHMgnCpoS/fwjiNYuwjTifQCK8WqPuR5CqVjB d2UmMhAqOK8Ur8xgMzgmRnYNIYZCdQftUmDNIQYEDz+SRY45ClUgcL+HMGRtBSx2Luo1 B70Cn65tJdyV/EUui6BHQOb2WYgJcmiaSlsFBSyHDBxCW5PSL2pVI/lPftFh1fV3bw+J +IDlst3isl6kJYnWFs28OTt5ThGZxn5vHJbKiZqII3/ycwpIm5aLXDQh6tn8ZtkoHbSu F+lA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id; bh=+qD7qd++uan0DQoZQoST8a+uMik4rTFW5uMRGk03rJ0=; fh=FIpcvi6fpRbu5wS8pslcv3jAaWDCAjfMq1bSQsX9khI=; b=rFPGQh+zV0cFd651FbSZB0Z/6jfbBCvH7hOgnvgeFym5y1Q0IEbHCTyEHe5gg40YDI feJ0Ob0o+YNqMgfe/UoJM0atyqXJg/bzeBlOq56Yi6cKiVFo/FkB40f4uKo31hblL2Us 38G5sT4fcIARFM9CBat1mUrrsRbSHnLxedqkKsJVRW+8wsr0N1Y3YZen0pbaA5PW+ijb 3xooX4KukY6W/98kntXU5OBHbK9oi1FNB/sAKNln21PPAictu+qJ+xGGJuuSvmToAkUA wFBUqvf377IqGaOfyRj09V46hW6bJhn4jMP6kKUTkbED0mGrVg9AhBww3DLV8CUK+Da4 gMXg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h8-20020a170902680800b001b8b0c1650esi867094plk.63.2023.07.05.01.32.05; Wed, 05 Jul 2023 01:32:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231893AbjGEI0M (ORCPT + 99 others); Wed, 5 Jul 2023 04:26:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231502AbjGEI0L (ORCPT ); Wed, 5 Jul 2023 04:26:11 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 29ECD1709 for ; Wed, 5 Jul 2023 01:26:10 -0700 (PDT) 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 39C7B1682; Wed, 5 Jul 2023 01:26:52 -0700 (PDT) Received: from [10.57.28.141] (unknown [10.57.28.141]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 70D7D3F73F; Wed, 5 Jul 2023 01:26:08 -0700 (PDT) Message-ID: <4c78c516-8cb6-d865-c64c-0b2443006690@arm.com> Date: Wed, 5 Jul 2023 09:26:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH] iommu/mediatek: Remove a unnecessary checking for larbid To: =?UTF-8?B?WW9uZyBXdSAo5ZC05YuHKQ==?= , "joro@8bytes.org" , "matthias.bgg@gmail.com" , "angelogioacchino.delregno@collabora.com" Cc: "will@kernel.org" , "linux-mediatek@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux.dev" References: <20230704115634.7727-1-yong.wu@mediatek.com> <633be7a7-0bb8-1575-535e-2f96302198bd@collabora.com> Content-Language: en-GB From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-07-05 07:49, Yong Wu (吴勇) wrote: > On Tue, 2023-07-04 at 14:19 +0200, AngeloGioacchino Del Regno wrote: >> >> External email : Please do not click links or open attachments until >> you have verified the sender or the content. >> Il 04/07/23 13:56, Yong Wu ha scritto: >>> Fix a coverity issue: >>> >>>>> assignment: Assigning: larbid = (fwspec->ids[0] >> 5) & 0x1fU. >>> larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); >>>>> between: At condition larbid >= 32U, the value of larbid must be >> between >>>>> 0 and 31. >>>>> dead_error_condition: The condition larbid >= 32U cannot be true. >>> if (larbid >= MTK_LARB_NR_MAX) >>>>> CID 11306470 (#1 of 1): Logically dead code (DEADCODE) >>>>> dead_error_line: Execution cannot reach this statement: >>>>> return ERR_PTR(-22L); >>> return ERR_PTR(-EINVAL); >>> >>> The checking "if (larbid >= MTK_LARB_NR_MAX)" is unnecessary. >>> >> >> I agree with the coverity tool in that after the transformation >> (going through >> the definition of MTK_M4U_TO_LARB) the check is pointless, but I >> think that the >> right fix here is to check for validity of fwspec->ids[0] instead of >> simply >> removing validation. >> >> Having no validation after mtk_iommu_probe_device() is fine, but >> that's >> because we assume that *this* function performs all validation steps. > > There already is validation code at the point later in this function. > > "if (!larbdev) return ERR_PTR(-EINVAL);" //if the larbid is invalid. > > This patch just removes a deadcode. Right, if the fwspec value was out of range then the truncated value might happen to map to a valid LARB, but then the fwspec could equally have an in-range value for a valid (but incorrect) LARB; in general a driver can't validate the overall correctness of data from the DT (and if it could, that data wouldn't need to be in the DT anyway). From the history, the intent of this check doesn't appear to have been anything other than protecting the dereference of the data->larb_imu array, and it's never had any functional effect, so we don't lose anything by removing it. FWIW, Reviewed-by: Robin Murphy Cheers, Robin. > >> >> Regards, >> Angelo >> >>> Signed-off-by: Yong Wu >>> --- >>> Rebase on v6.4-rc1. >>> --- >>> drivers/iommu/mtk_iommu.c | 3 --- >>> 1 file changed, 3 deletions(-) >>> >>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c >>> index aecc7d154f28..67caa90b481b 100644 >>> --- a/drivers/iommu/mtk_iommu.c >>> +++ b/drivers/iommu/mtk_iommu.c >>> @@ -838,9 +838,6 @@ static struct iommu_device >> *mtk_iommu_probe_device(struct device *dev) >>> * All the ports in each a device should be in the same larbs. >>> */ >>> larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); >>> -if (larbid >= MTK_LARB_NR_MAX) >>> -return ERR_PTR(-EINVAL); >>> - >>> for (i = 1; i < fwspec->num_ids; i++) { >>> larbidx = MTK_M4U_TO_LARB(fwspec->ids[i]); >>> if (larbid != larbidx) { >> >>