Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1257499

Re: [PATCH v2] perf/core: fix RCU issues with cgroup monitoring mode

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH v2] perf/core: fix RCU issues with cgroup monitoring mode
Date 2015-10-28 01:20 +0100
Message-ID <qomD9-3DG-29@gated-at.bofh.it> (permalink)
References <qoi6v-J0-39@gated-at.bofh.it> <qoj2y-1i5-27@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Oct 27, 2015 at 01:24:05PM -0700, Eric Dumazet wrote:
> On Tue, 2015-10-27 at 20:25 +0100, Stephane Eranian wrote:
> > This patch eliminates all known RCU violations detected
> > by the RCU  checker (PROVE_RCU). The impact code paths
> > were all related to cgroup mode monitoring and involved
> > access a task's cgrp.
> > 
> > V2 is updated to include suggestions from PeterZ to eliminate
> > some of the warnings without grabbing the rcu_read lock because
> > we know we are already holding the ctx->lock which prevents
> > the cgroup from disappearing while we are accessing it.
> > The trick, as suggested by Peter, is to modify the
> > perf_cgroup_from_task() to take an extra boolean parameter
> > to allow bypassing the lockdep test in the task_subsys_cstate()
> > macros. This patch uses this approach to update all calls the
> > perf_cgroup_from_task().
> > V2 Patch relative to:
> > 8b3c8e6 Revert "rculist: Make list_entry_rcu() use lockless_dereference()"
> > 
> > Signed-off-by: Stephane Eranian <eranian@google.com>
> > ---
> 
> 
> Instead trusting caller to provide correct 'safe' boolean,
> what about using lockdep_is_held() ?
> 
> This way, you keep full lockep support.

Because its really really hard to get from a random task to the right
lock in this case :/

The connection is something like:

	task <-> cgroup <-> event <-> ctx <-> lock

So for any given task, we need to find its cgroup (easy, but this
already requires knowing the lock), we need to find all events for that
cgroup and locate the one that is for the cpu the task runs on. Then we
need to find its context and see it the lock is taken.

So aside from if being rather hard, there's also the chicken-egg
problem.

Now I suppose we can pass the right ctx in, and when !NULL use
lock_is_held() on it. But we'd need to validate that the ctx passed
matches the cgroup, and that's not entirely trivial either.

A well :/

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

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[PATCH v2] perf/core: fix RCU issues with cgroup monitoring mode Stephane Eranian <eranian@google.com> - 2015-10-27 20:30 +0100
  Re: [PATCH v2] perf/core: fix RCU issues with cgroup monitoring mode Eric Dumazet <eric.dumazet@gmail.com> - 2015-10-27 21:30 +0100
    Re: [PATCH v2] perf/core: fix RCU issues with cgroup monitoring mode Stephane Eranian <eranian@google.com> - 2015-10-28 00:50 +0100
      Re: [PATCH v2] perf/core: fix RCU issues with cgroup monitoring mode Eric Dumazet <eric.dumazet@gmail.com> - 2015-10-28 01:20 +0100
        Re: [PATCH v2] perf/core: fix RCU issues with cgroup monitoring mode Stephane Eranian <eranian@google.com> - 2015-10-28 01:30 +0100
    Re: [PATCH v2] perf/core: fix RCU issues with cgroup monitoring mode Peter Zijlstra <peterz@infradead.org> - 2015-10-28 01:20 +0100

csiph-web