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, 7 Mar 2010 13:38:20 -0500 (EST)
From:	Tim Abbott <tabbott@...lice.com>
To:	Michael Schmitz <schmitz@...phys.uni-duesseldorf.de>
cc:	Andreas Schwab <schwab@...ux-m68k.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-m68k@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: "m68k: Cleanup linker scripts using new linker script macros."
 and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has
 a new email address)

Has this fix been merged yet?  It seems to me that the patch Michael sent 
is a totally reasonable solution to this problem, and I had assumed that 
it was going to get picked up in the m68k tree when I saw this patch 2 
months ago...

	-Tim Abbott

On Mon, 11 Jan 2010, Michael Schmitz wrote:

> Followup on this: You are absolutely right - the problem appears to be related 
> to the the .init_end section _only_ having the ALIGN, and nothing else (i.e. 
> no actual section content). 
> 
> Placing the align in the .m68k_fixup section like such:
> 
> --- arch/m68k/kernel/vmlinux-std.lds.org	2010-01-09 11:01:05.000000000 
> +1300
> +++ arch/m68k/kernel/vmlinux-std.lds	2010-01-12 08:43:07.000000000 +1300
> @@ -42,6 +42,7 @@
>  	__start_fixup = .;
>  	*(.m68k_fixup)
>  	__stop_fixup = .;
> +        . = ALIGN(PAGE_SIZE);
>    }
>    NOTES
>    .init_end : {
> 
> still puts .init_end, __init_end and _end on a page boundary, but also extends
> the load section up to that page boundary. (Unfortunately, it also extends the 
> kernel file size by a bit). 
> 
> Can the same be achieved in a more elegant way? The reason why the old script 
> worked with my binutils appears to be the placement of the initramfs data right 
> at the end - the start of initramfs is page aligned, and the size of the 
> initramfs is an integer number of pages, so the end of initramfs data, 
> __init_end and _end all are on a page boundary. With the fixup section now 
> placed after the initramfs explicitly, this no longer happens by accident...
> 
> Cheers,
> 
> 	Michael
> 
> 
> 
--
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