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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Nov 2011 17:50:37 +0000
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	paulmck@...ux.vnet.ibm.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 7, 2011 at 5:26 PM, Peter Zijlstra <peterz@...radead.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.
--
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/