Received-SPF: pass (google.com: domain of linux-kernel+bounces-151009-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 19 Apr 2024 07:13:50 +0200
From: Sam Ravnborg <sam@ravnborg.org>
To: Dawei Li <dawei.li@shingroup.cn>
Cc: davem@davemloft.net, andreas@gaisler.com, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] Remove onstack cpumask var usage
Message-ID: <20240419051350.GA558245@ravnborg.org>
References: <20240418104949.3606645-1-dawei.li@shingroup.cn>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240418104949.3606645-1-dawei.li@shingroup.cn>

Hi Dawei,

On Thu, Apr 18, 2024 at 06:49:44PM +0800, Dawei Li wrote:
> Hi,
> 
> This series aims at removing on-stack cpumask var usage for sparc arch.
> 
> Generally it's preferable to avoid placing cpumasks on the stack, as
> for large values of NR_CPUS these can consume significant amounts of
> stack space and make stack overflows more likely.

Took a quick look at the patches, looks good except the one the bot
already complained about.
A quick grep shows a few more cases where we have an on-stack cpumask
in sparc code.

kernel/ds.c:    cpumask_t mask;
kernel/leon_kernel.c:   cpumask_t mask;
kernel/leon_smp.c:static void leon_cross_call(void *func, cpumask_t mask, unsigned long arg1,
kernel/sun4d_smp.c:static void sun4d_cross_call(void *func, cpumask_t mask, unsigned long arg1,

Do you plan to look at the other on-stack users too?
It would be nice to see them all gone in one patch-set.

	Sam