All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
To: Li Zetao <lizetao1@huawei.com>, Mark Rutland <mark.rutland@arm.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>,
	<Dave.Martin@arm.com>, <xieyuanbin1@huawei.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <nixiaoming@huawei.com>,
	<wangbing6@huawei.com>, <douzhaolei@huawei.com>,
	<liaohua4@huawei.com>, <lijiahuan5@huawei.com>,
	<wangfangpeng1@huawei.com>,
	"zhangjianhua (E)" <chris.zjh@huawei.com>
Subject: Re: [PATCH] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
Date: Mon, 20 May 2024 21:21:39 +0800	[thread overview]
Message-ID: <876b3571-b7f5-03f1-5da2-07a2ec47ad08@huawei.com> (raw)
In-Reply-To: <20d70835-9411-9a08-c567-56d7040e01dd@huawei.com>



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.

WARNING: multiple messages have this Message-ID (diff)
From: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
To: Li Zetao <lizetao1@huawei.com>, Mark Rutland <mark.rutland@arm.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>,
	<Dave.Martin@arm.com>, <xieyuanbin1@huawei.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <nixiaoming@huawei.com>,
	<wangbing6@huawei.com>, <douzhaolei@huawei.com>,
	<liaohua4@huawei.com>, <lijiahuan5@huawei.com>,
	<wangfangpeng1@huawei.com>,
	"zhangjianhua (E)" <chris.zjh@huawei.com>
Subject: Re: [PATCH] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
Date: Mon, 20 May 2024 21:21:39 +0800	[thread overview]
Message-ID: <876b3571-b7f5-03f1-5da2-07a2ec47ad08@huawei.com> (raw)
In-Reply-To: <20d70835-9411-9a08-c567-56d7040e01dd@huawei.com>



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

  parent reply	other threads:[~2024-05-20 13:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17 14:13 [PATCH] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY Jiangfeng Xiao
2024-05-17 14:13 ` Jiangfeng Xiao
2024-05-20 10:33 ` Mark Rutland
2024-05-20 10:33   ` Mark Rutland
2024-05-20 12:05   ` Li Zetao
2024-05-20 12:05     ` Li Zetao
2024-05-20 13:01     ` Mark Rutland
2024-05-20 13:01       ` Mark Rutland
2024-05-20 13:21     ` Jiangfeng Xiao [this message]
2024-05-20 13:21       ` Jiangfeng Xiao
2024-05-20 13:30   ` Jiangfeng Xiao
2024-05-20 13:30     ` Jiangfeng Xiao
2024-05-20 13:34 ` [PATCH v2] " Jiangfeng Xiao
2024-05-20 13:34   ` Jiangfeng Xiao
2024-05-21 18:39   ` Will Deacon
2024-05-21 18:39     ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=876b3571-b7f5-03f1-5da2-07a2ec47ad08@huawei.com \
    --to=xiaojiangfeng@huawei.com \
    --cc=Dave.Martin@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=chris.zjh@huawei.com \
    --cc=douzhaolei@huawei.com \
    --cc=liaohua4@huawei.com \
    --cc=lijiahuan5@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizetao1@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=nixiaoming@huawei.com \
    --cc=wangbing6@huawei.com \
    --cc=wangfangpeng1@huawei.com \
    --cc=will@kernel.org \
    --cc=xieyuanbin1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.