linux-kernel - Re: [PATCH v3 5/5] cpusets, suspend: Save and restore cpusets during suspend/resume

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]

Date:	Tue, 15 May 2012 14:05:25 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	Nishanth Aravamudan <nacc@...ux.vnet.ibm.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	mingo@...nel.org, pjt@...gle.com, paul@...lmenage.org,
	akpm@...ux-foundation.org, rjw@...k.pl, nacc@...ibm.com,
	paulmck@...ux.vnet.ibm.com, tglx@...utronix.de,
	seto.hidetoshi@...fujitsu.com, tj@...nel.org, mschmidt@...hat.com,
	berrange@...hat.com, nikunj@...ux.vnet.ibm.com,
	vatsa@...ux.vnet.ibm.com, liuj97@...il.com,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v3 5/5] cpusets, suspend: Save and restore cpusets during
 suspend/resume

On Tue, 15 May 2012, Peter Zijlstra wrote:

> > However, if a thread did set_mempolicy(MPOL_BIND, 2-3) where cpuset.mems 
> > == node_online_map, cpuset.mems changes to 0-1, then cpuset.mems changes 
> > back to node_online_map, then I believe (and implemented in the mempolicy 
> > code and added the specification in the man page) that the thread should 
> > be bound to nodes 2-3.
> 
> I disagree, but alas that is done :-(
> 

Not sure what you're disagreeing with, it only happens with 
MPOL_F_STATIC_NODES or MPOL_F_RELATIVE_NODES and I've clearly defined the 
behavior in the man page.  I personally never had a use-case for 
MPOL_F_RELATIVE_NODES but Paul Jackson asked that it be added for SGI when 
we added mempolicy mode flags.

> But what happens if you unplug nodes 2-3?
> 

Mempolicies lack hotplug notifiers entirely so it falls back to no policy 
at allocation time, the rebinding of nodes in the context of cpusets only 
occurs when cpuset.mems changes, not with hotplug.

> The problem is that if you have some cpusets configuration and then do a
> s/r cycle the entire configuration is wrecked because suspend
> hot-unplugs all but cpu0 and resume re-plugs the cpus.
> 
> This destroys all masks and migrates all tasks in sets not including
> cpu0 to the root set.
> 

Yup.

> Srivatsa proposed to 'fix' this by remembering state of regular hotplug,
> to which I strongly oppose, hotplug is destructive and should be,
> there's no point in remembering state that might never be used again.
> Worse you temporarily 'break' your cpuset 'promise' to then silently
> restore it.
> 
> The s/r resume case is special in that userspace isn't actually around
> to observe the cpus going away and coming back, also it has the
> guarantee the cpus will be coming back.
> 
> So s/r is special and should not destroy state, hotplug should.
> 

Why can't we leave cpuset.cpus unaltered for all cpusets during suspend?  
Having a cpu set in cpuset.cpus does not mean the attached threads are 
allowed to run on all of them.
--
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/