Re: [RFC PATCH 0/7] Early task context tracking

[Daniel Bristot de Oliveira]

On 4/4/19 2:01 AM, Andy Lutomirski wrote:
>> To resolve this problem, the set/unset of the IRQ/NMI context needs to
>> be done before the execution of the first C execution, and after its
>> return. By doing so, and using this method to identify the context in the
>> trace recursion protection, no more events are lost.
> I would much rather do the opposite: completely remove context
> tracking from the asm and, instead, stick it into the C code.  We'd
> need to make sure that the C code is totally immune from tracing,
> kprobes, etc, but it would be a nice cleanup.  And then you could fix
> this bug in C!
> 
> 

Humm... what we could do to have things in C is to set the variable right at the
begin of the C handler, e.g., do_IRQ(), and right before the return.

But by doing this we would have a problem with two things:

1) irq handler itself (e.g., do_IRQ())
2) functions/tracepoints that might run before and after the handler execution
(e.g., preemptirq tracer), but still in the IRQ context.

We can work around the first case by checking if (the function is in the
__irq_entry .text section) in the recursion control.

The second case would still be a problem. For instance, the preemptirq:
tracepoints in the preemptirq tracer would be "dropped" in the case of a
miss-identification of a recursion.

Thinking aloud: should we try to move the preemptirq tracers to the C part?

I will try to come up with a patch with this approach to see if it "works."

Thoughts?

-- Daniel