linux-kernel - Re: [patch 01/28] cpu alloc: The allocator

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:	Tue, 13 Nov 2007 20:15:55 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Andi Kleen <andi@...stfloor.org>
cc:	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	linux-mm@...r.kernel.org, linux-kernel@...r.kernel.org,
	dada1@...mosbay.com, schwidefsky@...ibm.com
Subject: Re: [patch 01/28] cpu alloc: The allocator

Hmmm.. I have v2 in preparation here that puts the pda and the per cpu 
data into the cpu_alloc area. Thus gs: can be used to access all per cpu 
data.

Any ideas how to abstract out the pda operations? Wasnt local_t supposed 
to be able to do atomic ops on cpu data? Is there an segment register 
version of local_t? I want also to have cmpxchg xchg etc that are all 
atomic without requiring any interrupt disable or preempt disable.

cpu_alloc allows pointer arithmetic on cpu area pointers. The segment 
prefix can then be used to select the appropriate area.

Guess I need also to add an arch configuration guide to V2 as well so that 
the other arches can do similar tricks and emphasize that the static 
default that requires bss is only suitable for small systems.
-
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/