Re: [RFC PATCH 04/47] mm: asi: ASI support in interrupts/exceptions

[Thomas Gleixner]

Junaid,

On Mon, Mar 14 2022 at 19:01, Junaid Shahid wrote:
> On 3/14/22 08:50, Thomas Gleixner wrote:
>> On Tue, Feb 22 2022 at 21:21, Junaid Shahid wrote:
>>>   #define DEFINE_IDTENTRY_RAW(func)					\
>>> -__visible noinstr void func(struct pt_regs *regs)
>>> +static __always_inline void __##func(struct pt_regs *regs);		\
>>> +									\
>>> +__visible noinstr void func(struct pt_regs *regs)			\
>>> +{									\
>>> +	asi_intr_enter();						\
>> 
>> This is wrong. You cannot invoke arbitrary code within a noinstr
>> section.
>> 
>> Please enable CONFIG_VMLINUX_VALIDATION and watch the build result with
>> and without your patches.
>> 
> Thank you for the pointer. It seems that marking asi_intr_enter/exit
> and asi_enter/exit, and the few functions that they in turn call, as
> noinstr would fix this, correct? (Along with removing the VM_BUG_ONs
> from those functions and using notrace/nodebug variants of a couple of
> functions).

you can keep the BUG_ON()s. If such a bug happens the noinstr
correctness is the least of your worries, but it's important to get the
information out, right?

Vs. adding noinstr. Yes, making the full callchain noinstr is going to
cure it, but you really want to think hard whether these calls need to
be in this section of the exception handlers.

These code sections have other constraints aside of being excluded from
instrumentation, the main one being that you cannot use RCU there.

I'm not yet convinced that asi_intr_enter()/exit() need to be invoked in
exactly the places you put it. The changelog does not give any clue
about the why...

Thanks,

        tglx