From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18])
	(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 D5D711F3BA2
	for <linux-kernel@vger.kernel.org>; Tue, 18 Aug 2026 00:35:17 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1787013318; cv=none; b=NNzyooCq0DEn5TaKIm+okQUq9Mk8MXPjyii3A7/k5IkyiEumVO/tDs7xfq1kU5RlaeqaHJICFM16kBbd9BdqDMZj1aMWTd6306fVCH8rRpPYCXqFwKFDaEEOmde3dYsYSEVVs9BZXo+ZR0GYE9a01saY1O/Kw2Pt2k0By2u4C6w=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1787013318; c=relaxed/simple;
	bh=PX96oAyosOwDAKwLBOX7Mm6yDu7KwRWVwSk4RCEKDwM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=CmeA+XMMZYHIIvKGanU+rJo2PxUVPDpqhPRdGm9q2OwGvuVyKSSqp+yuWyFDLPp2oHuhmGxzrdmgrFOKSweAvJhIiJRSnllTy6UUDPfMWKVLvdl4e/ekbWLW/qHPMjVgQG5EtF9FLXRb0EptjQy1QVa/NmXmCKveXrq74A2LU/g=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U7lhpOz2; arc=none smtp.client-ip=100.103.45.18
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U7lhpOz2"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 746451F000E9;
	Tue, 18 Aug 2026 00:35:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1787013317;
	bh=D6o/Mjguy0kTftlgmBYSy4gaJDB68wNIKzA6Vj3TLJI=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=U7lhpOz2V9rjd0zWT8krD+LZt3v1GQPuKmCukHl/7x7wY9DvYezxlkpiTF8vcsjzF
	 ha+2mMxkmKc7BvRPbSCjlCdQbgwj7ZmXXeflh2but+bff51Dj1LQA0rf6z48ad6qbH
	 uu0tjJ8c+sXQ95Pv62HTCo70d9TlC3u0c9+SFFtviD5Kgiq0xou+dXp91DZxVAdWUo
	 1ZaO0OfzoMtupVa40r9H/TLiR+e/uOG67SzaGkO91E1zQUDXs6K+tgrlUu9rvowIgE
	 DXFVdukK+HWqV6vIvLiJ5nG/v3xnPjwHC5uTyn3k34tjomvJu4F7j7OvDGmhg5goqD
	 OBphIxoXc5pnw==
Date: Tue, 18 Aug 2026 00:35:15 +0000
From: Yosry Ahmed <yosry@kernel.org>
To: Brendan Jackman <brendan.jackman@linux.dev>
Cc: Brendan Jackman <jackmanb@google.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, Peter Zijlstra <peterz@infradead.org>, 
	Andrew Morton <akpm@linux-foundation.org>, David Hildenbrand <david@kernel.org>, 
	Vlastimil Babka <vbabka@kernel.org>, Mike Rapoport <rppt@kernel.org>, Wei Xu <weixugc@google.com>, 
	Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>, Lorenzo Stoakes <ljs@kernel.org>, 
	linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, 
	Sumit Garg <sumit.garg@oss.qualcomm.com>, Will Deacon <will@kernel.org>, rientjes@google.com, 
	"Kalyazin, Nikita" <kalyazin@amazon.co.uk>, patrick.roy@linux.dev, "Itazuri, Takahiro" <itazur@amazon.co.uk>, 
	Andy Lutomirski <luto@kernel.org>, David Kaplan <david.kaplan@amd.com>, 
	Thomas Gleixner <tglx@kernel.org>, Patrick Bellasi <derkling@google.com>, 
	Reiji Watanabe <reijiw@google.com>, Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH v3 13/26] mm: introduce freetype_t
Message-ID: <aoOomzh1ErtSeKFb@google.com>
References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com>
 <20260726-page_alloc-unmapped-v3-13-6f5729aa9832@google.com>
 <anJmOMqCVugycC9x@google.com>
 <DKOLND2TRB15.2Y8DKB3ZKEYAY@linux.dev>
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-Disposition: inline
In-Reply-To: <DKOLND2TRB15.2Y8DKB3ZKEYAY@linux.dev>

> >> +static inline
> >> +struct list_head *free_area_list(struct free_area *area, freetype_t type)
> >> +{
> >> +	int idx = freetype_idx(type);
> >> +
> >> +	VM_WARN_ON(idx < 0);
> >> +	return &area->free_list[idx];
> >
> > Should we return NULL here if idx < 0 instead of an out of bounds
> > access?
> 
> TBH my descending order of preference is:
> 
> 1.
> 
> BUG_ON(idx < 0);
> return &area->free_list[idx];
> 
> 2.
> 
> if (WARN_ON(idx < 0)) // OR VM_WARN_ON
>   return NULL;
> return &area->free_list[idx];
> 
> 3.
> 
> VM_WARN_ON(idx < 0);
> return &area->free_list[idx];
> 
> 4. 
> 
> return &area->free_list[idx];
> 
> But I suspect[0] Vlastimil (and Linus) would order it the exact opposite
> way.
> 
> [0]: https://lore.kernel.org/all/bd36e972-8900-4476-a66b-4dc218b21a4d@kernel.org/
> 
> And I care more about making Vlastimil (and Linus) happy than this tiny
> detail of the code, so I'll defer to him. The current style is a
> compromise, but maybe it's just a compromise that makes nobody happy.

I think I prefer #2 (regardless of whether it's WARN_ON() or
VM_WARN_ON()), let's see if anyone disagrees.