Messages in this thread | | | Date | Mon, 17 Jun 2013 22:09:38 +0200 | From | Pablo Neira Ayuso <> | Subject | Re: [netlink] WARNING: at mm/vmalloc.c:1487 __vunmap() |
| |
On Sat, Jun 15, 2013 at 06:01:19AM +0800, Fengguang Wu wrote: > netlink: allow large data transfers from user-space [...] > [ 65.085802] init: plymouth-upstart-bridge main process (345) terminated with status 1 > [ 65.138243] ------------[ cut here ]------------ > [ 65.140281] WARNING: at /c/kernel-tests/src/tip/mm/vmalloc.c:1487 __vunmap+0x10b/0x110() > [ 65.143247] Trying to vfree() nonexistent vm area (ffffc90000810000) > [ 65.145697] CPU: 0 PID: 145 Comm: trinity Not tainted 3.10.0-rc5-00652-ge8a36a6 #9 > [ 65.148822] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 > [ 65.151073] 0000000000000009 ffff88000f3b7bc8 ffffffff81d3e5b3 ffff88000f3b7c08 > [ 65.154718] ffffffff810cf7a6 ffff88000f3b7c28 ffffc90000810000 0000000000000000 > [ 65.158343] 0000000000000001 ffff88000dc36620 ffff8800091c87b0 ffff88000f3b7c68 > [ 65.161574] Call Trace: > [ 65.162609] [<ffffffff81d3e5b3>] dump_stack+0x19/0x1b > [ 65.164349] [<ffffffff810cf7a6>] warn_slowpath_common+0x66/0x90 > [ 65.166294] [<ffffffff810cf841>] warn_slowpath_fmt+0x41/0x50 > [ 65.168286] [<ffffffff81166f7b>] __vunmap+0x10b/0x110 > [ 65.170351] [<ffffffff81166e2f>] vfree+0x2f/0x70 > [ 65.172272] [<ffffffff81afd478>] netlink_skb_destructor+0xb8/0x100 > [ 65.174645] [<ffffffff81aac8a1>] skb_release_head_state+0x51/0xb0 > [ 65.177009] [<ffffffff81aadb61>] skb_release_all+0x11/0x30 > [ 65.179175] [<ffffffff81aadb91>] __kfree_skb+0x11/0x90 > [ 65.181293] [<ffffffff81aad9d9>] kfree_skb+0x19/0x40 > [ 65.183308] [<ffffffff81ab00a8>] skb_queue_purge+0x18/0x30 > [ 65.185482] [<ffffffff81afd858>] netlink_sock_destruct+0x38/0x110 > [ 65.187873] [<ffffffff81aa8c3a>] __sk_free+0x1a/0x120 > [ 65.189911] [<ffffffff81aa9989>] sk_free+0x19/0x20 > [ 65.191875] [<ffffffff81afec77>] netlink_release+0x177/0x2d0 > [ 65.194086] [<ffffffff81aa6208>] sock_release+0x18/0x70 > [ 65.196172] [<ffffffff81aa645d>] sock_close+0xd/0x20 > [ 65.198190] [<ffffffff8118ae55>] __fput+0xf5/0x240 > [ 65.200189] [<ffffffff8118b069>] ____fput+0x9/0x10 > [ 65.202139] [<ffffffff810eb955>] task_work_run+0x85/0xc0 > [ 65.204257] [<ffffffff810d4942>] do_exit+0x232/0x920 > [ 65.206262] [<ffffffff810d50ab>] do_group_exit+0x3b/0x90 > [ 65.208353] [<ffffffff810d5112>] SyS_exit_group+0x12/0x20 > [ 65.210517] [<ffffffff81d46827>] system_call_fastpath+0x16/0x1b > [ 65.212811] ---[ end trace 9a70fd0f1776886b ]---
I've been trying to trigger this bug here with no success using different communication configurations (userspace <-> userspace, userspace <-> kernelspace).
The address that vfree shows seems good to me and we always set skb->head to NULL after releasing the network buffer.
This patch also exposes the vmalloc infrastructure to user-space, which is something that didn't happen so far. Not sure if Trinity is uncovering a bug there.
| |