linux-kernel - RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

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]

Message-ID: <1FE6DD409037234FAB833C420AA843EC758076@orsmsx424.amr.corp.intel.com>
Date:	Wed, 30 Jan 2008 13:15:21 -0800
From:	"Luck, Tony" <tony.luck@...el.com>
To:	"Ingo Molnar" <mingo@...e.hu>
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

> 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.

Sounds very plausible.

> 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.

Yup.  That fixes the build ... the resulting binary doesn't boot though :-(
I just realized that it has been a while since I tried booting a UP
kernel ... so the problem may be unrelated bitrot elsewhere.

Overall you are right that the mca_asm.S code should not be dependent on
the relative location of the data objects.

I'll start digging on why this doesn't boot ... but you might as well
send the fixes so far upstream to Linus so that the SMP fix is available
(which is all anyone really cares about ... there are very, very few
UP ia64 systems in existence).

Acked-by: Tony Luck <tony.luck@...el.com>


-Tony
--
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/