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]
Date:	Wed, 09 Jul 2008 16:25:33 -0500
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Mike Travis <travis@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, 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

Jeremy Fitzhardinge wrote:

> No, it makes no difference.  %gs:X always has a 32-bit offset in the
> instruction, regardless of how big X is:
> 
>     mov %eax, %gs:0
>     mov %eax, %gs:0x1234567
> ->
>   0:    65 89 04 25 00 00 00 00    mov    %eax,%gs:0x0
>   8:    65 89 04 25 67 45 23 01    mov    %eax,%gs:0x1234567

The processor itself supports smaller offsets.

Note also that the 32 bit offset size limits the offset that can be added to the segment register. You either need to place the per cpu area either in the last 2G of the address space or in the first 2G. The zero based approach removes that limitation.


>>  It also is easier to handle since __per_cpu_start does not figure
>> in the calculation of the offsets.
>>   
> 
> No, you do it the same as i386.  You set the segment base to be
> percpu_area-__per_cpu_start, and then just refer to %gs:per_cpu__foo
> directly.  You can use rip-relative addressing to make it a smaller
> addressing mode too:
> 
>   0:    65 89 05 00 00 00 00     mov    %eax,%gs:0(%rip)        # 0x7

RIP relative also implies a 32 bit offset meaning that the code cannot be more than 2G away from the per cpu area.
--
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