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] [day] [month] [year] [list]
Date:	Thu, 17 May 2012 15:27:05 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	David Rientjes <rientjes@...gle.com>,
	Nishanth Aravamudan <nacc@...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 05/17/2012 02:54 AM, Peter Zijlstra wrote:

> On Wed, 2012-05-16 at 03:46 +0530, Srivatsa S. Bhat wrote:
>>
>> However, the cpu_active_mask was introduced to handle situations where hotplug
>> transition is still in progress, and the scheduler needs to take appropriate
>> decisions even with some of its data-structures in an inconsistent/stale state.
>> But once the hotplug operation is completed, the scheduler doesn't need to
>> depend on cpu_active_mask.
> 
>> (And on those lines, making the scheduler work correctly even in such cases
>> is only a good-to-have as a robustness measure and not a "bugfix".) 
> 
> I think those 2(?) cases you found not covered by active mask could
> actually happen during a hotplug. So far they simply haven't.
> 


Yes, it could happen during a hotplug too. And its on my todo list to fix.

(But the point I was trying to make was that keeping the sched domains outdated
across multiple hotplug operations isn't really correct.)

Anyway, I think this is the state where the discussion stands atm:

1. We are not going to alter how cpusets are handled during regular cpu hotplug.
   We will do a suspend/resume-only fix for cpusets.
   David Rientjes said that this can probably be argued about endlessly, but he
   has no objections against doing it this way.

2. David Rientjes pointed out that explicit save and restore for suspend/resume
   needs a new per-cpuset cpu mask and he would prefer a design where we wouldn't
   need a new per-cpuset mask.
   Such a design is possible, by building a single sched domain (ignoring cpuset
   configurations, by using partition_sched_domains(1, NULL, NULL)) throughout
   suspend/resume cpu hotplug operations, and then restoring the original sched
   domain tree by looking up the cpusets, towards end of resume (last online
   operation).
   
   The frozen userspace won't notice any of this.

3. David had some comments/suggestions about some patches in this series.

So, I'll go with the design mentioned in 2, and address 3 and spin out a new
version.

Regards,
Srivatsa S. Bhat

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ