1. 21 Oct, 2012 28 commits
  2. 12 Oct, 2012 12 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.0.46 · 40e6f936
      Greg Kroah-Hartman authored
      40e6f936
    • Andreas Bießmann's avatar
      mtd: omap2: fix module loading · 1434cc17
      Andreas Bießmann authored
      commit 4d3d688d upstream.
      
      Unloading the omap2 nand driver missed to release the memory region which will
      result in not being able to request it again if one want to load the driver
      later on.
      
      This patch fixes following error when loading omap2 module after unloading:
      ---8<---
      ~ $ rmmod omap2
      ~ $ modprobe omap2
      [   37.420928] omap2-nand: probe of omap2-nand.0 failed with error -16
      ~ $
      --->8---
      
      This error was introduced in 67ce04bf which
      was the first commit of this driver.
      Signed-off-by: default avatarAndreas Bießmann <andreas@biessmann.de>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1434cc17
    • Andreas Bießmann's avatar
      mtd: omap2: fix omap_nand_remove segfault · ecd111b6
      Andreas Bießmann authored
      commit 7d9b1102 upstream.
      
      Do not kfree() the mtd_info; it is handled in the mtd subsystem and
      already freed by nand_release(). Instead kfree() the struct
      omap_nand_info allocated in omap_nand_probe which was not freed before.
      
      This patch fixes following error when unloading the omap2 module:
      
      ---8<---
      ~ $ rmmod omap2
      ------------[ cut here ]------------
      kernel BUG at mm/slab.c:3126!
      Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
      Modules linked in: omap2(-)
      CPU: 0    Not tainted  (3.6.0-rc3-00230-g155e36d4-dirty #3)
      PC is at cache_free_debugcheck+0x2d4/0x36c
      LR is at kfree+0xc8/0x2ac
      pc : [<c01125a0>]    lr : [<c0112efc>]    psr: 200d0193
      sp : c521fe08  ip : c0e8ef90  fp : c521fe5c
      r10: bf0001fc  r9 : c521e000  r8 : c0d99c8c
      r7 : c661ebc0  r6 : c065d5a4  r5 : c65c4060  r4 : c78005c0
      r3 : 00000000  r2 : 00001000  r1 : c65c4000  r0 : 00000001
      Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c5387d  Table: 86694019  DAC: 00000015
      Process rmmod (pid: 549, stack limit = 0xc521e2f0)
      Stack: (0xc521fe08 to 0xc5220000)
      fe00:                   c008a874 c00bf44c c515c6d0 200d0193 c65c4860 c515c240
      fe20: c521fe3c c521fe30 c008a9c0 c008a854 c521fe5c c65c4860 c78005c0 bf0001fc
      fe40: c780ff40 a00d0113 c521e000 00000000 c521fe84 c521fe60 c0112efc c01122d8
      fe60: c65c4860 c0673778 c06737ac 00000000 00070013 00000000 c521fe9c c521fe88
      fe80: bf0001fc c0112e40 c0673778 bf001ca8 c521feac c521fea0 c02ca11c bf0001ac
      fea0: c521fec4 c521feb0 c02c82c4 c02ca100 c0673778 bf001ca8 c521fee4 c521fec8
      fec0: c02c8dd8 c02c8250 00000000 bf001ca8 bf001ca8 c0804ee0 c521ff04 c521fee8
      fee0: c02c804c c02c8d20 bf001924 00000000 bf001ca8 c521e000 c521ff1c c521ff08
      ff00: c02c950c c02c7fbc bf001d48 00000000 c521ff2c c521ff20 c02ca3a4 c02c94b8
      ff20: c521ff3c c521ff30 bf001938 c02ca394 c521ffa4 c521ff40 c009beb4 bf001930
      ff40: c521ff6c 70616d6f b6fe0032 c0014f84 70616d6f b6fe0032 00000081 60070010
      ff60: c521ff84 c521ff70 c008e1f4 c00bf328 0001a004 70616d6f c521ff94 0021ff88
      ff80: c008e368 0001a004 70616d6f b6fe0032 00000081 c0015028 00000000 c521ffa8
      ffa0: c0014dc0 c009bcd0 0001a004 70616d6f bec2ab38 00000880 bec2ab38 00000880
      ffc0: 0001a004 70616d6f b6fe0032 00000081 00000319 00000000 b6fe1000 00000000
      ffe0: bec2ab30 bec2ab20 00019f00 b6f539c0 60070010 bec2ab38 aaaaaaaa aaaaaaaa
      Backtrace:
      [<c01122cc>] (cache_free_debugcheck+0x0/0x36c) from [<c0112efc>] (kfree+0xc8/0x2ac)
      [<c0112e34>] (kfree+0x0/0x2ac) from [<bf0001fc>] (omap_nand_remove+0x5c/0x64 [omap2])
      [<bf0001a0>] (omap_nand_remove+0x0/0x64 [omap2]) from [<c02ca11c>] (platform_drv_remove+0x28/0x2c)
       r5:bf001ca8 r4:c0673778
      [<c02ca0f4>] (platform_drv_remove+0x0/0x2c) from [<c02c82c4>] (__device_release_driver+0x80/0xdc)
      [<c02c8244>] (__device_release_driver+0x0/0xdc) from [<c02c8dd8>] (driver_detach+0xc4/0xc8)
       r5:bf001ca8 r4:c0673778
      [<c02c8d14>] (driver_detach+0x0/0xc8) from [<c02c804c>] (bus_remove_driver+0x9c/0x104)
       r6:c0804ee0 r5:bf001ca8 r4:bf001ca8 r3:00000000
      [<c02c7fb0>] (bus_remove_driver+0x0/0x104) from [<c02c950c>] (driver_unregister+0x60/0x80)
       r6:c521e000 r5:bf001ca8 r4:00000000 r3:bf001924
      [<c02c94ac>] (driver_unregister+0x0/0x80) from [<c02ca3a4>] (platform_driver_unregister+0x1c/0x20)
       r5:00000000 r4:bf001d48
      [<c02ca388>] (platform_driver_unregister+0x0/0x20) from [<bf001938>] (omap_nand_driver_exit+0x14/0x1c [omap2])
      [<bf001924>] (omap_nand_driver_exit+0x0/0x1c [omap2]) from [<c009beb4>] (sys_delete_module+0x1f0/0x2ec)
      [<c009bcc4>] (sys_delete_module+0x0/0x2ec) from [<c0014dc0>] (ret_fast_syscall+0x0/0x48)
       r8:c0015028 r7:00000081 r6:b6fe0032 r5:70616d6f r4:0001a004
      Code: e1a00005 eb0d9172 e7f001f2 e7f001f2 (e7f001f2)
      ---[ end trace 6a30b24d8c0cc2ee ]---
      Segmentation fault
      --->8---
      
      This error was introduced in 67ce04bf which
      was the first commit of this driver.
      Signed-off-by: default avatarAndreas Bießmann <andreas@biessmann.de>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ecd111b6
    • Shmulik Ladkani's avatar
      mtd: nand: Use the mirror BBT descriptor when reading its version · ad9ca19a
      Shmulik Ladkani authored
      commit 7bb9c754 upstream.
      
      The code responsible for reading the version of the mirror bbt was
      incorrectly using the descriptor of the main bbt.
      
      Pass the mirror bbt descriptor to 'scan_read_raw' when reading the
      version of the mirror bbt.
      Signed-off-by: default avatarShmulik Ladkani <shmulik.ladkani@gmail.com>
      Acked-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad9ca19a
    • Richard Genoud's avatar
      mtd: nandsim: bugfix: fail if overridesize is too big · 776a41b8
      Richard Genoud authored
      commit bb0a13a1 upstream.
      
      If override size is too big, the module was actually loaded instead of
      failing, because retval was not set.
      
      This lead to memory corruption with the use of the freed structs nandsim
      and nand_chip.
      Signed-off-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      776a41b8
    • Alexander Shiyan's avatar
      mtd: autcpu12-nvram: Fix compile breakage · b4f7f36c
      Alexander Shiyan authored
      commit d1f55c68 upstream.
      
      Update driver autcpu12-nvram.c so it compiles; map_read32/map_write32
      no longer exist in the kernel so the driver is totally broken.
      Additionally, map_info name passed to simple_map_init is incorrect.
      Signed-off-by: default avatarAlexander Shiyan <shc_work@mail.ru>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4f7f36c
    • Srivatsa S. Bhat's avatar
      CPU hotplug, cpusets, suspend: Don't modify cpusets during suspend/resume · 8f48f1a2
      Srivatsa S. Bhat authored
      commit d35be8ba upstream.
      
      In the event of CPU hotplug, the kernel modifies the cpusets' cpus_allowed
      masks as and when necessary to ensure that the tasks belonging to the cpusets
      have some place (online CPUs) to run on. And regular CPU hotplug is
      destructive in the sense that the kernel doesn't remember the original cpuset
      configurations set by the user, across hotplug operations.
      
      However, suspend/resume (which uses CPU hotplug) is a special case in which
      the kernel has the responsibility to restore the system (during resume), to
      exactly the same state it was in before suspend.
      
      In order to achieve that, do the following:
      
      1. Don't modify cpusets during suspend/resume. At all.
         In particular, don't move the tasks from one cpuset to another, and
         don't modify any cpuset's cpus_allowed mask. So, simply ignore cpusets
         during the CPU hotplug operations that are carried out in the
         suspend/resume path.
      
      2. However, cpusets and sched domains are related. We just want to avoid
         altering cpusets alone. So, to keep the sched domains updated, build
         a single sched domain (containing all active cpus) during each of the
         CPU hotplug operations carried out in s/r path, effectively ignoring
         the cpusets' cpus_allowed masks.
      
         (Since userspace is frozen while doing all this, it will go unnoticed.)
      
      3. During the last CPU online operation during resume, build the sched
         domains by looking up the (unaltered) cpusets' cpus_allowed masks.
         That will bring back the system to the same original state as it was in
         before suspend.
      
      Ultimately, this will not only solve the cpuset problem related to suspend
      resume (ie., restores the cpusets to exactly what it was before suspend, by
      not touching it at all) but also speeds up suspend/resume because we avoid
      running cpuset update code for every CPU being offlined/onlined.
      Signed-off-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20120524141611.3692.20155.stgit@srivatsabhat.in.ibm.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      8f48f1a2
    • Mel Gorman's avatar
      mempolicy: fix a memory corruption by refcount imbalance in alloc_pages_vma() · d08719c4
      Mel Gorman authored
      commit 00442ad0 upstream.
      
      Commit cc9a6c87 ("cpuset: mm: reduce large amounts of memory barrier
      related damage v3") introduced a potential memory corruption.
      shmem_alloc_page() uses a pseudo vma and it has one significant unique
      combination, vma->vm_ops=NULL and vma->policy->flags & MPOL_F_SHARED.
      
      get_vma_policy() does NOT increase a policy ref when vma->vm_ops=NULL
      and mpol_cond_put() DOES decrease a policy ref when a policy has
      MPOL_F_SHARED.  Therefore, when a cpuset update race occurs,
      alloc_pages_vma() falls in 'goto retry_cpuset' path, decrements the
      reference count and frees the policy prematurely.
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Reviewed-by: default avatarChristoph Lameter <cl@linux.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d08719c4
    • KOSAKI Motohiro's avatar
      mempolicy: fix refcount leak in mpol_set_shared_policy() · 29715fe2
      KOSAKI Motohiro authored
      commit 63f74ca2 upstream.
      
      When shared_policy_replace() fails to allocate new->policy is not freed
      correctly by mpol_set_shared_policy().  The problem is that shared
      mempolicy code directly call kmem_cache_free() in multiple places where
      it is easy to make a mistake.
      
      This patch creates an sp_free wrapper function and uses it. The bug was
      introduced pre-git age (IOW, before 2.6.12-rc2).
      
      [mgorman@suse.de: Editted changelog]
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Reviewed-by: default avatarChristoph Lameter <cl@linux.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29715fe2
    • Mel Gorman's avatar
      mempolicy: fix a race in shared_policy_replace() · cedd186e
      Mel Gorman authored
      commit b22d127a upstream.
      
      shared_policy_replace() use of sp_alloc() is unsafe.  1) sp_node cannot
      be dereferenced if sp->lock is not held and 2) another thread can modify
      sp_node between spin_unlock for allocating a new sp node and next
      spin_lock.  The bug was introduced before 2.6.12-rc2.
      
      Kosaki's original patch for this problem was to allocate an sp node and
      policy within shared_policy_replace and initialise it when the lock is
      reacquired.  I was not keen on this approach because it partially
      duplicates sp_alloc().  As the paths were sp->lock is taken are not that
      performance critical this patch converts sp->lock to sp->mutex so it can
      sleep when calling sp_alloc().
      
      [kosaki.motohiro@jp.fujitsu.com: Original patch]
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Reviewed-by: default avatarChristoph Lameter <cl@linux.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cedd186e
    • KOSAKI Motohiro's avatar
      mempolicy: remove mempolicy sharing · e12681ff
      KOSAKI Motohiro authored
      commit 869833f2 upstream.
      
      Dave Jones' system call fuzz testing tool "trinity" triggered the
      following bug error with slab debugging enabled
      
          =============================================================================
          BUG numa_policy (Not tainted): Poison overwritten
          -----------------------------------------------------------------------------
      
          INFO: 0xffff880146498250-0xffff880146498250. First byte 0x6a instead of 0x6b
          INFO: Allocated in mpol_new+0xa3/0x140 age=46310 cpu=6 pid=32154
           __slab_alloc+0x3d3/0x445
           kmem_cache_alloc+0x29d/0x2b0
           mpol_new+0xa3/0x140
           sys_mbind+0x142/0x620
           system_call_fastpath+0x16/0x1b
      
          INFO: Freed in __mpol_put+0x27/0x30 age=46268 cpu=6 pid=32154
           __slab_free+0x2e/0x1de
           kmem_cache_free+0x25a/0x260
           __mpol_put+0x27/0x30
           remove_vma+0x68/0x90
           exit_mmap+0x118/0x140
           mmput+0x73/0x110
           exit_mm+0x108/0x130
           do_exit+0x162/0xb90
           do_group_exit+0x4f/0xc0
           sys_exit_group+0x17/0x20
           system_call_fastpath+0x16/0x1b
      
          INFO: Slab 0xffffea0005192600 objects=27 used=27 fp=0x          (null) flags=0x20000000004080
          INFO: Object 0xffff880146498250 @offset=592 fp=0xffff88014649b9d0
      
      The problem is that the structure is being prematurely freed due to a
      reference count imbalance. In the following case mbind(addr, len) should
      replace the memory policies of both vma1 and vma2 and thus they will
      become to share the same mempolicy and the new mempolicy will have the
      MPOL_F_SHARED flag.
      
        +-------------------+-------------------+
        |     vma1          |     vma2(shmem)   |
        +-------------------+-------------------+
        |                                       |
       addr                                 addr+len
      
      alloc_pages_vma() uses get_vma_policy() and mpol_cond_put() pair for
      maintaining the mempolicy reference count.  The current rule is that
      get_vma_policy() only increments refcount for shmem VMA and
      mpol_conf_put() only decrements refcount if the policy has
      MPOL_F_SHARED.
      
      In above case, vma1 is not shmem vma and vma->policy has MPOL_F_SHARED!
      The reference count will be decreased even though was not increased
      whenever alloc_page_vma() is called.  This has been broken since commit
      [52cd3b07: mempolicy: rework mempolicy Reference Counting] in 2008.
      
      There is another serious bug with the sharing of memory policies.
      Currently, mempolicy rebind logic (it is called from cpuset rebinding)
      ignores a refcount of mempolicy and override it forcibly.  Thus, any
      mempolicy sharing may cause mempolicy corruption.  The bug was
      introduced by commit [68860ec1: cpusets: automatic numa mempolicy
      rebinding].
      
      Ideally, the shared policy handling would be rewritten to either
      properly handle COW of the policy structures or at least reference count
      MPOL_F_SHARED based exclusively on information within the policy.
      However, this patch takes the easier approach of disabling any policy
      sharing between VMAs.  Each new range allocated with sp_alloc will
      allocate a new policy, set the reference count to 1 and drop the
      reference count of the old policy.  This increases the memory footprint
      but is not expected to be a major problem as mbind() is unlikely to be
      used for fine-grained ranges.  It is also inefficient because it means
      we allocate a new policy even in cases where mbind_range() could use the
      new_policy passed to it.  However, it is more straight-forward and the
      change should be invisible to the user.
      
      [mgorman@suse.de: Edited changelog]
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Cc: Christoph Lameter <cl@linux.com>
      Reviewed-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e12681ff
    • KOSAKI Motohiro's avatar
      revert "mm: mempolicy: Let vma_merge and vma_split handle vma->vm_policy linkages" · bdd77942
      KOSAKI Motohiro authored
      commit 8d34694c upstream.
      
      Commit 05f144a0 ("mm: mempolicy: Let vma_merge and vma_split handle
      vma->vm_policy linkages") removed vma->vm_policy updates code but it is
      the purpose of mbind_range().  Now, mbind_range() is virtually a no-op
      and while it does not allow memory corruption it is not the right fix.
      This patch is a revert.
      
      [mgorman@suse.de: Edited changelog]
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bdd77942