lkml.org 
[lkml]   [2021]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 1/2] ftrace: disable preemption between ftrace_test_recursion_trylock/unlock()
From
Date


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;
>
>>
>>

\
 
 \ /
  Last update: 2021-10-15 06:46    [W:0.068 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site