[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111107175332.GJ2332@linux.vnet.ibm.com>
Date: Mon, 7 Nov 2011 09:53:32 -0800
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Stephane Eranian <eranian@...gle.com>,
Li Zefan <lizf@...fujitsu.com>, Ingo Molnar <mingo@...e.hu>,
eric.dumazet@...il.com, shaohua.li@...el.com, ak@...ux.intel.com,
mhocko@...e.cz, alex.shi@...el.com, efault@....de,
linux-kernel@...r.kernel.org, Paul Turner <pjt@...gle.com>
Subject: Re: [GIT PULL rcu/next] RCU commits for 3.1
On Mon, Nov 07, 2011 at 06:26:17PM +0100, Peter Zijlstra 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..
OK, never mind my task==current suggestion. :-/
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists