1. 19 May, 2009 5 commits
    • Rafael J. Wysocki's avatar
      PCI PM: Fix initialization and kexec breakage for some devices · b3bad72e
      Rafael J. Wysocki authored
      Recent PCI PM changes introduced a bug that causes some devices to be
      mishandled after kexec and during early initialization.  The failure
      scenario in the kexec case is the following:
      
      * Assume a PCI device is not power-manageable by the platform and has
        PCI_PM_CTRL_NO_SOFT_RESET set in PMCSR.
      * The device is put into D3 before kexec (using the native PCI PM).
      * After kexec, pci_setup_device() sets the device's power state to
        PCI_UNKNOWN.
      * pci_set_power_state(dev, PCI_D0) is called by the device's driver.
      * __pci_start_power_transition(dev, PCI_D0) is called and since the
        device is not power-manageable by the platform, it causes
        pci_update_current_state(dev, PCI_D0) to be called.  As a result
        the device's current_state field is updated to PCI_D3, in
        accordance with the contents of its PCI PM registers.
      * pci_raw_set_power_state() is called and it changes the device power
        state to D0.  *However*, it should also call pci_restore_bars() to
        reinitialize the device, but it doesn't, because the device's
        current_state field has been modified earlier.
      
      To prevent this from happening, modify pci_platform_power_transition()
      so that it doesn't use pci_update_current_state() to update the
      current_state field for devices that aren't power-manageable by the
      platform.  Instead, this field should be updated directly for devices
      that don't support the native PCI PM.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      b3bad72e
    • Linus Torvalds's avatar
      Merge branch 'fixes-for-linus' of git://git.monstr.eu/linux-2.6-microblaze · 279e677f
      Linus Torvalds authored
      * 'fixes-for-linus' of git://git.monstr.eu/linux-2.6-microblaze:
        microblaze: Fix kind-of-intr checking against number of interrupts
        microblaze: Update Microblaze defconfig
      279e677f
    • Linus Torvalds's avatar
      467999f5
    • Linus Torvalds's avatar
      Avoid ICE in get_random_int() with gcc-3.4.5 · 26a9a418
      Linus Torvalds authored
      Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with
      RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an
      internal compiler error (ICE):
      
          drivers/char/random.c: In function `get_random_int':
          drivers/char/random.c:1672: error: unrecognizable insn:
          (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91])
                  (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88])
                              (subreg:DI (reg:SI 6 bp) 0))
                          (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil)
              (nil))
          drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083
      
      and after some debugging it turns out that it's due to the code trying
      to figure out the rough value of the current stack pointer by taking an
      address of an uninitialized variable and casting that to an integer.
      
      This is clearly a compiler bug, but it's not worth fighting - while the
      current stack kernel pointer might be somewhat hard to predict in user
      space, it's also not generally going to change for a lot of the call
      chains for a particular process.
      
      So just drop it, and mumble some incoherent curses at the compiler.
      Tested-by: default avatarMartin Knoblauch <spamtrap@knobisoft.de>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      26a9a418
    • Frank Filz's avatar
      nfs: Fix NFS v4 client handling of MAY_EXEC in nfs_permission. · 7ee2cb7f
      Frank Filz authored
      The problem is that permission checking is skipped if atomic open is
      possible, but when exec opens a file, it just opens it O_READONLY which
      means EXEC permission will not be checked at that time.
      
      This problem is observed by the following sequence (executed as root):
      
        mount -t nfs4 server:/ /mnt4
        echo "ls" >/mnt4/foo
        chmod 744 /mnt4/foo
        su guest -c "mnt4/foo"
      Signed-off-by: default avatarFrank Filz <ffilzlnx@us.ibm.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@kernel.org
      Tested-by: default avatarEugene Teo <eugeneteo@kernel.sg>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7ee2cb7f
  2. 18 May, 2009 15 commits
  3. 17 May, 2009 7 commits
  4. 16 May, 2009 13 commits