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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 A4700C00140 for ; Thu, 18 Aug 2022 12:26:18 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4M7kdP0SWpz3cB6 for ; Thu, 18 Aug 2022 22:26:17 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=CQojlGTD; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.vnet.ibm.com (client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com; envelope-from=naveen.n.rao@linux.vnet.ibm.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=CQojlGTD; dkim-atps=neutral Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4M7kcX3LDWz3bqT for ; Thu, 18 Aug 2022 22:25:31 +1000 (AEST) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27ICFgVK005148; Thu, 18 Aug 2022 12:25:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : subject : to : cc : references : in-reply-to : message-id : content-type : content-transfer-encoding : mime-version; s=pp1; bh=bBUtAJUoZNhGimQV8w6zRvR+wgmSvqiC/9eTqbWmPgE=; b=CQojlGTD7ga5JVDjY8Cr6a73b2iK5tVGEAjTFjinnWpqdp/sOdyrXh3R0PFt2XKU8fpH Y7LYVCR8gGFZfqKvExB5vw4PFDLqWFqyJUa7YRKN7EnWl9Kw6wlu8KJhn2Yui4Kw7WVW b+gk7KfX786vuBuczLrwMjKzvENBq6CuNSmliyRl1Wu/FRTvSWrfKazngtkZw9Zuzn3C osgGANjcPS2mYNCmnNPTtSvsg6PJ6TquJpv6fZGzj4gVXPsn8iCghQUSrw1GIavmjJM0 AhdYrX9/uRrXMlAQufkkiGmReFzK+uSnIuwBmdJW4mDOnAWBCC2xjwWAmvHu6R7pSEjz HA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j1n9a097c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 12:25:12 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 27ICFwqS005799; Thu, 18 Aug 2022 12:25:11 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j1n9a096d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 12:25:11 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27ICKdi8009339; Thu, 18 Aug 2022 12:25:09 GMT Received: from b06avi18878370.portsmouth.uk.ibm.com (b06avi18878370.portsmouth.uk.ibm.com [9.149.26.194]) by ppma06ams.nl.ibm.com with ESMTP id 3hx37jdx0w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 12:25:09 +0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06avi18878370.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27ICPPMq34537890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Aug 2022 12:25:25 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B304442041; Thu, 18 Aug 2022 12:25:06 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 377E24203F; Thu, 18 Aug 2022 12:25:06 +0000 (GMT) Received: from localhost (unknown [9.43.73.112]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 18 Aug 2022 12:25:06 +0000 (GMT) Date: Thu, 18 Aug 2022 17:55:04 +0530 From: "Naveen N. Rao" Subject: Re: [PATCH 01/16] powerpc: Replace unreachable() with it's builtin variant in WARN_ON() To: Christophe Leroy , "linuxppc-dev@lists.ozlabs.org" , Sathvika Vasireddy References: <20220808114908.240813-1-sv@linux.ibm.com> <20220808114908.240813-2-sv@linux.ibm.com> <82eec792-b71f-17cc-d905-368fd5ca62f2@csgroup.eu> <1660817468.4x4re2ul0k.naveen@linux.ibm.com> <06b7a93b-5148-4d92-0b56-5956afdfd3fb@csgroup.eu> In-Reply-To: <06b7a93b-5148-4d92-0b56-5956afdfd3fb@csgroup.eu> User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid) Message-Id: <1660824799.vnjff6w3m0.naveen@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: snzh_C56VDGLhgv1qqH-oIUtyQqqipvb X-Proofpoint-GUID: l8CYaXPg3IuQZ2UJotzNpNO1WmWyRP45 Content-Transfer-Encoding: quoted-printable X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-18_12,2022-08-18_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 spamscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208180042 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "aik@ozlabs.ru" , "linux-kernel@vger.kernel.org" , "npiggin@gmail.com" , "peterz@infradead.org" , "mingo@redhat.com" , "rostedt@goodmis.org" , "jpoimboe@redhat.com" , "mbenes@suse.cz" , "chenzhongjin@huawei.com" , "linux-arm-kernel@lists.infradead.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Christophe Leroy wrote: >=20 >=20 > Le 18/08/2022 =C3=A0 12:46, Naveen N. Rao a =C3=A9crit=C2=A0: >> Christophe Leroy wrote: >>> >>> >>> Le 08/08/2022 =C3=A0 13:48, Sathvika Vasireddy a =C3=A9crit=C2=A0: >>>> objtool is throwing *unannotated intra-function call* >>>> warnings with a few instructions that are marked >>>> unreachable. Replace unreachable() with __builtin_unreachable() >>>> to fix these warnings, as the codegen remains same >>>> with unreachable() and __builtin_unreachable(). >>> >>> I think it is necessary to explain why using unreachable() is not=20 >>> necessary for powerpc, or even why using unreachable() is wrong. >>> >>> Allthough we are getting rid of the problem here by replacing=20 >>> unreachable() by __builtin_unreachable(), it might still be a problem=20 >>> in core parts of kernel which still use unreachable. >>=20 >> I did a kernel build with this series applied, with a variant of=20 >> ppc64le_defconfig. I then did another build with the same config, but=20 >> with the below hunk to disable objtool: >>=20 >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> index 6be2e68fa9eb64..4c466acdc70d4c 100644 >> --- a/arch/powerpc/Kconfig >> +++ b/arch/powerpc/Kconfig >> @@ -237,8 +237,6 @@ config PPC >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_MOD_ARCH_SPECIFIC >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_NMI=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if PERF_EVENTS || (PPC6= 4=20 >> && PPC_BOOK3S) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_OPTPROBES >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_OBJTOOL=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if PPC32 || MPROFILE_KERNEL >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_OBJTOOL_MCOUNT=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if= HAVE_OBJTOOL >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_PERF_EVENTS >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_PERF_EVENTS_NMI=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if PPC64 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_PERF_REGS >>=20 >> This has the effect of disabling annotations for unreachable(). >>=20 >> When I compared the resulting object files, I did not see changes in=20 >> codegen relating to the annotation, like we do with using unreachable()= =20 >> in __WARN_FLAGS(). >>=20 >> More specifically, arch/powerpc/kvm/book3s.o:kvmppc_h_logical_ci_load()= =20 >> uses BUG(), and the generated code remains the same with/without the=20 >> unreachable() annotation. >>=20 >> This suggests that the bad codegen we are seeing with the annotation in= =20 >> unreachable() is limited to its use in __WARN_FLAGS(), which I suspect=20 >> is due to an interaction with the use of asm_volatile_goto() for=20 >> WARN_ENTRY(). >>=20 >> If I revert this patch (patch 01/16), gcc seems to add a label 8 bytes=20 >> before _some_ function in this object file, which happens to hold a=20 >> relocation against .TOC., and emits a bl to that symbol. Otherwise, gcc= =20 >> either emits no new instruction for the annotation, or a 'nop' in some=20 >> cases. >>=20 >> If I add a 'nop' between WARN_ENTRY() and unreachable() in=20 >> __WARN_FLAGS(), or convert WARN_ENTRY to BUG_ENTRY thereby removing use= =20 >> of asm_volatile_goto(), the problem goes away and no bl is emitted: >>=20 >> diff --git a/arch/powerpc/include/asm/bug.h=20 >> b/arch/powerpc/include/asm/bug.h >> index 61a4736355c244..88e0027c20ba5c 100644 >> --- a/arch/powerpc/include/asm/bug.h >> +++ b/arch/powerpc/include/asm/bug.h >> @@ -99,6 +99,7 @@ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __label__ __label_warn_on;=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WARN_ENTRY("twi 31, 0, 0", BUGFLAG= _WARNING | (flags),=20 >> __label_warn_on); \ >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __asm__ __volatile__("nop");=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unreachable();=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 \ >> __label_warn_on: >>=20 >>=20 >> In summary, I think the annotation itself is fine and we are only seeing= =20 >> an issue with its usage after WARN_ENTRY() due to use of=20 >> asm_volatile_goto. Other uses of unreachable() don't seem to exhibit=20 >> this problem. >>=20 >> As such, I think this patch is appropriate for this series, though I=20 >> think we should capture some of this information in the changelog. >>=20 >> Note also that if and when we start utlizing the annotation, if we=20 >> classify twui as INSN_BUG, this change will continue to be appropriate. >>=20 >=20 > INSN_TRAP instead of INSN_BUG ? INSN_BUG, in line with your suggestion here: http://lkml.kernel.org/r/ff623097-9f18-3914-5eae-bc6e4cd1510f@csgroup.eu Peter was of the opinion that INSN_TRAP may not be what we want: http://lkml.kernel.org/r/YsLSU6idNME/BtwH@hirez.programming.kicks-ass.net If we classify twui as INSN_BUG, then objtool will know to stop control=20 flow here without the need for an annotation. Parsing extable will=20 then show that control flow continues with the label subsequently. - Naveen 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 ECD49C00140 for ; Thu, 18 Aug 2022 12:26:37 +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:MIME-Version:Message-Id:In-Reply-To:References:Cc:To :Subject:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=1UPkMBFQjDpczTRkzWNVzD/iGbJBd9aoGSdqBViukmo=; b=ntUPwOCEJkfyfxa/nq8Tq5qvlE RM01HMviZsKfXVtLvOTQXkERN6St6SJbZoIFP3El6QmR6Yuncs27CFXpjsgE5VutkCSmN9RFQkJ9H lJY+pp++1K9WX712CWKls2lwuLlhAgi4SVPBkEwXLPbYp9Nh5gFAmgHLBxrhq4BWonwBkygo73z+5 LRcUkY7YpPrTks1Vt0amGX9gxFpkN8jE8FeCoyOstrLXDvJAs1iX4P0KuDp01ve1xCDx3Z7aTHCCV 1ygDf0Tx3614SU7NsfNGFPumVuWZGy8SOBkAToPICq04BQFQp+f6eUiUlNqK0v5Z2qHcfvqnzdE4V Kd/KIH9A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOeaa-004Wog-Ek; Thu, 18 Aug 2022 12:25:32 +0000 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOeaU-004WnB-UX; Thu, 18 Aug 2022 12:25:29 +0000 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27ICFgVK005148; Thu, 18 Aug 2022 12:25:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : subject : to : cc : references : in-reply-to : message-id : content-type : content-transfer-encoding : mime-version; s=pp1; bh=bBUtAJUoZNhGimQV8w6zRvR+wgmSvqiC/9eTqbWmPgE=; b=CQojlGTD7ga5JVDjY8Cr6a73b2iK5tVGEAjTFjinnWpqdp/sOdyrXh3R0PFt2XKU8fpH Y7LYVCR8gGFZfqKvExB5vw4PFDLqWFqyJUa7YRKN7EnWl9Kw6wlu8KJhn2Yui4Kw7WVW b+gk7KfX786vuBuczLrwMjKzvENBq6CuNSmliyRl1Wu/FRTvSWrfKazngtkZw9Zuzn3C osgGANjcPS2mYNCmnNPTtSvsg6PJ6TquJpv6fZGzj4gVXPsn8iCghQUSrw1GIavmjJM0 AhdYrX9/uRrXMlAQufkkiGmReFzK+uSnIuwBmdJW4mDOnAWBCC2xjwWAmvHu6R7pSEjz HA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j1n9a097c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 12:25:12 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 27ICFwqS005799; Thu, 18 Aug 2022 12:25:11 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j1n9a096d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 12:25:11 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27ICKdi8009339; Thu, 18 Aug 2022 12:25:09 GMT Received: from b06avi18878370.portsmouth.uk.ibm.com (b06avi18878370.portsmouth.uk.ibm.com [9.149.26.194]) by ppma06ams.nl.ibm.com with ESMTP id 3hx37jdx0w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 12:25:09 +0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06avi18878370.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27ICPPMq34537890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Aug 2022 12:25:25 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B304442041; Thu, 18 Aug 2022 12:25:06 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 377E24203F; Thu, 18 Aug 2022 12:25:06 +0000 (GMT) Received: from localhost (unknown [9.43.73.112]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 18 Aug 2022 12:25:06 +0000 (GMT) Date: Thu, 18 Aug 2022 17:55:04 +0530 From: "Naveen N. Rao" Subject: Re: [PATCH 01/16] powerpc: Replace unreachable() with it's builtin variant in WARN_ON() To: Christophe Leroy , "linuxppc-dev@lists.ozlabs.org" , Sathvika Vasireddy Cc: "aik@ozlabs.ru" , "chenzhongjin@huawei.com" , "jpoimboe@redhat.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "mbenes@suse.cz" , "mingo@redhat.com" , "mpe@ellerman.id.au" , "npiggin@gmail.com" , "peterz@infradead.org" , "rostedt@goodmis.org" References: <20220808114908.240813-1-sv@linux.ibm.com> <20220808114908.240813-2-sv@linux.ibm.com> <82eec792-b71f-17cc-d905-368fd5ca62f2@csgroup.eu> <1660817468.4x4re2ul0k.naveen@linux.ibm.com> <06b7a93b-5148-4d92-0b56-5956afdfd3fb@csgroup.eu> In-Reply-To: <06b7a93b-5148-4d92-0b56-5956afdfd3fb@csgroup.eu> User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid) Message-Id: <1660824799.vnjff6w3m0.naveen@linux.ibm.com> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: snzh_C56VDGLhgv1qqH-oIUtyQqqipvb X-Proofpoint-GUID: l8CYaXPg3IuQZ2UJotzNpNO1WmWyRP45 X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-18_12,2022-08-18_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 spamscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208180042 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220818_052527_282875_A4464504 X-CRM114-Status: GOOD ( 22.96 ) 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: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Q2hyaXN0b3BoZSBMZXJveSB3cm90ZToKPiAKPiAKPiBMZSAxOC8wOC8yMDIyIMOgIDEyOjQ2LCBO YXZlZW4gTi4gUmFvIGEgw6ljcml0wqA6Cj4+IENocmlzdG9waGUgTGVyb3kgd3JvdGU6Cj4+Pgo+ Pj4KPj4+IExlIDA4LzA4LzIwMjIgw6AgMTM6NDgsIFNhdGh2aWthIFZhc2lyZWRkeSBhIMOpY3Jp dMKgOgo+Pj4+IG9ianRvb2wgaXMgdGhyb3dpbmcgKnVuYW5ub3RhdGVkIGludHJhLWZ1bmN0aW9u IGNhbGwqCj4+Pj4gd2FybmluZ3Mgd2l0aCBhIGZldyBpbnN0cnVjdGlvbnMgdGhhdCBhcmUgbWFy a2VkCj4+Pj4gdW5yZWFjaGFibGUuIFJlcGxhY2UgdW5yZWFjaGFibGUoKSB3aXRoIF9fYnVpbHRp bl91bnJlYWNoYWJsZSgpCj4+Pj4gdG8gZml4IHRoZXNlIHdhcm5pbmdzLCBhcyB0aGUgY29kZWdl biByZW1haW5zIHNhbWUKPj4+PiB3aXRoIHVucmVhY2hhYmxlKCkgYW5kIF9fYnVpbHRpbl91bnJl YWNoYWJsZSgpLgo+Pj4KPj4+IEkgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5IHRvIGV4cGxhaW4gd2h5 IHVzaW5nIHVucmVhY2hhYmxlKCkgaXMgbm90IAo+Pj4gbmVjZXNzYXJ5IGZvciBwb3dlcnBjLCBv ciBldmVuIHdoeSB1c2luZyB1bnJlYWNoYWJsZSgpIGlzIHdyb25nLgo+Pj4KPj4+IEFsbHRob3Vn aCB3ZSBhcmUgZ2V0dGluZyByaWQgb2YgdGhlIHByb2JsZW0gaGVyZSBieSByZXBsYWNpbmcgCj4+ PiB1bnJlYWNoYWJsZSgpIGJ5IF9fYnVpbHRpbl91bnJlYWNoYWJsZSgpLCBpdCBtaWdodCBzdGls bCBiZSBhIHByb2JsZW0gCj4+PiBpbiBjb3JlIHBhcnRzIG9mIGtlcm5lbCB3aGljaCBzdGlsbCB1 c2UgdW5yZWFjaGFibGUuCj4+IAo+PiBJIGRpZCBhIGtlcm5lbCBidWlsZCB3aXRoIHRoaXMgc2Vy aWVzIGFwcGxpZWQsIHdpdGggYSB2YXJpYW50IG9mIAo+PiBwcGM2NGxlX2RlZmNvbmZpZy4gSSB0 aGVuIGRpZCBhbm90aGVyIGJ1aWxkIHdpdGggdGhlIHNhbWUgY29uZmlnLCBidXQgCj4+IHdpdGgg dGhlIGJlbG93IGh1bmsgdG8gZGlzYWJsZSBvYmp0b29sOgo+PiAKPj4gZGlmZiAtLWdpdCBhL2Fy Y2gvcG93ZXJwYy9LY29uZmlnIGIvYXJjaC9wb3dlcnBjL0tjb25maWcKPj4gaW5kZXggNmJlMmU2 OGZhOWViNjQuLjRjNDY2YWNkYzcwZDRjIDEwMDY0NAo+PiAtLS0gYS9hcmNoL3Bvd2VycGMvS2Nv bmZpZwo+PiArKysgYi9hcmNoL3Bvd2VycGMvS2NvbmZpZwo+PiBAQCAtMjM3LDggKzIzNyw2IEBA IGNvbmZpZyBQUEMKPj4gIMKgwqDCoMKgwqDCoCBzZWxlY3QgSEFWRV9NT0RfQVJDSF9TUEVDSUZJ Qwo+PiAgwqDCoMKgwqDCoMKgIHNlbGVjdCBIQVZFX05NScKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiBQRVJGX0VWRU5UUyB8fCAoUFBDNjQgCj4+ICYm IFBQQ19CT09LM1MpCj4+ICDCoMKgwqDCoMKgwqAgc2VsZWN0IEhBVkVfT1BUUFJPQkVTCj4+IC3C oMKgwqDCoMKgwqAgc2VsZWN0IEhBVkVfT0JKVE9PTMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgaWYgUFBDMzIgfHwgTVBST0ZJTEVfS0VSTkVMCj4+IC3CoMKgwqDCoMKg wqAgc2VsZWN0IEhBVkVfT0JKVE9PTF9NQ09VTlTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBp ZiBIQVZFX09CSlRPT0wKPj4gIMKgwqDCoMKgwqDCoCBzZWxlY3QgSEFWRV9QRVJGX0VWRU5UUwo+ PiAgwqDCoMKgwqDCoMKgIHNlbGVjdCBIQVZFX1BFUkZfRVZFTlRTX05NScKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBpZiBQUEM2NAo+PiAgwqDCoMKgwqDCoMKgIHNlbGVjdCBIQVZFX1BFUkZfUkVH Uwo+PiAKPj4gVGhpcyBoYXMgdGhlIGVmZmVjdCBvZiBkaXNhYmxpbmcgYW5ub3RhdGlvbnMgZm9y IHVucmVhY2hhYmxlKCkuCj4+IAo+PiBXaGVuIEkgY29tcGFyZWQgdGhlIHJlc3VsdGluZyBvYmpl Y3QgZmlsZXMsIEkgZGlkIG5vdCBzZWUgY2hhbmdlcyBpbiAKPj4gY29kZWdlbiByZWxhdGluZyB0 byB0aGUgYW5ub3RhdGlvbiwgbGlrZSB3ZSBkbyB3aXRoIHVzaW5nIHVucmVhY2hhYmxlKCkgCj4+ IGluIF9fV0FSTl9GTEFHUygpLgo+PiAKPj4gTW9yZSBzcGVjaWZpY2FsbHksIGFyY2gvcG93ZXJw Yy9rdm0vYm9vazNzLm86a3ZtcHBjX2hfbG9naWNhbF9jaV9sb2FkKCkgCj4+IHVzZXMgQlVHKCks IGFuZCB0aGUgZ2VuZXJhdGVkIGNvZGUgcmVtYWlucyB0aGUgc2FtZSB3aXRoL3dpdGhvdXQgdGhl IAo+PiB1bnJlYWNoYWJsZSgpIGFubm90YXRpb24uCj4+IAo+PiBUaGlzIHN1Z2dlc3RzIHRoYXQg dGhlIGJhZCBjb2RlZ2VuIHdlIGFyZSBzZWVpbmcgd2l0aCB0aGUgYW5ub3RhdGlvbiBpbiAKPj4g dW5yZWFjaGFibGUoKSBpcyBsaW1pdGVkIHRvIGl0cyB1c2UgaW4gX19XQVJOX0ZMQUdTKCksIHdo aWNoIEkgc3VzcGVjdCAKPj4gaXMgZHVlIHRvIGFuIGludGVyYWN0aW9uIHdpdGggdGhlIHVzZSBv ZiBhc21fdm9sYXRpbGVfZ290bygpIGZvciAKPj4gV0FSTl9FTlRSWSgpLgo+PiAKPj4gSWYgSSBy ZXZlcnQgdGhpcyBwYXRjaCAocGF0Y2ggMDEvMTYpLCBnY2Mgc2VlbXMgdG8gYWRkIGEgbGFiZWwg OCBieXRlcyAKPj4gYmVmb3JlIF9zb21lXyBmdW5jdGlvbiBpbiB0aGlzIG9iamVjdCBmaWxlLCB3 aGljaCBoYXBwZW5zIHRvIGhvbGQgYSAKPj4gcmVsb2NhdGlvbiBhZ2FpbnN0IC5UT0MuLCBhbmQg ZW1pdHMgYSBibCB0byB0aGF0IHN5bWJvbC4gT3RoZXJ3aXNlLCBnY2MgCj4+IGVpdGhlciBlbWl0 cyBubyBuZXcgaW5zdHJ1Y3Rpb24gZm9yIHRoZSBhbm5vdGF0aW9uLCBvciBhICdub3AnIGluIHNv bWUgCj4+IGNhc2VzLgo+PiAKPj4gSWYgSSBhZGQgYSAnbm9wJyBiZXR3ZWVuIFdBUk5fRU5UUlko KSBhbmQgdW5yZWFjaGFibGUoKSBpbiAKPj4gX19XQVJOX0ZMQUdTKCksIG9yIGNvbnZlcnQgV0FS Tl9FTlRSWSB0byBCVUdfRU5UUlkgdGhlcmVieSByZW1vdmluZyB1c2UgCj4+IG9mIGFzbV92b2xh dGlsZV9nb3RvKCksIHRoZSBwcm9ibGVtIGdvZXMgYXdheSBhbmQgbm8gYmwgaXMgZW1pdHRlZDoK Pj4gCj4+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vYnVnLmggCj4+IGIv YXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL2J1Zy5oCj4+IGluZGV4IDYxYTQ3MzYzNTVjMjQ0Li44 OGUwMDI3YzIwYmE1YyAxMDA2NDQKPj4gLS0tIGEvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL2J1 Zy5oCj4+ICsrKyBiL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9idWcuaAo+PiBAQCAtOTksNiAr OTksNyBAQAo+PiAgwqDCoMKgwqDCoMKgIF9fbGFiZWxfXyBfX2xhYmVsX3dhcm5fb247wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4+ ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIFwKPj4gIMKgwqDCoMKgwqDCoCBXQVJOX0VOVFJZKCJ0d2kgMzEsIDAsIDAi LCBCVUdGTEFHX1dBUk5JTkcgfCAoZmxhZ3MpLCAKPj4gX19sYWJlbF93YXJuX29uKTsgXAo+PiAr wqDCoMKgwqDCoMKgIF9fYXNtX18gX192b2xhdGlsZV9fKCJub3AiKTvCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXAo+PiAgwqDCoMKgwqDCoMKg IHVucmVhY2hhYmxlKCk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcCj4+ICDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IFwKPj4gX19sYWJlbF93YXJuX29uOgo+PiAKPj4gCj4+IEluIHN1bW1hcnksIEkgdGhpbmsgdGhl IGFubm90YXRpb24gaXRzZWxmIGlzIGZpbmUgYW5kIHdlIGFyZSBvbmx5IHNlZWluZyAKPj4gYW4g aXNzdWUgd2l0aCBpdHMgdXNhZ2UgYWZ0ZXIgV0FSTl9FTlRSWSgpIGR1ZSB0byB1c2Ugb2YgCj4+ IGFzbV92b2xhdGlsZV9nb3RvLiBPdGhlciB1c2VzIG9mIHVucmVhY2hhYmxlKCkgZG9uJ3Qgc2Vl bSB0byBleGhpYml0IAo+PiB0aGlzIHByb2JsZW0uCj4+IAo+PiBBcyBzdWNoLCBJIHRoaW5rIHRo aXMgcGF0Y2ggaXMgYXBwcm9wcmlhdGUgZm9yIHRoaXMgc2VyaWVzLCB0aG91Z2ggSSAKPj4gdGhp bmsgd2Ugc2hvdWxkIGNhcHR1cmUgc29tZSBvZiB0aGlzIGluZm9ybWF0aW9uIGluIHRoZSBjaGFu Z2Vsb2cuCj4+IAo+PiBOb3RlIGFsc28gdGhhdCBpZiBhbmQgd2hlbiB3ZSBzdGFydCB1dGxpemlu ZyB0aGUgYW5ub3RhdGlvbiwgaWYgd2UgCj4+IGNsYXNzaWZ5IHR3dWkgYXMgSU5TTl9CVUcsIHRo aXMgY2hhbmdlIHdpbGwgY29udGludWUgdG8gYmUgYXBwcm9wcmlhdGUuCj4+IAo+IAo+IElOU05f VFJBUCBpbnN0ZWFkIG9mIElOU05fQlVHID8KCklOU05fQlVHLCBpbiBsaW5lIHdpdGggeW91ciBz dWdnZXN0aW9uIGhlcmU6Cmh0dHA6Ly9sa21sLmtlcm5lbC5vcmcvci9mZjYyMzA5Ny05ZjE4LTM5 MTQtNWVhZS1iYzZlNGNkMTUxMGZAY3Nncm91cC5ldQoKUGV0ZXIgd2FzIG9mIHRoZSBvcGluaW9u IHRoYXQgSU5TTl9UUkFQIG1heSBub3QgYmUgd2hhdCB3ZSB3YW50OgpodHRwOi8vbGttbC5rZXJu ZWwub3JnL3IvWXNMU1U2aWROTUUvQnR3SEBoaXJlei5wcm9ncmFtbWluZy5raWNrcy1hc3MubmV0 CgpJZiB3ZSBjbGFzc2lmeSB0d3VpIGFzIElOU05fQlVHLCB0aGVuIG9ianRvb2wgd2lsbCBrbm93 IHRvIHN0b3AgY29udHJvbCAKZmxvdyBoZXJlIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGFuIGFubm90 YXRpb24uIFBhcnNpbmcgZXh0YWJsZSB3aWxsIAp0aGVuIHNob3cgdGhhdCBjb250cm9sIGZsb3cg Y29udGludWVzIHdpdGggdGhlIGxhYmVsIHN1YnNlcXVlbnRseS4KCgotIE5hdmVlbgoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5l bCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6 Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B912C00140 for ; Thu, 18 Aug 2022 12:25:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244643AbiHRMZl (ORCPT ); Thu, 18 Aug 2022 08:25:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244099AbiHRMZh (ORCPT ); Thu, 18 Aug 2022 08:25:37 -0400 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8086A4F676 for ; Thu, 18 Aug 2022 05:25:36 -0700 (PDT) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27ICFgVK005148; Thu, 18 Aug 2022 12:25:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : subject : to : cc : references : in-reply-to : message-id : content-type : content-transfer-encoding : mime-version; s=pp1; bh=bBUtAJUoZNhGimQV8w6zRvR+wgmSvqiC/9eTqbWmPgE=; b=CQojlGTD7ga5JVDjY8Cr6a73b2iK5tVGEAjTFjinnWpqdp/sOdyrXh3R0PFt2XKU8fpH Y7LYVCR8gGFZfqKvExB5vw4PFDLqWFqyJUa7YRKN7EnWl9Kw6wlu8KJhn2Yui4Kw7WVW b+gk7KfX786vuBuczLrwMjKzvENBq6CuNSmliyRl1Wu/FRTvSWrfKazngtkZw9Zuzn3C osgGANjcPS2mYNCmnNPTtSvsg6PJ6TquJpv6fZGzj4gVXPsn8iCghQUSrw1GIavmjJM0 AhdYrX9/uRrXMlAQufkkiGmReFzK+uSnIuwBmdJW4mDOnAWBCC2xjwWAmvHu6R7pSEjz HA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j1n9a097c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 12:25:12 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 27ICFwqS005799; Thu, 18 Aug 2022 12:25:11 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j1n9a096d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 12:25:11 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27ICKdi8009339; Thu, 18 Aug 2022 12:25:09 GMT Received: from b06avi18878370.portsmouth.uk.ibm.com (b06avi18878370.portsmouth.uk.ibm.com [9.149.26.194]) by ppma06ams.nl.ibm.com with ESMTP id 3hx37jdx0w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 12:25:09 +0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06avi18878370.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27ICPPMq34537890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Aug 2022 12:25:25 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B304442041; Thu, 18 Aug 2022 12:25:06 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 377E24203F; Thu, 18 Aug 2022 12:25:06 +0000 (GMT) Received: from localhost (unknown [9.43.73.112]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 18 Aug 2022 12:25:06 +0000 (GMT) Date: Thu, 18 Aug 2022 17:55:04 +0530 From: "Naveen N. Rao" Subject: Re: [PATCH 01/16] powerpc: Replace unreachable() with it's builtin variant in WARN_ON() To: Christophe Leroy , "linuxppc-dev@lists.ozlabs.org" , Sathvika Vasireddy Cc: "aik@ozlabs.ru" , "chenzhongjin@huawei.com" , "jpoimboe@redhat.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "mbenes@suse.cz" , "mingo@redhat.com" , "mpe@ellerman.id.au" , "npiggin@gmail.com" , "peterz@infradead.org" , "rostedt@goodmis.org" References: <20220808114908.240813-1-sv@linux.ibm.com> <20220808114908.240813-2-sv@linux.ibm.com> <82eec792-b71f-17cc-d905-368fd5ca62f2@csgroup.eu> <1660817468.4x4re2ul0k.naveen@linux.ibm.com> <06b7a93b-5148-4d92-0b56-5956afdfd3fb@csgroup.eu> In-Reply-To: <06b7a93b-5148-4d92-0b56-5956afdfd3fb@csgroup.eu> User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid) Message-Id: <1660824799.vnjff6w3m0.naveen@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: snzh_C56VDGLhgv1qqH-oIUtyQqqipvb X-Proofpoint-GUID: l8CYaXPg3IuQZ2UJotzNpNO1WmWyRP45 Content-Transfer-Encoding: quoted-printable X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-18_12,2022-08-18_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 spamscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208180042 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy wrote: >=20 >=20 > Le 18/08/2022 =C3=A0 12:46, Naveen N. Rao a =C3=A9crit=C2=A0: >> Christophe Leroy wrote: >>> >>> >>> Le 08/08/2022 =C3=A0 13:48, Sathvika Vasireddy a =C3=A9crit=C2=A0: >>>> objtool is throwing *unannotated intra-function call* >>>> warnings with a few instructions that are marked >>>> unreachable. Replace unreachable() with __builtin_unreachable() >>>> to fix these warnings, as the codegen remains same >>>> with unreachable() and __builtin_unreachable(). >>> >>> I think it is necessary to explain why using unreachable() is not=20 >>> necessary for powerpc, or even why using unreachable() is wrong. >>> >>> Allthough we are getting rid of the problem here by replacing=20 >>> unreachable() by __builtin_unreachable(), it might still be a problem=20 >>> in core parts of kernel which still use unreachable. >>=20 >> I did a kernel build with this series applied, with a variant of=20 >> ppc64le_defconfig. I then did another build with the same config, but=20 >> with the below hunk to disable objtool: >>=20 >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> index 6be2e68fa9eb64..4c466acdc70d4c 100644 >> --- a/arch/powerpc/Kconfig >> +++ b/arch/powerpc/Kconfig >> @@ -237,8 +237,6 @@ config PPC >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_MOD_ARCH_SPECIFIC >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_NMI=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if PERF_EVENTS || (PPC6= 4=20 >> && PPC_BOOK3S) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_OPTPROBES >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_OBJTOOL=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if PPC32 || MPROFILE_KERNEL >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_OBJTOOL_MCOUNT=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if= HAVE_OBJTOOL >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_PERF_EVENTS >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_PERF_EVENTS_NMI=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if PPC64 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 select HAVE_PERF_REGS >>=20 >> This has the effect of disabling annotations for unreachable(). >>=20 >> When I compared the resulting object files, I did not see changes in=20 >> codegen relating to the annotation, like we do with using unreachable()= =20 >> in __WARN_FLAGS(). >>=20 >> More specifically, arch/powerpc/kvm/book3s.o:kvmppc_h_logical_ci_load()= =20 >> uses BUG(), and the generated code remains the same with/without the=20 >> unreachable() annotation. >>=20 >> This suggests that the bad codegen we are seeing with the annotation in= =20 >> unreachable() is limited to its use in __WARN_FLAGS(), which I suspect=20 >> is due to an interaction with the use of asm_volatile_goto() for=20 >> WARN_ENTRY(). >>=20 >> If I revert this patch (patch 01/16), gcc seems to add a label 8 bytes=20 >> before _some_ function in this object file, which happens to hold a=20 >> relocation against .TOC., and emits a bl to that symbol. Otherwise, gcc= =20 >> either emits no new instruction for the annotation, or a 'nop' in some=20 >> cases. >>=20 >> If I add a 'nop' between WARN_ENTRY() and unreachable() in=20 >> __WARN_FLAGS(), or convert WARN_ENTRY to BUG_ENTRY thereby removing use= =20 >> of asm_volatile_goto(), the problem goes away and no bl is emitted: >>=20 >> diff --git a/arch/powerpc/include/asm/bug.h=20 >> b/arch/powerpc/include/asm/bug.h >> index 61a4736355c244..88e0027c20ba5c 100644 >> --- a/arch/powerpc/include/asm/bug.h >> +++ b/arch/powerpc/include/asm/bug.h >> @@ -99,6 +99,7 @@ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __label__ __label_warn_on;=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WARN_ENTRY("twi 31, 0, 0", BUGFLAG= _WARNING | (flags),=20 >> __label_warn_on); \ >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __asm__ __volatile__("nop");=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unreachable();=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 \ >> __label_warn_on: >>=20 >>=20 >> In summary, I think the annotation itself is fine and we are only seeing= =20 >> an issue with its usage after WARN_ENTRY() due to use of=20 >> asm_volatile_goto. Other uses of unreachable() don't seem to exhibit=20 >> this problem. >>=20 >> As such, I think this patch is appropriate for this series, though I=20 >> think we should capture some of this information in the changelog. >>=20 >> Note also that if and when we start utlizing the annotation, if we=20 >> classify twui as INSN_BUG, this change will continue to be appropriate. >>=20 >=20 > INSN_TRAP instead of INSN_BUG ? INSN_BUG, in line with your suggestion here: http://lkml.kernel.org/r/ff623097-9f18-3914-5eae-bc6e4cd1510f@csgroup.eu Peter was of the opinion that INSN_TRAP may not be what we want: http://lkml.kernel.org/r/YsLSU6idNME/BtwH@hirez.programming.kicks-ass.net If we classify twui as INSN_BUG, then objtool will know to stop control=20 flow here without the need for an annotation. Parsing extable will=20 then show that control flow continues with the label subsequently. - Naveen