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 7D1BFCF64B1 for ; Sat, 22 Nov 2025 11:05:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zxgMTK/rpJeW62sRb1TXMj768OjTRDF/xqa+/y0Pa8E=; b=23cZugIr+E2CLx2cUhQ/M61RCe lEV4+mH9a941wS3MLW1kCH8fDEZNJjS47P6FITlRI5VlPmXL8fu+YDlyg83RspwM4yv13xDmvHOEC Lz5bDx+Bi3GRJUDrrUiOD/NeQ1iMw7I3tRgJjaXz6RhjBt3UZ4pHHjxp/osfc4b9kMSILC6Vc0xAO 0sPfqxvMbrM3abOXyzCIiy9rTICVYg/s4U3LbwbJabNOu48UuiA610zB/RzWI86cAyhHS5+gEfTS1 vjyoNk/EP2s9ygcMRh+gTCr7iDcLKPa2kKu+vmEnl4Q8TbC5DarXYiumryX6mS+vQjfzx0tEu2lDO Ebtxuf+A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vMlQL-00000009Tva-3PAC; Sat, 22 Nov 2025 11:05:01 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vMlQK-00000009Tv2-1jHh; Sat, 22 Nov 2025 11:05:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description; bh=zxgMTK/rpJeW62sRb1TXMj768OjTRDF/xqa+/y0Pa8E=; b=Q2PBLQBi5oSoNFfWP8kA4vUvTJ vNtLx1nVZuzWxbncsVLv7Qz0EYG3aEbd7xNiaGeK0aao6h8jPYd64XzjFuTDGMEFPAfW68+G/b9aL fPbST/f9YK6bGDFYvGRPdi32E0INcotoXpCu8HaL6pzOlHfgG0I01G5cXiqIbKlP9x8vzvBoEOhF7 TS4nMWfxJg52rerKOcZp4Jh2GqJjIHd0QYwmYkT4koRNy83eI+V6m8Odt449R4ek65ZGeseKkdLnS orrWNUqm+XNKJAXxdSpAV2PJnkO8RrSZlR98pKiMn1p0tXNkGtwjnWGohzAQwjiH5LhErvc7OjfaH VI5Vl0Ww==; Received: from mail.loongson.cn ([114.242.206.163]) by casper.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vMlQF-00000004FX9-2GgY; Sat, 22 Nov 2025 11:04:58 +0000 Received: from loongson.cn (unknown [36.44.121.68]) by gateway (Coremail) with SMTP id _____8Cx77_EmCFpBO0mAA--.16101S3; Sat, 22 Nov 2025 19:04:36 +0800 (CST) Received: from [192.168.0.111] (unknown [36.44.121.68]) by front1 (Coremail) with SMTP id qMiowJDx_8O6mCFpg+Y7AQ--.35665S3; Sat, 22 Nov 2025 19:04:32 +0800 (CST) Message-ID: <39617a3e-c476-abac-8425-bbcece769cdb@loongson.cn> Date: Sat, 22 Nov 2025 19:04:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v2] efistub: Only link libstub to final vmlinux Content-Language: en-US To: Huacai Chen , Will Deacon Cc: Josh Poimboeuf , Catalin Marinas , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Madhavan T. Venkataraman" , Ard Biesheuvel , loongarch@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, linux-efi@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, Nathan Chancellor References: <33612d85-e70b-26da-8460-ea6b9064ce08@loongson.cn> <421c08e1-255b-447b-b5e3-ee6544fbefd2@loongson.cn> <32s3lvzfu6jkyho7qenrqbsm5wkgjnzn2imdp6tfwycmyxpzgu@kg5367uxmxii> From: Tiezhu Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: qMiowJDx_8O6mCFpg+Y7AQ--.35665S3 X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxAF45tryxCw18uFyfCr1kCrX_yoWrJw48pF WjyFWqkr4DJr4fXwnrK3WUXFWYyr1fJrW8WF90vry8CrWqvrn7Xw4Fkr4j9FyDXr13Wr12 vrW0qFyavFWUA3gCm3ZEXasCq-sJn29KB7ZKAUJUUUU7529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUPFb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ Gr0_Gr1UM2kKe7AKxVWUXVWUAwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYI kI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUAVWU twAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMx k0xIA0c2IEe2xFo4CEbIxvr21lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l 4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l4IxYO2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxV WUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r4a6rW5MIIYrxkI 7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r 4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI 42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUceOJUUUUU X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251122_110456_174713_52077D66 X-CRM114-Status: GOOD ( 22.26 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Cc: Nathan Chancellor Hi all, On 11/21/25 22:36, Huacai Chen wrote: > On Mon, Nov 17, 2025 at 7:33 PM Will Deacon wrote: >> >> On Sat, Nov 15, 2025 at 11:16:42AM +0800, Huacai Chen wrote: >>> On Wed, Nov 12, 2025 at 2:00 AM Josh Poimboeuf wrote: >>>> >>>> On Mon, Nov 10, 2025 at 03:00:00PM +0800, Huacai Chen wrote: >>>>> On Mon, Nov 10, 2025 at 9:19 AM Tiezhu Yang wrote: >>>>>> If I understand correctly, I should modify this patch to remove the >>>>>> changes of arm and riscv for now, do the changes only when there is >>>>>> a real problem or requirement some day, right? If no more comments, >>>>>> I will send v3 later. >>>>> >>>>> Now everyone involved agrees that the efistub code is correct, so the >>>>> proper solution is to fix the compiler. >>>> >>>> Hm? I don't see how it's a compiler bug. It's really just an objtool >>>> limitation. >>>> >>>>> Changing efistub code and changing objtool (ignore __efistub prefix) >>>>> are both workarounds, but I think changing objtool is a little more >>>>> reasonable. Maybe Josh has different ideas? >>>> >>>> I thought the conversation had converged on what Tiezhu mentioned above, >>>> which is to skip objtool on libstub for loongarch, but leave the other >>>> arches alone. That way objtool behavior is consistent between loongarch >>>> and x86, and objtool doesn't need to ignore any prefixes. >>>> >>>> So basically, the v2 patch minus the arm64/riscv changes. >>> >>> Hi, ARM64 and RISC-V maintainers, >>> >>> Would you mind that this patch modifies the three architectures >>> together (they are exactly the same style now)? >>> >>> Madhavan is the author of ARM64's objtool, I think your opinion is >>> also very important. >> >> arm64 doesn't (yet) use objtool. >> >> I defer to Ard on anything relating to the arm64 efistub. Reading the >> start of this thread, it doesn't look like he's convinced and I'm not >> surprised if it's purely an issue with objtool. > OK, I know, but I have a concern. > > Ard said that he is reluctant to make changes to accommodate a flawed > build time tool and there may be regression risk. > > So, I'm also reluctant and don't want LoongArch to meet regression > risk. If one day LoongArch has a regression, we probably need another > workaround to "fix" this workaround. But if these three architectures > change in the same way, we may have a chance to solve some fundamental > problems... IIUC, Josh do not like to ignore these EFISTUB functions in validate_branch() of objtool, Huacai do not like to only link libstub to vmlinux only for LoongArch. It seems that there is only one way to fix or workaround this problem, remove the attribute __noreturn for real_kernel_entry() and then make efi_boot_kernel() ends with a return instruction [1] or an unconditional jump instruction [2] that only touches drivers/firmware/efi/libstub/loongarch.c. Since this is a issue only for LoongArch by now, what do you think of this minimal change only for LoongArch libstub code? Using "return EFI_LOAD_ERROR" [1] or "while (1)" [2]? Maybe this is the simple and direct way for this special issue only on LoongArch so far. If not, any other suggestions? On the other hand, is it possible to add KBUILD_VMLINUX_LIBS_FINAL and then use it only for LoongArch first [3]? Any potential risks? What is the next step? [1] https://lore.kernel.org/loongarch/CAMj1kXH-rK0bRyHXdJ-crAyMyvJHApH0WR7_8Qd8vrSPBLK+yg@mail.gmail.com/ [2] https://lore.kernel.org/loongarch/20250826064631.9617-2-yangtiezhu@loongson.cn/ [3] https://lore.kernel.org/loongarch/20251122000101.GA1996391@ax162/ Thanks, Tiezhu