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:	Wed, 30 Jan 2008 21:59:15 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Mike Travis <travis@....com>,
	Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Development <linux-kernel@...r.kernel.org>,
	Linux/PPC Development <linuxppc-dev@...abs.org>,
	linux-ia64@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: x86/non-x86: percpu, node ids, apic ids x86.git fixup


* Luck, Tony <tony.luck@...el.com> wrote:

> > could you send the .config you are using?
> 
> Ok.  Attached.

thanks a ton - this produced a link error here too.

after half an hour of head scratching, the updated patch below solves 
the build problem.

The problem i believe is this code in arch/ia64/kernel/mca_asm.S:

#define GET_IA64_MCA_DATA(reg)                                          \
        GET_THIS_PADDR(reg, ia64_mca_data)                              \
        ;;                                                              \
        ld8 reg=[reg]

this i believe builds an implicit dependency between the mca_asm.o 
position within the image and the ia64_mca_data percpu variable it 
accesses - it relies on the immediate 22 addressing mode that has 4MB of 
scope. Per chance, the .config you sent creates a 14MB image, and the 
percpu variables moved too far away for the linker to be able to fulfill 
this constraint.

The workaround is to define PER_CPU_ATTRIBUTES to link percpu variables 
back into the .percpu section on UP too - which ia64 links specially 
into its vmlinux.lds. But ultimately i think the better solution would 
be to remove this dependency between arch/ia64/kernel/mca_asm.S and the 
position of the percpu data.

Is my analysis correct? Do you like my fix and does the patch build and 
boot on your system? Thanks,

	Ingo

--------------->
Subject: ia64: on UP percpu variables are not small memory model
From: Ingo Molnar <mingo@...e.hu>

Tony says:

| The CONFIG_SMP=n path in ia64 makes quite radical changes ... rather
| than putting all the per-cpu stuff into the top 64K of address space
| and providing a per-cpu TLB mapping for that range to a different
| physical address ... it just makes all the per-cpu stuff link as ordinary
| variables in .data.

the new generic percpu code got confused about this as PER_CPU_ATTRIBUTES
was defined even on UP, so it picked up that small memory model - which
was not possible to get linked. The right fix is to only define that
on SMP. This resolved the build failures in my cross-compiling environment.

also link these variables into the .percpu section - some assembly code 
has offset dependencies.

Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
 include/asm-ia64/percpu.h |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: linux-x86.q/include/asm-ia64/percpu.h
===================================================================
--- linux-x86.q.orig/include/asm-ia64/percpu.h
+++ linux-x86.q/include/asm-ia64/percpu.h
@@ -15,18 +15,20 @@
 
 #include <linux/threads.h>
 
+#ifdef CONFIG_SMP
+
 #ifdef HAVE_MODEL_SMALL_ATTRIBUTE
 # define PER_CPU_ATTRIBUTES	__attribute__((__model__ (__small__)))
 #endif
 
-#ifdef CONFIG_SMP
-
 #define __my_cpu_offset	__ia64_per_cpu_var(local_per_cpu_offset)
 
 extern void *per_cpu_init(void);
 
 #else /* ! SMP */
 
+#define PER_CPU_ATTRIBUTES	__attribute__((__section__(".data.percpu")))
+
 #define per_cpu_init()				(__phys_per_cpu_start)
 
 #endif	/* SMP */
--
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