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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48752121.3050208@zytor.com>
Date:	Wed, 09 Jul 2008 16:35:45 -0400
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	Jeremy Fitzhardinge <jeremy@...p.org>, Ingo Molnar <mingo@...e.hu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Mike Travis <travis@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jack Steiner <steiner@....com>, linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [RFC 00/15] x86_64: Optimize percpu accesses

Christoph Lameter wrote:
> 
> Another reason to use a zero based per cpu area is to limit the offset range. Limiting the offset range allows in turn to limit the size of the generated instructions because it is part of the instruction. It also is easier to handle since __per_cpu_start does not figure
> in the calculation of the offsets.
> 

No, that makes no difference.  There is no short-offset form that 
doesn't involve a register (ignoring the 16-bit 67h form on 32 bits.)

For 64 bits, you want to keep the offsets within %ripĀ±2 GB, or you will 
have relocation overflows for %rip-based forms; for absolute forms you 
have to be in the range 0-4 GB.  The %rip-based forms are shorter, and 
I'm pretty sure they're the ones we currently generate.  Since we base 
the kernel at 0xffffffff80000000 (-2 GB) this means a zero-based offset 
is actively wrong, and only work by accident (since the first 
CONFIG_PHYSICAL_START of that space is unused.)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ