| 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
| ||
|
Date: Mon, 15 Jun 2015 15:24:29 -0700
From: Alexei Starovoitov <ast@...mgrid.com>
To: paulmck@...ux.vnet.ibm.com,
Daniel Wagner <daniel.wagner@...-carit.de>,
LKML <linux-kernel@...r.kernel.org>
Subject: call_rcu from trace_preempt
Hi Paul,
I've been debugging the issue reported by Daniel:
http://thread.gmane.org/gmane.linux.kernel/1974304/focus=1974304
and it seems I narrowed it down to recursive call_rcu.
From trace_preempt_on() I'm doing:
e = kmalloc(sizeof(struct elem), GFP_ATOMIC)
kfree_rcu(e, rcu)
which causing all sorts of corruptions like:
[ 2.074175] WARNING: CPU: 0 PID: 3 at ../lib/debugobjects.c:263
debug_print_object+0x8c/0xb0()
[ 2.075567] ODEBUG: active_state not available (active state 0)
object type: rcu_head hint: (null)
[ 2.102141] WARNING: CPU: 0 PID: 3 at ../lib/debugobjects.c:263
debug_print_object+0x8c/0xb0()
[ 2.103547] ODEBUG: deactivate not available (active state 0) object
type: rcu_head hint: (null)
[ 2.253995] WARNING: CPU: 0 PID: 7 at ../kernel/rcu/tree.c:2976
__call_rcu.constprop.67+0x1e5/0x350()
[ 2.255510] __call_rcu(): Leaked duplicate callback
Sometimes stack looks like:
[ 2.145163] WARNING: CPU: 0 PID: 102 at ../lib/debugobjects.c:263
debug_print_object+0x8c/0xb0()
[ 2.147465] ODEBUG: active_state not available (active state 0)
object type: rcu_head hint: (null)
[ 2.148022] Modules linked in:
[ 2.148022] CPU: 0 PID: 102 Comm: systemd-udevd Not tainted
4.1.0-rc7+ #653
[ 2.148022] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.7.5-rc1-0-gb1d4dc9-20140515_140003-nilsson.home.kraxel.org
04/01/2014
[ 2.148022] ffffffff81a34f77 ffff88000fc03d18 ffffffff81781ed4
0000000000000105
[ 2.148022] ffff88000fc03d68 ffff88000fc03d58 ffffffff81064e57
0000000000000000
[ 2.148022] ffff88000fc03e20 ffffffff81c50f00 ffffffff81a34fdf
0000000000000286
[ 2.148022] Call Trace:
[ 2.148022] <IRQ> [<ffffffff81781ed4>] dump_stack+0x4f/0x7b
[ 2.148022] [<ffffffff81064e57>] warn_slowpath_common+0x97/0xe0
[ 2.148022] [<ffffffff81064f56>] warn_slowpath_fmt+0x46/0x50
[ 2.148022] [<ffffffff813d305c>] debug_print_object+0x8c/0xb0
[ 2.148022] [<ffffffff813d3cf6>] ? debug_object_active_state+0x66/0x160
[ 2.148022] [<ffffffff813d3d81>] debug_object_active_state+0xf1/0x160
[ 2.148022] [<ffffffff810e33b1>] rcu_process_callbacks+0x301/0xae0
[ 2.148022] [<ffffffff810e3397>] ? rcu_process_callbacks+0x2e7/0xae0
[ 2.148022] [<ffffffff810e9f28>] ? run_timer_softirq+0x218/0x4c0
[ 2.148022] [<ffffffff81069dff>] __do_softirq+0x14f/0x670
[ 2.148022] [<ffffffff8106a5f5>] irq_exit+0xa5/0xb0
[ 2.148022] [<ffffffff8178ea6a>] smp_apic_timer_interrupt+0x4a/0x60
[ 2.148022] [<ffffffff8178cea0>] apic_timer_interrupt+0x70/0x80
[ 2.148022] <EOI> [<ffffffff813d363c>] ?
debug_object_activate+0x9c/0x1e0
[ 2.148022] [<ffffffff8178bd47>] ? _raw_spin_unlock_irqrestore+0x67/0x80
[ 2.148022] [<ffffffff813d36f6>] debug_object_activate+0x156/0x1e0
[ 2.148022] [<ffffffff810de037>] rcuhead_fixup_activate+0x37/0x40
[ 2.148022] [<ffffffff813d36a1>] debug_object_activate+0x101/0x1e0
[ 2.148022] [<ffffffff8178bd2b>] ? _raw_spin_unlock_irqrestore+0x4b/0x80
[ 2.148022] [<ffffffff810e2d26>] __call_rcu.constprop.67+0x46/0x350
[ 2.148022] [<ffffffff813d3524>] ? __debug_object_init+0x3f4/0x430
[ 2.148022] [<ffffffff8178bd2b>] ? _raw_spin_unlock_irqrestore+0x4b/0x80
[ 2.148022] [<ffffffff810e308a>] kfree_call_rcu+0x1a/0x20
[ 2.148022] [<ffffffff8115e230>] trace_preempt_on+0x180/0x290
[ 2.148022] [<ffffffff8115e17e>] ? trace_preempt_on+0xce/0x290
[ 2.148022] [<ffffffff810991c3>] preempt_count_sub+0x73/0xf0
[ 2.148022] [<ffffffff8178bd2b>] _raw_spin_unlock_irqrestore+0x4b/0x80
[ 2.148022] [<ffffffff813d3524>] __debug_object_init+0x3f4/0x430
[ 2.148022] [<ffffffff8115e23c>] ? trace_preempt_on+0x18c/0x290
[ 2.148022] [<ffffffff813d357b>] debug_object_init+0x1b/0x20
[ 2.148022] [<ffffffff810de028>] rcuhead_fixup_activate+0x28/0x40
[ 2.148022] [<ffffffff813d36a1>] debug_object_activate+0x101/0x1e0
[ 2.148022] [<ffffffff812036b0>] ? get_max_files+0x20/0x20
[ 2.148022] [<ffffffff810e2d26>] __call_rcu.constprop.67+0x46/0x350
[ 2.148022] [<ffffffff810e30a7>] call_rcu+0x17/0x20
[ 2.148022] [<ffffffff81203903>] __fput+0x183/0x200
[ 2.148022] [<ffffffff812039ce>] ____fput+0xe/0x10
[ 2.148022] [<ffffffff81088dd5>] task_work_run+0xb5/0xe0
[ 2.148022] [<ffffffff81002c74>] do_notify_resume+0x64/0x80
[ 2.148022] [<ffffffff8178c26c>] int_signal+0x12/0x17
My reading of the code is debug_object_*() bits are reporting real
problem. In the above trace the call
debug_rcu_head_unqueue(list);
from rcu_do_batch() is not finding 'list' in tracked objects.
I know that doing call_rcu() from trace_preempt is ill advised,
but I still want to understand why call_rcu corrupts the memory.
Attaching a patch that I'm using for debugging.
It's doing recursion preemption check, so number of nested call_rcu
is no more than 2.
Also if I replace kfree_rcu is this patch with a regular kfree,
all works fine.
I'm seeing this crashes in VM with _single_ cpu.
Kernel is built with CONFIG_PREEMPT, CONFIG_PREEMPT_TRACER and
CONFIG_DEBUG_OBJECTS_RCU_HEAD.
Also interesting that size of
struct elem {
u64 pad[32];
struct rcu_head rcu;
};
that I'm using in kmalloc/kfree_rcu changes the crash.
If padding is zero, kernel just locksup, if pad[1] I see
one type of odebug warnings, if pad[32] - another.
Any advise on where to look is greatly appreciated.
Thanks!
View attachment "trace.patch" of type "text/plain" (1209 bytes)
Powered by blists - more mailing lists