linux-kernel - [mm/vmalloc] BUG: sleeping function called from invalid context at mm/vmalloc.c:74

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]

Date:	Wed, 19 Mar 2014 19:55:40 +0800
From:	Fengguang Wu <fengguang.wu@...el.com>
To:	David Vrabel <david.vrabel@...rix.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, lkp@...org,
	Linux Memory Management List <linux-mm@...ck.org>
Subject: [mm/vmalloc] BUG: sleeping function called from invalid context at
 mm/vmalloc.c:74

Hi David,

FYI, we noticed the below BUG on

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 032dda8b6c4021d4be63bcc483b47fd26c6f48a2 ("mm/vmalloc: avoid soft lockup warnings when vunmap()'ing large ranges")

[  229.097122] BUG: sleeping function called from invalid context at mm/vmalloc.c:74                            
[  229.109704] in_atomic(): 1, irqs_disabled(): 0, pid: 13598, name: poll2_threads  
[  229.119755] CPU: 17 PID: 13598 Comm: poll2_threads Not tainted 3.14.0-rc6-next-20140317 #1
[  229.130914] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BKLDSDP1.86B.0031.R01.1304221600 04/22/2013
[  229.144432]  0000000000000000 ffff881840111d80 ffffffff81a3ae8a ffffc9001cf38000                                  
[  229.155417]  ffff881840111d90 ffffffff81101256 ffff881840111e08 ffffffff811b1540
[  229.166340]  ffffc9001cf48fff ffffc9001cf48fff 0000000000000000 ffff881840111dd0
[  229.177355] Call Trace:
[  229.181129]  [<ffffffff81a3ae8a>] dump_stack+0x4d/0x66
[  229.188012]  [<ffffffff81101256>] __might_sleep+0x10a/0x10c
[  229.195320]  [<ffffffff811b1540>] vunmap_page_range+0x143/0x2b2
[  229.203046]  [<ffffffff811b2174>] ? map_vm_area+0x2e/0x40
[  229.210184]  [<ffffffff811b2c95>] remove_vm_area+0x58/0x75
[  229.217361]  [<ffffffff811b2ced>] __vunmap+0x3b/0xaf
[  229.223979]  [<ffffffff811b2df5>] vfree+0x67/0x6a
[  229.230316]  [<ffffffff811f4868>] free_fdmem+0x2a/0x33
[  229.237140]  [<ffffffff811f4949>] __free_fdtable+0x16/0x2a
[  229.244313]  [<ffffffff811f4c1e>] expand_files+0x121/0x143
[  229.251516]  [<ffffffff811f5075>] __alloc_fd+0x5e/0xef
[  229.258363]  [<ffffffff811f5136>] get_unused_fd_flags+0x30/0x32
[  229.266038]  [<ffffffff811dcf02>] do_sys_open+0x12e/0x1d6
[  229.273127]  [<ffffffff811dcfc8>] SyS_open+0x1e/0x20
[  229.279718]  [<ffffffff81a49de9>] system_call_fastpath+0x16/0x1b

Thanks,
Fengguang

View attachment ".dmesg" of type "text/plain" (234894 bytes)