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: <51D28E69.9060205@linux.vnet.ibm.com>
Date:	Tue, 02 Jul 2013 13:55:13 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Michael Wang <wangyun@...ux.vnet.ibm.com>
CC:	tglx@...utronix.de, peterz@...radead.org, tj@...nel.org,
	oleg@...hat.com, paulmck@...ux.vnet.ibm.com, rusty@...tcorp.com.au,
	mingo@...nel.org, akpm@...ux-foundation.org, namhyung@...nel.org,
	walken@...gle.com, vincent.guittot@...aro.org,
	laijs@...fujitsu.com, David.Laight@...lab.com, rostedt@...dmis.org,
	xiaoguangrong@...ux.vnet.ibm.com, sbw@....edu, fweisbec@...il.com,
	zhong@...ux.vnet.ibm.com, nikunj@...ux.vnet.ibm.com,
	linux-pm@...r.kernel.org, linux-arch@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Wang YanQing <udknight@...il.com>,
	Shaohua Li <shli@...ionio.com>,
	Jan Beulich <jbeulich@...e.com>,
	liguang <lig.fnst@...fujitsu.com>
Subject: Re: [PATCH v3 10/45] smp: Use get/put_online_cpus_atomic() to prevent
 CPU offline

Hi Michael,

On 07/02/2013 11:02 AM, Michael Wang wrote:
> Hi, Srivatsa
> 
> On 06/28/2013 03:54 AM, Srivatsa S. Bhat wrote:
> [snip]
>> @@ -625,8 +632,9 @@ EXPORT_SYMBOL(on_each_cpu_mask);
>>   * The function might sleep if the GFP flags indicates a non
>>   * atomic allocation is allowed.
>>   *
>> - * Preemption is disabled to protect against CPUs going offline but not online.
>> - * CPUs going online during the call will not be seen or sent an IPI.
>> + * We use get/put_online_cpus_atomic() to protect against CPUs going
>> + * offline but not online. CPUs going online during the call will
>> + * not be seen or sent an IPI.
> 
> I was a little confused about this comment, if the offline-cpu still
> have chances to become online, then there is chances that we will pick
> it from for_each_online_cpu(), isn't it? Did I miss some point?
>

Whether or not the newly onlined CPU is observed in our for_each_online_cpu()
loop, is dependent on timing. On top of that, there are 2 paths in the code:
one which uses a temporary cpumask and the other which doesn't. In the former
case, if a CPU comes online _after_ we populate the temporary cpumask, then
we won't send an IPI to that cpu, since the temporary cpumask doesn't contain
that CPU. Whereas, if we observe the newly onlined CPU in the for_each_online_cpu()
loop itself (either in the former or the latter case), then yes, we will send
the IPI to that CPU.

Regards,
Srivatsa S. Bhat

> 
>>   *
>>   * You must not call this function with disabled interrupts or
>>   * from a hardware interrupt handler or from a bottom half handler.
>> @@ -641,26 +649,26 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
>>  	might_sleep_if(gfp_flags & __GFP_WAIT);
>>
>>  	if (likely(zalloc_cpumask_var(&cpus, (gfp_flags|__GFP_NOWARN)))) {
>> -		preempt_disable();
>> +		get_online_cpus_atomic();
>>  		for_each_online_cpu(cpu)
>>  			if (cond_func(cpu, info))
>>  				cpumask_set_cpu(cpu, cpus);
>>  		on_each_cpu_mask(cpus, func, info, wait);
>> -		preempt_enable();
>> +		put_online_cpus_atomic();
>>  		free_cpumask_var(cpus);
>>  	} else {
>>  		/*
>>  		 * No free cpumask, bother. No matter, we'll
>>  		 * just have to IPI them one by one.
>>  		 */
>> -		preempt_disable();
>> +		get_online_cpus_atomic();
>>  		for_each_online_cpu(cpu)
>>  			if (cond_func(cpu, info)) {
>>  				ret = smp_call_function_single(cpu, func,
>>  								info, wait);
>>  				WARN_ON_ONCE(!ret);
>>  			}
>> -		preempt_enable();
>> +		put_online_cpus_atomic();
>>  	}
>>  }
>>  EXPORT_SYMBOL(on_each_cpu_cond);
>>
> 

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