Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp973768imm; Thu, 5 Jul 2018 12:14:45 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeiuyzzPM6FWBNpDm+cW/SfY7BnSc6TzaNotsdcnI0GVQyUIKNTpp871yLm41CNJYTOCNvs X-Received: by 2002:a63:9b19:: with SMTP id r25-v6mr6532990pgd.197.1530818085246; Thu, 05 Jul 2018 12:14:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530818085; cv=none; d=google.com; s=arc-20160816; b=CKI7/uyuohoLFAGEXl+u/W5Boeh4OKGFGDU1OKx4sSNPemt1oZ1kfxkf8/ZWDwwJ99 AnliDDd/aq9PBWVc1bAHZvZVyfTpdvUZty0AgSkuKMxMe0q0bTq2Z41FiI4muzEZlYy6 DHMAjWpVTVpjJp27SXg/N0eCWeSWAZ3/ZFppa4yZTW8uO9/Sm2cBjX//ZUlZLp8fxdJi 1D/NjDRnMCK/9d9rdgReD5TnC1uG0DnAg4VE4EYoZ/GqlBG+zwbtkWtB0PTRMKJxPXmU 4C+0vc0Ed1bBPozTh6zf6fXOdc4g/ho3SQAiXQ7kEqhZ1k8/NKHPqQlbq5iXQE7gY9Yl /Ncw== 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:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=1avR/RL9hjzrzluopCiwmn0bwu0k3eqOJdIJGzLIiwo=; b=UgU2IMDYvjrt0AB5o9vL0xK2RAqpP8AAi65JURjb2tS0/vuJfmavk1FgQTQ9tFHoem 8tt6UHsZiTlLE0gnD5aN8ig2QwjZhPqmpwHvFlQ3OGnDUuTpPHh6o253n2SyHTjdeTRU Nrd+E4h9z7JWUhaIb5IslJrVAcFuyeTmsWPX209d9PwgkYGRhnrRr2UP8iyG0HjA1Tys /Kkqzix7eSJzdydZ0vVyXtt2X225c27x4POTu26RTl1yTOiC6b07XavjskXFPbqSI63C mwJaJutJoeeQMhx58puTG4g2EeBYlLb7PgFhR2ffSnxljyR9D3YwB9lFTVl3iE20fYrQ 0LhQ== 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 x6-v6si6355910plv.315.2018.07.05.12.14.29; Thu, 05 Jul 2018 12:14:45 -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 S1754004AbeGETNe (ORCPT + 99 others); Thu, 5 Jul 2018 15:13:34 -0400 Received: from foss.arm.com ([217.140.101.70]:55262 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753466AbeGETNd (ORCPT ); Thu, 5 Jul 2018 15:13:33 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 20DC97A9; Thu, 5 Jul 2018 12:13:33 -0700 (PDT) Received: from why.wild-wind.fr.eu.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 013003F5A0; Thu, 5 Jul 2018 12:13:31 -0700 (PDT) Date: Thu, 5 Jul 2018 20:13:27 +0100 From: Marc Zyngier To: Bo Yan Cc: , , Subject: Re: [PATCH] irqchip/gic: check return value of of_address_to_resource Message-ID: <20180705201327.4a4dc7dd@why.wild-wind.fr.eu.org> In-Reply-To: <1530814859-11610-1-git-send-email-byan@nvidia.com> References: <1530814859-11610-1-git-send-email-byan@nvidia.com> Organization: ARM Ltd X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bo, On Thu, 5 Jul 2018 11:20:59 -0700 Bo Yan wrote: > The of_address_to_resource returns 0 if successful. gic_check_eoimode > calls it without checking the return value. This induces Coverity > warning: "Unchecked return value". > > Return false from gic_check_eoimode if of_address_to_resource returns > non-0 value. > > Signed-off-by: Bo Yan > --- > drivers/irqchip/irq-gic.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > index ced10c4..0bceb10 100644 > --- a/drivers/irqchip/irq-gic.c > +++ b/drivers/irqchip/irq-gic.c > @@ -1284,7 +1284,8 @@ static bool gic_check_eoimode(struct device_node *node, void __iomem **base) > { > struct resource cpuif_res; > > - of_address_to_resource(node, 1, &cpuif_res); > + if (of_address_to_resource(node, 1, &cpuif_res)) > + return false; We've just done an of_iomap() on this resource, which succeeded. How can the same thing now fail? It would mean that the device tree has been pulled from under our feet... And if it could happen, why is returning false the right thing to do? Why would we say we want EOImode==0 instead of 1? > > if (!is_hyp_mode_available()) > return false; As it stands, I'm not taking such a patch. It either papers over a bigger problem, or just keeps a warning quiet for the sake of it. Thanks, M. -- Without deviation from the norm, progress is not possible.