1. 12 Jan, 2011 28 commits
  2. 02 Jan, 2011 2 commits
  3. 29 Dec, 2010 1 commit
  4. 18 Dec, 2010 3 commits
  5. 17 Dec, 2010 6 commits
    • Chris Metcalf's avatar
      arch/tile: handle rt_sigreturn() more cleanly · 81711cee
      Chris Metcalf authored
      The current tile rt_sigreturn() syscall pattern uses the common idiom
      of loading up pt_regs with all the saved registers from the time of
      the signal, then anticipating the fact that we will clobber the ABI
      "return value" register (r0) as we return from the syscall by setting
      the rt_sigreturn return value to whatever random value was in the pt_regs
      for r0.
      
      However, this breaks in our 64-bit kernel when running "compat" tasks,
      since we always sign-extend the "return value" register to properly
      handle returned pointers that are in the upper 2GB of the 32-bit compat
      address space.  Doing this to the sigreturn path then causes occasional
      random corruption of the 64-bit r0 register.
      
      Instead, we stop doing the crazy "load the return-value register"
      hack in sigreturn.  We already have some sigreturn-specific assembly
      code that we use to pass the pt_regs pointer to C code.  We extend that
      code to also set the link register to point to a spot a few instructions
      after the usual syscall return address so we don't clobber the saved r0.
      Now it no longer matters what the rt_sigreturn syscall returns, and the
      pt_regs structure can be cleanly and completely reloaded.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      81711cee
    • Chris Metcalf's avatar
      arch/tile: handle CLONE_SETTLS in copy_thread(), not user space · bc4cf2bb
      Chris Metcalf authored
      Previously we were just setting up the "tp" register in the
      new task as started by clone() in libc.  However, this is not
      quite right, since in principle a signal might be delivered to
      the new task before it had its TLS set up.  (Of course, this race
      window still exists for resetting the libc getpid() cached value
      in the new task, in principle.  But in any case, we are now doing
      this exactly the way all other architectures do it.)
      
      This change is important for 2.6.37 since the tile glibc we will
      be submitting upstream will not set TLS in user space any more,
      so it will only work on a kernel that has this fix.  It should
      also be taken for 2.6.36.x in the stable tree if possible.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Cc: stable <stable@kernel.org>
      bc4cf2bb
    • Kevin Cernekee's avatar
      MIPS: Fix build errors in sc-mips.c · 081d835f
      Kevin Cernekee authored
      Seen with malta_defconfig on Linus' tree:
      
        CC      arch/mips/mm/sc-mips.o
      arch/mips/mm/sc-mips.c: In function 'mips_sc_is_activated':
      arch/mips/mm/sc-mips.c:77: error: 'config2' undeclared (first use in this function)
      arch/mips/mm/sc-mips.c:77: error: (Each undeclared identifier is reported only once
      arch/mips/mm/sc-mips.c:77: error: for each function it appears in.)
      arch/mips/mm/sc-mips.c:81: error: 'tmp' undeclared (first use in this function)
      make[2]: *** [arch/mips/mm/sc-mips.o] Error 1
      make[1]: *** [arch/mips/mm] Error 2
      make: *** [arch/mips] Error 2
      
      [Ralf: Cosmetic changes to minimize the number of arguments passed to
      mips_sc_is_activated]
      Signed-off-by: default avatarKevin Cernekee <cernekee@gmail.com>
      Patchwork: https://patchwork.linux-mips.org/patch/1752/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      081d835f
    • Bjorn Helgaas's avatar
      x86: avoid high BIOS area when allocating address space · a2c606d5
      Bjorn Helgaas authored
      This prevents allocation of the last 2MB before 4GB.
      
      The experiment described here shows Windows 7 ignoring the last 1MB:
      https://bugzilla.kernel.org/show_bug.cgi?id=23542#c27
      
      This patch ignores the top 2MB instead of just 1MB because H. Peter Anvin
      says "There will be ROM at the top of the 32-bit address space; it's a fact
      of the architecture, and on at least older systems it was common to have a
      shadow 1 MiB below."
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      a2c606d5
    • Bjorn Helgaas's avatar
      x86: avoid E820 regions when allocating address space · 4dc2287c
      Bjorn Helgaas authored
      When we allocate address space, e.g., to assign it to a PCI device, don't
      allocate anything mentioned in the BIOS E820 memory map.
      
      On recent machines (2008 and newer), we assign PCI resources from the
      windows described by the ACPI PCI host bridge _CRS.  On many Dell
      machines, these windows overlap some E820 reserved areas, e.g.,
      
          BIOS-e820: 00000000bfe4dc00 - 00000000c0000000 (reserved)
          pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]
      
      If we put devices at 0xbff00000, they don't work, probably because
      that's really RAM, not I/O memory.  This patch prevents that by removing
      the 0xbfe4dc00-0xbfffffff area from the "available" resource.
      
      I'm not very happy with this solution because Windows solves the problem
      differently (it seems to ignore E820 reserved areas and it allocates
      top-down instead of bottom-up; details at comment 45 of the bugzilla
      below).  That means we're vulnerable to BIOS defects that Windows would not
      trip over.  For example, if BIOS described a device in ACPI but didn't
      mention it in E820, Windows would work fine but Linux would fail.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=16228Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      4dc2287c
    • Bjorn Helgaas's avatar
      x86: avoid low BIOS area when allocating address space · 30919b0b
      Bjorn Helgaas authored
      This implements arch_remove_reservations() so allocate_resource() can
      avoid any arch-specific reserved areas.  This currently just avoids the
      BIOS area (the first 1MB), but could be used for E820 reserved areas if
      that turns out to be necessary.
      
      We previously avoided this area in pcibios_align_resource().  This patch
      moves the test from that PCI-specific path to a generic path, so *all*
      resource allocations will avoid this area.
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      30919b0b