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]

Message-ID: <alpine.LFD.2.00.0912020727410.2872@localhost.localdomain>
Date:	Wed, 2 Dec 2009 07:33:25 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jan Beulich <JBeulich@...ell.com>
cc:	Ingo Molnar <mingo@...e.hu>, a.p.zijlstra@...llo.nl,
	Jeremy Fitzhardinge <jeremy@...p.org>, tglx@...utronix.de,
	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()

On Wed, 2 Dec 2009, Jan Beulich wrote:

> >>> Ingo Molnar <mingo@...e.hu> 02.12.09 15:21 >>>
> 792a99a9 <_raw_spin_lock>:
> ...
> >792a99f3:	89 d8                	mov    %ebx,%eax
> >792a99f5:	ff 15 d0 6c f2 79    	call   *0x79f26cd0
> >792a99fb:	85 c0                	test   %eax,%eax
> ...
> >792a9a2e:	89 f8                	mov    %edi,%eax
> >792a9a30:	ff 15 d0 6c f2 79    	call   *0x79f26cd0
> >792a9a36:	85 c0                	test   %eax,%eax
> 
> Assuming that these are the calls to __raw_spin_trylock, it is clear that
> the generated code isn't what we want: It should be test %al, %al in
> both cases.

See my previous email.  Using 'bool' was a mistake. It's _always_ a 
mistake. 

'bool' basically says that the compiler can assume magic things, and 
compile the thing to be anything it wants that is convenient for it. 
Put another way, 'bool' has a magic API. For all you know, the rule might 
even be that a 'bool' return value is always returned in a flag register 
(ok, on x86 that would be _very_ inconvenient, but it's _possible_). 

So the calling convention could have been

	call <bool-returning-function>
	jne ..	// jump if it returned non-zero

because the rule about bool is that it is just one bit of information, 
but exactly _how_ that bit is done is totally up to the compiler ABI.

In this case, the rule gcc implements on x86 is probably just "we pass it 
around as an 'int' that contains 0 or 1". So the code would work if you 
had left in the 'movzbl'.

End result: don't use bool.

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