Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751239AbdHRKPR (ORCPT ); Fri, 18 Aug 2017 06:15:17 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:60828 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750877AbdHRKPQ (ORCPT ); Fri, 18 Aug 2017 06:15:16 -0400 Subject: Re: [PATCH] xen/events: events_fifo: Don't use {get,put}_cpu() in xen_evtchn_fifo_init() To: Boris Ostrovsky , xen-devel@lists.xen.org References: <20170817161453.19318-1-julien.grall@arm.com> <651ecfe9-fafa-de8c-3d1c-345b136aa366@oracle.com> Cc: jgross@suse.com, linux-kernel@vger.kernel.org From: Julien Grall Message-ID: <1f568982-1518-2f7b-64dc-cd94c1943c1d@arm.com> Date: Fri, 18 Aug 2017 11:15:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <651ecfe9-fafa-de8c-3d1c-345b136aa366@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3079 Lines: 65 Hi Boris, On 17/08/17 18:36, Boris Ostrovsky wrote: > On 08/17/2017 12:14 PM, Julien Grall wrote: >> When booting Linux as Xen guest with CONFIG_DEBUG_ATOMIC, the following >> splat appears: >> >> [ 0.002323] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes) >> [ 0.019717] ASID allocator initialised with 65536 entries >> [ 0.020019] xen:grant_table: Grant tables using version 1 layout >> [ 0.020051] Grant table initialized >> [ 0.020069] BUG: sleeping function called from invalid context at /data/src/linux/mm/page_alloc.c:4046 >> [ 0.020100] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0 >> [ 0.020123] no locks held by swapper/0/1. >> [ 0.020143] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc5 #598 >> [ 0.020166] Hardware name: FVP Base (DT) >> [ 0.020182] Call trace: >> [ 0.020199] [] dump_backtrace+0x0/0x270 >> [ 0.020222] [] show_stack+0x24/0x30 >> [ 0.020244] [] dump_stack+0xb8/0xf0 >> [ 0.020267] [] ___might_sleep+0x1c8/0x1f8 >> [ 0.020291] [] __might_sleep+0x58/0x90 >> [ 0.020313] [] __alloc_pages_nodemask+0x1c0/0x12e8 >> [ 0.020338] [] alloc_page_interleave+0x38/0x88 >> [ 0.020363] [] alloc_pages_current+0xdc/0xf0 >> [ 0.020387] [] __get_free_pages+0x28/0x50 >> [ 0.020411] [] evtchn_fifo_alloc_control_block+0x2c/0xa0 >> [ 0.020437] [] xen_evtchn_fifo_init+0x38/0xb4 >> [ 0.020461] [] xen_init_IRQ+0x44/0xc8 >> [ 0.020484] [] xen_guest_init+0x250/0x300 >> [ 0.020507] [] do_one_initcall+0x44/0x130 >> [ 0.020531] [] kernel_init_freeable+0x120/0x288 >> [ 0.020556] [] kernel_init+0x18/0x110 >> [ 0.020578] [] ret_from_fork+0x10/0x40 >> [ 0.020606] xen:events: Using FIFO-based ABI >> [ 0.020658] Xen: initializing cpu0 >> [ 0.027727] Hierarchical SRCU implementation. >> [ 0.036235] EFI services will not be available. >> [ 0.043810] smp: Bringing up secondary CPUs ... >> >> This is because get_cpu() in xen_evtchn_fifo_init() will disable >> preemption, but __get_free_page() might sleep (GFP_ATOMIC is not set). >> >> xen_evtchn_fifo_init() will always be called before SMP is initialized, >> so {get,put}_cpu() could be replaced by a simple smp_processor_id(). > > On x86 this will be called out of init_IRQ(), which is already preceded > by preempt_disable(). Well the main problem is preempt_disable() itself. in_atomic() will check preempt_count and return 1 if it is non-zero. __get_free_page might sleep if GFP_ATOMIC is not set and therefore you will see the splat when CONFIG_DEBUG_ATOMIC is enabled. However, those checks don't happen before the scheduler is setup. Hence why you don't see the error on x86. Cheers, > > Reviewed-by: Boris Ostrovsky > -- Julien Grall