Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp6390899iog; Thu, 23 Jun 2022 18:39:56 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t7ZCB8/Nara4ck2fKsSKvmV5J3LKadtICEa8pMhOp6/z+2T3hs+80x6sKBx4RKNn9FrlsX X-Received: by 2002:a17:90a:4307:b0:1ec:e56d:76d2 with SMTP id q7-20020a17090a430700b001ece56d76d2mr969519pjg.39.1656034796654; Thu, 23 Jun 2022 18:39:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656034796; cv=none; d=google.com; s=arc-20160816; b=CQ+8CSShZwkSGbp3aIVlxT/uWLfWrOCicjjq6FRKJ3FvTUmOC6nObCo0AXe3QTIHoL 3oqfHCk2Jt1QjwdlZHuwYp4wrFcEG97bxX02ep2t9bmzrxwBvB2IPtitLy616P01iJov /lpOM12W3X3uhfj+A7xoKODOrHHLMNlolWxXIamaQII/B743tuCRiUFa0n/ItrUmLejM 73/6Ec6pX/V3KBCnJH8YexmYDRFFAJhwuPIKxRnLe+2XR/xIXkEMsWDtpbG44B8cbtg1 s828rkcVCHYlrkklyU/z4uUTS/eDYCVNqEfUR0LNqQGwnx0HcHW0mTQoqXDQpC91UE37 igoA== 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 :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=hk2L5srKPz2pKgAIX9s65bMemghQZBP1kyI79iSJd1Y=; b=MOgL8E2c/7wTEU4DEyBPIC17U3//T6Jm2XzqSwpsGJQGqVWdY6F0GVjnAYadPy75GW SGo41WPFjw/IKit6xGrAHeHB936ePonpDz5mjPd/r2p/GQ1ajnqxEEkNdwk3w9oj1vyz pf/ikKIZYdR1kqOtP3OJhouw2q8R9V5fhcUyIBjYvbyCV5jlI0Neyxg0LiMKxmXZjiwV A197UsTG+I5aLeLncwq3jVdXVIhVTIzt+aeUkKuOsShd3rDlm9+aaH2jbjnEzCkG2uiI n3qftoeHtJIXBDGFyGSU0N4T7jREKKGp7FS+HqGK3e+iugdwsIFdmiwJEvETnmoSh5V0 3HGw== 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u11-20020a056a00124b00b00518da2b2c2bsi977218pfi.221.2022.06.23.18.39.44; Thu, 23 Jun 2022 18:39:56 -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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230493AbiFXBZI (ORCPT + 99 others); Thu, 23 Jun 2022 21:25:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37724 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230113AbiFXBZF (ORCPT ); Thu, 23 Jun 2022 21:25:05 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E297856779; Thu, 23 Jun 2022 18:25:03 -0700 (PDT) Received: from dggpemm500021.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4LTfWp4wkTzkWXL; Fri, 24 Jun 2022 09:23:18 +0800 (CST) Received: from dggpemm500013.china.huawei.com (7.185.36.172) by dggpemm500021.china.huawei.com (7.185.36.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 24 Jun 2022 09:25:01 +0800 Received: from [127.0.0.1] (10.67.108.67) by dggpemm500013.china.huawei.com (7.185.36.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 24 Jun 2022 09:25:01 +0800 Message-ID: <9217c85d-e39e-55b1-36c3-603d0c6203fd@huawei.com> Date: Fri, 24 Jun 2022 09:24:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v6 32/33] arm64: irq-gic: Replace unreachable() with -EINVAL Content-Language: en-US To: Marc Zyngier CC: , , , , , , , , , , , , , , , , , , , References: <20220623014917.199563-1-chenzhongjin@huawei.com> <20220623014917.199563-33-chenzhongjin@huawei.com> <7d26e36686495866e0752e12c38f170e@kernel.org> From: Chen Zhongjin In-Reply-To: <7d26e36686495866e0752e12c38f170e@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.108.67] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500013.china.huawei.com (7.185.36.172) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,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 Hi, Thanks for your review and patient. On 2022/6/23 16:13, Marc Zyngier wrote: > On 2022-06-23 02:49, Chen Zhongjin wrote: >> Using unreachable() at default of switch generates an extra branch at >> end of the function, and compiler won't generate a ret to close this >> branch because it knows it's unreachable. >> >> If there's no instruction in this branch, compiler will generate a NOP, >> And it will confuse objtool to warn this NOP as a fall through branch. >> >> In fact these branches are actually unreachable, so we can replace >> unreachable() with returning a -EINVAL value. >> >> Signed-off-by: Chen Zhongjin >> --- >>  arch/arm64/kvm/hyp/vgic-v3-sr.c | 7 +++---- >>  drivers/irqchip/irq-gic-v3.c    | 2 +- >>  2 files changed, 4 insertions(+), 5 deletions(-) > > Basic courtesy would have been to Cc the maintainers of this code. > Sorry for that. I'll cc everyone next time. >> >> diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c >> index 4fb419f7b8b6..f3cee92c3038 100644 >> --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c >> +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c >> @@ -6,7 +6,6 @@ >> >>  #include >> >> -#include >>  #include >>  #include >> >> @@ -55,7 +54,7 @@ static u64 __gic_v3_get_lr(unsigned int lr) >>          return read_gicreg(ICH_LR15_EL2); >>      } >> >> -    unreachable(); >> +    return -EINVAL; > > NAK. That's absolutely *wrong*, and will hide future bugs. > Nothing checks for -EINVAL, and we *never* expect to > reach this, hence the perfectly valid annotation. > > If something needs fixing, it probably is your tooling. > >         M. You are right. Essentially, this is because objtool does not anticipate that the compiler will generate additional instructions when marking unreachable instructions. I'll fix this problem or add a specific check for this state. Best, Chen