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  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:	Thu, 23 Oct 2014 15:51:16 +0200
From:	Marcin Jabrzyk <m.jabrzyk@...sung.com>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Thomas Gleixner <tglx@...utronix.de>
Cc:	linux-kernel@...r.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	kyungmin.park@...sung.com, linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org
Subject: PROBLEM: BUG  appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug

[1.] One line summary of the problem: "BUG: sleeping function called 
from invalid context at mm/slub.c:1250" after CPU hotplug
[2.] Full description of the problem/report:

This was tested on Exynos 3250 board with 
https://lkml.org/lkml/2014/9/24/441 applied. Board is booting to 
/bin/sh. After executing:

mount -t sysfs sys /sys && echo 0 > /sys/devices/system/cpu/cpu1/online 
&& echo 1 > /sys/devices/system/cpu/cpu1/online

I'm getting:

[    7.226405] IRQ258 no longer affine to CPU1
[    7.226629] CPU1: shutdown
[    7.230037] CPU1: Software reset
[    7.231822] CPU1: Booted secondary processor
[    7.231843] BUG: sleeping function called from invalid context at 
mm/slub.c:1250
[    7.231850] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[    7.231861] Preemption disabled at:[<  (null)>]   (null)
[    7.231864]
[    7.231876] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.17.0-dirty #45
[    7.231914] [<c0013c04>] (unwind_backtrace) from [<c0010eac>] 
(show_stack+0x10/0x14)
[    7.231931] [<c0010eac>] (show_stack) from [<c03ffd0c>] 
(dump_stack+0x70/0xbc)
[    7.231950] [<c03ffd0c>] (dump_stack) from [<c00b9a20>] 
(kmem_cache_alloc+0xe8/0x184)
[    7.231968] [<c00b9a20>] (kmem_cache_alloc) from [<c0059710>] 
(request_threaded_irq+0x64/0x128)
[    7.231985] [<c0059710>] (request_threaded_irq) from [<c030ecc8>] 
(exynos4_local_timer_setup+0xc0/0x13c)
[    7.232000] [<c030ecc8>] (exynos4_local_timer_setup) from 
[<c030ede4>] (exynos4_mct_cpu_notify+0x30/0xa8)
[    7.232016] [<c030ede4>] (exynos4_mct_cpu_notify) from [<c0038540>] 
(notifier_call_chain+0x44/0x84)
[    7.232034] [<c0038540>] (notifier_call_chain) from [<c0021144>] 
(__cpu_notify+0x28/0x44)
[    7.232049] [<c0021144>] (__cpu_notify) from [<c0012af0>] 
(secondary_start_kernel+0xe8/0x138)
[    7.232062] [<c0012af0>] (secondary_start_kernel) from [<400086a4>] 
(0x400086a4)

The problem is that request_irq is calling allocation with GFP_KERNEL 
flag in atomic block.
This bug should be easy observable on any board with 
"samsung,exynos4210-mct" compatible MCT block.

[4.1.] Kernel version (from /proc/version):
3.17.0
[4.2.] Kernel .config file:
exynos_defconfig + DEBUG_ATOMIC_SLEEP and DEBUG_PREEMPT

[7.] A small shell script or example program which triggers the
      problem (if possible)
mount -t sysfs sys /sys && echo 0 > /sys/devices/system/cpu/cpu1/online 
&& echo 1 > /sys/devices/system/cpu/cpu1/online
[8.] Environment
/bin/sh

When SoC have MCT_INT_SPI interrupt it is being allocated after 
hotplugging of the CPU, secondary_start_kernel() is sending CPU boot 
notifications which are send when preemption and interrupts are 
disabled. Exynos_mct notification handler tries to set up and allocate 
IRQ for SPI type interrupt for started CPU and then BUG appears.
There might be similar problem on qcom-timer I think just after looking 
on the code.

Best regards,
--
Marcin Jabrzyk
Samsung R&D Institute Poland
Samsung Electronics
--
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/

Powered by blists - more mailing lists