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 16A20E77197 for ; Thu, 2 Jan 2025 23:08:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E6F76B008A; Thu, 2 Jan 2025 18:08:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 997126B008C; Thu, 2 Jan 2025 18:08:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85EFC6B0092; Thu, 2 Jan 2025 18:08:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6541E6B008A for ; Thu, 2 Jan 2025 18:08:39 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E33711404A2 for ; Thu, 2 Jan 2025 23:08:38 +0000 (UTC) X-FDA: 82964051184.07.CEC9A21 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf17.hostedemail.com (Postfix) with ESMTP id 7B8534000A for ; Thu, 2 Jan 2025 23:07:58 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=gqYYJxvw; dmarc=none; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735859269; a=rsa-sha256; cv=none; b=TdYzEOWmW6UL9yEaxdJeM3IMZvsNfAbdGTCU2chC6LIfGck3gl9PEC6aqFUmVonppcwYnE LcDv3hhBJ1sCCOKD9lHDusE+AVu5yFe5q9nh5KT5yQHMe7N3SzJs66UUrxP8n3D0JI6lFc pOFoW/h+cQ5MmpR1Mjlp9DkOWVvdU+A= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=gqYYJxvw; dmarc=none; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735859269; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+keTjRN62BY0kSnK6EzL6+2HUkDJjLro3ptQ557clYA=; b=jemOdPL0A+sUhbVnoCxgpcqZ2gQ/sVjxlqzJ9XYj1OfV2YLrV0ti/41VgZrFaC5mcdjKnu rr8bIDqDCyHDiqSUNpzoQjd+B57zEyvPAOBg4BJT+EpsKSLL4yMYymgXmuuelhI7i4ehhk 5za1k6E9E+s1e8OuBgJPR1MIt5FoXWU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 5C083A4157B; Thu, 2 Jan 2025 23:06:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17CC9C4CED0; Thu, 2 Jan 2025 23:08:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1735859316; bh=7nH6vOGTXDlpSYPXJ2kxTSIlqCHxEXPnXNEBrCBgTY4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gqYYJxvwI0CWeFqOcnP1KT/SeLxHIEIn9xGpehv642scgHmwkG+tClyL6tbTEaxyz sDAUiO770oiuhhc1+rCROQd4pyGfCeGjBJ+Ig1D+F5Lp6CbFaGFUV2Uo36uujgSZNy tkP3bego/LVRIaEieeHvIE7J1xIVT6PccdOnCe9k= Date: Thu, 2 Jan 2025 15:08:35 -0800 From: Andrew Morton To: Guo Weikang Cc: Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8] mm/memblock: Add memblock_alloc_or_panic interface Message-Id: <20250102150835.776fe72f565cc3232d83e6a7@linux-foundation.org> In-Reply-To: <20250102072528.650926-1-guoweikang.kernel@gmail.com> References: <20250102072528.650926-1-guoweikang.kernel@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7B8534000A X-Stat-Signature: y13rdfgq53cnmn161dw6kf59w755gud3 X-Rspam-User: X-HE-Tag: 1735859278-93446 X-HE-Meta: U2FsdGVkX1/29sXnMi8UP1TY43RA1oWwy1yZlv8zhiDDZiaoNQIltikLMnf5HY7/YRkwLOpOJYuUkrldA2mcyVMfgGuEN9Z6nNv0Do/J/RzOJmPur2kbYEU32LwN6mc0rFG6XobwHScypm1qFcVhBuiqnWAXvuFxHMECwykhJ9uGBBsAlVWE8WHd60NN38HZCwTcnaCPOJ6YOnPOeXCms5JvulRhgczUAdz3NVOVzeJiselHSh2wIj4ByBFwllsfGvSbbHs0++ZehIzrnoNFi4P3QX0GwWHLc7qO6aLO+hbyjkyPo3U5Qa5la2rDfbaXQILTxrvZfVyY51VeZMAMC+pVnPTNkEr2eZhhXezkIySaZY2xyDx5ugJx7ZrPV5J1ZWS/NQGndjCMk+fQ+Ybn1XnbqoVMW0fiml9mY7WTy5obOPySMdlbLFqMgzz/yy0rXZcdFtRYXvAhSMdbldg4m5OpiL8ah0XGyHv3hIjBUVvZAAXw8/xJPg3fCoRGjk+LDW9fROQEPJ36NgEnyBRdEDGnTNhmtEDoGs+wXkCjGRw55fxaC/rCongvaJ8u7Q7LECDSIredNLSzcmz81Qsm1njYJHjxhD7tjX+LgAASfRG8stdLCHSXJZFDogZN2niYQxr9vrbQheSLrYoLjzcbdXR45PYh+3TLa2Y2xop0q4+a+FXUdiAAsaBw4abHFrIzbYBgZBlC9c2oW/WDlojBEGY4ohRGi2/KP3NQr+aYtRzSaJdpbPxdviSJLRgzQKAOPS9HzGrn+zfa/qMRDl4ClfznX90EPkoUBZqx82hXPWmdoQ9T4ZmKNxD1cFGR1HA7811AZSC6AYluP8rSxrXGn+h3gOOoeN2I0nI5F/j42a3A3LMTgZqvCXJcPn5mGJ+G1LTBd5JAMhRnNrLjVrVfuGozsYt2r4YqGLjV8rycHs5vc34P1ZmXFVPg3jDA1DvEn844r6+DEaind+6FdgA tReTVgMW 4wbnSpBdsJ/mxRpHLyq/JOW/IclPDGQN8MXMXPGiv48m2SmGZcVhMXcT3BlZdXh3uvED6xvjbcqKjwXrYm5uv9MQi5YqogVro3zMoDGh1s74B7PY9gBa7c9KUEhIreWo2/y4O0vW7chdDPYvkk5DICWY9x5u8cJJT7sQib/txRNchx6IknmA5/IEzCKYLe53+x+Ni8wRuEXJkfUSA7ShN5PXun+oBF/HDpm4LTuuO08X4TQHFhD6Zz6+ppcRk9dgdO90uuZuYDalT5iPPWycLfWLntpMgRZwbkX3vH7H7ZuSYsuYt+KFZ0EPNBNrio76UIlauO9gAaygb9Rrrok9Z15zN4agb7BJIOFWOCsa2rDzD8qLinIceQ3u/25FZWKPoRrc2vRXZMTZETTQ= 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: List-Subscribe: List-Unsubscribe: On Thu, 2 Jan 2025 15:25:28 +0800 Guo Weikang wrote: > Before SLUB initialization, various subsystems used memblock_alloc to > allocate memory. In most cases, when memory allocation fails, an immediate > panic is required. To simplify this behavior and reduce repetitive checks, > introduce `memblock_alloc_or_panic`. This function ensures that memory > allocation failures result in a panic automatically, improving code > readability and consistency across subsystems that require this behavior. Just to be annoying... We now have many more calls to memblock_alloc_or_panic() than to memblock_alloc(). So perhaps memblock_alloc() should default to panicing and we add a new memblock_alloc_no_panic() for the exceptional cases. And from looking around a bit, I think many of the remaining calls to memblock_alloc() could be made to panic on failure anyway. If the kernel cannot successfully execute memblock_alloc(small amount) at __init time then the kernel is hopelessly broken and there's no point in proceeding? In fact I wonder if there is really any legitimate use of memblock_alloc_no_panic()?