Skip to content
  • Steven Rostedt (Red Hat)'s avatar
    ftrace: Fix up trampoline accounting with looping on hash ops · bce0b6c5
    Steven Rostedt (Red Hat) authored
    
    
    Now that a ftrace_hash can be shared by multiple ftrace_ops, they can dec
    the rec->flags by more than once (one per those that share the ftrace_hash).
    This means that the tramp_hash may not have a hash item when it was added.
    
    For example, if two ftrace_ops share a hash for a ftrace record, and the
    first ops has a trampoline, when it adds itself it will set the rec->flags
    TRAMP flag and increments its nr_trampolines counter. When the second ops
    is added, it must clear that tramp flag but also decrement the other ops
    that shares its hash. As the update to the function callbacks has not yet
    been performed, the other ops will not have the tramp hash set yet and it
    can not be used to know to decrement its nr_trampolines.
    
    Luckily, the tramp_hash does not need to be used. As the ftrace_mutex is
    held, a ops with a trampoline to a record during an update of another ops
    that shares the record will have its func_hash pointing to it. Since a
    trampoline can only be set for a record if only one ops is attached to it,
    we can just check if the record has a trampoline (the FTRACE_FL_TRAMP flag
    is set) and then find the ops that has this record in its hashes.
    
    Also added some output to help debug when things go wrong.
    
    Cc: stable@vger.kernel.org # 3.16+ (apply after 3.17-rc4 is out)
    Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
    bce0b6c5