[PATCH v3 1/2] ftrace: disable preemption between ftrace_test_recursion_trylock/unlock()
王贇
yun.wang at linux.alibaba.com
Thu Oct 14 21:45:27 PDT 2021
On 2021/10/15 上午11:13, 王贇 wrote:
[snip]
>> # define do_ftrace_record_recursion(ip, pip) do { } while (0)
>> #endif
>>
>> +/*
>> + * trace_test_and_set_recursion() is called on several layers
>> + * of the ftrace code when handling the same ftrace entry.
>> + * These calls might be nested/recursive.
>> + *
>> + * It uses TRACE_LIST_*BITs to distinguish between this
>> + * internal recursion and recursion caused by calling
>> + * the traced function by the ftrace code.
>> + *
>> + * Returns: > 0 when no recursion
>> + * 0 when called recursively internally (safe)
>
> The 0 can also happened when ftrace handler recursively called trylock()
> under the same context, or not?
>
Never mind... you're right about this.
Regards,
Michael Wang
> Regards,
> Michael Wang
>
>> + * -1 when the traced function was called recursively from
>> + * the ftrace handler (unsafe)
>> + */
>> static __always_inline int trace_test_and_set_recursion(unsigned long ip, unsigned long pip,
>> int start, int max)
>> {
>> unsigned int val = READ_ONCE(current->trace_recursion);
>> int bit;
>>
>> - /* A previous recursion check was made */
>> + /* Called recursively internally by different ftrace code layers? */
>> if ((val & TRACE_CONTEXT_MASK) > max)
>> return 0;
>
>>
>>
More information about the linux-riscv
mailing list