From: Jinjie Ruan <ruanjinjie@huawei.com>
To: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>, <oleg@redhat.com>,
<tglx@linutronix.de>, <peterz@infradead.org>, <luto@kernel.org>,
<kees@kernel.org>, <wad@chromium.org>, <rostedt@goodmis.org>,
<arnd@arndb.de>, <ardb@kernel.org>, <broonie@kernel.org>,
<mark.rutland@arm.com>, <rick.p.edgecombe@intel.com>,
<leobras@redhat.com>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 3/3] arm64: entry: Convert to generic entry
Date: Thu, 22 Aug 2024 20:30:49 +0800 [thread overview]
Message-ID: <f1883449-9bab-0896-6cc9-4340d2ca72aa@huawei.com> (raw)
In-Reply-To: <4f79f56a-4019-46eb-91dc-f137b714acb7@arm.com>
On 2024/8/20 19:43, Kevin Brodsky wrote:
> On 29/06/2024 10:56, Jinjie Ruan wrote:
>> Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64
>> to use the generic entry infrastructure from kernel/entry/*. The generic
>> entry makes maintainers' work easier and codes more elegant, which also
>> removed duplicate 150+ LOC. The changes are below:
>>
>> - Remove TIF_SYSCALL_* flag, _TIF_WORK_MASK, _TIF_SYSCALL_WORK
>>
>> - Remove syscall_trace_enter/exit() and use generic one.
>>
>> - Remove *enter_from/exit_to_kernel_mode(), and wrap with generic
>> irqentry_enter/exit().
>>
>> - Remove *enter_from/exit_to_user_mode(), and wrap with generic
>> irqentry_enter_from/exit_to_user_mode().
>>
>> - Remove arm64_enter/exit_nmi() and use generic irqentry_nmi_enter/exit().
>>
>> - Remove PREEMPT_DYNAMIC code, as generic entry will do it ok by
>> implementing arch_irqentry_exit_need_resched().
>
> This is looking good to me overall, moving to using the generic helpers
> is a clear improvement. I've tried my best to check that the new
Thank you very much for the review, It does make the code more clear.
> implementation is functionally equivalent to the old. Ignoring additions
> in the generic code (such as additional instrumentation_{begin,end}()
> pairs or assertions), this seems to be the case, with one exception. The
> MTE operations are done in a slightly different order on entry:
>
> * mte_disable_tco_entry() was called *after* the generic lockdep/CT
> functions in __enter_from_user_mode(). It is now called before those
> generic operations - arch_enter_from_user_mode() called at the beginning
> of enter_from_user_mode().
The most special for arm64 are these MTE operations, the comment for
__enter_from_kernel_mode() and __enter_from_user_mode() said:
" Handle IRQ/context state management when entering from user/kernel
mode. Before this function is called it is not safe to call regular
kernel code "
I guess it is the reason why mte_disable_tco_entry() was called *after*
the generic lockdep/CT functions, but the first version of commit
38ddf7dafaeaf ("arm64: mte: avoid clearing PSTATE.TCO on entry unless
necessary") call it in arch/arm64/kernel/entry.S, so I think the order
is not so important.
>
> * Similarly mte_disable_tco_entry() and mte_check_tfsr_entry() was
> called after the generic operations in enter_from_kernel_mode(), and
> they are now called after - arch_enter_from_kernel_mode() called at the
> beginning of irqentry_enter().
This can be adjusted to be consistent.
>
> I am not under the impression that these ordering changes are
> problematic, but I may be missing something.>
>> [...]
>>
>> -/*
>> - * Handle IRQ/context state management when entering from kernel mode.
>> - * Before this function is called it is not safe to call regular kernel code,
>> - * instrumentable code, or any code which may trigger an exception.
>> - *
>> - * This is intended to match the logic in irqentry_enter(), handling the kernel
>> - * mode transitions only.
>> - */
>> -static __always_inline void __enter_from_kernel_mode(struct pt_regs *regs)
>> -{
>> - regs->exit_rcu = false;
>
> exit_rcu in struct pt_regs is unused now that these functions are gone
> so it can be removed.
It is also consistent with ARM64.
>
>> [...]
>>
>> @@ -259,48 +74,6 @@ static void noinstr arm64_exit_el1_dbg(struct pt_regs *regs)
>
> arm64_{enter,exit}_el1_dbg() have apparently no generic counterparts we
> can replace them with, but maybe we could align them with the generic
> functions some more? Specifically, I'm thinking about making them
> return/take an irqentry_state_t just like irqentry_nmi_{enter,exit}().
> This way we can get rid of struct pt_regs::lockdep_hardirqs, which is
> now only used by those functions.
>
>> lockdep_hardirqs_on(CALLER_ADDR0);
>> }
>>
>> -#ifdef CONFIG_PREEMPT_DYNAMIC
>> -DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched);
>
> The key is declared in asm/preempt.h, that declaration should also be
> removed.
Yes, you are right! commit 1b2d3451ee50 ("arm64: Support
PREEMPT_DYNAMIC") mentioned it:
"Since arm64 does not yet use the generic entry code, we must define
our own `sk_dynamic_irqentry_exit_cond_resched`, which will be
enabled/disabled by the common code in kernel/sched/core.c. All other
preemption functions and associated static keys are defined there."
So if arm64 switched to generic entry, the code can be removed.
>
> Kevin
>
>> [...]
>
>
next prev parent reply other threads:[~2024-08-22 12:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 8:55 [PATCH v3 0/3] " Jinjie Ruan
2024-06-29 8:55 ` [PATCH v3 1/3] entry: Add some arch funcs to support arm64 to use " Jinjie Ruan
2024-08-20 11:41 ` Kevin Brodsky
2024-08-22 12:36 ` Jinjie Ruan
2024-08-26 15:55 ` Kevin Brodsky
2024-06-29 8:56 ` [PATCH v3 2/3] arm64: Prepare to switch to " Jinjie Ruan
2024-08-20 11:42 ` Kevin Brodsky
2024-08-20 12:57 ` Jinjie Ruan
2024-06-29 8:56 ` [PATCH v3 3/3] arm64: entry: Convert " Jinjie Ruan
2024-07-23 1:39 ` Jinjie Ruan
2024-08-20 11:43 ` Kevin Brodsky
2024-08-22 12:30 ` Jinjie Ruan [this message]
2024-08-26 15:56 ` Kevin Brodsky
2024-09-18 1:59 ` Jinjie Ruan
2024-09-18 8:04 ` Mark Rutland
2024-07-01 15:40 ` [PATCH v3 0/3] " Kees Cook
2024-07-02 1:01 ` Jinjie Ruan
2024-07-02 20:59 ` Kees Cook
2024-07-07 19:20 ` Thomas Gleixner
2024-10-17 15:25 ` Mark Rutland
2024-10-21 8:30 ` Jinjie Ruan
2024-10-21 9:45 ` Mark Rutland
2024-10-22 12:07 ` Jinjie Ruan
2024-10-22 13:08 ` Mark Rutland
2024-10-22 13:37 ` Mark Rutland
2024-10-22 13:58 ` Russell King (Oracle)
2024-11-01 23:01 ` Linus Walleij
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=f1883449-9bab-0896-6cc9-4340d2ca72aa@huawei.com \
--to=ruanjinjie@huawei.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kees@kernel.org \
--cc=kevin.brodsky@arm.com \
--cc=leobras@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=wad@chromium.org \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®