1. 09 6月, 2006 8 次提交
    • M
      [PATCH] s390: fix in-user atomic futex operation. · bafe00cc
      Martin Schwidefsky 提交于
      From: Martin Schwidefsky <schwidefsky@de.ibm.com>
      
      __futex_atomic_op needs to do an atomic operation in the user address space,
      not the kernel address space.  Add the missing sacf 256/sacf 0 to switch to
      the secondary mode before doing the compare-and-swap.  In addition add
      another fixup for catch specification exceptions if the compare-and-swap
      address is not aligned.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bafe00cc
    • J
      [PATCH] debugfs inode leak · 71601e2b
      Jens Axboe 提交于
      Looking at the reiser4 crash, I found a leak in debugfs. In
      debugfs_mknod(), we create the inode before checking if the dentry
      already has one attached. We don't free it if that is the case.
      
      These bugs happen quite often, I'm starting to think we should disallow
      such coding in CodingStyle.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      71601e2b
    • J
      [PATCH] elevator switching race · bc1c1169
      Jens Axboe 提交于
      There's a race between shutting down one io scheduler and firing up the
      next, in which a new io could enter and cause the io scheduler to be
      invoked with bad or NULL data.
      
      To fix this, we need to maintain the queue lock for a bit longer.
      Unfortunately we cannot do that, since the elevator init requires to be
      run without the lock held.  This isn't easily fixable, without also
      changing the mempool API.  So split the initialization into two parts,
      and alloc-init operation and an attach operation.  Then we can
      preallocate the io scheduler and related structures, and run the attach
      inside the lock after we detach the old one.
      
      This patch has survived 30 minutes of 1 second io scheduler switching
      with a very busy io load.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bc1c1169
    • M
      [PATCH] fbcon: fix limited scroll in SCROLL_PAN_REDRAW mode · 26e780e8
      Malcom Parsons 提交于
      From: Malcom Parsons <malcolm.parsons@gmail.com>
      
      When scrolling up in SCROLL_PAN_REDRAW mode with a large limited scroll
      region, the bottom few lines have to be redrawn.  Without this patch, the
      wrong text is drawn into these lines, corrupting the display.
      
      Observed in 2.6.14 when running an IRC client in the Nintendo DS linux
      port.
      
      I haven't tested if scrolling down has the same problem.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      26e780e8
    • R
      [PATCH] Fix mempolicy.h build error · 45b35a5c
      Ralf Baechle 提交于
      From: Ralf Baechle <ralf@linux-mips.org>
      
      <linux/mempolicy.h> uses struct mm_struct and relies on a definition or
      declaration somehow magically being dragged in which may result in a
      build:
      
      [...]
        CC      mm/mempolicy.o
      In file included from mm/mempolicy.c:69:
      include/linux/mempolicy.h:150: warning: ‘struct mm_struct’ declared inside parameter list
      include/linux/mempolicy.h:150: warning: its scope is only this definition or declaration, which is probably not what you want
      include/linux/mempolicy.h:175: warning: ‘struct mm_struct’ declared inside parameter list
      mm/mempolicy.c:622: error: conflicting types for ‘do_migrate_pages’
      include/linux/mempolicy.h:175: error: previous declaration of ‘do_migrate_pages’ was here
      mm/mempolicy.c:1661: error: conflicting types for ‘mpol_rebind_mm’
      include/linux/mempolicy.h:150: error: previous declaration of ‘mpol_rebind_mm’ was here
      make[1]: *** [mm/mempolicy.o] Error 1
      make: *** [mm] Error 2
      [ralf@denk linux-ip35]$
      
      Including <linux/sched.h> is a step into direction of include hell so
      fixed by adding a forward declaration of struct mm_struct instead.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      45b35a5c
    • L
      [PATCH] ep93xx build fix · fd0a0ac1
      Lennert Buytenhek 提交于
      From: Lennert Buytenhek <buytenh@wantstofly.org>
      
      The recent renaming of m48t86's ->readb() and ->writeb() platform driver
      methods (2d7b20c1) to ->readbyte() and
      ->writebyte() to fix the ia64 build broke the build of the cirrus ep93xx
      ARM platform.  This patch fixes it up.
      Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fd0a0ac1
    • A
      [PATCH] Fix HPET operation on 64-bit NVIDIA platforms · a2ef3a50
      Andy Currid 提交于
      From: "Andy Currid" <ACurrid@nvidia.com>
      
      This patch fixes a kernel panic during boot that occurs on NVIDIA platforms
      that have HPET enabled.
      
      When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is
      advertised as such in the ACPI APIC table - but an earlier workaround in the
      kernel was ignoring this override.  The fix is to honor timer IRQ overrides
      from ACPI when HPET is detected on an NVIDIA platform.
      Signed-off-by: NAndy Currid <acurrid@nvidia.com>
      Cc: "Brown, Len" <len.brown@intel.com>
      Cc: "Yu, Luming" <luming.yu@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a2ef3a50
    • A
      [PATCH] Fix HPET operation on 32-bit NVIDIA platforms · d44647b0
      Andy Currid 提交于
      From: "Andy Currid" <ACurrid@nvidia.com>
      
      This patch fixes a kernel panic during boot that occurs on NVIDIA platforms
      that have HPET enabled.
      
      When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is
      advertised as such in the ACPI APIC table - but an earlier workaround in the
      kernel was ignoring this override.  The fix is to honor timer IRQ overrides
      from ACPI when HPET is detected on an NVIDIA platform.
      Signed-off-by: NAndy Currid <acurrid@nvidia.com>
      Cc: "Brown, Len" <len.brown@intel.com>
      Cc: "Yu, Luming" <luming.yu@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d44647b0
  2. 06 6月, 2006 32 次提交