Re: [RFC][PATCH 0/4] tracing/kprobes/uprobes: Fix race between openingprobe event files and deleting probe

[Masami Hiramatsu]

(2013/07/04 12:33), Steven Rostedt wrote:
> Currently there exists a race with deleting a kprobe or uprobe and
> a user opening the probe event file or using perf events.
> 
> The problem stems from not being able to take the probe_lock from the
> unregister code because we may have the event_mutex at the time, and
> the event mutex may be taken with the probe_lock held.
> 
> To solve this, the events get a ref count (using the flags field), where
> when an event file is opened, the ftrace_event_call ref count increments.
> Then this is checked under event_mutex and if set, the unregistering
> of the probe will fail.
> 
> Here's a test that shows how things break:
> 
>      # cd /sys/kernel/debug/tracing
>      # echo 'p:sigprocmask sigprocmask' > kprobe_events || exit -1
>      # enable_probe() {
>         sleep 10
>         echo 1
>      }
>      # file=events/kprobes/sigprocmask/enable
>      # enable_probe > $file &
>      > kprobe_events
>     
>     The above will corrupt the kprobe system, as the write to the enable
>     file will happen after the kprobe was deleted.
>     
>     Trying to create the probe again fails:
>     
>      # echo 'p:sigprocmask sigprocmask' > kprobe_events
>      # cat kprobe_events
>     p:kprobes/sigprocmask sigprocmask
>      # ls events/kprobes/
>     enable  filter
> 
> After applying these patches, the "> kprobe_events" fails due to the
> event being busy.
> 
> Masami, please review these patches and give your ack.

Steve, Oleg, could you also take a look on my additional 2 patches too?

I think both this series and my patches are required for
fixing most of the problem. (what we need is a patch to ensure
finishing all running uprobe handlers at disabling it *if needed*)

Thank you,

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/