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 16:24:28 +0000
From:	"Jan Beulich" <JBeulich@...ell.com>
To:	<a.p.zijlstra@...llo.nl>, <mingo@...e.hu>, <tglx@...utronix.de>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	<mingo@...hat.com>, <npiggin@...e.de>,
	<linux-kernel@...r.kernel.org>, <hpa@...or.com>
Subject: Re: [tip:core/locking] locking, x86: Slightly shorten
	 __ticket_spin_trylock()

>>> Linus Torvalds <torvalds@...ux-foundation.org> 02.12.09 16:26 >>>
>You have zero idea what type "bool" is, do you? It can well be "int", it 
>can be "char", it can be some compiler-internal type ("_Bool"). You have 
>no idea what size it is.
>
>And maybe it _is_ just a byte. But even if it is, using 'bool' here is 
>wrong. The fact is, bool has magic semantic properties outside of sizing. 
>You can't mix it with inline asm, because you simply don't know what the 
>compiler rules for 'bool' are.
>
>For example, maybe the rules are that it's always passed as an integer, 
>and is always guaranteed to have the values 0/1. So even if 'sizeof' 
>returns 1, that doesn't actually mean that you can necessarily pass it 
>around as a char - it only means that it will take one byte in a structure 
>(except that bool arrays might be packed, I think).
>
>In other words, the semantics of 'bool' are such that you have no clue 
>what the actual ABI for 'bool' is. You cannot mix this with asm.

This just can't be the case: In order for two compilers to be
interoperable, the processor specific ABI has to define the handling of
bool, just like it has to for any other data type.

>Secondly, the notion of using a union here is just totally broken. There's 
>no point to it, and it just makes the code look horrible.

There is a point: Avoiding to have the compiler allocate yet another
register for the asm().

>So if you want to do this, then just keep 'new' as an int, and make sure 
>that the function returns a 'char'. No games with 'bool' which is badly 
>defined, no games with unions.

I considered that, but since the code means to return a boolean value,
using a char here is as bogus as (mis-)using int-s for returning boolean
values.

>And please do make sure that it actually doesn't deprove code at the 
>callers too.

Not sure what you mean here (or whether it's a typo) - neither I nor
my dictionary know the word "deprove". I assume you mean that I ought
to check that this doesn't make worse the code at the call sites, which
I did.

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/