lkml.org 
[lkml]   [2013]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH] tracing: Atomically get refcounts of event_call and trace_array
    (2013/07/05 9:32), Oleg Nesterov wrote:
    > On 07/04, Masami Hiramatsu wrote:
    >>
    >> Currently ftrace_open_generic_file gets an event_file from
    >> inode->i_private, and then locks event_mutex and gets refcount.
    >> However, this can cause a race as below scenario;
    >>
    >> CPU0 CPU1
    >> open(kprobe_events)
    >> trace_remove_event_call() open(enable)
    >> lock event_mutex get event_file from inode->i_private
    >> event_remove() wait for unlock event_mutex
    >> ...
    >> free event_file
    >> unlock event_mutex
    >> lock event_mutex
    >> add refcount of event_file->call (*)
    >>
    >> So, at (*) point, the event_file is already freed and we
    >> may access the corrupted object.
    >
    > Yes, but the same can happen with event_call, so it seems that
    > this patch is not enough too.

    Oops, right!

    > Say, open(id) can take event_mutex when the caller of
    > trace_remove_event_call() has already freed ftrace_event_call.
    >
    > Or I missed something...
    >
    > Perhaps we can rely on d_unlinked() ? IOW, the caller of
    > __ftrace_event_call_get() should take event_mutex, check
    > d_unhashed(f_dentry) and only then do _get().

    It sounds a good idea! :)

    Thank you!

    >
    > Nasty, I agree.
    >
    > Oleg.
    >
    >


    --
    Masami HIRAMATSU
    IT Management Research Dept. Linux Technology Center
    Hitachi, Ltd., Yokohama Research Laboratory
    E-mail: masami.hiramatsu.pt@hitachi.com




    \
     
     \ /
      Last update: 2013-07-05 05:01    [W:5.328 / U:0.376 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site