1. 27 Dec, 2010 1 commit
    • Olof Johansson's avatar
      modpost: Fix address calculation in reloc_location() · 731ece41
      Olof Johansson authored
      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: default avatarRaymes Khoury <raymes@google.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      731ece41
  2. 22 Dec, 2010 1 commit
  3. 20 Dec, 2010 1 commit
  4. 16 Dec, 2010 1 commit
  5. 14 Dec, 2010 5 commits
  6. 02 Dec, 2010 1 commit
    • Thomas Chou's avatar
      gen_init_cpio: remove leading `/' from file names · 43f901fb
      Thomas Chou authored
      When we extracted the generated cpio archive using "cpio -id" command,
      it complained,
      
      cpio: Removing leading `/' from member names
      var/run
      cpio: Removing leading `/' from member names
      var/lib
      cpio: Removing leading `/' from member names
      var/lib/misc
      
      It is worse with the latest "cpio" or "pax", which tries to overwrite
      the host file system with the leading '/'.
      
      So the leading '/' of file names should be removed. This is consistent
      with the initramfs come with major distributions such as Fedora or
      Debian, etc.
      Signed-off-by: default avatarThomas Chou <thomas@wytron.com.tw>
      Acked-by: Mike Frysinger<vapier@gentoo.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      43f901fb
  7. 25 Nov, 2010 1 commit
  8. 11 Nov, 2010 1 commit
    • Eric Dumazet's avatar
      fixdep: use hash table instead of a single array · 8af27e1d
      Eric Dumazet authored
      I noticed fixdep uses ~2% of cpu time in kernel build, in function
      use_config()
      
      fixdep spends a lot of cpu cycles in linear searches in its internal
      string array. With about 400 stored strings per dep file, this begins to
      be noticeable.
      
      Convert fixdep to use a hash table.
      
      kbuild results on my x86_64 allmodconfig
      
      Before patch :
      
      real	10m30.414s
      user	61m51.456s
      sys	8m28.200s
      
      real	10m12.334s
      user	61m50.236s
      sys	8m30.448s
      
      real	10m42.947s
      user	61m50.028s
      sys	8m32.380s
      
      After:
      
      real	10m8.180s
      user	61m22.506s
      sys	8m32.384s
      
      real	10m35.039s
      user	61m21.654s
      sys	8m32.212s
      
      real	10m14.487s
      user	61m23.498s
      sys	8m32.312s
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      8af27e1d
  9. 01 Nov, 2010 10 commits
  10. 31 Oct, 2010 14 commits
  11. 30 Oct, 2010 4 commits