linux-kernel - Question about tboot_wait_for

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>] [day] [month] [year] [list]

Message-ID: <20120724155853.GA32362@linux.vnet.ibm.com>
Date:	Tue, 24 Jul 2012 08:58:53 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Question about tboot_wait_for_aps()

Hello!

While taking another pass through the CPU_DYING notifiers, I came upon
the following:

	static int tboot_wait_for_aps(int num_aps)
	{
		unsigned long timeout;

		timeout = AP_WAIT_TIMEOUT*HZ;
		while (atomic_read((atomic_t *)&tboot->num_in_wfs) != num_aps &&
		       timeout) {
			mdelay(1);
			timeout--;
		}

		if (timeout)
			pr_warning("tboot wait for APs timeout\n");

		return !(atomic_read((atomic_t *)&tboot->num_in_wfs) == num_aps);
	}

Questions:

1.	Why AP_WAIT_TIMEOUT*HZ?  Given the mdelay(), shouldn't this
	instead be AP_WAIT_TIMEOUT*1000?  The definition of AP_WAIT_TIMEOUT
	indicates that it is in seconds.

2.	Who changes ->num_in_wfs?  Any other CPUs are in stop_machine(),
	plus I don't see any assignments to this field.  Does the boot
	firmware run again to make this change, sort of like SMIs?

I guess that the good news is that I don't seen anything that cares about
stop_machine().  ;-)

							Thanx, Paul

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