linux-kernel - Re: [RFC/PATCH 0/4] CPUSET driven CPU isolation

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: <alpine.DEB.1.00.0802281452340.13082@chino.kir.corp.google.com>
Date:	Thu, 28 Feb 2008 15:00:37 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Paul Jackson <pj@....com>
cc:	mingo@...e.hu, a.p.zijlstra@...llo.nl, tglx@...utronix.de,
	oleg@...sign.ru, rostedt@...dmis.org, maxk@...lcomm.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH 0/4] CPUSET driven CPU isolation

On Thu, 28 Feb 2008, Paul Jackson wrote:

> > How about moving watchdog/0 to a cpuset with exclusive access to only cpu 
> > 1?
> 
> I don't understand your question here.
> 

Move the watchdog/0 thread to a cpuset that doesn't have access to cpu 0.  

> > >     +	if (unlikely((p->flags & PF_CPU_BOUND) && p != current &&
> > >     +	    	     !cpus_subset(p->cpus_allowed, new_mask))) {
> > >     +		ret = -EINVAL;
> > > 
> > 
> > That's a convenient way for a kthread to temporarily expand its set of 
> > cpus_allowed and then never be able to remove the added cpus again.  Do 
> > you have any examples in the tree where a kthread does this?
> 
> Good question.  Actually, we -normally- have pinned tasks in the top cpuset,
> where the top cpuset allows all CPUs, but the pinned task has a cpus_allowed
> (in its task struct) of just one or a few CPUs (for node pinning.)
> 

Same situation occurs for a task bound to a cpuset that issues a 
sched_setaffinity() call to restrict its cpumask further.  There's nothing 
new there.

> So ... could we allow moving pinned threads to any cpuset that allowed
> the CPUs to which it was pinned (my cpus_subset() test, above), but
> -not- change the pinned tasks cpus_allowed in its task struct, keeping
> it pinned to just the same one or few CPUs?
> 

I'd hesitate to do that unless you can guarantee that restricting 
kthreads mems_allowed via the cpuset interface won't cause any problems 
either.  Is there a benefit to reducing the size of a kthread's 
mems_allowed that doesn't have an adverse effect on the kernel?  What 
about kswapd?

> I don't think that the cpus_equal() check prevents that (shrinking a
> pinned tasks cpuset out from under it.)  Try the following on a freshly
> booted system with your proposed patch:
> 
>   mkdir /dev/cpuset
>   mount -t cpuset cpuset /dev/cpuset
>   cd /dev/cpuset
>   mkdir a
>   cp ???s a
>   < tasks sed -un -e p -e 10q > a/tasks
> 
> I'll wager you just moved a few pinned tasks into cpuset 'a'.  This
> would be allowed, as 'a' has the same cpus as the top cpuset.  But then
> one could shrink a (if it had more than 1 CPU in the first place), leaving
> some pinned tasks in a cpuset they weren't allowed to run in, essentially
> unpinning them.
> 

You can move them, but you cannot reduce the size of the thread's 
cpus_allowed since it was bound to a specific cpu via kthread_bind().  The 
change to set_cpus_allowed() simply prevents this from happening in the 
kernel as opposed to just stopping the possibility through cpusets.

> > PF_CPU_BOUND follows the nomenclature of kthread_bind() really well, but 
> > it could probably be confused with a processor-bound task.  So perhaps 
> > PF_BOUND_CPU is even better?
> 
> Good point - "BOUND" as the past tense of "BIND".  How about
> PF_THREAD_BIND ;)?
> 

Sure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/