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]

Message-ID: <alpine.DEB.2.00.1001201443340.17915@router.home>
Date:	Wed, 20 Jan 2010 14:51:09 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
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 Wed, 20 Jan 2010, H. Peter Anvin wrote:

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

That does not seem to be such a problematic thing to solve.

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

I thought we discourage such typedefs?

> > __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.

Well 2^32 readers is a bit large anyways. If we are satisifed with 2^30
(only a billion) then it works with the same code.

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