Re: BUG: sleeping function called from atomic due to "Balance initial LPI affinity across CPUs"

From: Marc Zyngier <maz@kernel.org>
To: John Garry <john.garry@huawei.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Qian Cai <cai@lca.pw>, Thomas Gleixner <tglx@linutronix.de>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: BUG: sleeping function called from atomic due to "Balance initial LPI affinity across CPUs"
Date: Wed, 20 May 2020 10:51:14 +0100	[thread overview]
Message-ID: <e07d73938a7534c6c2cd0517de378fcd@kernel.org> (raw)
In-Reply-To: <81796a6e-718a-aa93-d183-6747e0654c8c@huawei.com>

Hi John,

On 2020-05-20 09:43, John Garry wrote:
> On 19/05/2020 23:09, Qian Cai wrote:
>> Reverted the linux-next commit f068a62c548c ("irqchip/gic-v3-its:
>> Balance initial LPI affinity across CPUs") fixed these warnings during
>> boot,
> 
> Thanks for the notice. So we need the following set to see this:
> CONFIG_CPUMASK_OFFSTACK=y
> CONFIG_DEBUG_ATOMIC_SLEEP=y
> CONFIG_DEBUG_PER_CPU_MAPS=y

Ah, thanks for pointing this out.

>> its_select_cpu at drivers/irqchip/irq-gic-v3-its.c:1572
>> 
>> [  332.819381][ T3359] BUG: sleeping function called from invalid
>> context at mm/slab.h:568
>> [  332.827405][ T3359] in_atomic(): 1, irqs_disabled(): 128,
>> non_block: 0, pid: 3359, name: irqbalance
>> [  332.836455][ T3359] INFO: lockdep is turned off.
>> [  332.841076][ T3359] irq event stamp: 0
>> [  332.844836][ T3359] hardirqs last  enabled at (0): 
>> [<0000000000000000>] 0x0
>> [  332.851828][ T3359] hardirqs last disabled at (0):
>> [<ffff9000101ea65c>] copy_process+0x98c/0x1f34
>> [  332.860710][ T3359] softirqs last  enabled at (0):
>> [<ffff9000101ea690>] copy_process+0x9c0/0x1f34
>> [  332.869586][ T3359] softirqs last disabled at (0): 
>> [<0000000000000000>] 0x0
>> [  332.876560][ T3359] CPU: 155 PID: 3359 Comm: irqbalance Tainted: G
>>        W    L    5.7.0-rc6-next-20200519 #1
>> [  332.886563][ T3359] Hardware name: HPE Apollo 70
>> /C01_APACHE_MB         , BIOS L50_5.13_1.11 06/18/2019
>> [  332.897000][ T3359] Call trace:
>> [  332.900151][ T3359]  dump_backtrace+0x0/0x22c
>> [  332.904514][ T3359]  show_stack+0x28/0x34
>> [  332.908543][ T3359]  dump_stack+0x104/0x194
>> [  332.912738][ T3359]  ___might_sleep+0x314/0x328
>> [  332.917274][ T3359]  __might_sleep+0x7c/0xe0
>> [  332.921563][ T3359]  slab_pre_alloc_hook+0x44/0x8c
>> [  332.926360][ T3359]  __kmalloc_node+0xb0/0x618
>> [  332.930811][ T3359]  alloc_cpumask_var_node+0x48/0x94
> 
> We could use GFP_ATOMIC flag at the callsite here, but maybe there is
> a better solution.

I don't see one, and I doubt it is worth the hassle to have anything
but GFP_ATOMIC. The default arm64 config is to have on-stack cpumasks,
and only DEBUG_PER_CPU_MAPS allows this to be changed.

I'll stash a patch on top.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel