Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 23 5月, 2012 2 次提交
  3. 10 4月, 2012 1 次提交
    • F
      modpost: Fix modpost license checking of vmlinux.o · 258f7426
      由 Frank Rowand 提交于 
      Commit f02e8a65 ("module: Sort exported symbols") sorts symbols
placing each of them in its own elf section.  This sorting and merging
into the canonical sections are done by the linker.

Unfortunately modpost to generate Module.symvers file parses vmlinux.o
(which is not linked yet) and all modules object files (which aren't
linked yet).  These aren't sanitized by the linker yet.  That breaks
modpost that can't detect license properly for modules.

This patch makes modpost aware of the new exported symbols structure.

[ This above is a slightly corrected version of the explanation of the
  problem, copied from commit 62a26356 ("modpost: Fix modpost's
  license checking V3").  That commit fixed the problem for module
  object files, but not for vmlinux.o.  This patch fixes modpost for
  vmlinux.o. ]
Signed-off-by: NFrank Rowand <frank.rowand@am.sony.com>
Signed-off-by: NAlessio Igor Bogani <abogani@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      258f7426
  5. 27 3月, 2012 1 次提交
  7. 15 2月, 2012 1 次提交
  9. 07 11月, 2011 1 次提交
  11. 24 7月, 2011 1 次提交
    • A
      modpost: Fix modpost's license checking V3 · 62a26356
      由 Alessio Igor Bogani 提交于 
      The commit f02e8a65 sorts symbols placing each of them in its own elf section.
The sorting and merging into the canonical sections are done by the linker.
Unfortunately modpost to generate Module.symvers file parses vmlinux
(already linked) and all modules object files (which aren't linked yet).
These aren't sanitized by the linker yet. That breaks modpost that can't
detect license properly for modules. This patch makes modpost aware of
the new exported symbols structure.

Thanks to Arnaud Lacombe <lacombar@gmail.com> and Anders Kaseorg
<andersk@ksplice.com> for providing useful suggestions about code.

This work was supported by a hardware donation from the CE Linux Forum.
Reported-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAlessio Igor Bogani <abogani@kernel.org>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      62a26356
  13. 19 5月, 2011 1 次提交
  15. 17 3月, 2011 1 次提交
    • R
      modpost: fix trailing comma · 00759c0e
      由 Randy Dunlap 提交于 
      Consolidate locations that print a section whitelist into
calls to print_section_list().

Fix print_section_list() so that it does not print a trailing
comma & space:

If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,

becomes:
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>
      00759c0e
  17. 28 12月, 2010 1 次提交
    • O
      modpost: Fix address calculation in reloc_location() · 731ece41
      由 Olof Johansson 提交于 
      This patch fixes a segfault in modpost that is observed when the gold
linker is used to link the input objects.

The problem is that reloc_location (modpost.c) is computing the
address of the relocation target incorrectly. Here, elf->hdr points
to the beginning of the ELF file in memory, sechdr points to the
relocation section header, section is the index of the section
being relocated, and sechdrs[section].sh_offset would be the offset
of that section, relative to the beginning of the ELF file. Adding
elf->hdr + sechdrs[section].sh_offset gives you the address of the
beginning of the section, and adding r->r_offset to that gives you the
address of the location to be relocated. You do not need to subtract
sechdrs[section].sh_addr from that -- the result of this is an address
outside the file, and causes the segfault when addend_386_rel tries to
dereference it.

This bug is not observed when GNU ld is used to link the inputs. The
object file ubuntu/omnibook/omnibook.o is the result of an ld -r of
several other files.  When GNU ld does an ld -r, it sets the vaddr
field for each section to 0, but gold lays out the section addresses
sequentially instead:

Section Headers:
 [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
 [ 0]                   NULL            00000000 000000 000000 00      0   0  0
 [ 1] .text             PROGBITS        00000000 000034 004794 00  AX  0   0  4
 [ 2] .data             PROGBITS        0000b9d0 0047c8 0009c0 00  WA  0   0  4
 [ 3] .bss              NOBITS          000162f8 005188 00013c 00  WA  0   0  4
 [ 4] .rodata.str1.1    PROGBITS        00004f2d 0052c4 001b1a 01 AMS  0   0  1
 [ 5] .init.text        PROGBITS        00004794 006dde 0005fa 00  AX  0   0  1
 [ 6] .exit.text        PROGBITS        00004d8e 0073d8 00018a 00  AX  0   0  1
  ...

So the bug in the tool remained undiscovered because the section's vaddr
always happened to be 0.
Signed-off-by: NRaymes Khoury <raymes@google.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NMichal Marek <mmarek@suse.cz>
      731ece41
  19. 17 12月, 2010 1 次提交
  21. 02 11月, 2010 1 次提交
  23. 26 8月, 2010 1 次提交
  25. 13 8月, 2010 1 次提交
  27. 11 8月, 2010 2 次提交
  29. 10 8月, 2010 1 次提交
  31. 03 8月, 2010 1 次提交
  33. 08 7月, 2010 1 次提交
  35. 12 6月, 2010 1 次提交
    • K
      kbuild: Fix modpost segfault · 1c938663
      由 Krzysztof Halasa 提交于 
      Alan <alan@clueserver.org> writes:

> program: /home/alan/GitTrees/linux-2.6-mid-ref/scripts/mod/modpost -o
> Module.symvers -S vmlinux.o
>
> Program received signal SIGSEGV, Segmentation fault.

It just hit me.
It's the offset calculation in reloc_location() which overflows:
        return (void *)elf->hdr + sechdrs[section].sh_offset +
               (r->r_offset - sechdrs[section].sh_addr);

E.g. for the first rodata r entry:
r->r_offset < sechdrs[section].sh_addr
and the expression in the parenthesis produces 0xFFFFFFE0 or something
equally wise.
Reported-by: NAlan <alan@clueserver.org>
Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
Tested-by: NAlan <alan@clueserver.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>
      1c938663
  37. 31 1月, 2010 4 次提交
  39. 30 1月, 2010 3 次提交
  41. 15 12月, 2009 3 次提交
  43. 23 9月, 2009 1 次提交
  45. 10 6月, 2009 2 次提交
  47. 04 5月, 2009 3 次提交
  49. 01 5月, 2009 3 次提交
    • A
      kbuild, modpost: Check the section flags, to catch missing "ax"/"aw" · b614a697
      由 Anders Kaseorg 提交于 
      When you put
  .section ".foo"
in an assembly file instead of
  .section "foo", "ax"
, one of the possible symptoms is that modpost will see an
ld-generated section name ".foo.1" in section_rel() or section_rela().
But this heuristic has two problems: it will miss a bad section that
has no relocations, and it will incorrectly flag many gcc-generated
sections as bad when compiling with -ffunction-sections
-fdata-sections.

On mips it fixes a lot of bogus warnings with gcc 4.4.0 lije this one:
WARNING: crypto/cryptd.o (.text.T.349): unexpected section name.

So instead of checking whether the section name matches a particular
pattern, we directly check for a missing SHF_ALLOC in the section
flags.
Signed-off-by: NAnders Kaseorg <andersk@mit.edu>
Tested-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      b614a697
    • S
      kbuild: fix comment in modpost.c · c993971f
      由 Sam Ravnborg 提交于 
      There is some confusion on naming of the head section.
Correct naming is .head.text.

Fix comment so we use correct naming.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      c993971f
    • C
      kbuild: fix Module.markers permission error under cygwin · 99e3a1eb
      由 Cedric Hombourger 提交于 
      While building the kernel, we end-up calling modpost with -K and -M
options for the same file (Modules.markers).  This is resulting in
modpost's main function calling read_markers() and then write_markers() on
the same file.

We then have read_markers() mmap'ing the file, and writer_markers()
opening that same file for writing.

The issue is that read_markers() exits without munmap'ing the file and is
as a matter holding a reference on Modules.markers.  When write_markers()
is opening that very same file for writing, we still have a reference on
it and cygwin (Windows?) is then making fopen() fail with EPERM.

Calling release_file() before exiting read_markers() clears that reference
(and memory leak) and fopen() then succeeds.

Tested on both cygwin (1.3.22) and Linux.  Also ran modpost within
valgrind on Linux to make sure that the munmap'ed file was not accessed
after read_markers()
Signed-off-by: NCedric Hombourger <chombourger@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      99e3a1eb
  51. 28 4月, 2009 1 次提交