linux-kernel - Re: [x86] Unify semaphore_32.S and rwlock

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, 20 Jan 2010 12:14:22 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [x86] Unify semaphore_32.S and rwlock_64.S

On 01/20/2010 11:49 AM, Christoph Lameter wrote:
> On Tue, 19 Jan 2010, H. Peter Anvin wrote:
> 
>> Could you do this in the standard sequencing for unification patches:
>> first patch the two pieces of code so they are identical, and then
>> mechanically unifying them?  Otherwise it's almost impossible to see
>> what has changed.
> 
> Hmmm... Okay I better do that on top of your patches then.
> 
>>> This is also a good preparatory patch for getting the rwsem XADD stuff
>>> to work on x86_64.
>>
>> Have you tried the tip:x86/rwsem branch (Linus' work with a few
>> additions of mine) and had it not work for you?
> 
> No I just saw it. Linus first patch increases the 64/32 bit separation by
> creating yet another 64 bit specific file. Can we avoid that and have
> code that is shared as much as possible between 32 and 64 bit?

The ABI is completely different between 32 and 64 bits.  The stubs avoid
keeping track of *those* differences in each and every inline.  It might
be possible with macros, but there is something that really is very
different: for x86-32, there are only three function-clobbered
registers, which we pretty much need to use anyway.  For x86-64, there
are a lot more -- which means that each callsite would end up having gcc
generate save/restore code that would be in the fast path.  Linus' patch
pushes that into the slow path, which seems significantly better to me.

The new file seems like a very good way to deal with the ABI/register
set differences here.

> Then there is another that does the %z0 trick while we already have the
> proper definitions for that in include/asm/asm.h. Seems that you have
> switched to using those. Was that done consistently?

The %z0 trick would have been type-safe.  Unfortunately some versions of
gcc simply generate incorrect code with it, which is why I switched back
to the <asm/asm.h> macros (and yes, I got rid of all the %z's by sheer
necessity.)

> Why have a rwsem_count_t when a simple long would do in both cases? Just
> make sure that long is consistently used.

The motivation for rwsem_count_t seemed to be making it easier to switch
over.  I leave it up to Linus to motivate the typedef... I have to say,
though, that using a typedef also tells you want the number is for.

> __downgrade_write:  Why use the inc trick instead of the add
> like in 32 bit? There is not much difference and it results in much
> stabler code.

Because you can't do an add with a 64-bit immediate!  Yes, we could have
loaded it into a register, but that would have required an additional
10-byte(!) instruction for no good reason.

>>> x86_64 gains the FRAME/ENDFRAME handling that i386 has (not sure what the
>>> point is of having that there).
>>
>> Presumably it's so you can have frame pointers everywhere.
> 
> For a small code segment that does not do any subroutine calls?

It's kind of redundant, yes, but that was presumably the logic.

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