linux-kernel - Re: [PATCH] arm64: Remove the check for CONFIG_TINY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241014131042.GA17353@willie-the-truck>
Date: Mon, 14 Oct 2024 14:10:43 +0100
From: Will Deacon <will@...nel.org>
To: Ryo Takakura <ryotkkr98@...il.com>
Cc: catalin.marinas@....com, broonie@...nel.org, mark.rutland@....com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: Remove the check for CONFIG_TINY_RCU

On Sat, Sep 14, 2024 at 06:00:40PM +0900, Ryo Takakura wrote:
> Since the commit 4b3dc9679cf77 ("arm64: force CONFIG_SMP=y and remove
> redundant #ifdefs"), arm64 defaults to CONFIG_SMP but TINY_RCU is cofigured
> only for !SMP systems.
> 
> Remove the check for CONFIG_TINY_RCU as it should always be false.
> 
> Signed-off-by: Ryo Takakura <ryotkkr98@...il.com>
> ---
>  arch/arm64/kernel/entry-common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> index b77a15955f28..a9765364fc67 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -40,7 +40,7 @@ static __always_inline void __enter_from_kernel_mode(struct pt_regs *regs)
>  {
>  	regs->exit_rcu = false;
>  
> -	if (!IS_ENABLED(CONFIG_TINY_RCU) && is_idle_task(current)) {
> +	if (is_idle_task(current)) {
>  		lockdep_hardirqs_off(CALLER_ADDR0);
>  		ct_irq_enter();
>  		trace_hardirqs_off_finish();

I think this code was deliberately written to follow kernel/entry/common.c
as closely as possible, as we should be able to switch over to that at
some point.

Come to think of it, Mark, what work is needed before we can move to the
generic code? Is there anything you need a hand with?

Will