From: Greg Kroah-Hartman Date: Thu, 9 Aug 2012 18:54:27 +0000 (-0700) Subject: 3.5-stable patches X-Git-Tag: v3.5.2~31 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=40c521da6160b81d7fec358888aebe9aac820cbf;p=thirdparty%2Fkernel%2Fstable-queue.git 3.5-stable patches added patches: acpi-processor-fix-tick_broadcast_mask-online-offline-regression.patch ath9k-add-pid-vid-support-for-ar1111.patch block-uninitialized-ioc-nr_tasks-triggers-warn_on.patch input-synaptics-handle-out-of-bounds-values-from-the-hardware.patch mac80211-cancel-mesh-path-timer.patch md-raid1-don-t-abort-a-resync-on-the-first-badblock.patch misdn-bugfix-for-layer2-fixed-tei-mode.patch mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch mm-setup-pageblock_order-before-it-s-used-by-sparsemem.patch ore-fix-out-of-bounds-access-in-_ios_obj.patch sh-fix-up-recursive-fault-in-oops-with-unset-ttb.patch video-smscufx-fix-line-counting-in-fb_write.patch wireless-reg-restore-previous-behaviour-of-chan-max_power-calculations.patch x86-64-kcmp-the-kcmp-system-call-can-be-common.patch x86-nops-missing-break-resulting-in-incorrect-selection-on-intel.patch --- diff --git a/queue-3.5/acpi-processor-fix-tick_broadcast_mask-online-offline-regression.patch b/queue-3.5/acpi-processor-fix-tick_broadcast_mask-online-offline-regression.patch new file mode 100644 index 00000000000..dc3270a0c9a --- /dev/null +++ b/queue-3.5/acpi-processor-fix-tick_broadcast_mask-online-offline-regression.patch @@ -0,0 +1,37 @@ +From b7db60f45d74497c723dc7ae1370cf0b37dfb0d8 Mon Sep 17 00:00:00 2001 +From: Feng Tang +Date: Tue, 31 Jul 2012 12:44:43 +0800 +Subject: ACPI processor: Fix tick_broadcast_mask online/offline regression + +From: Feng Tang + +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 +Cc: Thomas Renninger +Reviewed-by: Rafael J. Wysocki +Reviewed-by: Deepthi Dharwar +Signed-off-by: Len Brown +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } diff --git a/queue-3.5/ath9k-add-pid-vid-support-for-ar1111.patch b/queue-3.5/ath9k-add-pid-vid-support-for-ar1111.patch new file mode 100644 index 00000000000..502b74f3869 --- /dev/null +++ b/queue-3.5/ath9k-add-pid-vid-support-for-ar1111.patch @@ -0,0 +1,59 @@ +From d4e5979c0da95791aa717c18e162540c7a596360 Mon Sep 17 00:00:00 2001 +From: Mohammed Shafi Shajakhan +Date: Thu, 2 Aug 2012 11:58:50 +0530 +Subject: ath9k: Add PID/VID support for AR1111 + +From: Mohammed Shafi Shajakhan + +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 +Cc: Felix Bitterli +Signed-off-by: Mohammed Shafi Shajakhan +Tested-by: Tim Bentley +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + 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 } + }; + diff --git a/queue-3.5/block-uninitialized-ioc-nr_tasks-triggers-warn_on.patch b/queue-3.5/block-uninitialized-ioc-nr_tasks-triggers-warn_on.patch new file mode 100644 index 00000000000..fabb6459d8d --- /dev/null +++ b/queue-3.5/block-uninitialized-ioc-nr_tasks-triggers-warn_on.patch @@ -0,0 +1,90 @@ +From 4638a83e8615de9c16c39dfed234951d0f468cf1 Mon Sep 17 00:00:00 2001 +From: Olof Johansson +Date: Wed, 1 Aug 2012 12:17:27 +0200 +Subject: block: uninitialized ioc->nr_tasks triggers WARN_ON + +From: Olof Johansson + +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] [] warn_slowpath_common+0x7a/0xb0 +[ 10.886912] [] warn_slowpath_null+0x15/0x20 +[ 10.886913] [] copy_process+0x1488/0x1560 +[ 10.886914] [] do_fork+0xb4/0x340 +[ 10.886918] [] ? recalc_sigpending+0x1a/0x50 +[ 10.886919] [] ? __set_task_blocked+0x32/0x80 +[ 10.886920] [] ? __set_current_blocked+0x3a/0x60 +[ 10.886923] [] sys_clone+0x23/0x30 +[ 10.886925] [] stub_clone+0x13/0x20 +[ 10.886927] [] ? 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 +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 + Cc: Vivek Goyal + Signed-off-by: Jens Axboe + +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 +Acked-by: Tejun Heo +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.5/input-synaptics-handle-out-of-bounds-values-from-the-hardware.patch b/queue-3.5/input-synaptics-handle-out-of-bounds-values-from-the-hardware.patch new file mode 100644 index 00000000000..256a14f80bb --- /dev/null +++ b/queue-3.5/input-synaptics-handle-out-of-bounds-values-from-the-hardware.patch @@ -0,0 +1,84 @@ +From c0394506e69b37c47d391c2a7bbea3ea236d8ec8 Mon Sep 17 00:00:00 2001 +From: Seth Forshee +Date: Tue, 24 Jul 2012 23:54:11 -0700 +Subject: Input: synaptics - handle out of bounds values from the hardware + +From: Seth Forshee + +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 +Reviewed-by: Daniel Kurtz +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-3.5/mac80211-cancel-mesh-path-timer.patch b/queue-3.5/mac80211-cancel-mesh-path-timer.patch new file mode 100644 index 00000000000..da144080f0f --- /dev/null +++ b/queue-3.5/mac80211-cancel-mesh-path-timer.patch @@ -0,0 +1,30 @@ +From dd4c9260e7f23f2e951cbfb2726e468c6d30306c Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Wed, 1 Aug 2012 21:03:21 +0200 +Subject: mac80211: cancel mesh path timer + +From: Johannes Berg + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.5/md-raid1-don-t-abort-a-resync-on-the-first-badblock.patch b/queue-3.5/md-raid1-don-t-abort-a-resync-on-the-first-badblock.patch new file mode 100644 index 00000000000..ad1c5e5ffb7 --- /dev/null +++ b/queue-3.5/md-raid1-don-t-abort-a-resync-on-the-first-badblock.patch @@ -0,0 +1,46 @@ +From b7219ccb33aa0df9949a60c68b5e9f712615e56f Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Tue, 31 Jul 2012 10:05:34 +1000 +Subject: md/raid1: don't abort a resync on the first badblock. + +From: NeilBrown + +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 +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.5/misdn-bugfix-for-layer2-fixed-tei-mode.patch b/queue-3.5/misdn-bugfix-for-layer2-fixed-tei-mode.patch new file mode 100644 index 00000000000..7f6338df423 --- /dev/null +++ b/queue-3.5/misdn-bugfix-for-layer2-fixed-tei-mode.patch @@ -0,0 +1,34 @@ +From 25099335944a23db75d4916644122c746684e093 Mon Sep 17 00:00:00 2001 +From: Karsten Keil +Date: Sat, 4 Aug 2012 00:14:25 +0000 +Subject: mISDN: Bugfix for layer2 fixed TEI mode + +From: Karsten Keil + +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 +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.5/mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch b/queue-3.5/mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch new file mode 100644 index 00000000000..a9a678c8077 --- /dev/null +++ b/queue-3.5/mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch @@ -0,0 +1,134 @@ +From 3ad3d901bbcfb15a5e4690e55350db0899095a68 Mon Sep 17 00:00:00 2001 +From: Xiao Guangrong +Date: Tue, 31 Jul 2012 16:45:52 -0700 +Subject: mm: mmu_notifier: fix freed page still mapped in secondary MMU + +From: Xiao Guangrong + +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 +Cc: Avi Kivity +Cc: Marcelo Tosatti +Cc: Paul Gortmaker +Cc: Andrea Arcangeli +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.5/mm-setup-pageblock_order-before-it-s-used-by-sparsemem.patch b/queue-3.5/mm-setup-pageblock_order-before-it-s-used-by-sparsemem.patch new file mode 100644 index 00000000000..abd6086ca10 --- /dev/null +++ b/queue-3.5/mm-setup-pageblock_order-before-it-s-used-by-sparsemem.patch @@ -0,0 +1,93 @@ +From ca57df79d4f64e1a4886606af4289d40636189c5 Mon Sep 17 00:00:00 2001 +From: Xishi Qiu +Date: Tue, 31 Jul 2012 16:43:19 -0700 +Subject: mm: setup pageblock_order before it's used by sparsemem + +From: Xishi Qiu + +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 +Signed-off-by: Jiang Liu +Cc: Tony Luck +Cc: Yinghai Lu +Cc: KAMEZAWA Hiroyuki +Cc: Benjamin Herrenschmidt +Cc: KOSAKI Motohiro +Cc: David Rientjes +Cc: Keping Chen +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-3.5/ore-fix-out-of-bounds-access-in-_ios_obj.patch b/queue-3.5/ore-fix-out-of-bounds-access-in-_ios_obj.patch new file mode 100644 index 00000000000..7ce43793c4a --- /dev/null +++ b/queue-3.5/ore-fix-out-of-bounds-access-in-_ios_obj.patch @@ -0,0 +1,73 @@ +From 9e62bb4458ad2cf28bd701aa5fab380b846db326 Mon Sep 17 00:00:00 2001 +From: Boaz Harrosh +Date: Wed, 1 Aug 2012 17:48:36 +0300 +Subject: ore: Fix out-of-bounds access in _ios_obj() + +From: Boaz Harrosh + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + diff --git a/queue-3.5/series b/queue-3.5/series index b177a296fcb..62a6d2fef06 100644 --- a/queue-3.5/series +++ b/queue-3.5/series @@ -28,3 +28,18 @@ alsa-hda-add-dock-support-for-thinkpad-t430s.patch 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 diff --git a/queue-3.5/sh-fix-up-recursive-fault-in-oops-with-unset-ttb.patch b/queue-3.5/sh-fix-up-recursive-fault-in-oops-with-unset-ttb.patch new file mode 100644 index 00000000000..429e614afbb --- /dev/null +++ b/queue-3.5/sh-fix-up-recursive-fault-in-oops-with-unset-ttb.patch @@ -0,0 +1,42 @@ +From 90eed7d87b748f9c0d11b9bad64a4c41e31b78c4 Mon Sep 17 00:00:00 2001 +From: Paul Mundt +Date: Tue, 24 Jul 2012 13:15:54 +0900 +Subject: sh: Fix up recursive fault in oops with unset TTB. + +From: Paul Mundt + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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, diff --git a/queue-3.5/video-smscufx-fix-line-counting-in-fb_write.patch b/queue-3.5/video-smscufx-fix-line-counting-in-fb_write.patch new file mode 100644 index 00000000000..d5d1c2287b8 --- /dev/null +++ b/queue-3.5/video-smscufx-fix-line-counting-in-fb_write.patch @@ -0,0 +1,34 @@ +From 2fe2d9f47cfe1a3e66e7d087368b3d7155b04c15 Mon Sep 17 00:00:00 2001 +From: Alexander Holler +Date: Sat, 21 Apr 2012 00:11:07 +0200 +Subject: video/smscufx: fix line counting in fb_write + +From: Alexander Holler + +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 +Signed-off-by: Florian Tobias Schandinat +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-3.5/wireless-reg-restore-previous-behaviour-of-chan-max_power-calculations.patch b/queue-3.5/wireless-reg-restore-previous-behaviour-of-chan-max_power-calculations.patch new file mode 100644 index 00000000000..cd679b31dae --- /dev/null +++ b/queue-3.5/wireless-reg-restore-previous-behaviour-of-chan-max_power-calculations.patch @@ -0,0 +1,59 @@ +From 5e31fc0815a4e2c72b1b495fe7a0d8f9bfb9e4b4 Mon Sep 17 00:00:00 2001 +From: Stanislaw Gruszka +Date: Tue, 24 Jul 2012 08:35:39 +0200 +Subject: wireless: reg: restore previous behaviour of chan->max_power calculations + +From: Stanislaw Gruszka + +commit 5e31fc0815a4e2c72b1b495fe7a0d8f9bfb9e4b4 upstream. + +commit eccc068e8e84c8fe997115629925e0422a98e4de +Author: Hong Wu +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 +Acked-by: Luis R. Rodriguez +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + 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, diff --git a/queue-3.5/x86-64-kcmp-the-kcmp-system-call-can-be-common.patch b/queue-3.5/x86-64-kcmp-the-kcmp-system-call-can-be-common.patch new file mode 100644 index 00000000000..78277dee100 --- /dev/null +++ b/queue-3.5/x86-64-kcmp-the-kcmp-system-call-can-be-common.patch @@ -0,0 +1,33 @@ +From eaf4ce6c5fed6b4c55f7efcd5fc3477435cab5e9 Mon Sep 17 00:00:00 2001 +From: "H. Peter Anvin" +Date: Wed, 1 Aug 2012 15:59:58 -0700 +Subject: x86-64, kcmp: The kcmp system call can be common + +From: "H. Peter Anvin" + +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 +Cc: H.J. Lu +Cc: Cyrill Gorcunov +Link: http://lkml.kernel.org/n/tip-vwzk3qbcr3yjyxjg2j38vgy9@git.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.5/x86-nops-missing-break-resulting-in-incorrect-selection-on-intel.patch b/queue-3.5/x86-nops-missing-break-resulting-in-incorrect-selection-on-intel.patch new file mode 100644 index 00000000000..80a6adddcf2 --- /dev/null +++ b/queue-3.5/x86-nops-missing-break-resulting-in-incorrect-selection-on-intel.patch @@ -0,0 +1,33 @@ +From d6250a3f12edb3a86db9598ffeca3de8b4a219e9 Mon Sep 17 00:00:00 2001 +From: Alan Cox +Date: Wed, 25 Jul 2012 16:28:19 +0100 +Subject: x86, nops: Missing break resulting in incorrect selection on Intel + +From: Alan Cox + +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 +Link: http://lkml.kernel.org/n/tip-lww2uirad4skzjlmrm0vru8o@git.kernel.org +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + 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;