Re: [GIT PULL rcu/next] RCU commits for 3.1

[Peter Zijlstra]

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..
--
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/