Messages in this thread | | | Date | Mon, 7 Nov 2011 17:50:37 +0000 | Subject | Re: [GIT PULL rcu/next] RCU commits for 3.1 | From | Stephane Eranian <> |
| |
On Mon, Nov 7, 2011 at 5:26 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Mon, 2011-11-07 at 17:12 +0000, Stephane Eranian wrote: >> I think on that path: >> >> >>> [<8108aa02>] perf_event_enable_on_exec+0x1d2/0x1e0 >> >>> [<81063764>] ? __lock_release+0x54/0xb0 >> >>> [<8108cca8>] perf_event_comm+0x18/0x60 >> >>> [<810d1abd>] ? set_task_comm+0x5d/0x80 >> >>> [<81af622d>] ? _raw_spin_unlock+0x1d/0x40 >> >>> [<810d1ac4>] set_task_comm+0x64/0x80 >> >> We are neither holding the rcu_read_lock() nor the task_lock() but we >> are operating on the current task. The task cannot just vanish. So >> the rcu_dereference() and lock_is_held() macros may detect a false >> positive in that case. Yet, I doubt this would be the only place.... > > Well, normally being current doesn't guarantee your cgroup won't > disappear. The perf stuff hwoever takes refs and is synced against > ->attach() by virtue of it calling perf_cgroup_switch() etc.. > perf_event_enable_on_exec() perf_cgroup_sched_out(current, NULL); perf_cgroup_from_task(current) task_subsys_state(current, perf_subsys_id)
That is the sequence triggering the warning. Obviously, we come here without task_lock() nor rcu_read_lock().
The cgroup cannot disappear because it is refcounted by perf_events. The task cannot disappear because it's the current task.
So I think we need to simply quiesce the warning, most likely like what Peter just suggested.
| |