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:3.194 / U:2.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site