linux-kernel - Weird rcu lockdep warning

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-next>] [day] [month] [year] [list]

Message-ID: <20100413200432.GB5099@nowhere>
Date:	Tue, 13 Apr 2010 22:04:36 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	David Miller <davem@...emloft.net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>
Cc:	SparcLinux <sparclinux@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Weird rcu lockdep warning

Hi,

I just ran the following on -rc4 with the latest pending sparc pull
request manually merged (no -tip bits):

	perf record -a -f -g sleep 5

And I got this warning:


[ 2235.846071] ===================================================
[ 2235.857419] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 2235.863127] ---------------------------------------------------
[ 2235.868734] kernel/perf_event.c:2232 invoked rcu_dereference_check() without protection!
[ 2235.879843] 
[ 2235.879848] other info that might help us debug this:
[ 2235.879855] 
[ 2235.895659] 
[ 2235.895663] rcu_scheduler_active = 1, debug_locks = 0
[ 2235.905505] 1 lock held by swapper/0:
[ 2235.910333]  #0:  (&ctx->lock){-.....}, at: [<00000000004d9e00>] __perf_event_enable+0x60/0x1e8
[ 2235.920430] 
[ 2235.920434] stack backtrace:
[ 2235.929691] Call Trace:
[ 2235.934143]  [000000000049fca0] lockdep_rcu_dereference+0x88/0x98
[ 2235.938700]  [00000000004d9304] perf_event_update_userpage+0x74/0x16c
[ 2235.943221]  [000000000044c148] sparc_perf_event_set_period+0xb4/0xc4
[ 2235.947593]  [000000000044c238] perf_event_nmi_handler+0xe0/0x190
[ 2235.951801]  [0000000000494924] notifier_call_chain+0x2c/0x84
[ 2235.956112]  [0000000000495008] __atomic_notifier_call_chain+0x54/0x9c
[ 2235.960493]  [0000000000495070] atomic_notifier_call_chain+0x20/0x34
[ 2235.964830]  [00000000004950a8] notify_die+0x24/0x38
[ 2235.969175]  [000000000043a650] perfctr_irq+0xa4/0x3f4
[ 2235.973493]  [00000000004209f4] tl0_irq15+0x14/0x20
[ 2235.977744]  [0000000000406920] sun4v_niagara2_setperf+0x8/0x28
[ 2235.982265]  [000000000044c448] hw_perf_enable+0x160/0x170
[ 2235.986494]  [00000000004d89b4] perf_enable+0x3c/0x4c
[ 2235.990513]  [00000000004d9f2c] __perf_event_enable+0x18c/0x1e8
[ 2235.994665]  [00000000004aad5c] generic_smp_call_function_single_interrupt+0x114/0x16c
[ 2236.002975]  [0000000000764770] smp_call_function_single_client+0x20/0x30


This is weird as everything looks fine there, it seems we have
a well matching rcu_read_lock/rcu_dereference couple:

void perf_event_update_userpage(struct perf_event *event)
{
	struct perf_event_mmap_page *userpg;
	struct perf_mmap_data *data;

	rcu_read_lock();
	data = rcu_dereference(event->data);
	if (!data)
		goto unlock;

	userpg = data->user_page;
	[...]


I've attached the config in case someone has an idea.

Thanks.

View attachment "sparc.config" of type "text/plain" (38027 bytes)