[PATCH -next v4 03/19] arm64: entry: Remove __enter_from_user_mode()

Jinjie Ruan posted 19 patches 1 month, 1 week ago
There is a newer version of this series
[PATCH -next v4 03/19] arm64: entry: Remove __enter_from_user_mode()
Posted by Jinjie Ruan 1 month, 1 week ago
The __enter_from_user_mode() is only called by enter_from_user_mode(),
so replaced it with enter_from_user_mode().

No functional changes.

Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
 arch/arm64/kernel/entry-common.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 68a9aecacdb9..ccf59b44464d 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -109,7 +109,7 @@ static void noinstr exit_to_kernel_mode(struct pt_regs *regs,
  * Before this function is called it is not safe to call regular kernel code,
  * instrumentable code, or any code which may trigger an exception.
  */
-static __always_inline void __enter_from_user_mode(void)
+static __always_inline void enter_from_user_mode(struct pt_regs *regs)
 {
 	lockdep_hardirqs_off(CALLER_ADDR0);
 	CT_WARN_ON(ct_state() != CT_STATE_USER);
@@ -118,11 +118,6 @@ static __always_inline void __enter_from_user_mode(void)
 	mte_disable_tco_entry(current);
 }
 
-static __always_inline void enter_from_user_mode(struct pt_regs *regs)
-{
-	__enter_from_user_mode();
-}
-
 /*
  * Handle IRQ/context state management when exiting to user mode.
  * After this function returns it is not safe to call regular kernel code,
-- 
2.34.1
Re: [PATCH -next v4 03/19] arm64: entry: Remove __enter_from_user_mode()
Posted by Mark Rutland 1 month ago
On Fri, Oct 25, 2024 at 06:06:44PM +0800, Jinjie Ruan wrote:
> The __enter_from_user_mode() is only called by enter_from_user_mode(),
> so replaced it with enter_from_user_mode().

As with the next two patches, all the __enter_from_*() and __exit_to_*()
are supposed to handle the raw entry, closely matching the generic code,
and the non-underscored enter_from_*() and exit_to_*() functions are
supposed to be wrappers that handle (possibly instrumentable)
arm64-specific post-entry and pre-exit logic.

I would prefer to keep that split, even though enter_from_user_mode() is
a trivial wrapper.

Am I missing some reason we must remove the wrappers?

Mark.

> 
> No functional changes.
> 
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
>  arch/arm64/kernel/entry-common.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> index 68a9aecacdb9..ccf59b44464d 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -109,7 +109,7 @@ static void noinstr exit_to_kernel_mode(struct pt_regs *regs,
>   * Before this function is called it is not safe to call regular kernel code,
>   * instrumentable code, or any code which may trigger an exception.
>   */
> -static __always_inline void __enter_from_user_mode(void)
> +static __always_inline void enter_from_user_mode(struct pt_regs *regs)
>  {
>  	lockdep_hardirqs_off(CALLER_ADDR0);
>  	CT_WARN_ON(ct_state() != CT_STATE_USER);
> @@ -118,11 +118,6 @@ static __always_inline void __enter_from_user_mode(void)
>  	mte_disable_tco_entry(current);
>  }
>  
> -static __always_inline void enter_from_user_mode(struct pt_regs *regs)
> -{
> -	__enter_from_user_mode();
> -}
> -
>  /*
>   * Handle IRQ/context state management when exiting to user mode.
>   * After this function returns it is not safe to call regular kernel code,
> -- 
> 2.34.1
>
Re: [PATCH -next v4 03/19] arm64: entry: Remove __enter_from_user_mode()
Posted by Jinjie Ruan 1 month ago

On 2024/10/29 22:42, Mark Rutland wrote:
> On Fri, Oct 25, 2024 at 06:06:44PM +0800, Jinjie Ruan wrote:
>> The __enter_from_user_mode() is only called by enter_from_user_mode(),
>> so replaced it with enter_from_user_mode().
> 
> As with the next two patches, all the __enter_from_*() and __exit_to_*()
> are supposed to handle the raw entry, closely matching the generic code,
> and the non-underscored enter_from_*() and exit_to_*() functions are
> supposed to be wrappers that handle (possibly instrumentable)

Sure, the __enter_from_*() and __exit_to_*() is all about the generic
code, and the enter_from_*() and exit_to_*() includes arm64-specific MTE
  check.

> arm64-specific post-entry and pre-exit logic.
> 
> I would prefer to keep that split, even though enter_from_user_mode() is
> a trivial wrapper.
> 
> Am I missing some reason we must remove the wrappers?

It is not necessary to remove these functions, just found it by chance
and cleanup them by the way, originally I thought that removing the
underline function might make the relative order of the MTE functions
look clearer.

> 
> Mark.
> 
>>
>> No functional changes.
>>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>>  arch/arm64/kernel/entry-common.c | 7 +------
>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
>> index 68a9aecacdb9..ccf59b44464d 100644
>> --- a/arch/arm64/kernel/entry-common.c
>> +++ b/arch/arm64/kernel/entry-common.c
>> @@ -109,7 +109,7 @@ static void noinstr exit_to_kernel_mode(struct pt_regs *regs,
>>   * Before this function is called it is not safe to call regular kernel code,
>>   * instrumentable code, or any code which may trigger an exception.
>>   */
>> -static __always_inline void __enter_from_user_mode(void)
>> +static __always_inline void enter_from_user_mode(struct pt_regs *regs)
>>  {
>>  	lockdep_hardirqs_off(CALLER_ADDR0);
>>  	CT_WARN_ON(ct_state() != CT_STATE_USER);
>> @@ -118,11 +118,6 @@ static __always_inline void __enter_from_user_mode(void)
>>  	mte_disable_tco_entry(current);
>>  }
>>  
>> -static __always_inline void enter_from_user_mode(struct pt_regs *regs)
>> -{
>> -	__enter_from_user_mode();
>> -}
>> -
>>  /*
>>   * Handle IRQ/context state management when exiting to user mode.
>>   * After this function returns it is not safe to call regular kernel code,
>> -- 
>> 2.34.1
>>
>