All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Américo Wang" <xiyou.wangcong@gmail.com>
To: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: mmarek@suse.cz, Sam Ravnborg <sam@ravnborg.org>,
	Michael Holzheu <holzheu@linux.vnet.ibm.com>,
	tabbott@ksplice.com, vda.linux@googlemail.com,
	hpa@linux.intel.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, heiko.carstens@de.ibm.com,
	schwidefsky@de.ibm.com
Subject: Re: [PATCH 2/2] initramfs: Fix initramfs size calculation
Date: Wed, 1 Sep 2010 15:47:21 +0800	[thread overview]
Message-ID: <20100901074721.GA5671@cr0.nay.redhat.com> (raw)
In-Reply-To: <20100831083844.043619334@linux.vnet.ibm.com>

On Tue, Aug 31, 2010 at 10:23:09AM +0200, Hendrik Brueckner wrote:
>The size of a built-in initramfs is calculated in init/initramfs.c by 
>"__initramfs_end - __initramfs_start".  Those symbols are defined in the
>linker script include/asm-generic/vmlinux.lds.h:
>
>#define INIT_RAM_FS                                                     \
>        . = ALIGN(PAGE_SIZE);                                           \
>        VMLINUX_SYMBOL(__initramfs_start) = .;                          \
>        *(.init.ramfs)                                                  \
>        VMLINUX_SYMBOL(__initramfs_end) = .;
>
>If the initramfs file has an odd number of bytes, the "__initramfs_end"
>symbol points to an odd address, for example, the symbols in the System.map
>might look like:
>
>    0000000000572000 T __initramfs_start
>    00000000005bcd05 T __initramfs_end	  <-- odd address
>
>At least on s390 this causes a problem:
>
>Certain s390 instructions, especially instructions for loading addresses
>(larl) or branch addresses must be on even addresses. 
>The compiler loads the symbol addresses with the "larl" instruction. This
>instruction sets the last bit to 0 and, therefore, for odd size files, the
>calculated size is one byte less than it should be:
>
>    0000000000540a9c <populate_rootfs>:
>      540a9c:     eb cf f0 78 00 24       stmg    %r12,%r15,120(%r15),
>      540aa2:     c0 10 00 01 8a af       larl    %r1,572000 <__initramfs_start>
>      540aa8:     c0 c0 00 03 e1 2e       larl    %r12,5bcd04 <initramfs_end>
>                                                  (Instead of  5bcd05)
>      ...
>      540abe:     1b c1                   sr      %r12,%r1
>
>To fix the problem, this patch introduces the global variable
>__initramfs_size, which is calculated in the "usr/initramfs_data.S" file.
>The populate_rootfs() function can then use the start marker of the
>.init.ramfs section and the value of __initramfs_size for loading the
>initramfs.  Because the start marker and size is sufficient, the
>__initramfs_end symbol is no longer needed and is removed.
>
>Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
>Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>


This patch looks good for me too,

Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>

I think Michal will take this into kbuild tree.

Thanks!

  reply	other threads:[~2010-09-01  7:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-31  8:23 [PATCH 0/2] initramfs: Cleanup and fix initramfs size calculation Hendrik Brueckner
2010-08-31  8:23 ` [PATCH 1/2] initramfs: Generalize initramfs_data.xxx.S variants Hendrik Brueckner
2010-08-31  8:23 ` [PATCH 2/2] initramfs: Fix initramfs size calculation Hendrik Brueckner
2010-09-01  7:47   ` Américo Wang [this message]
2010-10-17 18:28   ` Mike Frysinger
2010-10-18 10:37     ` Hendrik Brueckner
2010-10-18 23:07       ` Mike Frysinger
2010-10-19 11:08         ` [PATCH] initramfs: Fix build break on symbol-prefixed archs Hendrik Brueckner
2010-10-19 20:11           ` Mike Frysinger
2010-10-19 21:31             ` Sam Ravnborg
2010-10-19 21:39               ` Mike Frysinger
2010-10-27 18:23                 ` Mike Frysinger
2010-10-27 22:46                   ` Michal Marek
2010-10-27 23:10                     ` Mike Frysinger
2010-10-27 23:33                       ` Michal Marek
2010-10-27 23:58                         ` Mike Frysinger
2010-10-28 12:08                           ` Michal Marek
2010-10-28 19:46                             ` Mike Frysinger
2010-10-28 19:51                               ` Mike Frysinger
2010-10-28 20:35                     ` Sam Ravnborg
2010-10-28 20:42                       ` Mike Frysinger
2010-10-28 20:53                         ` Mike Frysinger
2010-10-29  6:12                         ` Sam Ravnborg
2010-10-28 21:19                       ` Michal Marek
2010-11-13 23:17                         ` Mike Frysinger
2010-11-24  8:40                           ` Mike Frysinger
2010-11-29 22:38                             ` Andrew Morton
2010-11-29 23:29                               ` Mike Frysinger
2010-11-30 15:36                                 ` Michal Marek
2010-12-02  4:12                                   ` Mike Frysinger
2010-08-31 14:08 ` [PATCH 0/2] initramfs: Cleanup and fix initramfs size calculation Michal Marek
2010-09-07 21:25   ` H. Peter Anvin

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=20100901074721.GA5671@cr0.nay.redhat.com \
    --to=xiyou.wangcong@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=brueckner@linux.vnet.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=holzheu@linux.vnet.ibm.com \
    --cc=hpa@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=sam@ravnborg.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=tabbott@ksplice.com \
    --cc=vda.linux@googlemail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.