1. 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
  2. 17 12月, 2010 1 次提交
  3. 26 8月, 2010 1 次提交
  4. 13 8月, 2010 1 次提交
  5. 11 8月, 2010 2 次提交
  6. 10 8月, 2010 1 次提交
  7. 03 8月, 2010 1 次提交
  8. 08 7月, 2010 1 次提交
  9. 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
  10. 19 5月, 2010 1 次提交
    • O
      MODULE_DEVICE_TABLE(isapnp, ...) does nothing · fedb3d27
      Ondrej Zary 提交于
      On Monday 23 November 2009 04:29:53 Rusty Russell wrote:
      > On Mon, 23 Nov 2009 07:31:57 am Ondrej Zary wrote:
      > > The problem is that
      > > scripts/mod/file2alias.c simply ignores isapnp.
      >
      > AFAICT it always has, and noone has complained until now.  Perhaps
      > something was still reading /lib/modules/`uname -r`/modules.isapnpmap?
      
      The patch below works fine (at least with Debian). It needs your first
      patch that moves the definitions to mod_devicetable.h. Verified that
      aliases for these modules are generated correctly:
      
      drivers/media/radio/radio-sf16fmi.c
      drivers/net/ne.c
      drivers/net/3c515.c
      drivers/net/smc-ultra.c
      drivers/pcmcia/i82365.c
      drivers/scsi/aha1542.c
      drivers/scsi/aha152x.c
      drivers/scsi/sym53c416.c
      drivers/scsi/g_NCR5380.c
      
      Tested with RTL8019AS (ne), AVA-1505AE (aha152x) and dtc436e (g_NCR5380)
      cards - they now work automatically.
      
      Generate pnp:d aliases for isapnp_device_tables. This allows udev to load
      these modules automatically.
      Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      fedb3d27
  11. 18 5月, 2010 1 次提交
  12. 03 4月, 2010 1 次提交
  13. 31 1月, 2010 4 次提交
  14. 30 1月, 2010 3 次提交
  15. 18 1月, 2010 1 次提交
    • M
      modpost: fix segfault in sym_is() with prefixed arches · 3a5dd791
      Mike Frysinger 提交于
      The sym_is() compares a symbol in an attempt to automatically skip symbol
      prefixes.  It does this first by searching the real symbol with the normal
      unprefixed symbol.  But then it uses the length of the original symbol to
      check the end of the substring instead of the length of the symbol it is
      looking for.  On non-prefixed arches, this is effectively the same thing,
      so there is no problem.  On prefixed-arches, since this is exceeds by just
      one byte, a crash is rare and it is usually a NUL byte anyways.  But every
      once in a blue moon, you get the right page alignment and it segfaults.
      
      For example, on the Blackfin arch, sym_is() will be called with the real
      symbol "___mod_usb_device_table" as "symbol" when looking for the normal
      symbol "__mod_usb_device_table" as "name".  The substring will thus return
      one byte into "symbol" and store it into "match".  But then "match" will
      be indexed with the length of "symbol" instead of "name" and so we will
      exceed the storage.  i.e. the code ends up doing:
      	char foo[] = "abc"; return foo[strlen(foo)+1] == '\0';
      Signed-off-by: NMike Frysinger <vapier@gentoo.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3a5dd791
  16. 15 12月, 2009 3 次提交
  17. 12 12月, 2009 2 次提交
    • N
      USB: handle bcd incrementation in usb modalias generation · 55f49f26
      Nathaniel McCallum 提交于
      This patch fixes a bug when incrementing/decrementing on a BCD formatted
      integer (i.e. 0x09++ should be 0x10 not 0x0A).  It just adds a function
      for incrementing/decrementing BCD integers by converting to decimal,
      doing the increment/decrement and then converting back to BCD.
      Signed-off-by: NNathaniel McCallum <nathaniel@natemccallum.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      55f49f26
    • N
      USB: add hex/bcd detection to usb modalias generation · afe2dab4
      Nathaniel McCallum 提交于
      The current code to generate usb modaliases from usb_device_id assumes
      that the device's bcdDevice descriptor will actually be in BCD format.
      While this should be a sane assumption, some devices don't follow spec
      and just use plain old hex.  This causes drivers for these devices to
      generate invalid modalias lines which will never actually match for the
      hardware.
      
      The following patch adds hex support for bcdDevice in file2alias.c by
      detecting when a driver uses a hex formatted bcdDevice_(lo|hi) and
      adjusts the output to hex format accordingly.
      
      Drivers for devices which have bcdDevice conforming to BCD will have no
      change in modalias output.  Drivers for devices which don't conform
      (i.e. ibmcam) should now generate valid modaliases.
      
      EXAMPLE OUTPUT (ibmcam; space added to highlight change)
          Old: usb:v0545p800D d030[10-9] dc*dsc*dp*ic*isc*ip*
          New: usb:v0545p800D d030a      dc*dsc*dp*ic*isc*ip*
      Signed-off-by: NNathaniel McCallum <nathaniel@natemccallum.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      afe2dab4
  18. 23 9月, 2009 3 次提交
  19. 21 9月, 2009 1 次提交
  20. 12 6月, 2009 1 次提交
  21. 10 6月, 2009 2 次提交
  22. 04 5月, 2009 3 次提交
  23. 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
  24. 28 4月, 2009 1 次提交