linux-kernel - Re: [GIT RFC] percpu: use dynamic percpu allocator as the default percpu 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:	Mon, 16 Mar 2009 19:01:32 +0100
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	mingo@...e.hu, rusty@...tcorp.com.au, tglx@...utronix.de,
	x86@...nel.org, linux-kernel@...r.kernel.org, hpa@...or.com,
	Paul Mundt <lethal@...ux-sh.org>, rmk@....linux.org.uk,
	starvik@...s.com, ralf@...ux-mips.org, davem@...emloft.net,
	cooloney@...nel.org, kyle@...artin.ca, matthew@....cx,
	grundler@...isc-linux.org, takata@...ux-m32r.org,
	benh@...nel.crashing.org, rth@...ddle.net,
	ink@...assic.park.msu.ru, heiko.carstens@...ibm.com
Subject: Re: [GIT RFC] percpu: use dynamic percpu allocator as the default
 percpu allocator

Hi Tejun,

On Tue, 10 Mar 2009 16:53:46 +0900
Tejun Heo <tj@...nel.org> wrote:

> The only differences are 1. there can be more space between percpu
> areas for each cpu to accomodate minimum allocation size and first
> chunk dynamic reserve and 2. dynamic percpu variables use the same
> address translation mechanism as static ones.
> 
> #1 shouldn't cause any trouble and #2 shouldn't too because the
> offsets for dynamic percpu variables are carried in full pointer-width
> variables, so as long as the calculations don't make wrong assumptions
> (should be masked by RELOC_HIDE), it should be okay, but if your arch
> has addressing limitations (alpha, s390), please take a second look.

We do have a problem with #2, the dynamic percpu patches currently
breaks s390. But the nice thing is that we can now get rid of the GOTENT
relocation for the percpu symbols. If the code is changed to use
RELOC_HIDE for the SHIFT_PERCPU_PTR define, everything works just fine.
Patch attached. Nice works guys.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

---
Subject: [PATCH] s390: percpu access.

From: Martin Schwidefsky <schwidefsky@...ibm.com>

With the dynamic percpu allocator there is no need anymore to play
tricks with the GOTENT relocation for the access to the percpu
symbols. A simple RELOC_HIDE gets the job done.

Signed-off-by: Martin Schwidefsky <schwidefsky@...ibm.com>
---

 arch/s390/include/asm/percpu.h |   26 +-------------------------
 1 file changed, 1 insertion(+), 25 deletions(-)

diff -urpN linux-next/arch/s390/include/asm/percpu.h linux-patched/arch/s390/include/asm/percpu.h
--- linux-next/arch/s390/include/asm/percpu.h	2009-03-16 18:53:47.000000000 +0100
+++ linux-patched/arch/s390/include/asm/percpu.h	2009-03-16 18:53:35.000000000 +0100
@@ -4,31 +4,7 @@
 #include <linux/compiler.h>
 #include <asm/lowcore.h>
 
-/*
- * s390 uses its own implementation for per cpu data, the offset of
- * the cpu local data area is cached in the cpu's lowcore memory.
- * For 64 bit module code s390 forces the use of a GOT slot for the
- * address of the per cpu variable. This is needed because the module
- * may be more than 4G above the per cpu area.
- */
-#if defined(__s390x__) && defined(MODULE)
-
-#define SHIFT_PERCPU_PTR(ptr,offset) (({			\
-	extern int simple_identifier_##var(void);	\
-	unsigned long *__ptr;				\
-	asm ( "larl %0, %1@...ENT"		\
-	    : "=a" (__ptr) : "X" (ptr) );		\
-	(typeof(ptr))((*__ptr) + (offset));	}))
-
-#else
-
-#define SHIFT_PERCPU_PTR(ptr, offset) (({				\
-	extern int simple_identifier_##var(void);		\
-	unsigned long __ptr;					\
-	asm ( "" : "=a" (__ptr) : "0" (ptr) );			\
-	(typeof(ptr)) (__ptr + (offset)); }))
-
-#endif
+#define SHIFT_PERCPU_PTR(var, offset) RELOC_HIDE(&per_cpu_var(var), (offset))
 
 #define __my_cpu_offset S390_lowcore.percpu_offset
 
--
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/