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.LFD.2.00.1001201542000.13231@localhost.localdomain>
Date:	Wed, 20 Jan 2010 15:46:16 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Christoph Lameter <cl@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [x86] Unify semaphore_32.S and rwlock_64.S

On Wed, 20 Jan 2010, H. Peter Anvin wrote:
> 
> 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...

Indeed. I wanted to separate the issue of cleaning up the mask values from 
cleaning up the code. That required that we'd have a separate type that 
can change in _one_ place with the bias values.

It was also an unholy type mess before, so the rwsem_count_t also was 
about making that unholy mess clearer. That's especially true since the 
type will also have to percolate down to the slow cases before you can 
actually fix the BIAS values.

As to keeping the 64-bit and 32-bit slow case wrappers separate: this is 
very much one case where we _have_ to. Trying to pretend that 32-bit code 
and 64-bit code is similar in this case is just lying. The calling 
conventions are totally different, there is nothing similar there at all 
(different argument registers, different clobbered registers, different 
_everything_ that matters for the wrapper).

		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/