linux-kernel - Re: [PATCH] Introduce compat_u64 and compat

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:	Fri, 15 Jun 2007 14:00:06 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Andi Kleen <ak@...e.de>, David Howells <dhowells@...hat.com>,
	Arnd Bergmann <arnd@...db.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Airlie <airlied@...ux.ie>, linux-arch@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] Introduce compat_u64 and compat_s64 types

On Fri, 2007-06-15 at 13:54 +0100, Alan Cox wrote:
> For the parts used by the processors in question yes people have done
> that work so using the types without unaligned.

I still think we could use a 'get_maybe_but_probably_not_unaligned()',
although it could have a better name.

People now use get_unaligned() for two reasons -- firstly because we
_expect_ something to be unaligned, and we get a performance improvement
if we just emit code to directly handle that instead of taking the trap.
And more recently we've also started to use it because there's a
_slight_ chance it could be unaligned, and some architectures can't
cope.

Where the unalignment is possible but unlikely, many architectures
probably shouldn't be emitting code to cope with it; they should just
take the trap in the rare case.

In fact, the probability threshold at which it makes sense to just take
the trap will vary from architecture to architecture. We should probably
just have a get_probably_unaligned(...) macro which has its first arg as
an _estimated_ constant probability. Then the architecture code could
emit what it likes according to the probability.

-- 
dwmw2

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