From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: 2.6.6-rc3-mm2
Date: Wed, 5 May 2004 19:59:13 +0200 [thread overview]
Message-ID: <200405051959.13907.arnd@arndb.de> (raw)
In-Reply-To: <20040505163320.A4250@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 3551 bytes --]
On Wednesday 05 May 2004 17:33, Christoph Hellwig wrote:
> On Wed, May 05, 2004 at 01:31:35AM -0700, Andrew Morton wrote:
> >static-define_per_cpu-vs-modules-2.patch
> >
> > Work around relative address displacement problems on s390.
>
> I'm not happy with this one. It prevents perfectly valid optimizations
> that become more important with modern compilers because of s390 brokenness.
>
> Of the options listed in the patch description (why the heck didn't it ever
> make it to a mailinglist??) the options to avoid the static effect in s390
> code looks most appealing but hard to implement to me, and if it doesn't
> work out we'll probably have to do the STATIC_DEFINE_PER_CPU variant.
When I prepared that patch, I was certain that the bug was not s390
specific, as it now turned out to be. The reason is that only on s390, the
kernel virtual address space for builtin code is the same as the physical
address space while modules are loaded to the vmalloc area, which may be >32
bit apart.
For exported symbols, we work around this by compiling modules with -fpic,
which does not work for per_cpu relocations.
Martin was now able to do a similar workaround for these by loading the
address through inline assembly without affecting the other architectures,
following a suggestion by Richard Henderson. This is his patch:
Force the use of a 64 bit relocation to access the per_cpu__##var
variables and fix a problem in the module loader regarding GOTENT and
GOTPLTENT relocs.
diff -urN linux-2.6/arch/s390/kernel/module.c linux-2.6-s390/arch/s390/kernel/module.c
--- linux-2.6/arch/s390/kernel/module.c Sun Apr 4 05:38:13 2004
+++ linux-2.6-s390/arch/s390/kernel/module.c Wed May 5 19:40:22 2004
@@ -277,7 +277,8 @@
*(unsigned int *) loc = val;
else if (r_type == R_390_GOTENT ||
r_type == R_390_GOTPLTENT)
- *(unsigned int *) loc = val >> 1;
+ *(unsigned int *) loc =
+ (val + (Elf_Addr) me->module_core - loc) >> 1;
else if (r_type == R_390_GOT64 ||
r_type == R_390_GOTPLT64)
*(unsigned long *) loc = val;
diff -urN linux-2.6/include/asm-s390/percpu.h linux-2.6-s390/include/asm-s390/percpu.h
--- linux-2.6/include/asm-s390/percpu.h Sun Apr 4 05:38:20 2004
+++ linux-2.6-s390/include/asm-s390/percpu.h Wed May 5 19:40:22 2004
@@ -5,10 +5,26 @@
#include <asm/lowcore.h>
/*
- * s390 uses the generic implementation for per cpu data, with the exception that
- * the offset of the cpu local data area is cached in the cpu's lowcore memory
+ * For builtin kernel code s390 uses the generic implementation for
+ * per cpu data, with the exception that 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 __get_got_cpu_var(var,offset) \
+ (*({ unsigned long *__ptr; \
+ asm ( "larl %0,per_cpu__"#var"@GOTENT" : "=a" (__ptr) ); \
+ ((typeof(&per_cpu__##var))((*__ptr) + offset)); \
+ }))
+#undef __get_cpu_var
+#define __get_cpu_var(var) __get_got_cpu_var(var,S390_lowcore.percpu_offset)
+#undef per_cpu
+#define per_cpu(var,cpu) __get_got_cpu_var(var,__per_cpu_offset[cpu])
+#else
#undef __get_cpu_var
#define __get_cpu_var(var) (*RELOC_HIDE(&per_cpu__##var, S390_lowcore.percpu_offset))
+#endif
#endif /* __ARCH_S390_PERCPU__ */
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-05-05 17:59 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-05 8:31 2.6.6-rc3-mm2 Andrew Morton
2004-05-05 8:46 ` 2.6.6-rc3-mm2 Fabio Coatti
2004-05-05 9:07 ` 2.6.6-rc3-mm2 Onur Kucuk
2004-05-05 11:12 ` 2.6.6-rc3-mm2 (4KSTACK) Dominik Karall
2004-05-05 11:10 ` Ralf Hildebrandt
2004-05-05 11:13 ` Jan-Benedict Glaw
2004-05-05 11:24 ` Arjan van de Ven
2004-05-05 11:30 ` Andrew Morton
2004-05-05 12:09 ` Rene Herman
2004-05-05 16:47 ` Steve Lord
2004-05-05 18:48 ` Felipe Alfaro Solana
2004-05-05 19:51 ` Arjan van de Ven
2004-05-05 19:56 ` Steve Lord
2004-05-05 19:59 ` Arjan van de Ven
2004-05-06 17:44 ` Max Valdez
2004-05-05 20:31 ` Bill Davidsen
2004-05-05 23:04 ` Bartlomiej Zolnierkiewicz
2004-05-06 12:55 ` Norberto Bensa
2004-05-06 13:33 ` Bartlomiej Zolnierkiewicz
2004-05-06 18:47 ` Norberto Bensa
2004-05-09 17:00 ` Bill Davidsen
2004-05-09 18:25 ` Bartlomiej Zolnierkiewicz
2004-05-11 16:24 ` Bill Davidsen
2004-05-11 23:27 ` Bartlomiej Zolnierkiewicz
2004-05-11 23:50 ` Andrew Morton
2004-05-12 0:05 ` Valdis.Kletnieks
2004-05-12 16:07 ` Bill Davidsen
2004-05-12 16:20 ` Arjan van de Ven
2004-05-15 19:48 ` Bill Davidsen
2004-05-06 10:09 ` Helge Hafting
2004-05-06 12:54 ` Bill Davidsen
2004-05-05 18:22 ` Valdis.Kletnieks
2004-05-05 21:51 ` Jörn Engel
2004-05-06 15:18 ` Valdis.Kletnieks
2004-05-06 15:40 ` Arjan van de Ven
2004-05-06 16:29 ` Valdis.Kletnieks
2004-05-07 9:50 ` Helge Hafting
2004-05-07 0:37 ` Paul Jakma
2004-05-07 2:50 ` Andrew Morton
2004-05-07 3:44 ` Paul Jakma
2004-05-07 3:58 ` Andrew Morton
2004-05-07 7:05 ` Arjan van de Ven
2004-05-07 15:26 ` Martin J. Bligh
2004-05-07 19:41 ` Andrew Morton
2004-05-07 6:51 ` Arjan van de Ven
2004-05-07 15:13 ` Dave Jones
2004-05-07 15:47 ` Steve Lord
2004-05-07 15:59 ` Arjan van de Ven
2004-05-07 16:09 ` J. Bruce Fields
2004-05-07 16:11 ` Steve Lord
2004-05-07 16:28 ` Jörn Engel
2004-05-07 19:45 ` Paul Jakma
2004-05-07 19:48 ` Paul Jakma
2004-05-10 19:49 ` Bill Davidsen
2004-05-10 20:31 ` Horst von Brand
2004-05-11 2:39 ` Andrew Morton
2004-05-11 8:45 ` Helge Hafting
2004-05-11 17:59 ` several messages Bill Davidsen
2004-05-06 16:03 ` 2.6.6-rc3-mm2 (4KSTACK) Malte Schröder
2004-05-06 16:13 ` Valdis.Kletnieks
2004-05-06 17:05 ` Matt Mackall
2004-05-05 13:31 ` 2.6.6-rc3-mm2 [delete-posix-...-unifix-message] Paul Jackson
2004-05-05 15:33 ` 2.6.6-rc3-mm2 Christoph Hellwig
2004-05-05 17:59 ` Arnd Bergmann [this message]
2004-05-05 16:06 ` 2.6.6-rc3-mm2 Paul Jackson
2004-05-05 16:40 ` 2.6.6-rc3-mm2 Christoph Hellwig
2004-05-05 16:49 ` 2.6.6-rc3-mm2 Paul Jackson
2004-05-05 20:16 ` 2.6.6-rc3-mm2 R. J. Wysocki
2004-05-06 1:51 ` 2.6.6-rc3-mm2 Paul Jackson
2004-05-06 19:38 ` 2.6.6-rc3-mm2 R. J. Wysocki
2004-05-05 17:10 ` 2.6.6-rc3-mm2 (compile stats) John Cherry
2004-05-05 17:33 ` 2.6.6-rc3-mm2 [sparc, sparc64, mips syscall broken] Paul Jackson
2004-05-05 23:29 ` 2.6.6-rc3-mm2: vermagic compile error if CONFIG_MODULES=n Adrian Bunk
2004-05-06 14:53 ` 2.6.6-rc3-mm2 Antonio Dolcetta
2004-05-06 15:12 ` 2.6.6-rc3-mm2 Andrew Morton
2004-05-06 15:56 ` 2.6.6-rc3-mm2 Antonio Dolcetta
2004-05-06 17:26 ` 2.6.6-rc3-mm2 Adrian Bunk
2004-05-06 21:46 ` 2.6.6-rc3-mm2 Bruce Guenter
2004-05-07 2:52 ` 2.6.6-rc3-mm2 Andrew Morton
2004-05-07 4:16 ` 2.6.6-rc3-mm2 Rusty Russell
2004-05-07 16:05 ` 2.6.6-rc3-mm2 Bruce Guenter
2004-05-07 20:13 ` 2.6.6-rc3-mm2 R. J. Wysocki
2004-05-08 6:09 ` 2.6.6-rc3-mm2 Andrew Morton
[not found] ` <200405081329.43017.rjwysocki@sisk.pl>
2004-05-08 11:31 ` 2.6.6-rc3-mm2 Andrew Morton
2004-05-08 16:25 ` 2.6.6-rc3-mm2 R. J. Wysocki
2004-05-08 11:43 ` 2.6.6-rc3-mm2 Andrew Morton
2004-05-08 12:16 ` 2.6.6-rc3-mm2 R. J. Wysocki
2004-05-08 16:59 ` 2.6.6-rc3-mm2 Bruce Guenter
2004-05-08 18:46 ` 2.6.6-rc3-mm2 Andrew Morton
2004-05-08 18:31 ` 2.6.6-rc3-mm2 Joseph Fannin
-- strict thread matches above, loose matches on Subject: below --
2004-05-05 11:28 2.6.6-rc3-mm2 Oleg Nesterov
2004-05-05 12:17 ` 2.6.6-rc3-mm2 Oleg Nesterov
2004-05-05 15:59 ` 2.6.6-rc3-mm2 William Lee Irwin III
2004-05-05 17:17 ` 2.6.6-rc3-mm2 Oleg Nesterov
2004-05-05 19:10 2.6.6-rc3-mm2 Jan Killius
[not found] <fa.gcf87gs.1sjkoj6@ifi.uio.no>
[not found] ` <fa.freqmjk.11j6bhe@ifi.uio.no>
2004-05-08 19:29 ` 2.6.6-rc3-mm2 Andy Lutomirski
2004-05-09 13:32 ` 2.6.6-rc3-mm2 Andi Kleen
2004-05-09 22:16 ` 2.6.6-rc3-mm2 Rusty Russell
2004-05-10 5:40 ` 2.6.6-rc3-mm2 Andi Kleen
2004-05-10 10:48 ` 2.6.6-rc3-mm2 Rusty Russell
2004-05-10 9:59 ` 2.6.6-rc3-mm2 Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200405051959.13907.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox