From: Greg Kroah-Hartman Date: Thu, 9 Aug 2012 18:24:55 +0000 (-0700) Subject: 3.4-stable patches X-Git-Tag: v3.5.2~34 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=cb27a0f2d57fada8582e86885b225fd384cf780e;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: acpi-processor-fix-tick_broadcast_mask-online-offline-regression.patch ath9k-add-pid-vid-support-for-ar1111.patch mac80211-cancel-mesh-path-timer.patch md-raid1-don-t-abort-a-resync-on-the-first-badblock.patch mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch ore-fix-out-of-bounds-access-in-_ios_obj.patch video-smscufx-fix-line-counting-in-fb_write.patch wireless-reg-restore-previous-behaviour-of-chan-max_power-calculations.patch --- diff --git a/queue-3.4/acpi-processor-fix-tick_broadcast_mask-online-offline-regression.patch b/queue-3.4/acpi-processor-fix-tick_broadcast_mask-online-offline-regression.patch new file mode 100644 index 00000000000..dc3270a0c9a --- /dev/null +++ b/queue-3.4/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.4/ath9k-add-pid-vid-support-for-ar1111.patch b/queue-3.4/ath9k-add-pid-vid-support-for-ar1111.patch new file mode 100644 index 00000000000..a38bade1c2e --- /dev/null +++ b/queue-3.4/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 +@@ -676,6 +676,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 +@@ -35,6 +35,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.4/mac80211-cancel-mesh-path-timer.patch b/queue-3.4/mac80211-cancel-mesh-path-timer.patch new file mode 100644 index 00000000000..43548124e66 --- /dev/null +++ b/queue-3.4/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 +@@ -595,6 +595,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.4/md-raid1-don-t-abort-a-resync-on-the-first-badblock.patch b/queue-3.4/md-raid1-don-t-abort-a-resync-on-the-first-badblock.patch new file mode 100644 index 00000000000..565d47845fe --- /dev/null +++ b/queue-3.4/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 +@@ -2429,7 +2429,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.4/mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch b/queue-3.4/mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch new file mode 100644 index 00000000000..a9a678c8077 --- /dev/null +++ b/queue-3.4/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.4/ore-fix-out-of-bounds-access-in-_ios_obj.patch b/queue-3.4/ore-fix-out-of-bounds-access-in-_ios_obj.patch new file mode 100644 index 00000000000..7ce43793c4a --- /dev/null +++ b/queue-3.4/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.4/series b/queue-3.4/series index d889f596c6b..76f1b7175d8 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -18,3 +18,11 @@ 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-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 +ore-fix-out-of-bounds-access-in-_ios_obj.patch +acpi-processor-fix-tick_broadcast_mask-online-offline-regression.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 diff --git a/queue-3.4/video-smscufx-fix-line-counting-in-fb_write.patch b/queue-3.4/video-smscufx-fix-line-counting-in-fb_write.patch new file mode 100644 index 00000000000..d5d1c2287b8 --- /dev/null +++ b/queue-3.4/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.4/wireless-reg-restore-previous-behaviour-of-chan-max_power-calculations.patch b/queue-3.4/wireless-reg-restore-previous-behaviour-of-chan-max_power-calculations.patch new file mode 100644 index 00000000000..cd679b31dae --- /dev/null +++ b/queue-3.4/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,