From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47199C05027 for ; Mon, 6 Feb 2023 18:10:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A33676B0072; Mon, 6 Feb 2023 13:10:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E3C06B0073; Mon, 6 Feb 2023 13:10:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AB086B0074; Mon, 6 Feb 2023 13:10:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7806D6B0072 for ; Mon, 6 Feb 2023 13:10:08 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 43E1040A28 for ; Mon, 6 Feb 2023 18:10:08 +0000 (UTC) X-FDA: 80437656096.21.F949594 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf21.hostedemail.com (Postfix) with ESMTP id 53A291C0002 for ; Mon, 6 Feb 2023 18:10:05 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=LCDwQx6r; dkim=pass header.d=linutronix.de header.s=2020e header.b=v854839J; spf=pass (imf21.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675707005; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pnsD8O7AGv/ghgX6NFYa+KhfEm1cKVXyeecAuGcrGc8=; b=fVssD15pJ8BP+1D+n4VidmVQj0JSVvORr7IbZlm9EfYNAYDl2ZI3/Y2+Dd9tmKK9mJTqXt eUuwlT1v+ILRzyIWBCwMcikSwBoXrQXyI3dNX6lsmzqHo0iKP9zhZHKqANfE8sBctJdhkq 6EORnpxbztq0b8Hf4y0gQ7Zee6o5r1Q= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=LCDwQx6r; dkim=pass header.d=linutronix.de header.s=2020e header.b=v854839J; spf=pass (imf21.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675707005; a=rsa-sha256; cv=none; b=yJIpD8YbvkOEzxLsHgeS9hUDVdZizHutj7ZShMV4Sztn0tieMuiyzUVqXBtmp4xpe/xCSh 2PthYXZy29Ql5a5IPeOzy8Yd34BVEXdWk1NIch54MZvQ/YACV09EGJ2GEW3rFAICeBSFx8 Vm0wiDLck1sjuOzCIV8+CDGUgu3ueJI= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1675707002; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pnsD8O7AGv/ghgX6NFYa+KhfEm1cKVXyeecAuGcrGc8=; b=LCDwQx6rF0S2wMbs06qsNSIV4PMAkOB0SpBJVrqteSNNl07N6FwgDkuRqLWd7BSNEJeFtz jCF4wUQHomXrDBAYxj3i3GkJTPOe6nJ+l4vjkq4O0ukdsXZNyAEeWwJ9I1j7apBrwBE2xa ByS0kIH6UgWjoBkTSQVVF6CrlNjHYEgYdfL2dmsgFDMJKT77W9SN5E6qDVtM3lM9Ps67UO F1oc/bij8jbkXvFzYJpWMdMLUROkOg444nXbwSQl1iuONGjSKUuSCturmYAXwgKyAs8fGL ay8xfQ0jccYiqLArCDrpE/wWtiJPAehxzUN76X6ngkm6cx0vx9Zqtb8Ly5gQtQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1675707002; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pnsD8O7AGv/ghgX6NFYa+KhfEm1cKVXyeecAuGcrGc8=; b=v854839Ja9qHeAUoo9A55MaeyPfSfr0iCQhaDj0DVimhoIEUpf0w9aY3/4tsed5i7CZoVQ XedNHdH6dBvFe2Aw== To: Vlastimil Babka , kernel test robot , Shanker Donthineni Cc: oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, Marc Zyngier , Michael Walle , Sebastian Andrzej Siewior , Hans de Goede , Wolfram Sang , linux-mm@kvack.org, "Liam R. Howlett" , Matthew Wilcox Subject: Re: [PATCH 5/5] genirq: Use the maple tree for IRQ descriptors management In-Reply-To: <9a682773-df56-f36c-f582-e8eeef55d7f8@suse.cz> References: <202302011308.f53123d2-oliver.sang@intel.com> <87o7qdzfay.ffs@tglx> <9a682773-df56-f36c-f582-e8eeef55d7f8@suse.cz> Date: Mon, 06 Feb 2023 19:10:02 +0100 Message-ID: <87lelay8at.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: ufoudwcfs9o6adhd3qgukh7amrr9zy4m X-Rspamd-Queue-Id: 53A291C0002 X-HE-Tag: 1675707005-274069 X-HE-Meta: U2FsdGVkX180ph6yQezNF8Ndk8XOYIM31bW6H70TfPBmNaWGufdkni5GYq5Cr/WT9OnSd6j88CXvJXRGQs83dchTJDWo0/sBlCnDmkvRhvwlz0+GC0B83OKyS7SO6asSOjHPWekd6zltYuOps1negD7UzEIm7LejW8bWizhZriCOj/Fvi5b2fmMgJX1Lj6cOXVaRdM7GhI0H5VH9lEOrf7/T/eBpl8pFBIgPZ5tkcnLCaH+/OHEsG6XGVqDOyIj6qTjAyUjdGiylrhCYRSY6BwMRSebvtFh1Br0BOYB4bNjjpfYPiv25sY/d0b3YjB14Uo/kSJHPNF5ntHnekxGExKea2c55lNYW3tsAQKhbbYltSAp8ueIH8ElJFyYppFURyS4kEGA2BC21ni9CHDet24FZobIdPDfswtwaIASBSidWx2GVdKnj274GaLXbc8aSfoAe9ms/+BAat1qfcNJfYBS9eGHAY6WdE2yIMol2jXH8VIYiKjrAg/y5F0baoATII4Xbqnb6sQbR3JBLhNB+4M0Um/L7kunaZPVv2gJ4cIIutzlw+BtDsCUOgGndqcKaPUu8rtlodwP/Z9S+wp8vUEUtJDR240KhknM2defeSWnT7Zgck1mLr9KnjHnE25YqooZ6XwK8F82VcwBk4YSyjS1t9M7kMpU5tPEKXCohqPjhJ9legBI4gdsgXbr/tzzYsiAoKPvdYZ3Mij6/nZzqqI8cFU1ecLjPpLFj8mmCPlLd5lx1AaU5zhAyw9prhqvnR0rCDCfv3ii2zBenAzeAIr+KWZfrCjyDLIgfxczaFwtgQoJRcaTiE/0HOW7NsQjdlhSQBkph5c9Z/WRqxZFZm/PbQU07YcuWmr4jUBYBZKSykxfh6fX/lKzzOQvI6rC24AmloRpqALk/dCukPg/df0lJRhAaH23gdxkstfQQsT9VinqQ9Kd0bfMcaAmTwf1JYeLWfjR9WKICFLRgVJF IoJwcgCX f3EEtf5U9tq233m1PvuHtW6BR9D5+3XFNMWNWsLO9w/Vh/iVzp9OolVnOsarplTWAxs0YTefOtxxuDYmlC1Nn2K5abiMd031+2/f3f1wD2yYfX0OOkw937bQwxZxnTX2fciB2r5WqS0YQ71o= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 06 2023 at 15:24, Vlastimil Babka wrote: > On 2/1/23 14:27, Thomas Gleixner wrote: >> This triggers because __kmem_cache_alloc_bulk() uses >> lock_irq()/unlock_irq(). Seems nobody used it during early boot stage >> yet. Though the maple tree conversion of the interrupt descriptor >> storage which is the purpose of the patch in question makes that happen. >> >> Fix below. > > Looks like it should work. But I think we also need to adjust SLAB's > mm/slab.c kmem_cache_alloc_bulk() which does local_irq_disable(); / > local_irq_enable(); right? Yup. > Also if we enter this with IRQ's disabled, then we should take care about > the proper gfp flags. Looking at the patch [1] I see > > WARN_ON(mas_store_gfp(&mas, desc, GFP_KERNEL) != 0); > > so GFP_KERNEL would be wrong with irqs disabled, looks like a case for > GFP_ATOMIC. > OTOH I can see the thing it replaces was: > > static RADIX_TREE(irq_desc_tree, GFP_KERNEL); > > so that's also a GFP_KERNEL and we haven't seen debug splats from > might_alloc() checks before in this code?. That's weird, or maybe the > case might_alloc() might_sleep_if() __might_sleep() WARN_ON(task->state != RUNNING); <- Does not trigger __might_resched() if (.... || system_state == SYSTEM_BOOTING || ...) return; As system_state is SYSTEM_BOOTING at this point the splats are not happening. > of "we didn't enable irqs yet on this cpu being bootstrapped" is handled > differently than "we have temporarily disabled irqs"? Sure, during early > boot we should have all the memory and no need to reclaim... The point is that interrupts are fully disabled during early boot and there is no scheduler so there is no scheduling possible. Quite some code in the kernel relies on GFP_KERNEL being functional during that early boot stage. If the kernel runs out of memory that early, then the chance of recovery is exactly 0. Thanks, tglx