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 EFE631C3C04 for ; Fri, 10 Jan 2025 10:15:42 +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=1736504143; cv=none; b=SitfkZLdBlD4hjPhkmfwFBa/bqIOfimDxZXAQrFuWYowk88rMhbZ9ROe3YU6ELPEPL93/W6D23VBslbwmJlmk5EDTf12C37RIHw0MXb9HHZioe8k9WBdickMYqlG0ttSQNk8IhUnxawI9+DEvS2AkJ6R2DZCbCzAk/UCrBxNq9s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736504143; c=relaxed/simple; bh=g4hhOtazNORl5bNwvJkabH2mc9sAFrDXBlVetbOfdSU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jJ+as6hAIcJNpjlEf4EwsT4wpoSKwFRGoVjYGqIv4Z60gfCvIjtAAp6t9spA/33IfDlNeKAWS6by1rYqmPjO0nISesim5EiZgwGInQDllfT0f3omNj6ytpGcDXp8VBoeTH8ZXbsvSIqQs8jrLHOrWAlTXC3W9dKKKs3bxEk35lw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=k2cjfhQl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="k2cjfhQl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8E2FC4CED6; Fri, 10 Jan 2025 10:15:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736504142; bh=g4hhOtazNORl5bNwvJkabH2mc9sAFrDXBlVetbOfdSU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=k2cjfhQlsWoad5+rMzaZy8ggV3Odyw3y4BjMnIu42LamZXzR0SQ4R/81v/w7NKUw3 R8zalHODDkd4snvoTZhKcKm5bvUfte25RRyb4DmJScUM/I60BYamJge0FfveuauKxF a/v7LuZXp6Drt4W1nEMlgrsP8fDvjNygEclAvjciesuMQUdspxcR1BYTcsL4A/QEyb xraIz72Q3bDwp6nSJEsV7WwZYGf2RZHSvkqIaW//GaMqPhx2FbZJPFZCeqVsTX504y +Z4V5Ka6qnkrIC7hN/ZdX4eVW7OUZs6S/Cq3kdWiHXiM0iM6IhRWwoaglPWgPeVX1k YGjiefOKIcafw== Date: Fri, 10 Jan 2025 12:15:31 +0200 From: Mike Rapoport To: Andrew Morton Cc: Guo Weikang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8] mm/memblock: Add memblock_alloc_or_panic interface Message-ID: References: <20250102072528.650926-1-guoweikang.kernel@gmail.com> <20250102150835.776fe72f565cc3232d83e6a7@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250102150835.776fe72f565cc3232d83e6a7@linux-foundation.org> Hi Andrew, On Thu, Jan 02, 2025 at 03:08:35PM -0800, Andrew Morton wrote: > 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. I'd prefer the API to be explicit about what it does. memblock_alloc_or_panic() is indeed longer, but it emphasizes what it does, while memblock_alloc() that panics does not. I also wouldn't want to duplicate all memblock_alloc* with _panic or _nopanic versions. > 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()? At the very least the caller has more context and can print something more descriptive than "failed to allocate X bytes". And I think sometimes the boot can continue with reduced functionality. I don't have examples with memblock_alloc() from the top of my head, but e.g. failure to reserve crash kernel is really not a fatal error. -- Sincerely yours, Mike.