Re: [PATCH v2 3/4] arm64: mte: Enable async tag check fault

[Vincenzo Frascino <vincenzo.frascino@arm.com>]

On 1/14/21 2:25 PM, Catalin Marinas wrote:
> On Thu, Jan 14, 2021 at 10:24:25AM +0000, Vincenzo Frascino wrote:
>> On 1/13/21 6:11 PM, Catalin Marinas wrote:
>>> On Thu, Jan 07, 2021 at 05:29:07PM +0000, Vincenzo Frascino wrote:
>>>>  static inline void mte_sync_tags(pte_t *ptep, pte_t pte)
>>>>  {
>>>>  }
>>>> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
>>>> index 5346953e4382..74b020ce72d7 100644
>>>> --- a/arch/arm64/kernel/entry-common.c
>>>> +++ b/arch/arm64/kernel/entry-common.c
>>>> @@ -37,6 +37,8 @@ static void noinstr enter_from_kernel_mode(struct pt_regs *regs)
>>>>  	lockdep_hardirqs_off(CALLER_ADDR0);
>>>>  	rcu_irq_enter_check_tick();
>>>>  	trace_hardirqs_off_finish();
>>>> +
>>>> +	mte_check_tfsr_el1();
>>>>  }
>>>>  
>>>>  /*
>>>> @@ -47,6 +49,8 @@ static void noinstr exit_to_kernel_mode(struct pt_regs *regs)
>>>>  {
>>>>  	lockdep_assert_irqs_disabled();
>>>>  
>>>> +	mte_check_tfsr_el1();
>>>> +
>>>>  	if (interrupts_enabled(regs)) {
>>>>  		if (regs->exit_rcu) {
>>>>  			trace_hardirqs_on_prepare();
>>>> @@ -243,6 +247,8 @@ asmlinkage void noinstr enter_from_user_mode(void)
>>>>  
>>>>  asmlinkage void noinstr exit_to_user_mode(void)
>>>>  {
>>>> +	mte_check_tfsr_el1();
>>>
>>> While for kernel entry the asynchronous faults are sync'ed automatically
>>> with TFSR_EL1, we don't have this for exit, so we'd need an explicit
>>> DSB. But rather than placing it here, it's better if we add a bool sync
>>> argument to mte_check_tfsr_el1() which issues a dsb() before checking
>>> the register. I think that's the only place where such argument would be
>>> true (for now).
>>
>> Good point, I will add the dsb() in mte_check_tfsr_el1() but instead of a bool
>> parameter I will add something more explicit.
> 
> Or rename the function to mte_check_tfsr_el1_no_sync() and have a static
> inline mte_check_tfsr_el1() which issues a dsb() before calling the
> *no_sync variant.
> 
> Adding an enum instead here is not worth it (if that's what you meant by
> not using a bool).
> 

I like this option more, thanks for pointing it out.

-- 
Regards,
Vincenzo