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 DFB19140E5F
	for <linux-kernel@vger.kernel.org>; Sat,  9 May 2026 15:35:51 +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=1778340951; cv=none; b=HyBu7oGzLraK41wErZJCot7KNrp2PoWo8nWHn2wzt1Ic1JghaG35Ow1ZA4BF9qdQiwvocp8ln5k5S/hTT0SHWBk9d5kLLsSbyI2J+8nuHIDv0g0JbSRw3jYbYJrMzwnE8J4IHebwDxHnpl0Zz4F5OtMy2C4UA6X4iCrT/lvbP1g=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1778340951; c=relaxed/simple;
	bh=tmcnbuw+ugtesj9KcIv3suCuq9QnKOxMSZwtLoJ8dAw=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=HeZaKWpT/YGivKlSnDROvZuCeKtBX2pgPCnWMQQ9tnNjHbbZ3jVBS82AGvTBbExa+vMcDbE37WRH62/VFibEAMv2Y0a5pkuzuCFaiE7ylje7R5Dn3FI1prGZMLM9VSJ4AgC6IwtINIKiqcguWqsl6cn/ZYs/PFXH2Qwq9U7WSYw=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qgz/kqoo; 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="qgz/kqoo"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1BDD0C2BCB2;
	Sat,  9 May 2026 15:35:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1778340951;
	bh=tmcnbuw+ugtesj9KcIv3suCuq9QnKOxMSZwtLoJ8dAw=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=qgz/kqooInyVkxq9eY15oPPq4XLR5G5zW8VYI6ZGSoTmnrqdTaPSyZJ14p0atxZrq
	 EtOiHGOBrkRIr0/ooVrD29IrL/JuKC7pcTx0DO/4WFFEkaXJ96O7+cb5/b7PNr5qvv
	 l6sryzBi+VhW17eCpmB20N8ytXKl7wTCE29rgA2Ul6lj+ondjPxWIgG9PF6vTiePNA
	 07sOIM9TG7vDbjwXth3qDO0RJ+2FC9AjAvCncgiOclv7f70YwMEISkxUGxbA8khmDz
	 QIo1td8ZSmX42qJ6xaNfMKYjOF5MQQvdv8jWc2eefQKM7LEmDslfQAuC8TNE2UdN8j
	 cOVr8fnKBBm8Q==
From: SeongJae Park <sj@kernel.org>
To: "zhen.ni" <zhen.ni@easystack.cn>
Cc: SeongJae Park <sj@kernel.org>,
	akpm@linux-foundation.org,
	vbabka@kernel.org,
	surenb@google.com,
	mhocko@suse.com,
	jackmanb@google.com,
	hannes@cmpxchg.org,
	ziy@nvidia.com,
	linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/3] mm/page_owner: add NUMA node filter with nodelist support
Date: Sat,  9 May 2026 08:35:45 -0700
Message-ID: <20260509153547.89036-1-sj@kernel.org>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <9ebddab1-b7b4-462e-a920-f850cc5c55c5@easystack.cn>
References: 
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=UTF-8
Content-Transfer-Encoding: 8bit

On Sat, 9 May 2026 15:27:22 +0800 "zhen.ni" <zhen.ni@easystack.cn> wrote:

> 
> 
> 在 2026/5/9 08:44, SeongJae Park 写道:
> > On Thu,  7 May 2026 14:46:42 +0800 Zhen Ni <zhen.ni@easystack.cn> wrote:
[...]
> >> +static ssize_t nid_filter_write(struct file *file,
> >> +				 const char __user *buf,
> >> +				 size_t count, loff_t *ppos)
> >> +{
> >> +	char *kbuf;
> >> +	nodemask_t mask;
> >> +	int ret;
> >> +
> >> +	/*
> >> +	 * Limit input size to handle worst-case nodelist (all nodes).
> >> +	 * Worst case per node: ",NNNNN" (comma + 5-digit node number) = 6 bytes.
> >> +	 * Formula: 100 bytes overhead + 6 * MAX_NUMNODES
> > 
> > What is the 100 bytes overhead?
> 
> The 100 bytes is intended as a safety margin, but it's not strictly 
> necessary.
> Maybe I should simplify it to just 6 * MAX_NUMNODES?

I wouldn't mind keep having 100 bytes, but I'd suggest to clearly document the
intention if you will do so.  But if you also don't think it is necessary, I'm
also up to just removing it.

> > 
> >> +	 */
> >> +	if (count > (100 + 6 * MAX_NUMNODES))
> >> +		return -EINVAL;
> >> +
> >> +	kbuf = kmalloc(count + 1, GFP_KERNEL);
> >> +	if (!kbuf)
> >> +		return -ENOMEM;
> > 
> > Would it make sense to use kmalloc_objs()?
> 
> I'll update the code to use
> kmalloc_objs(char, count + 1, GFP_KERNEL)

kmalloc_objs() use GFP_KERNEL by default.  It can also understand the type of
the ojbect.  So you could kmalloc_objs(*kbuf, count + 1).

> 
> Thanks for the review!

I'm happy to help! :)


Thanks,
SJ

[...]