--- /dev/null
+From b7db60f45d74497c723dc7ae1370cf0b37dfb0d8 Mon Sep 17 00:00:00 2001
+From: Feng Tang <feng.tang@intel.com>
+Date: Tue, 31 Jul 2012 12:44:43 +0800
+Subject: ACPI processor: Fix tick_broadcast_mask online/offline regression
+
+From: Feng Tang <feng.tang@intel.com>
+
+commit b7db60f45d74497c723dc7ae1370cf0b37dfb0d8 upstream.
+
+In commit 99b725084 "ACPI processor hotplug: Delay acpi_processor_start()
+call for hotplugged cores", acpi_processor_hotplug(pr) was wrongly replaced
+by acpi_processor_cst_has_changed() inside the acpi_cpu_soft_notify(). This
+patch will restore it back, fixing the tick_broadcast_mask regression:
+ https://lkml.org/lkml/2012/7/30/169
+
+Signed-off-by: Feng Tang <feng.tang@intel.com>
+Cc: Thomas Renninger <trenn@suse.de>
+Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
+Reviewed-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/processor_driver.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/acpi/processor_driver.c
++++ b/drivers/acpi/processor_driver.c
+@@ -442,7 +442,7 @@ static int acpi_cpu_soft_notify(struct n
+ /* Normal CPU soft online event */
+ } else {
+ acpi_processor_ppc_has_changed(pr, 0);
+- acpi_processor_cst_has_changed(pr);
++ acpi_processor_hotplug(pr);
+ acpi_processor_reevaluate_tstate(pr, action);
+ acpi_processor_tstate_has_changed(pr);
+ }
--- /dev/null
+From d4e5979c0da95791aa717c18e162540c7a596360 Mon Sep 17 00:00:00 2001
+From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
+Date: Thu, 2 Aug 2012 11:58:50 +0530
+Subject: ath9k: Add PID/VID support for AR1111
+
+From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
+
+commit d4e5979c0da95791aa717c18e162540c7a596360 upstream.
+
+AR1111 is same as AR9485. The h/w
+difference between them is quite insignificant,
+Felix suggests only very few baseband features
+may not be available in AR1111. The h/w code for
+AR9485 is already present, so AR1111 should
+work fine with the addition of its PID/VID.
+
+Reported-by: Tim Bentley <Tim.Bentley@Gmail.com>
+Cc: Felix Bitterli <felixb@qca.qualcomm.com>
+Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
+Tested-by: Tim Bentley <Tim.Bentley@Gmail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/ath/ath9k/hw.c | 1 +
+ drivers/net/wireless/ath/ath9k/hw.h | 1 +
+ drivers/net/wireless/ath/ath9k/pci.c | 1 +
+ 3 files changed, 3 insertions(+)
+
+--- a/drivers/net/wireless/ath/ath9k/hw.c
++++ b/drivers/net/wireless/ath/ath9k/hw.c
+@@ -740,6 +740,7 @@ int ath9k_hw_init(struct ath_hw *ah)
+ case AR9300_DEVID_AR9340:
+ case AR9300_DEVID_AR9580:
+ case AR9300_DEVID_AR9462:
++ case AR9485_DEVID_AR1111:
+ break;
+ default:
+ if (common->bus_ops->ath_bus_type == ATH_USB)
+--- a/drivers/net/wireless/ath/ath9k/hw.h
++++ b/drivers/net/wireless/ath/ath9k/hw.h
+@@ -48,6 +48,7 @@
+ #define AR9300_DEVID_AR9580 0x0033
+ #define AR9300_DEVID_AR9462 0x0034
+ #define AR9300_DEVID_AR9330 0x0035
++#define AR9485_DEVID_AR1111 0x0037
+
+ #define AR5416_AR9100_DEVID 0x000b
+
+--- a/drivers/net/wireless/ath/ath9k/pci.c
++++ b/drivers/net/wireless/ath/ath9k/pci.c
+@@ -37,6 +37,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_i
+ { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E AR9485 */
+ { PCI_VDEVICE(ATHEROS, 0x0033) }, /* PCI-E AR9580 */
+ { PCI_VDEVICE(ATHEROS, 0x0034) }, /* PCI-E AR9462 */
++ { PCI_VDEVICE(ATHEROS, 0x0037) }, /* PCI-E AR1111/AR9485 */
+ { 0 }
+ };
+
--- /dev/null
+From 4638a83e8615de9c16c39dfed234951d0f468cf1 Mon Sep 17 00:00:00 2001
+From: Olof Johansson <olof@lixom.net>
+Date: Wed, 1 Aug 2012 12:17:27 +0200
+Subject: block: uninitialized ioc->nr_tasks triggers WARN_ON
+
+From: Olof Johansson <olof@lixom.net>
+
+commit 4638a83e8615de9c16c39dfed234951d0f468cf1 upstream.
+
+Hi,
+
+I'm using the old-fashioned 'dump' backup tool, and I noticed that it spews the
+below warning as of 3.5-rc1 and later (3.4 is fine):
+
+[ 10.886893] ------------[ cut here ]------------
+[ 10.886904] WARNING: at include/linux/iocontext.h:140 copy_process+0x1488/0x1560()
+[ 10.886905] Hardware name: Bochs
+[ 10.886906] Modules linked in:
+[ 10.886908] Pid: 2430, comm: dump Not tainted 3.5.0-rc7+ #27
+[ 10.886908] Call Trace:
+[ 10.886911] [<ffffffff8107ce8a>] warn_slowpath_common+0x7a/0xb0
+[ 10.886912] [<ffffffff8107ced5>] warn_slowpath_null+0x15/0x20
+[ 10.886913] [<ffffffff8107c088>] copy_process+0x1488/0x1560
+[ 10.886914] [<ffffffff8107c244>] do_fork+0xb4/0x340
+[ 10.886918] [<ffffffff8108effa>] ? recalc_sigpending+0x1a/0x50
+[ 10.886919] [<ffffffff8108f6b2>] ? __set_task_blocked+0x32/0x80
+[ 10.886920] [<ffffffff81091afa>] ? __set_current_blocked+0x3a/0x60
+[ 10.886923] [<ffffffff81051db3>] sys_clone+0x23/0x30
+[ 10.886925] [<ffffffff8179bd73>] stub_clone+0x13/0x20
+[ 10.886927] [<ffffffff8179baa2>] ? system_call_fastpath+0x16/0x1b
+[ 10.886928] ---[ end trace 32a14af7ee6a590b ]---
+
+Reproducing is easy, I can hit it on a KVM system with a very basic
+config (x86_64 make defconfig + enable the drivers needed). To hit it,
+just install dump (on debian/ubuntu, not sure what the package might be
+called on Fedora), and:
+
+dump -o -f /tmp/foo /
+
+You'll see the warning in dmesg once it forks off the I/O process and
+starts dumping filesystem contents.
+
+I bisected it down to the following commit:
+
+commit f6e8d01bee036460e03bd4f6a79d014f98ba712e
+Author: Tejun Heo <tj@kernel.org>
+Date: Mon Mar 5 13:15:26 2012 -0800
+
+ block: add io_context->active_ref
+
+ Currently ioc->nr_tasks is used to decide two things - whether an ioc
+ is done issuing IOs and whether it's shared by multiple tasks. This
+ patch separate out the first into ioc->active_ref, which is acquired
+ and released using {get|put}_io_context_active() respectively.
+
+ This will be used to associate bio's with a given task. This patch
+ doesn't introduce any visible behavior change.
+
+ Signed-off-by: Tejun Heo <tj@kernel.org>
+ Cc: Vivek Goyal <vgoyal@redhat.com>
+ Signed-off-by: Jens Axboe <axboe@kernel.dk>
+
+It seems like the init of ioc->nr_tasks was removed in that patch,
+so it starts out at 0 instead of 1.
+
+Tejun, is the right thing here to add back the init, or should something else
+be done?
+
+The below patch removes the warning, but I haven't done any more extensive
+testing on it.
+
+Signed-off-by: Olof Johansson <olof@lixom.net>
+Acked-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/blk-ioc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/block/blk-ioc.c
++++ b/block/blk-ioc.c
+@@ -244,6 +244,7 @@ int create_task_io_context(struct task_s
+
+ /* initialize */
+ atomic_long_set(&ioc->refcount, 1);
++ atomic_set(&ioc->nr_tasks, 1);
+ atomic_set(&ioc->active_ref, 1);
+ spin_lock_init(&ioc->lock);
+ INIT_RADIX_TREE(&ioc->icq_tree, GFP_ATOMIC | __GFP_HIGH);
--- /dev/null
+From c0394506e69b37c47d391c2a7bbea3ea236d8ec8 Mon Sep 17 00:00:00 2001
+From: Seth Forshee <seth.forshee@canonical.com>
+Date: Tue, 24 Jul 2012 23:54:11 -0700
+Subject: Input: synaptics - handle out of bounds values from the hardware
+
+From: Seth Forshee <seth.forshee@canonical.com>
+
+commit c0394506e69b37c47d391c2a7bbea3ea236d8ec8 upstream.
+
+The touchpad on the Acer Aspire One D250 will report out of range values
+in the extreme lower portion of the touchpad. These appear as abrupt
+changes in the values reported by the hardware from very low values to
+very high values, which can cause unexpected vertical jumps in the
+position of the mouse pointer.
+
+What seems to be happening is that the value is wrapping to a two's
+compliment negative value of higher resolution than the 13-bit value
+reported by the hardware, with the high-order bits being truncated. This
+patch adds handling for these values by converting them to the
+appropriate negative values.
+
+The only tricky part about this is deciding when to treat a number as
+negative. It stands to reason that if out of range values can be
+reported on the low end then it could also happen on the high end, so
+not all out of range values should be treated as negative. The approach
+taken here is to split the difference between the maximum legitimate
+value for the axis and the maximum possible value that the hardware can
+report, treating values greater than this number as negative and all
+other values as positive. This can be tweaked later if hardware is found
+that operates outside of these parameters.
+
+BugLink: http://bugs.launchpad.net/bugs/1001251
+Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
+Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/synaptics.c | 22 ++++++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+--- a/drivers/input/mouse/synaptics.c
++++ b/drivers/input/mouse/synaptics.c
+@@ -40,11 +40,27 @@
+ * Note that newer firmware allows querying device for maximum useable
+ * coordinates.
+ */
++#define XMIN 0
++#define XMAX 6143
++#define YMIN 0
++#define YMAX 6143
+ #define XMIN_NOMINAL 1472
+ #define XMAX_NOMINAL 5472
+ #define YMIN_NOMINAL 1408
+ #define YMAX_NOMINAL 4448
+
++/* Size in bits of absolute position values reported by the hardware */
++#define ABS_POS_BITS 13
++
++/*
++ * Any position values from the hardware above the following limits are
++ * treated as "wrapped around negative" values that have been truncated to
++ * the 13-bit reporting range of the hardware. These are just reasonable
++ * guesses and can be adjusted if hardware is found that operates outside
++ * of these parameters.
++ */
++#define X_MAX_POSITIVE (((1 << ABS_POS_BITS) + XMAX) / 2)
++#define Y_MAX_POSITIVE (((1 << ABS_POS_BITS) + YMAX) / 2)
+
+ /*****************************************************************************
+ * Stuff we need even when we do not want native Synaptics support
+@@ -555,6 +571,12 @@ static int synaptics_parse_hw_state(cons
+ hw->right = (buf[0] & 0x02) ? 1 : 0;
+ }
+
++ /* Convert wrap-around values to negative */
++ if (hw->x > X_MAX_POSITIVE)
++ hw->x -= 1 << ABS_POS_BITS;
++ if (hw->y > Y_MAX_POSITIVE)
++ hw->y -= 1 << ABS_POS_BITS;
++
+ return 0;
+ }
+
--- /dev/null
+From dd4c9260e7f23f2e951cbfb2726e468c6d30306c Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Wed, 1 Aug 2012 21:03:21 +0200
+Subject: mac80211: cancel mesh path timer
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit dd4c9260e7f23f2e951cbfb2726e468c6d30306c upstream.
+
+The mesh path timer needs to be canceled when
+leaving the mesh as otherwise it could fire
+after the interface has been removed already.
+
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/mesh.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/mac80211/mesh.c
++++ b/net/mac80211/mesh.c
+@@ -621,6 +621,7 @@ void ieee80211_stop_mesh(struct ieee8021
+
+ del_timer_sync(&sdata->u.mesh.housekeeping_timer);
+ del_timer_sync(&sdata->u.mesh.mesh_path_root_timer);
++ del_timer_sync(&sdata->u.mesh.mesh_path_timer);
+ /*
+ * If the timer fired while we waited for it, it will have
+ * requeued the work. Now the work will be running again
--- /dev/null
+From b7219ccb33aa0df9949a60c68b5e9f712615e56f Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Tue, 31 Jul 2012 10:05:34 +1000
+Subject: md/raid1: don't abort a resync on the first badblock.
+
+From: NeilBrown <neilb@suse.de>
+
+commit b7219ccb33aa0df9949a60c68b5e9f712615e56f upstream.
+
+If a resync of a RAID1 array with 2 devices finds a known bad block
+one device it will neither read from, or write to, that device for
+this block offset.
+So there will be one read_target (The other device) and zero write
+targets.
+This condition causes md/raid1 to abort the resync assuming that it
+has finished - without known bad blocks this would be true.
+
+When there are no write targets because of the presence of bad blocks
+we should only skip over the area covered by the bad block.
+RAID10 already gets this right, raid1 doesn't. Or didn't.
+
+As this can cause a 'sync' to abort early and appear to have succeeded
+it could lead to some data corruption, so it suitable for -stable.
+
+Reported-by: Alexander Lyakas <alex.bolshoy@gmail.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid1.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid1.c
++++ b/drivers/md/raid1.c
+@@ -2428,7 +2428,10 @@ static sector_t sync_request(struct mdde
+ /* There is nowhere to write, so all non-sync
+ * drives must be failed - so we are finished
+ */
+- sector_t rv = max_sector - sector_nr;
++ sector_t rv;
++ if (min_bad > 0)
++ max_sector = sector_nr + min_bad;
++ rv = max_sector - sector_nr;
+ *skipped = 1;
+ put_buf(r1_bio);
+ return rv;
--- /dev/null
+From 25099335944a23db75d4916644122c746684e093 Mon Sep 17 00:00:00 2001
+From: Karsten Keil <keil@b1-systems.de>
+Date: Sat, 4 Aug 2012 00:14:25 +0000
+Subject: mISDN: Bugfix for layer2 fixed TEI mode
+
+From: Karsten Keil <keil@b1-systems.de>
+
+commit 25099335944a23db75d4916644122c746684e093 upstream.
+
+If a fixed TEI is used, the initial state of the layer 2 statmachine need to be
+4 (TEI assigned). This was true only for Point to Point connections, but not
+for the other fixed TEIs. It was not found before, because usually only the
+TEI 0 is used as fixed TEI for PtP mode, but if you try X31 packet mode
+connections with SAPI 16, TEI 1, it did fail.
+
+Signed-off-by: Karsten Keil <keil@b1-systems.de>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/isdn/mISDN/layer2.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/isdn/mISDN/layer2.c
++++ b/drivers/isdn/mISDN/layer2.c
+@@ -2222,7 +2222,7 @@ create_l2(struct mISDNchannel *ch, u_int
+ InitWin(l2);
+ l2->l2m.fsm = &l2fsm;
+ if (test_bit(FLG_LAPB, &l2->flag) ||
+- test_bit(FLG_PTP, &l2->flag) ||
++ test_bit(FLG_FIXED_TEI, &l2->flag) ||
+ test_bit(FLG_LAPD_NET, &l2->flag))
+ l2->l2m.state = ST_L2_4;
+ else
--- /dev/null
+From 3ad3d901bbcfb15a5e4690e55350db0899095a68 Mon Sep 17 00:00:00 2001
+From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
+Date: Tue, 31 Jul 2012 16:45:52 -0700
+Subject: mm: mmu_notifier: fix freed page still mapped in secondary MMU
+
+From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
+
+commit 3ad3d901bbcfb15a5e4690e55350db0899095a68 upstream.
+
+mmu_notifier_release() is called when the process is exiting. It will
+delete all the mmu notifiers. But at this time the page belonging to the
+process is still present in page tables and is present on the LRU list, so
+this race will happen:
+
+ CPU 0 CPU 1
+mmu_notifier_release: try_to_unmap:
+ hlist_del_init_rcu(&mn->hlist);
+ ptep_clear_flush_notify:
+ mmu nofifler not found
+ free page !!!!!!
+ /*
+ * At the point, the page has been
+ * freed, but it is still mapped in
+ * the secondary MMU.
+ */
+
+ mn->ops->release(mn, mm);
+
+Then the box is not stable and sometimes we can get this bug:
+
+[ 738.075923] BUG: Bad page state in process migrate-perf pfn:03bec
+[ 738.075931] page:ffffea00000efb00 count:0 mapcount:0 mapping: (null) index:0x8076
+[ 738.075936] page flags: 0x20000000000014(referenced|dirty)
+
+The same issue is present in mmu_notifier_unregister().
+
+We can call ->release before deleting the notifier to ensure the page has
+been unmapped from the secondary MMU before it is freed.
+
+Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
+Cc: Avi Kivity <avi@redhat.com>
+Cc: Marcelo Tosatti <mtosatti@redhat.com>
+Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/mmu_notifier.c | 45 +++++++++++++++++++++++----------------------
+ 1 file changed, 23 insertions(+), 22 deletions(-)
+
+--- a/mm/mmu_notifier.c
++++ b/mm/mmu_notifier.c
+@@ -33,6 +33,24 @@
+ void __mmu_notifier_release(struct mm_struct *mm)
+ {
+ struct mmu_notifier *mn;
++ struct hlist_node *n;
++
++ /*
++ * RCU here will block mmu_notifier_unregister until
++ * ->release returns.
++ */
++ rcu_read_lock();
++ hlist_for_each_entry_rcu(mn, n, &mm->mmu_notifier_mm->list, hlist)
++ /*
++ * if ->release runs before mmu_notifier_unregister it
++ * must be handled as it's the only way for the driver
++ * to flush all existing sptes and stop the driver
++ * from establishing any more sptes before all the
++ * pages in the mm are freed.
++ */
++ if (mn->ops->release)
++ mn->ops->release(mn, mm);
++ rcu_read_unlock();
+
+ spin_lock(&mm->mmu_notifier_mm->lock);
+ while (unlikely(!hlist_empty(&mm->mmu_notifier_mm->list))) {
+@@ -46,23 +64,6 @@ void __mmu_notifier_release(struct mm_st
+ * mmu_notifier_unregister to return.
+ */
+ hlist_del_init_rcu(&mn->hlist);
+- /*
+- * RCU here will block mmu_notifier_unregister until
+- * ->release returns.
+- */
+- rcu_read_lock();
+- spin_unlock(&mm->mmu_notifier_mm->lock);
+- /*
+- * if ->release runs before mmu_notifier_unregister it
+- * must be handled as it's the only way for the driver
+- * to flush all existing sptes and stop the driver
+- * from establishing any more sptes before all the
+- * pages in the mm are freed.
+- */
+- if (mn->ops->release)
+- mn->ops->release(mn, mm);
+- rcu_read_unlock();
+- spin_lock(&mm->mmu_notifier_mm->lock);
+ }
+ spin_unlock(&mm->mmu_notifier_mm->lock);
+
+@@ -284,16 +285,13 @@ void mmu_notifier_unregister(struct mmu_
+ {
+ BUG_ON(atomic_read(&mm->mm_count) <= 0);
+
+- spin_lock(&mm->mmu_notifier_mm->lock);
+ if (!hlist_unhashed(&mn->hlist)) {
+- hlist_del_rcu(&mn->hlist);
+-
+ /*
+ * RCU here will force exit_mmap to wait ->release to finish
+ * before freeing the pages.
+ */
+ rcu_read_lock();
+- spin_unlock(&mm->mmu_notifier_mm->lock);
++
+ /*
+ * exit_mmap will block in mmu_notifier_release to
+ * guarantee ->release is called before freeing the
+@@ -302,8 +300,11 @@ void mmu_notifier_unregister(struct mmu_
+ if (mn->ops->release)
+ mn->ops->release(mn, mm);
+ rcu_read_unlock();
+- } else
++
++ spin_lock(&mm->mmu_notifier_mm->lock);
++ hlist_del_rcu(&mn->hlist);
+ spin_unlock(&mm->mmu_notifier_mm->lock);
++ }
+
+ /*
+ * Wait any running method to finish, of course including
--- /dev/null
+From ca57df79d4f64e1a4886606af4289d40636189c5 Mon Sep 17 00:00:00 2001
+From: Xishi Qiu <qiuxishi@huawei.com>
+Date: Tue, 31 Jul 2012 16:43:19 -0700
+Subject: mm: setup pageblock_order before it's used by sparsemem
+
+From: Xishi Qiu <qiuxishi@huawei.com>
+
+commit ca57df79d4f64e1a4886606af4289d40636189c5 upstream.
+
+On architectures with CONFIG_HUGETLB_PAGE_SIZE_VARIABLE set, such as
+Itanium, pageblock_order is a variable with default value of 0. It's set
+to the right value by set_pageblock_order() in function
+free_area_init_core().
+
+But pageblock_order may be used by sparse_init() before free_area_init_core()
+is called along path:
+sparse_init()
+ ->sparse_early_usemaps_alloc_node()
+ ->usemap_size()
+ ->SECTION_BLOCKFLAGS_BITS
+ ->((1UL << (PFN_SECTION_SHIFT - pageblock_order)) *
+NR_PAGEBLOCK_BITS)
+
+The uninitialized pageblock_size will cause memory wasting because
+usemap_size() returns a much bigger value then it's really needed.
+
+For example, on an Itanium platform,
+sparse_init() pageblock_order=0 usemap_size=24576
+free_area_init_core() before pageblock_order=0, usemap_size=24576
+free_area_init_core() after pageblock_order=12, usemap_size=8
+
+That means 24K memory has been wasted for each section, so fix it by calling
+set_pageblock_order() from sparse_init().
+
+Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
+Signed-off-by: Jiang Liu <liuj97@gmail.com>
+Cc: Tony Luck <tony.luck@intel.com>
+Cc: Yinghai Lu <yinghai@kernel.org>
+Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
+Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Keping Chen <chenkeping@huawei.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/internal.h | 2 ++
+ mm/page_alloc.c | 4 ++--
+ mm/sparse.c | 3 +++
+ 3 files changed, 7 insertions(+), 2 deletions(-)
+
+--- a/mm/internal.h
++++ b/mm/internal.h
+@@ -347,3 +347,5 @@ extern u32 hwpoison_filter_enable;
+ extern unsigned long vm_mmap_pgoff(struct file *, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long);
++
++extern void set_pageblock_order(void);
+--- a/mm/page_alloc.c
++++ b/mm/page_alloc.c
+@@ -4301,7 +4301,7 @@ static inline void setup_usemap(struct p
+ #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
+
+ /* Initialise the number of pages represented by NR_PAGEBLOCK_BITS */
+-static inline void __init set_pageblock_order(void)
++void __init set_pageblock_order(void)
+ {
+ unsigned int order;
+
+@@ -4329,7 +4329,7 @@ static inline void __init set_pageblock_
+ * include/linux/pageblock-flags.h for the values of pageblock_order based on
+ * the kernel config
+ */
+-static inline void set_pageblock_order(void)
++void __init set_pageblock_order(void)
+ {
+ }
+
+--- a/mm/sparse.c
++++ b/mm/sparse.c
+@@ -493,6 +493,9 @@ void __init sparse_init(void)
+ struct page **map_map;
+ #endif
+
++ /* Setup pageblock_order for HUGETLB_PAGE_SIZE_VARIABLE */
++ set_pageblock_order();
++
+ /*
+ * map is using big page (aka 2M in x86 64 bit)
+ * usemap is less one page (aka 24 bytes)
--- /dev/null
+From 9e62bb4458ad2cf28bd701aa5fab380b846db326 Mon Sep 17 00:00:00 2001
+From: Boaz Harrosh <bharrosh@panasas.com>
+Date: Wed, 1 Aug 2012 17:48:36 +0300
+Subject: ore: Fix out-of-bounds access in _ios_obj()
+
+From: Boaz Harrosh <bharrosh@panasas.com>
+
+commit 9e62bb4458ad2cf28bd701aa5fab380b846db326 upstream.
+
+_ios_obj() is accessed by group_index not device_table index.
+
+The oc->comps array is only a group_full of devices at a time
+it is not like ore_comp_dev() which is indexed by a global
+device_table index.
+
+This did not BUG until now because exofs only uses a single
+COMP for all devices. But with other FSs like PanFS this is
+not true.
+
+This bug was only in the write_path, all other users were
+using it correctly
+
+[This is a bug since 3.2 Kernel]
+
+Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/exofs/ore.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/fs/exofs/ore.c
++++ b/fs/exofs/ore.c
+@@ -837,11 +837,11 @@ static int _write_mirror(struct ore_io_s
+ bio->bi_rw |= REQ_WRITE;
+ }
+
+- osd_req_write(or, _ios_obj(ios, dev), per_dev->offset,
+- bio, per_dev->length);
++ osd_req_write(or, _ios_obj(ios, cur_comp),
++ per_dev->offset, bio, per_dev->length);
+ ORE_DBGMSG("write(0x%llx) offset=0x%llx "
+ "length=0x%llx dev=%d\n",
+- _LLU(_ios_obj(ios, dev)->id),
++ _LLU(_ios_obj(ios, cur_comp)->id),
+ _LLU(per_dev->offset),
+ _LLU(per_dev->length), dev);
+ } else if (ios->kern_buff) {
+@@ -853,20 +853,20 @@ static int _write_mirror(struct ore_io_s
+ (ios->si.unit_off + ios->length >
+ ios->layout->stripe_unit));
+
+- ret = osd_req_write_kern(or, _ios_obj(ios, per_dev->dev),
++ ret = osd_req_write_kern(or, _ios_obj(ios, cur_comp),
+ per_dev->offset,
+ ios->kern_buff, ios->length);
+ if (unlikely(ret))
+ goto out;
+ ORE_DBGMSG2("write_kern(0x%llx) offset=0x%llx "
+ "length=0x%llx dev=%d\n",
+- _LLU(_ios_obj(ios, dev)->id),
++ _LLU(_ios_obj(ios, cur_comp)->id),
+ _LLU(per_dev->offset),
+ _LLU(ios->length), per_dev->dev);
+ } else {
+- osd_req_set_attributes(or, _ios_obj(ios, dev));
++ osd_req_set_attributes(or, _ios_obj(ios, cur_comp));
+ ORE_DBGMSG2("obj(0x%llx) set_attributes=%d dev=%d\n",
+- _LLU(_ios_obj(ios, dev)->id),
++ _LLU(_ios_obj(ios, cur_comp)->id),
+ ios->out_attr_len, dev);
+ }
+
alsa-hda-add-dock-support-for-thinkpad-x230.patch
alsa-hda-remove-quirk-for-dell-vostro-1015.patch
alsa-hda-fix-double-quirk-for-quanta-fl1-lenovo-ideapad.patch
+mm-setup-pageblock_order-before-it-s-used-by-sparsemem.patch
+mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch
+md-raid1-don-t-abort-a-resync-on-the-first-badblock.patch
+video-smscufx-fix-line-counting-in-fb_write.patch
+block-uninitialized-ioc-nr_tasks-triggers-warn_on.patch
+sh-fix-up-recursive-fault-in-oops-with-unset-ttb.patch
+ore-fix-out-of-bounds-access-in-_ios_obj.patch
+acpi-processor-fix-tick_broadcast_mask-online-offline-regression.patch
+misdn-bugfix-for-layer2-fixed-tei-mode.patch
+mac80211-cancel-mesh-path-timer.patch
+ath9k-add-pid-vid-support-for-ar1111.patch
+wireless-reg-restore-previous-behaviour-of-chan-max_power-calculations.patch
+x86-nops-missing-break-resulting-in-incorrect-selection-on-intel.patch
+x86-64-kcmp-the-kcmp-system-call-can-be-common.patch
+input-synaptics-handle-out-of-bounds-values-from-the-hardware.patch
--- /dev/null
+From 90eed7d87b748f9c0d11b9bad64a4c41e31b78c4 Mon Sep 17 00:00:00 2001
+From: Paul Mundt <lethal@linux-sh.org>
+Date: Tue, 24 Jul 2012 13:15:54 +0900
+Subject: sh: Fix up recursive fault in oops with unset TTB.
+
+From: Paul Mundt <lethal@linux-sh.org>
+
+commit 90eed7d87b748f9c0d11b9bad64a4c41e31b78c4 upstream.
+
+Presently the oops code looks for the pgd either from the mm context or
+the cached TTB value. There are presently cases where the TTB can be
+unset or otherwise cleared by hardware, which we weren't handling,
+resulting in recursive faults on the NULL pgd. In these cases we can
+simply reload from swapper_pg_dir and continue on as normal.
+
+Signed-off-by: Paul Mundt <lethal@linux-sh.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/sh/mm/fault.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/arch/sh/mm/fault.c
++++ b/arch/sh/mm/fault.c
+@@ -58,11 +58,15 @@ static void show_pte(struct mm_struct *m
+ {
+ pgd_t *pgd;
+
+- if (mm)
++ if (mm) {
+ pgd = mm->pgd;
+- else
++ } else {
+ pgd = get_TTB();
+
++ if (unlikely(!pgd))
++ pgd = swapper_pg_dir;
++ }
++
+ printk(KERN_ALERT "pgd = %p\n", pgd);
+ pgd += pgd_index(addr);
+ printk(KERN_ALERT "[%08lx] *pgd=%0*Lx", addr,
--- /dev/null
+From 2fe2d9f47cfe1a3e66e7d087368b3d7155b04c15 Mon Sep 17 00:00:00 2001
+From: Alexander Holler <holler@ahsoftware.de>
+Date: Sat, 21 Apr 2012 00:11:07 +0200
+Subject: video/smscufx: fix line counting in fb_write
+
+From: Alexander Holler <holler@ahsoftware.de>
+
+commit 2fe2d9f47cfe1a3e66e7d087368b3d7155b04c15 upstream.
+
+Line 0 and 1 were both written to line 0 (on the display) and all subsequent
+lines had an offset of -1. The result was that the last line on the display
+was never overwritten by writes to /dev/fbN.
+
+The origin of this bug seems to have been udlfb.
+
+Signed-off-by: Alexander Holler <holler@ahsoftware.de>
+Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/smscufx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/video/smscufx.c
++++ b/drivers/video/smscufx.c
+@@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_i
+ result = fb_sys_write(info, buf, count, ppos);
+
+ if (result > 0) {
+- int start = max((int)(offset / info->fix.line_length) - 1, 0);
++ int start = max((int)(offset / info->fix.line_length), 0);
+ int lines = min((u32)((result / info->fix.line_length) + 1),
+ (u32)info->var.yres);
+
--- /dev/null
+From 5e31fc0815a4e2c72b1b495fe7a0d8f9bfb9e4b4 Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+Date: Tue, 24 Jul 2012 08:35:39 +0200
+Subject: wireless: reg: restore previous behaviour of chan->max_power calculations
+
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+
+commit 5e31fc0815a4e2c72b1b495fe7a0d8f9bfb9e4b4 upstream.
+
+commit eccc068e8e84c8fe997115629925e0422a98e4de
+Author: Hong Wu <Hong.Wu@dspg.com>
+Date: Wed Jan 11 20:33:39 2012 +0200
+
+ wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit pow
+
+changed the way we calculate chan->max_power as min(chan->max_power,
+chan->max_reg_power). That broke rt2x00 (and perhaps some other
+drivers) that do not set chan->max_power. It is not so easy to fix this
+problem correctly in rt2x00.
+
+According to commit eccc068e8 changelog, change claim only to save
+maximum regulatory power - changing setting of chan->max_power was side
+effect. This patch restore previous calculations of chan->max_power and
+do not touch chan->max_reg_power.
+
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/wireless/reg.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+--- a/net/wireless/reg.c
++++ b/net/wireless/reg.c
+@@ -891,7 +891,21 @@ static void handle_channel(struct wiphy
+ chan->max_antenna_gain = min(chan->orig_mag,
+ (int) MBI_TO_DBI(power_rule->max_antenna_gain));
+ chan->max_reg_power = (int) MBM_TO_DBM(power_rule->max_eirp);
+- chan->max_power = min(chan->max_power, chan->max_reg_power);
++ if (chan->orig_mpwr) {
++ /*
++ * Devices that have their own custom regulatory domain
++ * but also use WIPHY_FLAG_STRICT_REGULATORY will follow the
++ * passed country IE power settings.
++ */
++ if (initiator == NL80211_REGDOM_SET_BY_COUNTRY_IE &&
++ wiphy->flags & WIPHY_FLAG_CUSTOM_REGULATORY &&
++ wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY)
++ chan->max_power = chan->max_reg_power;
++ else
++ chan->max_power = min(chan->orig_mpwr,
++ chan->max_reg_power);
++ } else
++ chan->max_power = chan->max_reg_power;
+ }
+
+ static void handle_band(struct wiphy *wiphy,
--- /dev/null
+From eaf4ce6c5fed6b4c55f7efcd5fc3477435cab5e9 Mon Sep 17 00:00:00 2001
+From: "H. Peter Anvin" <hpa@linux.intel.com>
+Date: Wed, 1 Aug 2012 15:59:58 -0700
+Subject: x86-64, kcmp: The kcmp system call can be common
+
+From: "H. Peter Anvin" <hpa@linux.intel.com>
+
+commit eaf4ce6c5fed6b4c55f7efcd5fc3477435cab5e9 upstream.
+
+We already use the same system call handler for i386 and x86-64, there
+is absolutely no reason x32 can't use the same system call, too.
+
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Cc: H.J. Lu <hjl.tools@gmail.com>
+Cc: Cyrill Gorcunov <gorcunov@openvz.org>
+Link: http://lkml.kernel.org/n/tip-vwzk3qbcr3yjyxjg2j38vgy9@git.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/syscalls/syscall_64.tbl | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/syscalls/syscall_64.tbl
++++ b/arch/x86/syscalls/syscall_64.tbl
+@@ -318,7 +318,7 @@
+ 309 common getcpu sys_getcpu
+ 310 64 process_vm_readv sys_process_vm_readv
+ 311 64 process_vm_writev sys_process_vm_writev
+-312 64 kcmp sys_kcmp
++312 common kcmp sys_kcmp
+
+ #
+ # x32-specific system call numbers start at 512 to avoid cache impact
--- /dev/null
+From d6250a3f12edb3a86db9598ffeca3de8b4a219e9 Mon Sep 17 00:00:00 2001
+From: Alan Cox <alan@linux.intel.com>
+Date: Wed, 25 Jul 2012 16:28:19 +0100
+Subject: x86, nops: Missing break resulting in incorrect selection on Intel
+
+From: Alan Cox <alan@linux.intel.com>
+
+commit d6250a3f12edb3a86db9598ffeca3de8b4a219e9 upstream.
+
+The Intel case falls through into the generic case which then changes
+the values. For cases like the P6 it doesn't do the right thing so
+this seems to be a screwup.
+
+Signed-off-by: Alan Cox <alan@linux.intel.com>
+Link: http://lkml.kernel.org/n/tip-lww2uirad4skzjlmrm0vru8o@git.kernel.org
+Signed-off-by: H. Peter Anvin <hpa@zytor.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/alternative.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/alternative.c
++++ b/arch/x86/kernel/alternative.c
+@@ -219,7 +219,7 @@ void __init arch_init_ideal_nops(void)
+ ideal_nops = intel_nops;
+ #endif
+ }
+-
++ break;
+ default:
+ #ifdef CONFIG_X86_64
+ ideal_nops = k8_nops;
projects / thirdparty / kernel / stable-queue.git / commitdiff
