linux-kernel - Re: A question of sleeping with interrupts are disabled in start

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

Message-ID: <alpine.DEB.2.21.1804061223240.1982@nanos.tec.linutronix.de>
Date:   Fri, 6 Apr 2018 12:27:39 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
cc:     akpm@...ux-foundation.org, mingo@...nel.org, keescook@...omium.org,
        lauraa@...eaurora.org, viresh.kumar@...aro.org,
        nicolas.pitre@...aro.org, thomas.lendacky@....com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: A question of sleeping with interrupts are disabled in
 start_kernel()

On Fri, 6 Apr 2018, Jia-Ju Bai wrote:

> Hello,
> 
> I have a question of the call path init/main.c:
> init/main.c: start_kernel() ->
> kernel/events/core.c: perf_pmu_register() ->
> kernel/events/core.c: perf_event_init() ->
> kernel/events/core.c: pmu_dev_alloc()
> 
> In this call path, start_kernel() calls local_irq_disable() to disable the
> interrupt;
> perf_pmu_register() calls mutex_lock() and idr_alloc(GFP_KERNEL), and they can
> sleep;
> pmu_dev_alloc() calls kzalloc(GFP_KERNEL), and it can sleep.
> 
> In my opinion, this code may sleep with interrupts are disabled.
> I wonder why this code is okay?

Because this is the very early boot up stage where contention of the mutex
cannot happen and the allocations are all implicitely converted to atomic
allocations. If the mutex would be contended then the system would fail to
boot anyway. If the allocations fail at that stage, it's unlikely that the
machine will come up at all.

So yes, it looks odd, but we don't want to have duplicated code pathes just
for the early boot up and the debugging mechanisms are aware of that
situation and don't emit warnings. Once the scheduler is functional and the
early boot stage is done, these 'magic' violations are not longer allowed.

Hope that helps.

Thanks,

	tglx