linux-kernel - Re: [PATCH] sched: cgroup: Move task_can

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aN__h87LFTCG3jBp@gpd4>
Date: Fri, 3 Oct 2025 18:53:27 +0200
From: Andrea Righi <arighi@...dia.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Waiman Long <longman@...hat.com>, Tejun Heo <tj@...nel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Koutný <mkoutny@...e.com>,
	Julia Lawall <Julia.Lawall@...ia.fr>,
	"Luis Claudio R. Goncalves" <lgoncalv@...hat.com>,
	Joseph Salisbury <joseph.salisbury@...cle.com>
Subject: Re: [PATCH] sched: cgroup: Move task_can_attach() to cpuset.c

On Fri, Oct 03, 2025 at 12:43:00PM -0400, Steven Rostedt wrote:
...
> > > +static inline int task_can_attach(struct task_struct *p)
> > > +{
> > > +	int ret = 0;
> > > +
> > > +	/*
> > > +	 * Kthreads which disallow setaffinity shouldn't be moved
> > > +	 * to a new cpuset; we don't want to change their CPU
> > > +	 * affinity and isolating such threads by their set of
> > > +	 * allowed nodes is unnecessary.  Thus, cpusets are not
> > > +	 * applicable for such threads.  This prevents checking for
> > > +	 * success of set_cpus_allowed_ptr() on all attached tasks
> > > +	 * before cpus_mask may be changed.
> > > +	 */
> > > +	if (p->flags & PF_NO_SETAFFINITY)
> > > +		ret = -EINVAL;
> > > +
> > > +	return ret;  
> > 
> > As we're cleaning up, we could just return -EINVAL and 0 directly and get
> > rid of that ret variable.
> 
> That should be a separate patch. Moves should really not do much else. I
> even wondered about making it a static inline too, but figured that wasn't
> touching the logic, and the function was going to become static anyway.

Oh yes, good point. In the meantime, FWIW:

Tested-by: Andrea Righi <arighi@...dia.com>

Thanks,
-Andrea