From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD802149E00
	for <linux-kernel@vger.kernel.org>; Thu,  2 Jan 2025 23:08:36 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1735859316; cv=none; b=lJTT1CNLHsJS0A0xATy6R7+/R8RU/nzTM0qF1xv5UCu78NGULQuqOmRa4sK8yUV2nD4skMHIvqs0y2GCbvApzQKy3T2qn3aAKSxxDP87V4eCJ3Z89kzxkxlqhe1l6R+EOWx6dTgaUq9pnI1nIDnPNcurf/hAHPfJvjU5KVtfO1k=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1735859316; c=relaxed/simple;
	bh=7nH6vOGTXDlpSYPXJ2kxTSIlqCHxEXPnXNEBrCBgTY4=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=nT7aaNKO/MJhd7lDNw7SOiSWe7Y+cuT3lky/ZZP+YW+HWqvRjixHKGw3rpnb/vW2P/xPEICHI6RoHvBqaHszhTCYL1RcSY5URYYWLx+eWSNPYp7K33o7rOEhZMEaBHyNOtH4NoaAi95VCNoOlSKH3vNn22L2xB/G1gBzjrExWjY=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=gqYYJxvw; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="gqYYJxvw"
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 <akpm@linux-foundation.org>
To: Guo Weikang <guoweikang.kernel@gmail.com>
Cc: Mike Rapoport <rppt@kernel.org>, 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)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu,  2 Jan 2025 15:25:28 +0800 Guo Weikang <guoweikang.kernel@gmail.com> 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()?