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:	Wed, 13 Jul 2011 14:47:51 -0700
From:	"Luck, Tony" <tony.luck@...el.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
CC:	"Yu, Fenghua" <fenghua.yu@...el.com>,
	"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: ia64: replace old cpumask functions with new one

> But ummm.. I can't understand the author expect which effect by this volatile.
> If I am correct, its volatile has no effect. we can simply remove it.

It may be a legacy from when cpumask was a simple integer type. The
boot cpu wakes up each "AP" cpu in turn - and spins looking at
cpu_callin_mask waiting to see if the cpu has really woken up,
since the AP cpu will set its own bit in this mask when it begins
execution.

Making the original integer mask a volatile was a way to make
sure that the compiler did not optimize away the re-read of
this variable in the loop.

When NR_CPUS is small enough - we still use a simple
integer for cpumask type - don't we? So if you remove
the volatile, look very carefully at this loop:

        for (timeout = 0; timeout < 100000; timeout++) {
                if (cpu_isset(cpu, cpu_callin_map))
                        break;  /* It has booted */
                udelay(100);
        }

to make sure that the cpu_isset() check really does look
at cpu_callin_map every time (and not at some cached in a
register copy of it). Booting would become painfully slow
if we get stuck for 10 seconds per cpu just here.

-Tony


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