1. 16 Dec, 2010 2 commits
  2. 09 Dec, 2010 2 commits
    • Tristan Ye's avatar
      Ocfs2: Teach 'coherency=full' O_DIRECT writes to correctly up_read i_alloc_sem. · 39c99f12
      Tristan Ye authored
      Due to newly-introduced 'coherency=full' O_DIRECT writes also takes the EX
      rw_lock like buffered writes did(rw_level == 1), it turns out messing the
      usage of 'level' in ocfs2_dio_end_io() up, which caused i_alloc_sem being
      failed to get up_read'd correctly.
      
      This patch tries to teach ocfs2_dio_end_io to understand well on all locking
      stuffs by explicitly introducing a new bit for i_alloc_sem in iocb's private
      data, just like what we did for rw_lock.
      Signed-off-by: default avatarTristan Ye <tristan.ye@oracle.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      39c99f12
    • Sunil Mushran's avatar
      ocfs2/dlm: Migrate lockres with no locks if it has a reference · 388c4bcb
      Sunil Mushran authored
      o2dlm was not migrating resources with zero locks because it assumed that that
      resource would get purged by dlm_thread. However, some usage patterns involve
      creating and dropping locks at a high rate leading to the migrate thread seeing
      zero locks but the purge thread seeing an active reference. When this happens,
      the dlm_thread cannot purge the resource and the migrate thread sees no reason
      to migrate that resource. The spell is broken when the migrate thread catches
      the resource with a lock.
      
      The fix is to make the migrate thread also consider the reference map.
      
      This usage pattern can be triggered by userspace on userdlm locks and flocks.
      Signed-off-by: default avatarSunil Mushran <sunil.mushran@oracle.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      388c4bcb
  3. 06 Dec, 2010 4 commits
  4. 04 Dec, 2010 5 commits
    • Guy Martin's avatar
      parisc: Fix GSC PS/2 driver name for keyboard and mouse · 7bfbeae9
      Guy Martin authored
      Fix kernel warnings caused by the driver name of GSC PS/2 containing '/'.
      
      The following warnings are observed on a K410 system :
      
      [   10.700000] name 'GSC PS/2 keyboard'
      [   10.732000] ------------[ cut here ]------------
      [   10.772000] WARNING: at fs/proc/generic.c:323
      [   10.828000] Modules linked in:
      [   10.916000]
      [   10.916000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      [   10.936000] PSW: 00000000000001000000000000001111 Not tainted
      [   10.992000] r00-03  0004000f 104fe3e0 10201ea0 00000000
      [   11.060000] r04-07  4fc405c8 00000006 4fc405c8 4fc40694
      [   11.124000] r08-11  4fc40708 10438aa0 00000001 1043bfc8
      [   11.184000] r12-15  104ff2a0 104ff2a0 4fc38634 104ff2a0
      [   11.248000] r16-19  f0001570 10479af0 f000006c 1044fe50
      [   11.308000] r20-23  00000000 00000028 104cd858 00000000
      [   11.372000] r24-27  ffffffff 0000000e 1044fe10 1043bbe0
      [   11.436000] r28-31  0000002b 00000078 4fc40800 0000000d
      [   11.496000] sr00-03  00000000 00000000 00000000 00000000
      [   11.560000] sr04-07  00000000 00000000 00000000 00000000
      [   11.624000]
      [   11.688000] IASQ: 00000000 00000000 IAOQ: 10201ea0 10201ea4
      [   11.704000]  IIR: 03ffe01f    ISR: 00000000  IOR: 0000000d
      [   11.772000]  CPU:        0   CR30: 4fc40000 CR31: f01043b0
      [   11.836000]  ORIG_R28: 4fc40940
      [   11.904000]  IAOQ[0]: __xlate_proc_name+0x90/0xd0
      [   11.940000]  IAOQ[1]: __xlate_proc_name+0x94/0xd0
      [   11.996000]  RP(r2): __xlate_proc_name+0x90/0xd0
      [   12.052000] Backtrace:
      [   12.108000]  [<10257790>] vsnprintf+0x290/0x4f4
      [   12.136000]
      [   12.188000] ---[ end trace 91bf6ece17e322dd ]---
      [   12.208000] serio: GSC PS/2 keyboard port at 0x0001c000 irq 19 @ 10:12:7
      [   12.264000] name 'GSC PS/2 mouse'
      [   12.344000] ------------[ cut here ]------------
      [   12.384000] WARNING: at fs/proc/generic.c:323
      [   12.436000] Modules linked in:
      [   12.524000]
      [   12.528000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      [   12.544000] PSW: 00000000000001000000000000001111 Tainted: G        W
      [   12.600000] r00-03  0004000f 104fe3e0 10201ea0 00000000
      [   12.680000] r04-07  4fc405c8 00000006 4fc405c8 4fc40694
      [   12.740000] r08-11  4fc40708 10438aa0 00000001 1043bfc8
      [   12.804000] r12-15  104ff2a0 104ff2a0 4fc38634 104ff2a0
      [   12.868000] r16-19  f0001570 10479af0 f000006c 1044fe50
      [   12.928000] r20-23  00000000 00000025 104cd858 00000000
      [   12.992000] r24-27  ffffffff 0000000e 1044fe10 1043bbe0
      [   13.056000] r28-31  00000028 00000078 4fc40800 0000000d
      [   13.116000] sr00-03  00000000 00000000 00000000 00000000
      [   13.180000] sr04-07  00000000 00000000 00000000 00000000
      [   13.244000]
      [   13.308000] IASQ: 00000000 00000000 IAOQ: 10201ea0 10201ea4
      [   13.324000]  IIR: 03ffe01f    ISR: 00000000  IOR: 0000000d
      [   13.392000]  CPU:        0   CR30: 4fc40000 CR31: f01043b0
      [   13.456000]  ORIG_R28: 4fc40940
      [   13.524000]  IAOQ[0]: __xlate_proc_name+0x90/0xd0
      [   13.560000]  IAOQ[1]: __xlate_proc_name+0x94/0xd0
      [   13.616000]  RP(r2): __xlate_proc_name+0x90/0xd0
      [   13.672000] Backtrace:
      [   13.728000]  [<10257790>] vsnprintf+0x290/0x4f4
      [   13.756000]
      [   13.808000] ---[ end trace 91bf6ece17e322de ]---
      [   13.828000] serio: GSC PS/2 mouse port at 0x00020100 irq 19 @ 10:12:8
      Signed-off-by: default avatarGuy Martin <gmsoft@tuxicoman.be>
      Acked-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      7bfbeae9
    • Guy Martin's avatar
      parisc: KittyHawk LCD fix · 79a04296
      Guy Martin authored
      K class aka KittyHawk don't have LED support on their LCD. Installing
      HP-UX confirmed this. The current led_wq fills the LCD with black
      characters each time it runs.
      
      The patch prevents the led_wq workqueue and its proc entry to be
      created for KittyHawk machines.
      
      It also increase min_cmd_delay as currently, one character out of two
      is lost when a string is sent to the LCD.
      Signed-off-by: default avatarGuy Martin <gmsoft@tuxicoman.be>
      Signed-off-by: default avatarKyle McMartin <kyle@mcmartin.c>
      79a04296
    • James Bottomley's avatar
      parisc: convert the rest of the irq handlers to simple/percpu · 51890613
      James Bottomley authored
      The generic conversion eliminates the spurious no_ack and no_end
      routines, converts all the cascaded handlers to handle_simple_irq() and
      makes iosapic use a modified handle_percpu_irq() to become the same as
      the CPU irq's.  This isn't an essential change, but it eliminates the
      mask/unmask overhead of handle_level_irq().
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Tested-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      51890613
    • James Bottomley's avatar
      parisc: fix dino/gsc interrupts · d16cd297
      James Bottomley authored
      The essential problem we're currently having is that dino (and gsc) is a
      cascaded CPU interrupt.  Under the old __do_IRQ() handler, our CPU
      interrupts basically did an ack followed by an end.  In the new scheme,
      we replaced them with level handlers which do a mask, an ack and then an
      unmask (but no end).  Instead, with the renaming of end to eoi, we
      actually want to call the percpu flow handlers, because they actually
      have all the characteristics we want.
      
      This patch does the conversion and gets my C360 booting again.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      d16cd297
    • Tero Roponen's avatar
      slub: Fix a crash during slabinfo -v · 37d57443
      Tero Roponen authored
      Commit f7cb1933 ("SLUB: Pass active
      and inactive redzone flags instead of boolean to debug functions")
      missed two instances of check_object(). This caused a lot of warnings
      during 'slabinfo -v' finally leading to a crash:
      
        BUG ext4_xattr: Freepointer corrupt
        ...
        BUG buffer_head: Freepointer corrupt
        ...
        BUG ext4_alloc_context: Freepointer corrupt
        ...
        ...
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
        IP: [<ffffffff810a291f>] file_sb_list_del+0x1c/0x35
        PGD 79d78067 PUD 79e67067 PMD 0
        Oops: 0002 [#1] SMP
        last sysfs file: /sys/kernel/slab/:t-0000192/validate
      
      This patch fixes the problem by converting the two missed instances.
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarTero Roponen <tero.roponen@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      37d57443
  5. 03 Dec, 2010 13 commits
  6. 02 Dec, 2010 14 commits
    • Jeremy Fitzhardinge's avatar
      xen: prevent crashes with non-HIGHMEM 32-bit kernels with largeish memory · 2a4c92fa
      Jeremy Fitzhardinge authored
      If this is a non-HIGHMEM 32-bit kernel, then the page structures only go
      up to the limit of addressable memory, even if more memory is physically
      present.  Don't try to add that extra memory to the balloon.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      2a4c92fa
    • Nelson Elhage's avatar
      do_exit(): make sure that we run with get_fs() == USER_DS · 33dd94ae
      Nelson Elhage authored
      If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not
      otherwise reset before do_exit().  do_exit may later (via mm_release in
      fork.c) do a put_user to a user-controlled address, potentially allowing
      a user to leverage an oops into a controlled write into kernel memory.
      
      This is only triggerable in the presence of another bug, but this
      potentially turns a lot of DoS bugs into privilege escalations, so it's
      worth fixing.  I have proof-of-concept code which uses this bug along
      with CVE-2010-3849 to write a zero to an arbitrary kernel address, so
      I've tested that this is not theoretical.
      
      A more logical place to put this fix might be when we know an oops has
      occurred, before we call do_exit(), but that would involve changing
      every architecture, in multiple places.
      
      Let's just stick it in do_exit instead.
      
      [akpm@linux-foundation.org: update code comment]
      Signed-off-by: default avatarNelson Elhage <nelhage@ksplice.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      33dd94ae
    • KOSAKI Motohiro's avatar
      ksm: annotate ksm_thread_mutex is no deadlock source · a0b0f58c
      KOSAKI Motohiro authored
      commit 62b61f61 ("ksm: memory hotremove migration only") caused the
      following new lockdep warning.
      
        =======================================================
        [ INFO: possible circular locking dependency detected ]
        -------------------------------------------------------
        bash/1621 is trying to acquire lock:
         ((memory_chain).rwsem){.+.+.+}, at: [<ffffffff81079339>]
        __blocking_notifier_call_chain+0x69/0xc0
      
        but task is already holding lock:
         (ksm_thread_mutex){+.+.+.}, at: [<ffffffff8113a3aa>]
        ksm_memory_callback+0x3a/0xc0
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #1 (ksm_thread_mutex){+.+.+.}:
             [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
             [<ffffffff81505d74>] __mutex_lock_common+0x44/0x3f0
             [<ffffffff81506228>] mutex_lock_nested+0x48/0x60
             [<ffffffff8113a3aa>] ksm_memory_callback+0x3a/0xc0
             [<ffffffff8150c21c>] notifier_call_chain+0x8c/0xe0
             [<ffffffff8107934e>] __blocking_notifier_call_chain+0x7e/0xc0
             [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
             [<ffffffff813afbfb>] memory_notify+0x1b/0x20
             [<ffffffff81141b7c>] remove_memory+0x1cc/0x5f0
             [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
             [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
             [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
             [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
             [<ffffffff8114f398>] vfs_write+0xc8/0x190
             [<ffffffff8114fc14>] sys_write+0x54/0x90
             [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b
      
        -> #0 ((memory_chain).rwsem){.+.+.+}:
             [<ffffffff8108b5ba>] __lock_acquire+0x155a/0x1600
             [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
             [<ffffffff81506601>] down_read+0x51/0xa0
             [<ffffffff81079339>] __blocking_notifier_call_chain+0x69/0xc0
             [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
             [<ffffffff813afbfb>] memory_notify+0x1b/0x20
             [<ffffffff81141f1e>] remove_memory+0x56e/0x5f0
             [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
             [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
             [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
             [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
             [<ffffffff8114f398>] vfs_write+0xc8/0x190
             [<ffffffff8114fc14>] sys_write+0x54/0x90
             [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b
      
      But it's a false positive.  Both memory_chain.rwsem and ksm_thread_mutex
      have an outer lock (mem_hotplug_mutex).  So they cannot deadlock.
      
      Thus, This patch annotate ksm_thread_mutex is not deadlock source.
      
      [akpm@linux-foundation.org: update comment, from Hugh]
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a0b0f58c
    • KOSAKI Motohiro's avatar
      mem-hotplug: introduce {un}lock_memory_hotplug() · 20d6c96b
      KOSAKI Motohiro authored
      Presently hwpoison is using lock_system_sleep() to prevent a race with
      memory hotplug.  However lock_system_sleep() is a no-op if
      CONFIG_HIBERNATION=n.  Therefore we need a new lock.
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Suggested-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      20d6c96b
    • Andrew Morton's avatar
      Documentation/filesystems/vfs.txt: fix ->repeasepage() description · 4fe65cab
      Andrew Morton authored
      ->releasepage() does not remove the page from the mapping.
      Acked-by: default avatarNeil Brown <neilb@suse.de>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4fe65cab
    • Jeremy Fitzhardinge's avatar
      vmalloc: eagerly clear ptes on vunmap · 64141da5
      Jeremy Fitzhardinge authored
      On stock 2.6.37-rc4, running:
      
        # mount lilith:/export /mnt/lilith
        # find  /mnt/lilith/ -type f -print0 | xargs -0 file
      
      crashes the machine fairly quickly under Xen.  Often it results in oops
      messages, but the couple of times I tried just now, it just hung quietly
      and made Xen print some rude messages:
      
          (XEN) mm.c:2389:d80 Bad type (saw 7400000000000001 != exp
          3000000000000000) for mfn 1d7058 (pfn 18fa7)
          (XEN) mm.c:964:d80 Attempt to create linear p.t. with write perms
          (XEN) mm.c:2389:d80 Bad type (saw 7400000000000010 != exp
          1000000000000000) for mfn 1d2e04 (pfn 1d1fb)
          (XEN) mm.c:2965:d80 Error while pinning mfn 1d2e04
      
      Which means the domain tried to map a pagetable page RW, which would
      allow it to map arbitrary memory, so Xen stopped it.  This is because
      vm_unmap_ram() left some pages mapped in the vmalloc area after NFS had
      finished with them, and those pages got recycled as pagetable pages
      while still having these RW aliases.
      
      Removing those mappings immediately removes the Xen-visible aliases, and
      so it has no problem with those pages being reused as pagetable pages.
      Deferring the TLB flush doesn't upset Xen because it can flush the TLB
      itself as needed to maintain its invariants.
      
      When unmapping a region in the vmalloc space, clear the ptes
      immediately.  There's no point in deferring this because there's no
      amortization benefit.
      
      The TLBs are left dirty, and they are flushed lazily to amortize the
      cost of the IPIs.
      
      This specific motivation for this patch is an oops-causing regression
      since 2.6.36 when using NFS under Xen, triggered by the NFS client's use
      of vm_map_ram() introduced in 56e4ebf8 ("NFS: readdir with vmapped
      pages") .  XFS also uses vm_map_ram() and could cause similar problems.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Bryan Schumaker <bjschuma@netapp.com>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Alex Elder <aelder@sgi.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      64141da5
    • Andres Salomon's avatar
      cs5535-gpio: apply CS5536 errata workaround for GPIOs · 853ff883
      Andres Salomon authored
      The AMD Geode CS5536 Companion Device Silicon Revision B1 Specification
      Update mentions the follow as issue #36:
      
       "Atomic write transactions to the atomic GPIO High Bank Feature Bit
        registers should only affect the bits selected [...]"
      
       "after Suspend, an atomic write transaction [...] will clear all
        non-selected bits of the accessed register."
      
      In other words, writing to the high bank for a single GPIO bit will
      clear every other GPIO bit (but only sometimes after a suspend).
      
      The workaround described is obvious and simple; do a read-modify-write.
      This patch does that, and documents why we're doing it.
      Signed-off-by: default avatarAndres Salomon <dilinger@queued.net>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      853ff883
    • Frederic Weisbecker's avatar
      reiserfs: don't acquire lock recursively in reiserfs_acl_chmod · 238af875
      Frederic Weisbecker authored
      reiserfs_acl_chmod() can be called by reiserfs_set_attr() and then take
      the reiserfs lock a second time.  Thereafter it may call journal_begin()
      that definitely requires the lock not to be nested in order to release
      it before taking the journal mutex because the reiserfs lock depends on
      the journal mutex already.
      
      So, aviod nesting the lock in reiserfs_acl_chmod().
      Reported-by: default avatarPawel Zawora <pzawora@gmail.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Tested-by: default avatarPawel Zawora <pzawora@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: <stable@kernel.org>		[2.6.32.x+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      238af875
    • Johannes Berg's avatar
      leds: fix up dependencies · 0bae35e1
      Johannes Berg authored
      It's not useful to build LED triggers when there's no LEDs that can be
      triggered by them.  Therefore, fix up the dependencies so that this
      cannot happen, and fix a few users that select triggers to depend on
      LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS,
      which is OK).
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Reported-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Acked-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Tested-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Arnd Hannemann <arnd@arndnet.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Richard Purdie <rpurdie@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0bae35e1
    • Wu Fengguang's avatar
      vmstat: fix dirty threshold ordering · e172662d
      Wu Fengguang authored
      The nr_dirty_[background_]threshold fields are misplaced before the
      numa_* fields, and users will read strange values.
      
      This is the right order.  Before patch, nr_dirty_background_threshold
      will read as 0 (the value from numa_miss).
      
      	numa_hit 128501
      	numa_miss 0
      	numa_foreign 0
      	numa_interleave 7388
      	numa_local 128501
      	numa_other 0
      	nr_dirty_threshold 144291
      	nr_dirty_background_threshold 72145
      Signed-off-by: default avatarWu Fengguang <fengguang.wu@intel.com>
      Cc: Michael Rubin <mrubin@google.com>
      Reviewed-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Reviewed-by: default avatarMinchan Kim <minchan.kim@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e172662d
    • Zeng Zhaoming's avatar
      mm/mempolicy.c: add rcu read lock to protect pid structure · 55cfaa3c
      Zeng Zhaoming authored
      find_task_by_vpid() should be protected by rcu_read_lock(), to prevent
      free_pid() reclaiming pid.
      Signed-off-by: default avatarZeng Zhaoming <zengzm.kernel@gmail.com>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      55cfaa3c
    • Dean Nelson's avatar
      mm/hugetlb.c: avoid double unlock_page() in hugetlb_fault() · 1f64d69c
      Dean Nelson authored
      Have hugetlb_fault() call unlock_page(page) only if it had previously
      called lock_page(page).
      
      Setting CONFIG_DEBUG_VM=y and then running the libhugetlbfs test suite,
      resulted in the tripping of VM_BUG_ON(!PageLocked(page)) in
      unlock_page() having been called by hugetlb_fault() when page ==
      pagecache_page.  This patch remedied the problem.
      Signed-off-by: default avatarDean Nelson <dnelson@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1f64d69c
    • Linus Torvalds's avatar
      Merge branch 'staging-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6 · 94c35de9
      Linus Torvalds authored
      * 'staging-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6: (27 commits)
        Staging: rt2870: Add USB ID for Buffalo Airstation WLI-UC-GN
        staging: easycap needs smp_lock.h, fixes build error
        Staging: batman-adv: ensure that eth_type_trans gets linear memory
        Staging: batman-adv: Don't remove interface with spinlock held
        staging: brcm80211: updated maintainers contact information
        staging: fix winbond build, needs delay.h
        Staging: line6: fix up my fixup for some sysfs attribute permissions
        Staging: zram: fix up my fixup for some sysfs attribute permissions
        Staging: udlfb: fix up my fixup for some sysfs attribute permissions
        Staging: samsung-laptop: fix up my fixup for some sysfs attribute permissions
        Staging: iio: adis16220: fix up my fixup for some sysfs attribute permissions
        Staging: frontier: fix up my fixup for some sysfs attribute permissions
        Staging: asus_oled: fix up my fixup for some sysfs attribute permissions
        staging: spectra: fix build error
        Staging: intel_sst: fix memory leak
        Staging: rtl8712: signedness bug in init
        staging: rtl8187se: Change panic to warn when RF switch turned off
        staging: comedi: fix memory leak
        Staging: quickstart: free after input_unregister_device()
        Staging: speakup: free after input_unregister_device()
        ...
      94c35de9
    • Linus Torvalds's avatar
      Merge branch 'driver-core-linus' of... · 8733cb29
      Linus Torvalds authored
      Merge branch 'driver-core-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6
      
      * 'driver-core-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6:
        uio: Change mail address of Hans J. Koch
        driver core: prune docs about device_interface
        driver core: the development tree has switched to git
      8733cb29