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 90877C04FFE for ; Mon, 20 May 2024 13:22:19 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:CC:References:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=LOADxe3n7tGT9s39diChWThfyQk+UUHRqQL6A/6xYug=; b=QU19GWjmWkXpSgf+QuCc5rpQvD pMtvTJPJwA+WWeSmDXXIZflwqL+aUqQJHuSS8fqBcXya8c8NLar5qQ9DZeXlazX9BaEG7PDCqQhnB zBmQ1wXzdBtcR0KPl2OGofJNedDiYVBPCMQnWQIc3LhkHjiTJRq2O87R2RJmU9jagN3r0rnnX0nWh qwbPm8gD+ob+PxsPCf41UgflLR5pTgp5r1zIix+GMaz7YA8Ob8TOJRhlXxRw2A0OsP5Q/fT/v2sAz 06nTGy5kvuhCDt+iJOsqxx31xvu9QhSiASp+sMBb2v90mTiLAgqQpL1t4zq7KcAnRsJTrfI8EMMm+ TW8wF8Rw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s92xs-0000000EZji-1ien; Mon, 20 May 2024 13:22:08 +0000 Received: from szxga05-in.huawei.com ([45.249.212.191]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s92xp-0000000EZfB-3apx for linux-arm-kernel@lists.infradead.org; Mon, 20 May 2024 13:22:07 +0000 Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4VjdTp3zn5z1HCJF; Mon, 20 May 2024 21:20:14 +0800 (CST) Received: from canpemm500010.china.huawei.com (unknown [7.192.105.118]) by mail.maildlp.com (Postfix) with ESMTPS id 8334B180062; Mon, 20 May 2024 21:21:44 +0800 (CST) Received: from [10.67.111.82] (10.67.111.82) by canpemm500010.china.huawei.com (7.192.105.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 20 May 2024 21:21:44 +0800 Subject: Re: [PATCH] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY To: Li Zetao , Mark Rutland References: <1715955208-17109-1-git-send-email-xiaojiangfeng@huawei.com> <20d70835-9411-9a08-c567-56d7040e01dd@huawei.com> CC: , , , , , , , , , , , , "zhangjianhua (E)" From: Jiangfeng Xiao Message-ID: <876b3571-b7f5-03f1-5da2-07a2ec47ad08@huawei.com> Date: Mon, 20 May 2024 21:21:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20d70835-9411-9a08-c567-56d7040e01dd@huawei.com> X-Originating-IP: [10.67.111.82] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500010.china.huawei.com (7.192.105.118) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240520_062206_257071_BF683D4E X-CRM114-Status: GOOD ( 12.84 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2024/5/20 20:05, Li Zetao wrote: >>> diff --git a/arch/arm64/include/asm/asm-bug.h b/arch/arm64/include/asm/asm-bug.h >>> index c762038..6e73809 100644 >>> --- a/arch/arm64/include/asm/asm-bug.h >>> +++ b/arch/arm64/include/asm/asm-bug.h >>> @@ -28,6 +28,7 @@ >>> 14470: .long 14471f - .; \ >>> _BUGVERBOSE_LOCATION(__FILE__, __LINE__) \ >>> .short flags; \ >>> + .align 2; \ > The use of .align 2 here is based on the assumption that struct bug_entry is 4-byte aligned. Currently, there is no problem with this assumption, but for compatibility reasons, refer to the riscv architecture and refactor the implementation of __BUG_FLAGS: > > #define __BUG_FLAGS(flags) \ > do { \ > __asm__ __volatile__ ( \ > "1:\n\t" \ > "ebreak\n" \ > ".pushsection __bug_table,\"aw\"\n\t" \ > "2:\n\t" \ > __BUG_ENTRY "\n\t" \ > ".org 2b + %3\n\t" \ > ".popsection" \ > : \ > : "i" (__FILE__), "i" (__LINE__), \ > "i" (flags), \ > "i" (sizeof(struct bug_entry))); \ > } while (0) > > Align the real size of struct bug_entry through .org. What do you think? The implementation of risc-v BUG_ENTRY does handle the `implicit padding` at the end of the struct correctly, however, it does not handle the `implicit padding` in the middle of the struct correctly, for example, assume that the struct bug_entry changes as follows in the future: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 6 bytes unsigned long long flags2; // 8 bytes } Even the implementation of risc-v BUG_ENTRY can't handle this situation. Referencing risc-v solution complicates things, but doesn't completely solve the problem. In the current scenario, we know the contents of struct bug_entry and generate variables using assembly language. I don't think it's necessary to complicate things. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel