Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 9月, 2011 2 次提交
  3. 26 9月, 2011 6 次提交
  5. 21 9月, 2011 3 次提交
    • R
      ARM: fix vmlinux.lds.S discarding sections · 6760b109
      由 Russell King 提交于 
      We are seeing linker errors caused by sections being discarded, despite
the linker script trying to keep them.  The result is (eg):

`.exit.text' referenced in section `.alt.smp.init' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.alt.smp.init' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o

This is the relevent part of the linker script (reformatted to make it
clearer):
| SECTIONS
| {
| /*
| * unwind exit sections must be discarded before the rest of the
| * unwind sections get included.
| */
| /DISCARD/ : {
| *(.ARM.exidx.exit.text)
| *(.ARM.extab.exit.text)
| }
| ...
| .exit.text : {
| *(.exit.text)
| *(.memexit.text)
| }
| ...
| /DISCARD/ : {
| *(.exit.text)
| *(.memexit.text)
| *(.exit.data)
| *(.memexit.data)
| *(.memexit.rodata)
| *(.exitcall.exit)
| *(.discard)
| *(.discard.*)
| }
| }

Now, this is what the linker manual says about discarded output sections:

|    The special output section name `/DISCARD/' may be used to discard
| input sections.  Any input sections which are assigned to an output
| section named `/DISCARD/' are not included in the output file.

No questions, no exceptions. It doesn't say "unless they are listed
before the /DISCARD/ section." Now, this is what asn-generic/vmlinux.lds.S
says:
| /*
|  * Default discarded sections.
|  *
|  * Some archs want to discard exit text/data at runtime rather than
|  * link time due to cross-section references such as alt instructions,
|  * bug table, eh_frame, etc. DISCARDS must be the last of output
|  * section definitions so that such archs put those in earlier section
|  * definitions.
|  */

And guess what - the list _always_ includes .exit.text etc.

Now, what's actually happening is that the linker is reading the script,
and it finds the first /DISCARD/ output section at the beginning of the
script. It continues reading the script, and finds the 'DISCARD' macro
at the end, which having been postprocessed results in another
/DISCARD/ output section. As the linker already contains the earlier
/DISCARD/ output section, it adds it to that existing section, so it
effectively is placed at the start. This can be seen by using the -M
option to ld:

| Linker script and memory map
|
|                 0xc037c080                jiffies = jiffies_64
|
| /DISCARD/
|  *(.ARM.exidx.exit.text)
|  *(.ARM.extab.exit.text)
|  *(.exit.text)
|  *(.memexit.text)
|  *(.exit.data)
|  *(.memexit.data)
|  *(.memexit.rodata)
|  *(.exitcall.exit)
|  *(.discard)
|  *(.discard.*)
|
|                 0xc0008000                . = 0xc0008000
|
| .head.text      0xc0008000      0x1d0
|                 0xc0008000                _text = .
|  *(.head.text)
|  .head.text     0xc0008000      0x1d0 arch/arm/kernel/head.o
|                 0xc0008000                stext
|
| .text           0xc0008200   0x2d78d0
|                 0xc0008200                _stext = .
|                 0xc0008200                __exception_text_start = .
|  *(.exception.text)
|  .exception.text
| ...

As you can see, all the discarded sections are grouped together - and
as a result of it being the first output section, they all appear before
any other section.

The result is that not only is the unwind information discarded (as
intended), but also the .exit.text, despite us wanting to have the
.exit.text preserved.

We can't move the unwind information elsewhere, because it'll then be
included even when we do actually discard the .exit.text (and similar)
sections.

So, work around this by avoiding the generic DISCARDS macro, and instead
conditionalize the sections to be discarded ourselves.  This avoids the
ambiguity in how the linker assigns input sections to output sections,
making our script less dependent on undocumented linker behaviour.
Reported-by: NRob Herring <robherring2@gmail.com>
Tested-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6760b109
    • L
      mach-integrator: fix VGA base regression · b71d8429
      由 Linus Walleij 提交于 
      The changes introduced in commit
cc22b4c1
"ARM: set vga memory base at run-time"

Makes the Integrator/AP freeze completely. I appears that
this is due to the VGA base address being assigned at PCI
init time, while this base is needed earlier than that.
Moving the initialization of the base address to the
.map_io function solves this problem.

Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      b71d8429
    • S
      arm/dt: Tegra: Update SDHCI nodes to match bindings · a0638eb6
      由 Stephen Warren 提交于 
      The bindings were recently updated to have separate properties for each
type of GPIO. Update the Device Tree source to match that.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      a0638eb6
  7. 20 9月, 2011 2 次提交
  9. 17 9月, 2011 2 次提交
  11. 16 9月, 2011 1 次提交
    • L
      asm alternatives: remove incorrect alignment notes · a7f934d4
      由 Linus Torvalds 提交于 
      On x86-64, they were just wasteful: with the explicitly added (now
unnecessary) padding, the size of the alternatives structure was 16
bytes, and an alignment of 8 bytes didn't hurt much.

However, it was still silly, since the natural size and alignment for
the structure is actually just 12 bytes, 4-byte aligned since commit
59e97e4d ("x86: Make alternative instruction pointers relative").
So removing the padding, and removing the extra alignment is just a good
idea.

On x86-32, the alignment of 4 bytes was correct, but was incorrectly
hardcoded as 8 bytes in <asm/alternative-asm.h>.  That header file had
used to be an x86-64 only header file, but various unification efforts
have made it be used for x86-32 too (ie the unification of rwlock and
rwsem).

That in turn caused x86-32 boot failures, because the extra alignment
would result in random zero-filled words in the altinstructions section,
causing oopses early at boot when doing alternative instruction
replacement.

So just remove all the alignment noise entirely.  It's wrong, and it's
unnecessary.  The section itself is already properly aligned by the
linker scripts, and all additions to the section had better be of the
proper 12-byte format, keeping it aligned.  So if the align directive
were to ever make a difference, that would be an indication of a serious
bug to begin with.
Reported-by: NWerner Landgraf <w.landgraf@ru.r>
Acked-by: NAndrew Lutomirski <luto@mit.edu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7f934d4
  13. 15 9月, 2011 19 次提交
  15. 14 9月, 2011 1 次提交
  17. 13 9月, 2011 1 次提交
    • D
      xen/e820: if there is no dom0_mem=, don't tweak extra_pages. · e3b73c4a
      由 David Vrabel 提交于 
      The patch "xen: use maximum reservation to limit amount of usable RAM"
(d312ae87) breaks machines that
do not use 'dom0_mem=' argument with:

reserve RAM buffer: 000000133f2e2000 - 000000133fffffff
(XEN) mm.c:4976:d0 Global bit is set to kernel page fffff8117e
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
...

The reason being that the last E820 entry is created using the
'extra_pages' (which is based on how many pages have been freed).
The mentioned git commit sets the initial value of 'extra_pages'
using a hypercall which returns the number of pages (if dom0_mem
has been used) or -1 otherwise. If the later we return with
MAX_DOMAIN_PAGES as basis for calculation:

    return min(max_pages, MAX_DOMAIN_PAGES);

and use it:

     extra_limit = xen_get_max_pages();
     if (extra_limit >= max_pfn)
             extra_pages = extra_limit - max_pfn;
     else
             extra_pages = 0;

which means we end up with extra_pages = 128GB in PFNs (33554432)
- 8GB in PFNs (2097152, on this specific box, can be larger or smaller),
and then we add that value to the E820 making it:

  Xen: 00000000ff000000 - 0000000100000000 (reserved)
  Xen: 0000000100000000 - 000000133f2e2000 (usable)

which is clearly wrong. It should look as so:

  Xen: 00000000ff000000 - 0000000100000000 (reserved)
  Xen: 0000000100000000 - 000000027fbda000 (usable)

Naturally this problem does not present itself if dom0_mem=max:X
is used.

CC: stable@kernel.org
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      e3b73c4a
  19. 11 9月, 2011 3 次提交