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 13:49:16 -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>
Subject: Re: [x86] Unify semaphore_32.S and rwlock_64.S

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?

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?

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

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

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