linux-kernel - Re: [tip:core/locking] locking, x86: Slightly shorten __ticket_spin

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:	Wed, 02 Dec 2009 14:06:59 +0000
From:	"Jan Beulich" <JBeulich@...ell.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	<a.p.zijlstra@...llo.nl>, <tglx@...utronix.de>,
	<torvalds@...ux-foundation.org>, <mingo@...hat.com>,
	<npiggin@...e.de>, <linux-kernel@...r.kernel.org>,
	<linux-tip-commits@...r.kernel.org>, <hpa@...or.com>
Subject: Re: [tip:core/locking] locking, x86: Slightly shorten
	 __ticket_spin_trylock()

>>> Ingo Molnar <mingo@...e.hu> 02.12.09 14:29 >>>
>at first quick sight, this bit looks odd:
>
>+       union { int i; bool b; } new;
>
>+       return new.b;
>
>shouldnt that be short based, to work correctly in the 0-255 CPUs case?

No, I can't see why. In both instances, we're using (and had been
using previously, just with the added movzbl) the outcome of a
setCC instruction, which produces valid bool (single byte) values.
It is precisely that reason why I needed to introduce these unions,
since the upper bytes of the register aren't valid (and shouldn't be
looked at by the caller).

Do you happen to have the vmlinux binary still around, to look at
the code your compiler generated (I went through the code I got
in quite a bit of detail to make sure it got translated correctly)?

Jan

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