1. 20 5月, 2009 4 次提交
    • T
      futex: setup writeable mapping for futex ops which modify user space data · 64d1304a
      Thomas Gleixner 提交于
      The futex code installs a read only mapping via get_user_pages_fast()
      even if the futex op function has to modify user space data. The
      eventual fault was fixed up by futex_handle_fault() which walked the
      VMA with mmap_sem held.
      
      After the cleanup patches which removed the mmap_sem dependency of the
      futex code commit 4dc5b7a36a49eff97050894cf1b3a9a02523717 (futex:
      clean up fault logic) removed the private VMA walk logic from the
      futex code. This change results in a stale RO mapping which is not
      fixed up.
      
      Instead of reintroducing the previous fault logic we set up the
      mapping in get_user_pages_fast() read/write for all operations which
      modify user space data. Also handle private futexes in the same way
      and make the current unconditional access_ok(VERIFY_WRITE) depend on
      the futex op.
      Reported-by: NAndreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      CC: stable@kernel.org
      64d1304a
    • L
      Merge branch 'fixes-for-linus' of git://git.monstr.eu/linux-2.6-microblaze · 279e677f
      Linus Torvalds 提交于
      * '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
    • L
      467999f5
    • L
      Avoid ICE in get_random_int() with gcc-3.4.5 · 26a9a418
      Linus Torvalds 提交于
      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: NMartin Knoblauch <spamtrap@knobisoft.de>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26a9a418
  2. 19 5月, 2009 5 次提交
  3. 18 5月, 2009 18 次提交
  4. 17 5月, 2009 6 次提交
  5. 16 5月, 2009 7 次提交