--- /dev/null
+From hughd@google.com Wed Apr 10 13:39:41 2013
+From: Hugh Dickins <hughd@google.com>
+Date: Mon, 8 Apr 2013 13:00:02 -0700 (PDT)
+Subject: mm: prevent mmap_cache race in find_vma()
+To: gregkh@linuxfoundation.org
+Cc: Ben Hutchings <ben@decadent.org.uk>, jstancek@redhat.com, rientjes@google.com, torvalds@linux-foundation.org, stable@vger.kernel.org, stable-commits@vger.kernel.org
+Message-ID: <alpine.LNX.2.00.1304081244250.2677@eggly.anvils>
+
+From: Jan Stancek <jstancek@redhat.com>
+
+commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c upstream.
+
+find_vma() can be called by multiple threads with read lock
+held on mm->mmap_sem and any of them can update mm->mmap_cache.
+Prevent compiler from re-fetching mm->mmap_cache, because other
+readers could update it in the meantime:
+
+ thread 1 thread 2
+ |
+ find_vma() | find_vma()
+ struct vm_area_struct *vma = NULL; |
+ vma = mm->mmap_cache; |
+ if (!(vma && vma->vm_end > addr |
+ && vma->vm_start <= addr)) { |
+ | mm->mmap_cache = vma;
+ return vma; |
+ ^^ compiler may optimize this |
+ local variable out and re-read |
+ mm->mmap_cache |
+
+This issue can be reproduced with gcc-4.8.0-1 on s390x by running
+mallocstress testcase from LTP, which triggers:
+
+ kernel BUG at mm/rmap.c:1088!
+ Call Trace:
+ ([<000003d100c57000>] 0x3d100c57000)
+ [<000000000023a1c0>] do_wp_page+0x2fc/0xa88
+ [<000000000023baae>] handle_pte_fault+0x41a/0xac8
+ [<000000000023d832>] handle_mm_fault+0x17a/0x268
+ [<000000000060507a>] do_protection_exception+0x1e2/0x394
+ [<0000000000603a04>] pgm_check_handler+0x138/0x13c
+ [<000003fffcf1f07a>] 0x3fffcf1f07a
+ Last Breaking-Event-Address:
+ [<000000000024755e>] page_add_new_anon_rmap+0xc2/0x168
+
+Thanks to Jakub Jelinek for his insight on gcc and helping to
+track this down.
+
+Signed-off-by: Jan Stancek <jstancek@redhat.com>
+Acked-by: David Rientjes <rientjes@google.com>
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+[bwh: Backported to 3.2: adjust context, indentation]
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/mmap.c | 2 +-
+ mm/nommu.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -1581,7 +1581,7 @@ struct vm_area_struct *find_vma(struct m
+ if (mm) {
+ /* Check the cache first. */
+ /* (Cache hit rate is typically around 35%.) */
+- vma = mm->mmap_cache;
++ vma = ACCESS_ONCE(mm->mmap_cache);
+ if (!(vma && vma->vm_end > addr && vma->vm_start <= addr)) {
+ struct rb_node * rb_node;
+
+--- a/mm/nommu.c
++++ b/mm/nommu.c
+@@ -808,7 +808,7 @@ struct vm_area_struct *find_vma(struct m
+ struct vm_area_struct *vma;
+
+ /* check the cache first */
+- vma = mm->mmap_cache;
++ vma = ACCESS_ONCE(mm->mmap_cache);
+ if (vma && vma->vm_start <= addr && vma->vm_end > addr)
+ return vma;
+
--- /dev/null
+From foo@baz Wed Apr 10 15:21:39 PDT 2013
+Date: Wed, 10 Apr 2013 15:21:39 -0700
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+To: Greg KH <gregkh@linuxfoundation.org>
+Subject: Revert "mwifiex: cancel cmd timer and free curr_cmd in shutdown process
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+revert commit b9f1f48ce20a1b923429c216669d03b5a900a8cf which is commit
+084c7189acb3f969c855536166042e27f5dd703f upstream.
+
+It shouldn't have been applied to the 3.0-stable tree.
+
+Reported-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Marco Cesarano <marco@marvell.com>
+Reported-by: Bing Zhao <bzhao@marvell.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/mwifiex/init.c | 8 --------
+ 1 file changed, 8 deletions(-)
+
+--- a/drivers/net/wireless/mwifiex/init.c
++++ b/drivers/net/wireless/mwifiex/init.c
+@@ -561,14 +561,6 @@ mwifiex_shutdown_drv(struct mwifiex_adap
+ return ret;
+ }
+
+- /* cancel current command */
+- if (adapter->curr_cmd) {
+- dev_warn(adapter->dev, "curr_cmd is still in processing\n");
+- del_timer(&adapter->cmd_timer);
+- mwifiex_insert_cmd_to_free_q(adapter, adapter->curr_cmd);
+- adapter->curr_cmd = NULL;
+- }
+-
+ /* shut down mwifiex */
+ dev_dbg(adapter->dev, "info: shutdown mwifiex...\n");
+
--- /dev/null
+From 83589b30f1e1dc9898986293c9336b8ce1705dec Mon Sep 17 00:00:00 2001
+From: Tim Gardner <tim.gardner@canonical.com>
+Date: Mon, 18 Feb 2013 12:56:28 -0700
+Subject: rt2x00: rt2x00pci_regbusy_read() - only print register access failure once
+
+From: Tim Gardner <tim.gardner@canonical.com>
+
+commit 83589b30f1e1dc9898986293c9336b8ce1705dec upstream.
+
+BugLink: http://bugs.launchpad.net/bugs/1128840
+
+It appears that when this register read fails it never recovers, so
+I think there is no need to repeat the same error message ad infinitum.
+
+Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
+Cc: Ivo van Doorn <IvDoorn@gmail.com>
+Cc: Gertjan van Wingerde <gwingerde@gmail.com>
+Cc: Helmut Schaa <helmut.schaa@googlemail.com>
+Cc: "John W. Linville" <linville@tuxdriver.com>
+Cc: linux-wireless@vger.kernel.org
+Cc: users@rt2x00.serialmonkey.com
+Cc: netdev@vger.kernel.org
+Cc: stable@vger.kernel.org
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/rt2x00/rt2x00pci.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
++++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
+@@ -52,8 +52,8 @@ int rt2x00pci_regbusy_read(struct rt2x00
+ udelay(REGISTER_BUSY_DELAY);
+ }
+
+- ERROR(rt2x00dev, "Indirect register access failed: "
+- "offset=0x%.08x, value=0x%.08x\n", offset, *reg);
++ printk_once(KERN_ERR "%s() Indirect register access failed: "
++ "offset=0x%.08x, value=0x%.08x\n", __func__, offset, *reg);
+ *reg = ~0;
+
+ return 0;
crypto-gcm-fix-assumption-that-assoc-has-one-segment.patch
block-avoid-using-uninitialized-value-in-from-queue_var_store.patch
thermal-return-an-error-on-failure-to-register-thermal-class.patch
+mm-prevent-mmap_cache-race-in-find_vma.patch
+x86-32-mm-rip-out-x86_32-numa-remapping-code.patch
+revert-mwifiex-cancel-cmd-timer-and-free-curr_cmd-in-shutdown-process.patch
+rt2x00-rt2x00pci_regbusy_read-only-print-register-access-failure-once.patch
--- /dev/null
+From f03574f2d5b2d6229dcdf2d322848065f72953c7 Mon Sep 17 00:00:00 2001
+From: Dave Hansen <dave@linux.vnet.ibm.com>
+Date: Wed, 30 Jan 2013 16:56:16 -0800
+Subject: x86-32, mm: Rip out x86_32 NUMA remapping code
+
+From: Dave Hansen <dave@linux.vnet.ibm.com>
+
+commit f03574f2d5b2d6229dcdf2d322848065f72953c7 upstream.
+
+This code was an optimization for 32-bit NUMA systems.
+
+It has probably been the cause of a number of subtle bugs over
+the years, although the conditions to excite them would have
+been hard to trigger. Essentially, we remap part of the kernel
+linear mapping area, and then sometimes part of that area gets
+freed back in to the bootmem allocator. If those pages get
+used by kernel data structures (say mem_map[] or a dentry),
+there's no big deal. But, if anyone ever tried to use the
+linear mapping for these pages _and_ cared about their physical
+address, bad things happen.
+
+For instance, say you passed __GFP_ZERO to the page allocator
+and then happened to get handed one of these pages, it zero the
+remapped page, but it would make a pte to the _old_ page.
+There are probably a hundred other ways that it could screw
+with things.
+
+We don't need to hang on to performance optimizations for
+these old boxes any more. All my 32-bit NUMA systems are long
+dead and buried, and I probably had access to more than most
+people.
+
+This code is causing real things to break today:
+
+ https://lkml.org/lkml/2013/1/9/376
+
+I looked in to actually fixing this, but it requires surgery
+to way too much brittle code, as well as stuff like
+per_cpu_ptr_to_phys().
+
+[ hpa: Cc: this for -stable, since it is a memory corruption issue.
+ However, an alternative is to simply mark NUMA as depends BROKEN
+ rather than EXPERIMENTAL in the X86_32 subclause... ]
+
+Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.com
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Cc: Jiri Slaby <jslaby@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/Kconfig | 4 ----
+ arch/x86/mm/numa.c | 3 ---
+ arch/x86/mm/numa_internal.h | 6 ------
+ 3 files changed, 13 deletions(-)
+
+--- a/arch/x86/Kconfig
++++ b/arch/x86/Kconfig
+@@ -1219,10 +1219,6 @@ config HAVE_ARCH_BOOTMEM
+ def_bool y
+ depends on X86_32 && NUMA
+
+-config HAVE_ARCH_ALLOC_REMAP
+- def_bool y
+- depends on X86_32 && NUMA
+-
+ config ARCH_HAVE_MEMORY_PRESENT
+ def_bool y
+ depends on X86_32 && DISCONTIGMEM
+--- a/arch/x86/mm/numa.c
++++ b/arch/x86/mm/numa.c
+@@ -207,9 +207,6 @@ static void __init setup_node_data(int n
+ if (end && (end - start) < NODE_MIN_SIZE)
+ return;
+
+- /* initialize remap allocator before aligning to ZONE_ALIGN */
+- init_alloc_remap(nid, start, end);
+-
+ start = roundup(start, ZONE_ALIGN);
+
+ printk(KERN_INFO "Initmem setup node %d %016Lx-%016Lx\n",
+--- a/arch/x86/mm/numa_internal.h
++++ b/arch/x86/mm/numa_internal.h
+@@ -21,12 +21,6 @@ void __init numa_reset_distance(void);
+
+ void __init x86_numa_init(void);
+
+-#ifdef CONFIG_X86_64
+-static inline void init_alloc_remap(int nid, u64 start, u64 end) { }
+-#else
+-void __init init_alloc_remap(int nid, u64 start, u64 end);
+-#endif
+-
+ #ifdef CONFIG_NUMA_EMU
+ void __init numa_emulation(struct numa_meminfo *numa_meminfo,
+ int numa_dist_cnt);
projects / thirdparty / kernel / stable-queue.git / commitdiff
