On Fri 2021-10-15 11:00:35, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@xxxxxxxxxxx>
>
> While writing an email explaining the "bit = 0" logic for a discussion on
> making ftrace_test_recursion_trylock() disable preemption, I discovered a
> path that makes the "not do the logic if bit is zero" unsafe.
>
> Since we want to encourage architectures to implement all ftrace features,
> having them slow down due to this extra logic may encourage the
> maintainers to update to the latest ftrace features. And because this
> logic is only safe for them, remove it completely.
>
> [*] There is on layer of recursion that is allowed, and that is to allow
> for the transition between interrupt context (normal -> softirq ->
> irq -> NMI), because a trace may occur before the context update is
> visible to the trace recursion logic.
>
> diff --git a/include/linux/trace_recursion.h b/include/linux/trace_recursion.h
> index a9f9c5714e65..168fdf07419a 100644
> --- a/include/linux/trace_recursion.h
> +++ b/include/linux/trace_recursion.h
> @@ -165,40 +147,29 @@ static __always_inline int trace_test_and_set_recursion(unsigned long ip, unsign
> unsigned int val = READ_ONCE(current->trace_recursion);
> int bit;
>
> - /* A previous recursion check was made */
> - if ((val & TRACE_CONTEXT_MASK) > max)
> - return 0;
@max parameter is no longer used.
> -
> bit = trace_get_context_bit() + start;
> if (unlikely(val & (1 << bit))) {
> /*
> * It could be that preempt_count has not been updated during
> * a switch between contexts. Allow for a single recursion.
> */
> - bit = TRACE_TRANSITION_BIT;
> + bit = TRACE_CTX_TRANSITION + start;
I just want to be sure that I understand it correctly.
The transition bit is the same for all contexts. It will allow one
recursion only in one context.
IMHO, the same problem (not-yet-updated preempt_count) might happen
in any transition between contexts: normal -> soft IRQ -> IRQ -> NMI.
Well, I am not sure what exacly it means "preempt_count has not been
updated during a switch between contexts."
Is it that a function in the interrupt entry code is traced before
preempt_count is updated?
Or that an interrupt entry is interrupted by a higher level
interrupt, e.g. IRQ entry code interrupted by NMI?
I guess that it is the first case. It would mean that the above
function allows one mistake (one traced funtion in an interrupt entry
code before the entry code updates preempt_count).
Do I get it correctly?
Is this what we want?
Could we please update the comment? I mean to say if it is a race
or if we trace a function that should not get traced.
> if (val & (1 << bit)) {
> do_ftrace_record_recursion(ip, pip);
> return -1;
> }
> - } else {
> - /* Normal check passed, clear the transition to allow it again */
> - val &= ~(1 << TRACE_TRANSITION_BIT);
> }
>
> val |= 1 << bit;
> current->trace_recursion = val;
> barrier();
>
> - return bit + 1;
> + return bit;
> }
>
> static __always_inline void trace_clear_recursion(int bit)
> {
> - if (!bit)
> - return;
> -
> barrier();
> - bit--;
> trace_recursion_clear(bit);
> }
Otherwise, the change looks great. It simplifies that logic a lot.
I think that I start understanding it ;-)
Best Regards,
Petr
