linux-kernel - Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"

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:	Sun, 01 Apr 2007 00:15:51 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jurriaan <thunder7@...all.nl>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Helge Hafting <helgehaf@...el.hist.no>,
	linux-kernel@...r.kernel.org, Vivek Goyal <vgoyal@...ibm.com>
Subject: Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"

thunder7@...all.nl writes:

> I had the same with this .config from 2.6.21-rc3-mm2 after running 'make
> oldconfig' and answering N to all new questions. Then, I tweaked some
> items, mostly to see if there was an 'align kernel' item in there
> somewhere. Diff between _working_ 2.6.21-rc5-mm3 .config and this
> 2.6.21-rc3-mm2 .config at the end. Somehow that seems to have adapted
> 'CONFIG_PHYSICAL_START', maybe that's it?

That looks like it.

Does anyone know how to express the constraint of a 2M aligned number in Kconfig?

The original plan was to remove CONFIG_PHYSICAL_START and CONFIG_RELOCATABLE on
x86_64 because after this series they have no cost and thus just lead to a little
more confusion.

However because we don't tag vmlinux as ET_DYN and Xen has some use for kernel
built at different physical addresses (or at least loaded at them), and because
Xen directly loads vmlinux he kept those options.

If we can find a place to stick it into the build doing a little post processing
of vmlinux so that it has the proper ELF header type (ET_DYN not ET_EXEC) would
be useful and allow us to remove those extra confusing options.

If I have a spare moment I will take a look.  Since there is confusion it is
probably worth removing the unnecessary confusing options if we can instead
of supporting the full confusion.

Doing the same for i386 would be a little harder but with Dave
Miller's suggestions for Xen and leaving the functions to be replaced
unlinked so the compiler generates efficient calls and then doing
linking magic to fill in the pieces at boot looks about as tricky as
moving the relocation logic for i386 into vmlinux as well.  So it
seems feasible and possibly worth doing.

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