linux-kernel - Re: PROBLEM: BUG appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug

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

Message-ID: <20141023140644.GI27405@n2100.arm.linux.org.uk>
Date:	Thu, 23 Oct 2014 15:06:44 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Marcin Jabrzyk <m.jabrzyk@...sung.com>
Cc:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	kyungmin.park@...sung.com, linux-samsung-soc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: PROBLEM: BUG  appearing when trying to allocate interrupt on
 Exynos MCT after CPU hotplug

On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
> [1.] One line summary of the problem: "BUG: sleeping function called from
> invalid context at mm/slub.c:1250" after CPU hotplug

I'm really not surprised.

> 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.

The CPU notifier is called via notify_cpu_starting(), which is called
with interrupts disabled, and a reason code of CPU_STARTING.  Interrupts
at this point /must/ remain disabled.

The Exynos code then goes on to call exynos4_local_timer_setup() which
tries to reverse the free_irq() in exynos4_local_timer_stop() by calling
request_irq().  Calling request_irq() with interrupts off has never been
permissible.

So, this code is wrong today, and it was also wrong when it was written.
It /couldn't/ have been tested.  It looks like this commit added this
buggy code:

commit ee98d27df6827b5ba4bd99cb7d5cb1239b6a1a31
Author: Stephen Boyd <sboyd@...eaurora.org>
Date:   Fri Feb 15 16:40:51 2013 -0800

    ARM: EXYNOS4: Divorce mct from local timer API

    Separate the mct local timers from the local timer API. This will
    allow us to remove ARM local timer support in the near future and
    gets us closer to moving this driver to drivers/clocksource.

    Acked-by: Kukjin Kim <kgene.kim@...sung.com>
    Acked-by: Marc Zyngier <marc.zyngier@....com>
    Cc: Thomas Abraham <thomas.abraham@...aro.org>
    Signed-off-by: Stephen Boyd <sboyd@...eaurora.org>

A good question would be: why doesn't this happen at boot time when CPU1
is first brought up?  The conditions here are no different from hotplugging
CPU1 back in.  Do you see a similar warning on boot too?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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/