public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Reloc Kernel List <fastboot@lists.osdl.org>,
	ebiederm@xmission.com, ak@suse.de, horms@verge.net.au,
	lace@jankratochvil.net, hpa@zytor.com, magnus.damm@gmail.com,
	lwang@redhat.com, dzickus@redhat.com, maneesh@in.ibm.com,
	kraxel@suse.de
Subject: Re: [PATCH 1/12] i386: Distinguish absolute symbols
Date: Sun, 8 Oct 2006 12:47:13 -0400	[thread overview]
Message-ID: <20061008164713.GA7149@in.ibm.com> (raw)
In-Reply-To: <20061006233547.43888a48.akpm@osdl.org>

On Fri, Oct 06, 2006 at 11:35:47PM -0700, Andrew Morton wrote:
> On Tue, 3 Oct 2006 13:04:13 -0400
> Vivek Goyal <vgoyal@in.ibm.com> wrote:
> 
> > Ld knows about 2 kinds of symbols,  absolute and section
> > relative.  Section relative symbols symbols change value
> > when a section is moved and absolute symbols do not.
> > 
> > Currently in the linker script we have several labels
> > marking the beginning and ending of sections that
> > are outside of sections, making them absolute symbols.
> > Having a mixture of absolute and section relative
> > symbols refereing to the same data is currently harmless
> > but it is confusing.
> > 
> > This must be done carefully as newer revs of ld do not place
> > symbols that appear in sections without data and instead
> > ld makes those symbols global :(
> > 
> > My ultimate goal is to build a relocatable kernel.  The
> > safest and least intrusive technique is to generate
> > relocation entries so the kernel can be relocated at load
> > time.  The only penalty would be an increase in the size
> > of the kernel binary.  The problem is that if absolute and
> > relocatable symbols are not properly specified absolute symbols
> > will be relocated or section relative symbols won't be, which
> > is fatal.
> > 
> > The practical motivation is that when generating kernels that
> > will run from a reserved area for analyzing what caused
> > a kernel panic, it is simpler if you don't need to hard code
> > the physical memory location they will run at, especially
> > for the distributions.
> 
> This patch causes the following warnings:
> 
> /opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-ld: .tmp_vmlinux1: warning: allocated section `.smp_altinstr_replacement' not in segment
> /opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-ld: .tmp_vmlinux2: warning: allocated section `.smp_altinstr_replacement' not in segment
> /opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-ld: vmlinux: warning: allocated section `.smp_altinstr_replacement' not in segment
> 
> The patch
> i386-force-section-size-to-be-non-zero-to-prevent-a-symbol-becoming-absolute.patch
> makes those warnings go away again, but we decided to drop that.
> 
> This:
> 
>   .smp_altinstr_replacement : AT(ADDR(.smp_altinstr_replacement) - LOAD_OFFSET) {
> 	*(.smp_altinstr_replacement)
> 	. = ALIGN(4096);
> 	__smp_alt_end = .;
>   }
> 
> looks odd.  What's the point in putting a gap before __smp_alt_end?  Moving
> __smp_alt_end to before the ALIGN doesn't prevent the warning.
> 

Actually this ALIGN(4096) was already present present before symbol
__smp_alt_end that's why we kept it even when we moved __smp_alt_end
inside the section.

But now thinking about it, it looks like this ALIGN(4096) might not be
required. There is already one ALIGN(4086) present after this section
which should take care of protecting other data while this page is freed.

Please find attached a patch for the same. I am also copying Gerd Hoffmann,
who introduced this ALIGN. Gerd, can you please confirm that above ALIGN()
is not required and the patch attached should be fine.

As a side effect, above warning also disappears. Looks like there is no
data in the section .smp_altinstr_replacement but above ALIGN() forced
the linker to create a non-empty allocatable section. The type of the
section is NOBITS and probably that's why linker is emitting the warning.
I will write a separate mail to linker folks to find more about it.

Thanks
Vivek
  

o There seems to be one extra ALIGN(4096) before symbol __smp_alt_end. The
  only usage of __smp_alt_end is to mark the end of smp alternative
  sections so that this memory can be freed. As a physical page is freed
  one has to just make sure that there is no other data on the same page
  where __smp_alt_end is pointing. There is already a ALIGN(4096) after
  this section which should take care of the above issue. Hence it looks
  like the ALIGN(4096) before __smp_alt_end is redundant and not required.

Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---

 linux-2.6.19-rc1-vivek/arch/i386/kernel/vmlinux.lds.S |    1 -
 1 files changed, 1 deletion(-)

diff -puN arch/i386/kernel/vmlinux.lds.S~i386-remove-unnecessary-align-option arch/i386/kernel/vmlinux.lds.S
--- linux-2.6.19-rc1/arch/i386/kernel/vmlinux.lds.S~i386-remove-unnecessary-align-option	2006-10-08 12:33:05.000000000 -0400
+++ linux-2.6.19-rc1-vivek/arch/i386/kernel/vmlinux.lds.S	2006-10-08 12:33:05.000000000 -0400
@@ -112,7 +112,6 @@ SECTIONS
   }
   .smp_altinstr_replacement : AT(ADDR(.smp_altinstr_replacement) - LOAD_OFFSET) {
 	*(.smp_altinstr_replacement)
-	. = ALIGN(4096);
 	__smp_alt_end = .;
   }
 
_

  reply	other threads:[~2006-10-08 16:47 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-03 17:00 [RFC][PATCH 0/12] ELF Relocatable x86 bzImage (V2) Vivek Goyal
2006-10-03 17:04 ` [PATCH 1/12] i386: Distinguish absolute symbols Vivek Goyal
2006-10-07  6:35   ` Andrew Morton
2006-10-08 16:47     ` Vivek Goyal [this message]
2006-10-09  7:35       ` Gerd Hoffmann
2006-10-09 13:49         ` Vivek Goyal
2006-10-03 17:06 ` [PATCH 2/12] i386: align data section to 4K boundary Vivek Goyal
2006-10-04 11:17   ` Andi Kleen
2006-10-04 15:18     ` H. Peter Anvin
2006-10-03 17:09 ` [PATCH 3/12] i386: Force section size to be non-zero to prevent a symbol becoming absolute Vivek Goyal
2006-10-04 11:02   ` Andi Kleen
2006-10-04 14:07     ` Eric W. Biederman
2006-10-04 14:45       ` Vivek Goyal
2006-10-04 16:09   ` Andrew Morton
2006-10-04 16:14     ` Vivek Goyal
2006-10-03 17:10 ` [PATCH 4/12] i386: define __pa_symbol() Vivek Goyal
2006-10-04  8:26   ` Franck Bui-Huu
2006-10-04 19:44     ` Vivek Goyal
2006-10-06 13:10       ` Franck Bui-Huu
2006-10-06 18:33         ` Vivek Goyal
2006-10-03 17:12 ` [PATCH 5/12] i386 setup.c: Reserve kernel memory starting from _text Vivek Goyal
2006-10-03 17:15 ` [PATCH 6/12] i386: CONFIG_PHYSICAL_START cleanup Vivek Goyal
2006-10-03 18:45   ` Dave Hansen
2006-10-03 18:52     ` Vivek Goyal
2006-10-03 18:59     ` Eric W. Biederman
2006-10-03 19:35       ` Vivek Goyal
2006-10-03 17:17 ` [PATCH 7/12] Make linux/elf.h safe to be included in assembly files Vivek Goyal
2006-10-03 17:19 ` [PATCH 8/12] elf: Add ELFOSABI_STANDALONE to elf.h Vivek Goyal
2006-10-03 17:21 ` [PATCH 9/12] kallsyms: Generate relocatable symbols Vivek Goyal
2006-10-03 17:22 ` [PATCH 10/12] i386: Relocatable kernel support Vivek Goyal
2006-10-03 17:24 ` [PATCH 11/12] i386: Implement CONFIG_PHYSICAL_ALIGN Vivek Goyal
2006-10-03 17:25 ` [PATCH 12/12] i386 boot: Add an ELF header to bzImage Vivek Goyal
2006-10-04  3:13   ` Andrew Morton
2006-10-04  4:28     ` Vivek Goyal
2006-10-04  4:40       ` H. Peter Anvin
2006-10-04  8:04         ` Eric W. Biederman
2006-10-04 15:18           ` H. Peter Anvin
2006-10-05  4:12             ` Eric W. Biederman
2006-10-05  4:17               ` H. Peter Anvin
2006-10-04 20:22         ` Vivek Goyal
2006-10-04 20:27           ` H. Peter Anvin
2006-10-04 20:48             ` Vivek Goyal
2006-10-04 20:52               ` H. Peter Anvin
2006-10-04 21:06                 ` Vivek Goyal
2006-10-04 21:09                   ` H. Peter Anvin
2006-10-04  5:37       ` Andrew Morton
2006-10-05  4:06     ` Eric W. Biederman
2006-10-05  4:12       ` H. Peter Anvin
2006-10-05  4:44       ` Andrew Morton
2006-10-05  6:13         ` Eric W. Biederman
2006-10-05  6:31           ` Andrew Morton
2006-10-05  6:48             ` Eric W. Biederman
2006-10-05 21:54               ` Vivek Goyal
2006-10-05 15:25             ` H. Peter Anvin
2006-10-05 15:35               ` Eric W. Biederman
2006-10-05 15:29             ` Eric W. Biederman
2006-10-05 15:44               ` H. Peter Anvin
2006-10-06  6:59               ` Andrew Morton
2006-10-06 12:56                 ` Eric W. Biederman
2006-10-06 18:38                   ` Vivek Goyal
2006-10-06 18:54                     ` H. Peter Anvin
2006-10-06 19:09                       ` Eric W. Biederman
2006-10-06 21:54                         ` H. Peter Anvin
2006-10-09 14:33                           ` Vivek Goyal
2006-10-10  3:14                             ` Andrew Morton
2006-10-10  4:51                               ` Eric W. Biederman
2006-10-10 14:30                               ` Vivek Goyal
2006-10-10 18:46                                 ` Andrew Morton
2006-10-10 21:40                               ` Vivek Goyal
2006-10-11  2:35                                 ` Andrew Morton
2006-10-06 19:01                     ` Eric W. Biederman
2006-10-04  7:08   ` Eric W. Biederman
2006-10-04 14:23     ` Vivek Goyal
2006-10-05  3:09       ` Eric W. Biederman
2006-10-04 17:03     ` Vivek Goyal
2006-10-05  6:25       ` Eric W. Biederman
2006-10-05 21:34         ` Vivek Goyal

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=20061008164713.GA7149@in.ibm.com \
    --to=vgoyal@in.ibm.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=dzickus@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=fastboot@lists.osdl.org \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=kraxel@suse.de \
    --cc=lace@jankratochvil.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwang@redhat.com \
    --cc=magnus.damm@gmail.com \
    --cc=maneesh@in.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox