Please sign in to comment.
perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race
Di Shen reported a race between two concurrent sys_perf_event_open() calls where both try and move the same pre-existing software group into a hardware context. The problem is exactly that described in commit: f63a8da ("perf: Fix event->ctx locking") ... where, while we wait for a ctx->mutex acquisition, the event->ctx relation can have changed under us. That very same commit failed to recognise sys_perf_event_context() as an external access vector to the events and thereby didn't apply the established locking rules correctly. So while one sys_perf_event_open() call is stuck waiting on mutex_lock_double(), the other (which owns said locks) moves the group about. So by the time the former sys_perf_event_open() acquires the locks, the context we've acquired is stale (and possibly dead). Apply the established locking rules as per perf_event_ctx_lock_nested() to the mutex_lock_double() for the 'move_group' case. This obviously means we need to validate state after we acquire the locks. Reported-by: Di Shen (Keen Lab) Tested-by: John Dias <firstname.lastname@example.org> Signed-off-by: Peter Zijlstra (Intel) <email@example.com> Cc: Alexander Shishkin <firstname.lastname@example.org> Cc: Arnaldo Carvalho de Melo <email@example.com> Cc: Arnaldo Carvalho de Melo <firstname.lastname@example.org> Cc: Jiri Olsa <email@example.com> Cc: Kees Cook <firstname.lastname@example.org> Cc: Linus Torvalds <email@example.com> Cc: Min Chong <firstname.lastname@example.org> Cc: Peter Zijlstra <email@example.com> Cc: Stephane Eranian <firstname.lastname@example.org> Cc: Thomas Gleixner <email@example.com> Cc: Vince Weaver <firstname.lastname@example.org> Fixes: f63a8da ("perf: Fix event->ctx locking") Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar <email@example.com>
- Loading branch information...