From: Greg Kroah-Hartman Date: Thu, 29 Nov 2012 20:47:38 +0000 (-0800) Subject: 3.4-stable patches X-Git-Tag: v3.6.9~17 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=7a8521b469829f2f5996e3c17319892e9166412b;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: alsa-hda-cirrus-correctly-clear-line_out_pins-when-moving-to-speaker.patch alsa-ua101-usx2y-fix-broken-midi-output.patch dm-fix-deadlock-with-request-based-dm-and-queue-request_fn-recursion.patch drm-radeon-add-new-si-pci-id.patch futex-avoid-wake_futex-for-a-pi-futex_q.patch jffs2-fix-lock-acquisition-order-bug-in-jffs2_write_begin.patch mac80211-deinitialize-ibss-internals-after-emptiness-check.patch md-avoid-write-invalid-address-if-read_seqretry-returned-true.patch md-raid10-decrement-correct-pending-counter-when-writing-to-replacement.patch md-reassigned-the-parameters-if-read_seqretry-returned-true-in-func-md_is_badblock.patch mtd-ofpart-fix-incorrect-null-check-in-parse_ofoldpart_partitions.patch mtd-slram-invalid-checking-of-absolute-end-address.patch mwifiex-fix-system-hang-issue-in-cmd-timeout-error-case.patch mwifiex-report-error-to-mmc-core-if-we-cannot-suspend.patch parisc-fix-user-triggerable-panic-on-parisc.patch parisc-fix-virtual-aliasing-issue-in-get_shared_area.patch radeon-add-agpmode-1-quirk-for-rv250.patch rtlwifi-rtl8192cu-add-new-usb-id.patch scsi-isci-copy-fis-0x34-response-into-proper-buffer.patch x86-32-fix-invalid-stack-address-while-in-softirq.patch x86-efi-fix-processor-specific-memcpy-build-error.patch x86-microcode-amd-add-support-for-family-16h-processors.patch --- diff --git a/queue-3.4/alsa-hda-cirrus-correctly-clear-line_out_pins-when-moving-to-speaker.patch b/queue-3.4/alsa-hda-cirrus-correctly-clear-line_out_pins-when-moving-to-speaker.patch new file mode 100644 index 00000000000..5ee628ff632 --- /dev/null +++ b/queue-3.4/alsa-hda-cirrus-correctly-clear-line_out_pins-when-moving-to-speaker.patch @@ -0,0 +1,32 @@ +From 34c3d1926bdaf45d3a891dd577482abcdd9faa34 Mon Sep 17 00:00:00 2001 +From: David Henningsson +Date: Wed, 21 Nov 2012 10:03:10 +0100 +Subject: ALSA: hda - Cirrus: Correctly clear line_out_pins when moving to speaker + +From: David Henningsson + +commit 34c3d1926bdaf45d3a891dd577482abcdd9faa34 upstream. + +If this array is not cleared, the jack related code later might +fail to create "Internal Speaker Phantom Jack" on Dell Inspiron 3420 and +Dell Vostro 2420. + +BugLink: https://bugs.launchpad.net/bugs/1076840 +Signed-off-by: David Henningsson +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_cirrus.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_cirrus.c ++++ b/sound/pci/hda/patch_cirrus.c +@@ -460,6 +460,7 @@ static int parse_output(struct hda_codec + memcpy(cfg->speaker_pins, cfg->line_out_pins, + sizeof(cfg->speaker_pins)); + cfg->line_outs = 0; ++ memset(cfg->line_out_pins, 0, sizeof(cfg->line_out_pins)); + } + + return 0; diff --git a/queue-3.4/alsa-ua101-usx2y-fix-broken-midi-output.patch b/queue-3.4/alsa-ua101-usx2y-fix-broken-midi-output.patch new file mode 100644 index 00000000000..6064a577cf9 --- /dev/null +++ b/queue-3.4/alsa-ua101-usx2y-fix-broken-midi-output.patch @@ -0,0 +1,65 @@ +From e99ddfde6ae0dd2662bb40435696002b590e4057 Mon Sep 17 00:00:00 2001 +From: Clemens Ladisch +Date: Wed, 31 Oct 2012 16:35:30 +0100 +Subject: ALSA: ua101, usx2y: fix broken MIDI output + +From: Clemens Ladisch + +commit e99ddfde6ae0dd2662bb40435696002b590e4057 upstream. + +Commit 88a8516a2128 (ALSA: usbaudio: implement USB autosuspend) added +autosuspend code to all files making up the snd-usb-audio driver. +However, midi.c is part of snd-usb-lib and is also used by other +drivers, not all of which support autosuspend. Thus, calls to +usb_autopm_get_interface() could fail, and this unexpected error would +result in the MIDI output being completely unusable. + +Make it work by ignoring the error that is expected with drivers that do +not support autosuspend. + +Reported-by: Colin Fletcher +Reported-by: Devin Venable +Reported-by: Dr Nick Bailey +Reported-by: Jannis Achstetter +Reported-by: Rui Nuno Capela +Cc: Oliver Neukum +Signed-off-by: Clemens Ladisch +Signed-off-by: Greg Kroah-Hartman + +--- + sound/usb/midi.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/sound/usb/midi.c ++++ b/sound/usb/midi.c +@@ -148,6 +148,7 @@ struct snd_usb_midi_out_endpoint { + struct snd_usb_midi_out_endpoint* ep; + struct snd_rawmidi_substream *substream; + int active; ++ bool autopm_reference; + uint8_t cable; /* cable number << 4 */ + uint8_t state; + #define STATE_UNKNOWN 0 +@@ -1076,7 +1077,8 @@ static int snd_usbmidi_output_open(struc + return -ENXIO; + } + err = usb_autopm_get_interface(umidi->iface); +- if (err < 0) ++ port->autopm_reference = err >= 0; ++ if (err < 0 && err != -EACCES) + return -EIO; + substream->runtime->private_data = port; + port->state = STATE_UNKNOWN; +@@ -1087,9 +1089,11 @@ static int snd_usbmidi_output_open(struc + static int snd_usbmidi_output_close(struct snd_rawmidi_substream *substream) + { + struct snd_usb_midi* umidi = substream->rmidi->private_data; ++ struct usbmidi_out_port *port = substream->runtime->private_data; + + substream_open(substream, 0); +- usb_autopm_put_interface(umidi->iface); ++ if (port->autopm_reference) ++ usb_autopm_put_interface(umidi->iface); + return 0; + } + diff --git a/queue-3.4/dm-fix-deadlock-with-request-based-dm-and-queue-request_fn-recursion.patch b/queue-3.4/dm-fix-deadlock-with-request-based-dm-and-queue-request_fn-recursion.patch new file mode 100644 index 00000000000..c97ac051b7f --- /dev/null +++ b/queue-3.4/dm-fix-deadlock-with-request-based-dm-and-queue-request_fn-recursion.patch @@ -0,0 +1,43 @@ +From a8c32a5c98943d370ea606a2e7dc04717eb92206 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Tue, 6 Nov 2012 12:24:26 +0100 +Subject: dm: fix deadlock with request based dm and queue request_fn recursion + +From: Jens Axboe + +commit a8c32a5c98943d370ea606a2e7dc04717eb92206 upstream. + +Request based dm attempts to re-run the request queue off the +request completion path. If used with a driver that potentially does +end_io from its request_fn, we could deadlock trying to recurse +back into request dispatch. Fix this by punting the request queue +run to kblockd. + +Tested to fix a quickly reproducible deadlock in such a scenario. + +Acked-by: Alasdair G Kergon +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/dm.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/md/dm.c ++++ b/drivers/md/dm.c +@@ -754,8 +754,14 @@ static void rq_completed(struct mapped_d + if (!md_in_flight(md)) + wake_up(&md->wait); + ++ /* ++ * Run this off this callpath, as drivers could invoke end_io while ++ * inside their request_fn (and holding the queue lock). Calling ++ * back into ->request_fn() could deadlock attempting to grab the ++ * queue lock again. ++ */ + if (run_queue) +- blk_run_queue(md->queue); ++ blk_run_queue_async(md->queue); + + /* + * dm_put() must be at the end of this function. See the comment above diff --git a/queue-3.4/drm-radeon-add-new-si-pci-id.patch b/queue-3.4/drm-radeon-add-new-si-pci-id.patch new file mode 100644 index 00000000000..dd68bb03843 --- /dev/null +++ b/queue-3.4/drm-radeon-add-new-si-pci-id.patch @@ -0,0 +1,26 @@ +From 0181bd5dea2ed0696f84591a92da0b6a1f1a2e62 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 21 Nov 2012 18:37:38 -0500 +Subject: drm/radeon: add new SI pci id + +From: Alex Deucher + +commit 0181bd5dea2ed0696f84591a92da0b6a1f1a2e62 upstream. + +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + include/drm/drm_pciids.h | 1 + + 1 file changed, 1 insertion(+) + +--- a/include/drm/drm_pciids.h ++++ b/include/drm/drm_pciids.h +@@ -214,6 +214,7 @@ + {0x1002, 0x6798, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6799, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x679A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ ++ {0x1002, 0x679B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x679E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x679F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6800, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \ diff --git a/queue-3.4/futex-avoid-wake_futex-for-a-pi-futex_q.patch b/queue-3.4/futex-avoid-wake_futex-for-a-pi-futex_q.patch new file mode 100644 index 00000000000..5e3828c2d41 --- /dev/null +++ b/queue-3.4/futex-avoid-wake_futex-for-a-pi-futex_q.patch @@ -0,0 +1,98 @@ +From aa10990e028cac3d5e255711fb9fb47e00700e35 Mon Sep 17 00:00:00 2001 +From: Darren Hart +Date: Mon, 26 Nov 2012 16:29:56 -0800 +Subject: futex: avoid wake_futex() for a PI futex_q + +From: Darren Hart + +commit aa10990e028cac3d5e255711fb9fb47e00700e35 upstream. + +Dave Jones reported a bug with futex_lock_pi() that his trinity test +exposed. Sometime between queue_me() and taking the q.lock_ptr, the +lock_ptr became NULL, resulting in a crash. + +While futex_wake() is careful to not call wake_futex() on futex_q's with +a pi_state or an rt_waiter (which are either waiting for a +futex_unlock_pi() or a PI futex_requeue()), futex_wake_op() and +futex_requeue() do not perform the same test. + +Update futex_wake_op() and futex_requeue() to test for q.pi_state and +q.rt_waiter and abort with -EINVAL if detected. To ensure any future +breakage is caught, add a WARN() to wake_futex() if the same condition +is true. + +This fix has seen 3 hours of testing with "trinity -c futex" on an +x86_64 VM with 4 CPUS. + +[akpm@linux-foundation.org: tidy up the WARN()] +Signed-off-by: Darren Hart +Reported-by: Dave Jones +Cc: Thomas Gleixner +Cc: Peter Zijlstra +Cc: Ingo Molnar +Cc: John Kacur +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/futex.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -843,6 +843,9 @@ static void wake_futex(struct futex_q *q + { + struct task_struct *p = q->task; + ++ if (WARN(q->pi_state || q->rt_waiter, "refusing to wake PI futex\n")) ++ return; ++ + /* + * We set q->lock_ptr = NULL _before_ we wake up the task. If + * a non-futex wake up happens on another CPU then the task +@@ -1078,6 +1081,10 @@ retry_private: + + plist_for_each_entry_safe(this, next, head, list) { + if (match_futex (&this->key, &key1)) { ++ if (this->pi_state || this->rt_waiter) { ++ ret = -EINVAL; ++ goto out_unlock; ++ } + wake_futex(this); + if (++ret >= nr_wake) + break; +@@ -1090,6 +1097,10 @@ retry_private: + op_ret = 0; + plist_for_each_entry_safe(this, next, head, list) { + if (match_futex (&this->key, &key2)) { ++ if (this->pi_state || this->rt_waiter) { ++ ret = -EINVAL; ++ goto out_unlock; ++ } + wake_futex(this); + if (++op_ret >= nr_wake2) + break; +@@ -1098,6 +1109,7 @@ retry_private: + ret += op_ret; + } + ++out_unlock: + double_unlock_hb(hb1, hb2); + out_put_keys: + put_futex_key(&key2); +@@ -1387,9 +1399,13 @@ retry_private: + /* + * FUTEX_WAIT_REQEUE_PI and FUTEX_CMP_REQUEUE_PI should always + * be paired with each other and no other futex ops. ++ * ++ * We should never be requeueing a futex_q with a pi_state, ++ * which is awaiting a futex_unlock_pi(). + */ + if ((requeue_pi && !this->rt_waiter) || +- (!requeue_pi && this->rt_waiter)) { ++ (!requeue_pi && this->rt_waiter) || ++ this->pi_state) { + ret = -EINVAL; + break; + } diff --git a/queue-3.4/jffs2-fix-lock-acquisition-order-bug-in-jffs2_write_begin.patch b/queue-3.4/jffs2-fix-lock-acquisition-order-bug-in-jffs2_write_begin.patch new file mode 100644 index 00000000000..692ddd4a72c --- /dev/null +++ b/queue-3.4/jffs2-fix-lock-acquisition-order-bug-in-jffs2_write_begin.patch @@ -0,0 +1,143 @@ +From 5ffd3412ae5536a4c57469cb8ea31887121dcb2e Mon Sep 17 00:00:00 2001 +From: Thomas Betker +Date: Wed, 17 Oct 2012 22:59:30 +0200 +Subject: jffs2: Fix lock acquisition order bug in jffs2_write_begin + +From: Thomas Betker + +commit 5ffd3412ae5536a4c57469cb8ea31887121dcb2e upstream. + +jffs2_write_begin() first acquires the page lock, then f->sem. This +causes an AB-BA deadlock with jffs2_garbage_collect_live(), which first +acquires f->sem, then the page lock: + +jffs2_garbage_collect_live + mutex_lock(&f->sem) (A) + jffs2_garbage_collect_dnode + jffs2_gc_fetch_page + read_cache_page_async + do_read_cache_page + lock_page(page) (B) + +jffs2_write_begin + grab_cache_page_write_begin + find_lock_page + lock_page(page) (B) + mutex_lock(&f->sem) (A) + +We fix this by restructuring jffs2_write_begin() to take f->sem before +the page lock. However, we make sure that f->sem is not held when +calling jffs2_reserve_space(), as this is not permitted by the locking +rules. + +The deadlock above was observed multiple times on an SoC with a dual +ARMv7 (Cortex-A9), running the long-term 3.4.11 kernel; it occurred +when using scp to copy files from a host system to the ARM target +system. The fix was heavily tested on the same target system. + +Signed-off-by: Thomas Betker +Acked-by: Joakim Tjernlund +Signed-off-by: Artem Bityutskiy +Signed-off-by: Greg Kroah-Hartman + +--- + fs/jffs2/file.c | 39 +++++++++++++++++++++------------------ + 1 file changed, 21 insertions(+), 18 deletions(-) + +--- a/fs/jffs2/file.c ++++ b/fs/jffs2/file.c +@@ -138,33 +138,39 @@ static int jffs2_write_begin(struct file + struct page *pg; + struct inode *inode = mapping->host; + struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode); ++ struct jffs2_sb_info *c = JFFS2_SB_INFO(inode->i_sb); ++ struct jffs2_raw_inode ri; ++ uint32_t alloc_len = 0; + pgoff_t index = pos >> PAGE_CACHE_SHIFT; + uint32_t pageofs = index << PAGE_CACHE_SHIFT; + int ret = 0; + ++ jffs2_dbg(1, "%s()\n", __func__); ++ ++ if (pageofs > inode->i_size) { ++ ret = jffs2_reserve_space(c, sizeof(ri), &alloc_len, ++ ALLOC_NORMAL, JFFS2_SUMMARY_INODE_SIZE); ++ if (ret) ++ return ret; ++ } ++ ++ mutex_lock(&f->sem); + pg = grab_cache_page_write_begin(mapping, index, flags); +- if (!pg) ++ if (!pg) { ++ if (alloc_len) ++ jffs2_complete_reservation(c); ++ mutex_unlock(&f->sem); + return -ENOMEM; ++ } + *pagep = pg; + +- jffs2_dbg(1, "%s()\n", __func__); +- +- if (pageofs > inode->i_size) { ++ if (alloc_len) { + /* Make new hole frag from old EOF to new page */ +- struct jffs2_sb_info *c = JFFS2_SB_INFO(inode->i_sb); +- struct jffs2_raw_inode ri; + struct jffs2_full_dnode *fn; +- uint32_t alloc_len; + + jffs2_dbg(1, "Writing new hole frag 0x%x-0x%x between current EOF and new page\n", + (unsigned int)inode->i_size, pageofs); + +- ret = jffs2_reserve_space(c, sizeof(ri), &alloc_len, +- ALLOC_NORMAL, JFFS2_SUMMARY_INODE_SIZE); +- if (ret) +- goto out_page; +- +- mutex_lock(&f->sem); + memset(&ri, 0, sizeof(ri)); + + ri.magic = cpu_to_je16(JFFS2_MAGIC_BITMASK); +@@ -191,7 +197,6 @@ static int jffs2_write_begin(struct file + if (IS_ERR(fn)) { + ret = PTR_ERR(fn); + jffs2_complete_reservation(c); +- mutex_unlock(&f->sem); + goto out_page; + } + ret = jffs2_add_full_dnode_to_inode(c, f, fn); +@@ -206,12 +211,10 @@ static int jffs2_write_begin(struct file + jffs2_mark_node_obsolete(c, fn->raw); + jffs2_free_full_dnode(fn); + jffs2_complete_reservation(c); +- mutex_unlock(&f->sem); + goto out_page; + } + jffs2_complete_reservation(c); + inode->i_size = pageofs; +- mutex_unlock(&f->sem); + } + + /* +@@ -220,18 +223,18 @@ static int jffs2_write_begin(struct file + * case of a short-copy. + */ + if (!PageUptodate(pg)) { +- mutex_lock(&f->sem); + ret = jffs2_do_readpage_nolock(inode, pg); +- mutex_unlock(&f->sem); + if (ret) + goto out_page; + } ++ mutex_unlock(&f->sem); + jffs2_dbg(1, "end write_begin(). pg->flags %lx\n", pg->flags); + return ret; + + out_page: + unlock_page(pg); + page_cache_release(pg); ++ mutex_unlock(&f->sem); + return ret; + } + diff --git a/queue-3.4/mac80211-deinitialize-ibss-internals-after-emptiness-check.patch b/queue-3.4/mac80211-deinitialize-ibss-internals-after-emptiness-check.patch new file mode 100644 index 00000000000..2936b9285fc --- /dev/null +++ b/queue-3.4/mac80211-deinitialize-ibss-internals-after-emptiness-check.patch @@ -0,0 +1,53 @@ +From b78a4932f5fb11fadf41e69c606a33fa6787574c Mon Sep 17 00:00:00 2001 +From: Simon Wunderlich +Date: Tue, 13 Nov 2012 18:43:03 +0100 +Subject: mac80211: deinitialize ibss-internals after emptiness check + +From: Simon Wunderlich + +commit b78a4932f5fb11fadf41e69c606a33fa6787574c upstream. + +The check whether the IBSS is active and can be removed should be +performed before deinitializing the fields used for the check/search. +Otherwise, the configured BSS will not be found and removed properly. + +To make it more clear for the future, rename sdata->u.ibss to the +local pointer ifibss which is used within the checks. + +This behaviour was introduced by +f3209bea110cade12e2b133da8b8499689cb0e2e +("mac80211: fix IBSS teardown race") + +Signed-off-by: Simon Wunderlich +Cc: Ignacy Gawedzki +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/ibss.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/net/mac80211/ibss.c ++++ b/net/mac80211/ibss.c +@@ -1153,10 +1153,6 @@ int ieee80211_ibss_leave(struct ieee8021 + + mutex_lock(&sdata->u.ibss.mtx); + +- sdata->u.ibss.state = IEEE80211_IBSS_MLME_SEARCH; +- memset(sdata->u.ibss.bssid, 0, ETH_ALEN); +- sdata->u.ibss.ssid_len = 0; +- + active_ibss = ieee80211_sta_active_ibss(sdata); + + if (!active_ibss && !is_zero_ether_addr(ifibss->bssid)) { +@@ -1177,6 +1173,10 @@ int ieee80211_ibss_leave(struct ieee8021 + } + } + ++ ifibss->state = IEEE80211_IBSS_MLME_SEARCH; ++ memset(ifibss->bssid, 0, ETH_ALEN); ++ ifibss->ssid_len = 0; ++ + sta_info_flush(sdata->local, sdata); + + spin_lock_bh(&ifibss->incomplete_lock); diff --git a/queue-3.4/md-avoid-write-invalid-address-if-read_seqretry-returned-true.patch b/queue-3.4/md-avoid-write-invalid-address-if-read_seqretry-returned-true.patch new file mode 100644 index 00000000000..b1552233d65 --- /dev/null +++ b/queue-3.4/md-avoid-write-invalid-address-if-read_seqretry-returned-true.patch @@ -0,0 +1,40 @@ +From 35f9ac2dcec8f79d7059ce174fd7b7ee3290d620 Mon Sep 17 00:00:00 2001 +From: majianpeng +Date: Thu, 8 Nov 2012 08:56:27 +0800 +Subject: md: Avoid write invalid address if read_seqretry returned true. + +From: majianpeng + +commit 35f9ac2dcec8f79d7059ce174fd7b7ee3290d620 upstream. + +If read_seqretry returned true and bbp was changed, it will write +invalid address which can cause some serious problem. + +This bug was introduced by commit v3.0-rc7-130-g2699b67. +So fix is suitable for 3.0.y thru 3.6.y. + +Reported-by: zhuwenfeng@kedacom.com +Tested-by: zhuwenfeng@kedacom.com +Signed-off-by: Jianpeng Ma +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/md.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -1805,10 +1805,10 @@ retry: + memset(bbp, 0xff, PAGE_SIZE); + + for (i = 0 ; i < bb->count ; i++) { +- u64 internal_bb = *p++; ++ u64 internal_bb = p[i]; + u64 store_bb = ((BB_OFFSET(internal_bb) << 10) + | BB_LEN(internal_bb)); +- *bbp++ = cpu_to_le64(store_bb); ++ bbp[i] = cpu_to_le64(store_bb); + } + bb->changed = 0; + if (read_seqretry(&bb->lock, seq)) diff --git a/queue-3.4/md-raid10-decrement-correct-pending-counter-when-writing-to-replacement.patch b/queue-3.4/md-raid10-decrement-correct-pending-counter-when-writing-to-replacement.patch new file mode 100644 index 00000000000..9ba8c7ab1e3 --- /dev/null +++ b/queue-3.4/md-raid10-decrement-correct-pending-counter-when-writing-to-replacement.patch @@ -0,0 +1,40 @@ +From 884162df2aadd7414bef4935e1a54976fd4e3988 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Thu, 22 Nov 2012 15:12:09 +1100 +Subject: md/raid10: decrement correct pending counter when writing to replacement. + +From: NeilBrown + +commit 884162df2aadd7414bef4935e1a54976fd4e3988 upstream. + +When a write to a replacement device completes, we carefully +and correctly found the rdev that the write actually went to +and the blithely called rdev_dec_pending on the primary rdev, +even if this write was to the replacement. + +This means that any writes to an array while a replacement +was ongoing would cause the nr_pending count for the primary +device to go negative, so it could never be removed. + +This bug has been present since replacement was introduced in +3.3, so it is suitable for any -stable kernel since then. + +Reported-by: "George Spelvin" +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid10.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/md/raid10.c ++++ b/drivers/md/raid10.c +@@ -476,7 +476,7 @@ static void raid10_end_write_request(str + */ + one_write_done(r10_bio); + if (dec_rdev) +- rdev_dec_pending(conf->mirrors[dev].rdev, conf->mddev); ++ rdev_dec_pending(rdev, conf->mddev); + } + + /* diff --git a/queue-3.4/md-reassigned-the-parameters-if-read_seqretry-returned-true-in-func-md_is_badblock.patch b/queue-3.4/md-reassigned-the-parameters-if-read_seqretry-returned-true-in-func-md_is_badblock.patch new file mode 100644 index 00000000000..053ad849163 --- /dev/null +++ b/queue-3.4/md-reassigned-the-parameters-if-read_seqretry-returned-true-in-func-md_is_badblock.patch @@ -0,0 +1,44 @@ +From ab05613a0646dcc11049692d54bae76ca9ffa910 Mon Sep 17 00:00:00 2001 +From: majianpeng +Date: Tue, 6 Nov 2012 17:13:44 +0800 +Subject: md: Reassigned the parameters if read_seqretry returned true in func md_is_badblock. + +From: majianpeng + +commit ab05613a0646dcc11049692d54bae76ca9ffa910 upstream. + +This bug was introduced by commit(v3.0-rc7-126-g2230dfe). +So fix is suitable for 3.0.y thru 3.6.y. + +Signed-off-by: Jianpeng Ma +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/md.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -7694,9 +7694,9 @@ int md_is_badblock(struct badblocks *bb, + sector_t *first_bad, int *bad_sectors) + { + int hi; +- int lo = 0; ++ int lo; + u64 *p = bb->page; +- int rv = 0; ++ int rv; + sector_t target = s + sectors; + unsigned seq; + +@@ -7711,7 +7711,8 @@ int md_is_badblock(struct badblocks *bb, + + retry: + seq = read_seqbegin(&bb->lock); +- ++ lo = 0; ++ rv = 0; + hi = bb->count; + + /* Binary search between lo and hi for 'target' diff --git a/queue-3.4/mtd-ofpart-fix-incorrect-null-check-in-parse_ofoldpart_partitions.patch b/queue-3.4/mtd-ofpart-fix-incorrect-null-check-in-parse_ofoldpart_partitions.patch new file mode 100644 index 00000000000..9e9a42fb45d --- /dev/null +++ b/queue-3.4/mtd-ofpart-fix-incorrect-null-check-in-parse_ofoldpart_partitions.patch @@ -0,0 +1,37 @@ +From 5a6ea4af0907f995dc06df21a9c9ef764c7cd3bc Mon Sep 17 00:00:00 2001 +From: Sachin Kamat +Date: Tue, 25 Sep 2012 15:27:13 +0530 +Subject: mtd: ofpart: Fix incorrect NULL check in parse_ofoldpart_partitions() + +From: Sachin Kamat + +commit 5a6ea4af0907f995dc06df21a9c9ef764c7cd3bc upstream. + +The pointer returned by kzalloc should be tested for NULL +to avoid potential NULL pointer dereference later. Incorrect +pointer was being tested for NULL. Bug introduced by commit fbcf62a3 +(mtd: physmap_of: move parse_obsolete_partitions to become separate +parser). +This patch fixes this bug. + +Cc: Dmitry Eremin-Solenikov +Cc: Artem Bityutskiy +Signed-off-by: Sachin Kamat +Signed-off-by: David Woodhouse +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/ofpart.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mtd/ofpart.c ++++ b/drivers/mtd/ofpart.c +@@ -121,7 +121,7 @@ static int parse_ofoldpart_partitions(st + nr_parts = plen / sizeof(part[0]); + + *pparts = kzalloc(nr_parts * sizeof(*(*pparts)), GFP_KERNEL); +- if (!pparts) ++ if (!*pparts) + return -ENOMEM; + + names = of_get_property(dp, "partition-names", &plen); diff --git a/queue-3.4/mtd-slram-invalid-checking-of-absolute-end-address.patch b/queue-3.4/mtd-slram-invalid-checking-of-absolute-end-address.patch new file mode 100644 index 00000000000..33fbe0b9ff7 --- /dev/null +++ b/queue-3.4/mtd-slram-invalid-checking-of-absolute-end-address.patch @@ -0,0 +1,30 @@ +From c36a7ff4578ab6294885aef5ef241aeec4cdb1f0 Mon Sep 17 00:00:00 2001 +From: Jiri Engelthaler +Date: Thu, 20 Sep 2012 16:49:50 +0200 +Subject: mtd: slram: invalid checking of absolute end address + +From: Jiri Engelthaler + +commit c36a7ff4578ab6294885aef5ef241aeec4cdb1f0 upstream. + +Fixed parsing end absolute address. + +Signed-off-by: Jiri Engelthaler +Signed-off-by: Artem Bityutskiy +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/devices/slram.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mtd/devices/slram.c ++++ b/drivers/mtd/devices/slram.c +@@ -240,7 +240,7 @@ static int parse_cmdline(char *devname, + + if (*(szlength) != '+') { + devlength = simple_strtoul(szlength, &buffer, 0); +- devlength = handle_unit(devlength, buffer) - devstart; ++ devlength = handle_unit(devlength, buffer); + if (devlength < devstart) + goto err_out; + diff --git a/queue-3.4/mwifiex-fix-system-hang-issue-in-cmd-timeout-error-case.patch b/queue-3.4/mwifiex-fix-system-hang-issue-in-cmd-timeout-error-case.patch new file mode 100644 index 00000000000..2ee953a2c8a --- /dev/null +++ b/queue-3.4/mwifiex-fix-system-hang-issue-in-cmd-timeout-error-case.patch @@ -0,0 +1,56 @@ +From b1a47aa5e1e159e2cb06d7dfcc17ef5149b09299 Mon Sep 17 00:00:00 2001 +From: Bing Zhao +Date: Thu, 15 Nov 2012 15:58:47 -0800 +Subject: mwifiex: fix system hang issue in cmd timeout error case + +From: Bing Zhao + +commit b1a47aa5e1e159e2cb06d7dfcc17ef5149b09299 upstream. + +Reported by Tim Shepard: +I was seeing sporadic failures (wedgeups), and the majority of those +failures I saw printed the printouts in mwifiex_cmd_timeout_func with +cmd = 0xe5 which is CMD_802_11_HS_CFG_ENH. When this happens, two +minutes later I get notified that the rtcwake thread is blocked, like +this: + INFO: task rtcwake:3495 blocked for more than 120 seconds. + +To get the hung thread unblocked we wake up the cmd wait queue and +cancel the ioctl. + +Reported-by: Tim Shepard +Signed-off-by: Bing Zhao +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/mwifiex/cmdevt.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + +--- a/drivers/net/wireless/mwifiex/cmdevt.c ++++ b/drivers/net/wireless/mwifiex/cmdevt.c +@@ -816,9 +816,6 @@ mwifiex_cmd_timeout_func(unsigned long f + return; + } + cmd_node = adapter->curr_cmd; +- if (cmd_node->wait_q_enabled) +- adapter->cmd_wait_q.status = -ETIMEDOUT; +- + if (cmd_node) { + adapter->dbg.timeout_cmd_id = + adapter->dbg.last_cmd_id[adapter->dbg.last_cmd_index]; +@@ -864,6 +861,14 @@ mwifiex_cmd_timeout_func(unsigned long f + + dev_err(adapter->dev, "ps_mode=%d ps_state=%d\n", + adapter->ps_mode, adapter->ps_state); ++ ++ if (cmd_node->wait_q_enabled) { ++ adapter->cmd_wait_q.status = -ETIMEDOUT; ++ wake_up_interruptible(&adapter->cmd_wait_q.wait); ++ mwifiex_cancel_pending_ioctl(adapter); ++ /* reset cmd_sent flag to unblock new commands */ ++ adapter->cmd_sent = false; ++ } + } + if (adapter->hw_status == MWIFIEX_HW_STATUS_INITIALIZING) + mwifiex_init_fw_complete(adapter); diff --git a/queue-3.4/mwifiex-report-error-to-mmc-core-if-we-cannot-suspend.patch b/queue-3.4/mwifiex-report-error-to-mmc-core-if-we-cannot-suspend.patch new file mode 100644 index 00000000000..3da556c17b2 --- /dev/null +++ b/queue-3.4/mwifiex-report-error-to-mmc-core-if-we-cannot-suspend.patch @@ -0,0 +1,51 @@ +From dd321acddc3be1371263b8c9e6c6f2af89f63d57 Mon Sep 17 00:00:00 2001 +From: Bing Zhao +Date: Thu, 15 Nov 2012 15:58:48 -0800 +Subject: mwifiex: report error to MMC core if we cannot suspend + +From: Bing Zhao + +commit dd321acddc3be1371263b8c9e6c6f2af89f63d57 upstream. + +When host_sleep_config command fails we should return error to +MMC core to indicate the failure for our device. + +The misspelled variable is also removed as it's redundant. + +Signed-off-by: Bing Zhao +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/mwifiex/sdio.c | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +--- a/drivers/net/wireless/mwifiex/sdio.c ++++ b/drivers/net/wireless/mwifiex/sdio.c +@@ -158,7 +158,6 @@ static int mwifiex_sdio_suspend(struct d + struct sdio_mmc_card *card; + struct mwifiex_adapter *adapter; + mmc_pm_flag_t pm_flag = 0; +- int hs_actived = 0; + int i; + int ret = 0; + +@@ -185,12 +184,14 @@ static int mwifiex_sdio_suspend(struct d + adapter = card->adapter; + + /* Enable the Host Sleep */ +- hs_actived = mwifiex_enable_hs(adapter); +- if (hs_actived) { +- pr_debug("cmd: suspend with MMC_PM_KEEP_POWER\n"); +- ret = sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER); ++ if (!mwifiex_enable_hs(adapter)) { ++ dev_err(adapter->dev, "cmd: failed to suspend\n"); ++ return -EFAULT; + } + ++ dev_dbg(adapter->dev, "cmd: suspend with MMC_PM_KEEP_POWER\n"); ++ ret = sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER); ++ + /* Indicate device suspended */ + adapter->is_suspended = true; + diff --git a/queue-3.4/parisc-fix-user-triggerable-panic-on-parisc.patch b/queue-3.4/parisc-fix-user-triggerable-panic-on-parisc.patch new file mode 100644 index 00000000000..cb63c921557 --- /dev/null +++ b/queue-3.4/parisc-fix-user-triggerable-panic-on-parisc.patch @@ -0,0 +1,59 @@ +From 441a179dafc0f99fc8b3a8268eef66958621082e Mon Sep 17 00:00:00 2001 +From: Al Viro +Date: Wed, 21 Nov 2012 19:27:23 +0000 +Subject: PARISC: fix user-triggerable panic on parisc + +From: Al Viro + +commit 441a179dafc0f99fc8b3a8268eef66958621082e upstream. + +int sys32_rt_sigprocmask(int how, compat_sigset_t __user *set, compat_sigset_t __user *oset, + unsigned int sigsetsize) +{ + sigset_t old_set, new_set; + int ret; + + if (set && get_sigset32(set, &new_set, sigsetsize)) + +... +static int +get_sigset32(compat_sigset_t __user *up, sigset_t *set, size_t sz) +{ + compat_sigset_t s; + int r; + + if (sz != sizeof *set) panic("put_sigset32()"); + +In other words, rt_sigprocmask(69, (void *)69, 69) done by 32bit process +will promptly panic the box. + +Signed-off-by: Al Viro +Signed-off-by: James Bottomley +Signed-off-by: Greg Kroah-Hartman + +--- + arch/parisc/kernel/signal32.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/arch/parisc/kernel/signal32.c ++++ b/arch/parisc/kernel/signal32.c +@@ -67,7 +67,8 @@ put_sigset32(compat_sigset_t __user *up, + { + compat_sigset_t s; + +- if (sz != sizeof *set) panic("put_sigset32()"); ++ if (sz != sizeof *set) ++ return -EINVAL; + sigset_64to32(&s, set); + + return copy_to_user(up, &s, sizeof s); +@@ -79,7 +80,8 @@ get_sigset32(compat_sigset_t __user *up, + compat_sigset_t s; + int r; + +- if (sz != sizeof *set) panic("put_sigset32()"); ++ if (sz != sizeof *set) ++ return -EINVAL; + + if ((r = copy_from_user(&s, up, sz)) == 0) { + sigset_32to64(set, &s); diff --git a/queue-3.4/parisc-fix-virtual-aliasing-issue-in-get_shared_area.patch b/queue-3.4/parisc-fix-virtual-aliasing-issue-in-get_shared_area.patch new file mode 100644 index 00000000000..f118e90f6f7 --- /dev/null +++ b/queue-3.4/parisc-fix-virtual-aliasing-issue-in-get_shared_area.patch @@ -0,0 +1,47 @@ +From 949a05d03490e39e773e8652ccab9157e6f595b4 Mon Sep 17 00:00:00 2001 +From: James Bottomley +Date: Fri, 2 Nov 2012 12:30:53 +0000 +Subject: PARISC: fix virtual aliasing issue in get_shared_area() + +From: James Bottomley + +commit 949a05d03490e39e773e8652ccab9157e6f595b4 upstream. + +On Thu, 2012-11-01 at 16:45 -0700, Michel Lespinasse wrote: +> Looking at the arch/parisc/kernel/sys_parisc.c implementation of +> get_shared_area(), I do have a concern though. The function basically +> ignores the pgoff argument, so that if one creates a shared mapping of +> pages 0-N of a file, and then a separate shared mapping of pages 1-N +> of that same file, both will have the same cache offset for their +> starting address. +> +> This looks like this would create obvious aliasing issues. Am I +> misreading this ? I can't understand how this could work good enough +> to be undetected, so there must be something I'm missing here ??? + +This turns out to be correct and we need to pay attention to the pgoff as +well as the address when creating the virtual address for the area. +Fortunately, the bug is rarely triggered as most applications which use pgoff +tend to use large values (git being the primary one, and it uses pgoff in +multiples of 16MB) which are larger than our cache coherency modulus, so the +problem isn't often seen in practise. + +Reported-by: Michel Lespinasse +Signed-off-by: James Bottomley +Signed-off-by: Greg Kroah-Hartman + +--- + arch/parisc/kernel/sys_parisc.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/parisc/kernel/sys_parisc.c ++++ b/arch/parisc/kernel/sys_parisc.c +@@ -73,6 +73,8 @@ static unsigned long get_shared_area(str + struct vm_area_struct *vma; + int offset = mapping ? get_offset(mapping) : 0; + ++ offset = (offset + (pgoff << PAGE_SHIFT)) & 0x3FF000; ++ + addr = DCACHE_ALIGN(addr - offset) + offset; + + for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) { diff --git a/queue-3.4/radeon-add-agpmode-1-quirk-for-rv250.patch b/queue-3.4/radeon-add-agpmode-1-quirk-for-rv250.patch new file mode 100644 index 00000000000..6cc87fed3d4 --- /dev/null +++ b/queue-3.4/radeon-add-agpmode-1-quirk-for-rv250.patch @@ -0,0 +1,39 @@ +From 45171002b01b2e2ec4f991eca81ffd8430fd0aec Mon Sep 17 00:00:00 2001 +From: Paul Bolle +Date: Mon, 19 Nov 2012 21:17:31 +0100 +Subject: radeon: add AGPMode 1 quirk for RV250 + +From: Paul Bolle + +commit 45171002b01b2e2ec4f991eca81ffd8430fd0aec upstream. + +The Intel 82855PM host bridge / Mobility FireGL 9000 RV250 combination +in an (outdated) ThinkPad T41 needs AGPMode 1 for suspend/resume (under +KMS, that is). So add a quirk for it. + +(Change R250 to RV250 in comment for preceding quirk too.) + +Signed-off-by: Paul Bolle +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_agp.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/radeon/radeon_agp.c ++++ b/drivers/gpu/drm/radeon/radeon_agp.c +@@ -70,9 +70,12 @@ static struct radeon_agpmode_quirk radeo + /* Intel 82830 830 Chipset Host Bridge / Mobility M6 LY Needs AGPMode 2 (fdo #17360)*/ + { PCI_VENDOR_ID_INTEL, 0x3575, PCI_VENDOR_ID_ATI, 0x4c59, + PCI_VENDOR_ID_DELL, 0x00e3, 2}, +- /* Intel 82852/82855 host bridge / Mobility FireGL 9000 R250 Needs AGPMode 1 (lp #296617) */ ++ /* Intel 82852/82855 host bridge / Mobility FireGL 9000 RV250 Needs AGPMode 1 (lp #296617) */ + { PCI_VENDOR_ID_INTEL, 0x3580, PCI_VENDOR_ID_ATI, 0x4c66, + PCI_VENDOR_ID_DELL, 0x0149, 1}, ++ /* Intel 82855PM host bridge / Mobility FireGL 9000 RV250 Needs AGPMode 1 for suspend/resume */ ++ { PCI_VENDOR_ID_INTEL, 0x3340, PCI_VENDOR_ID_ATI, 0x4c66, ++ PCI_VENDOR_ID_IBM, 0x0531, 1}, + /* Intel 82852/82855 host bridge / Mobility 9600 M10 RV350 Needs AGPMode 1 (deb #467460) */ + { PCI_VENDOR_ID_INTEL, 0x3580, PCI_VENDOR_ID_ATI, 0x4e50, + 0x1025, 0x0061, 1}, diff --git a/queue-3.4/rtlwifi-rtl8192cu-add-new-usb-id.patch b/queue-3.4/rtlwifi-rtl8192cu-add-new-usb-id.patch new file mode 100644 index 00000000000..867d8402f7f --- /dev/null +++ b/queue-3.4/rtlwifi-rtl8192cu-add-new-usb-id.patch @@ -0,0 +1,31 @@ +From a485e827f07bfdd0762059386e6e787bed6e81ee Mon Sep 17 00:00:00 2001 +From: Albert Pool +Date: Tue, 30 Oct 2012 20:58:06 +0100 +Subject: rtlwifi: rtl8192cu: Add new USB ID + +From: Albert Pool + +commit a485e827f07bfdd0762059386e6e787bed6e81ee upstream. + +This is an ISY IWL 2000. Probably a clone of Belkin F7D1102 050d:1102. +Its FCC ID is the same. + +Signed-off-by: Albert Pool +Acked-by: Larry Finger +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c ++++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c +@@ -297,6 +297,7 @@ static struct usb_device_id rtl8192c_usb + /*=== Customer ID ===*/ + /****** 8188CU ********/ + {RTL_USB_DEVICE(0x050d, 0x1102, rtl92cu_hal_cfg)}, /*Belkin - Edimax*/ ++ {RTL_USB_DEVICE(0x050d, 0x11f2, rtl92cu_hal_cfg)}, /*Belkin - ISY*/ + {RTL_USB_DEVICE(0x06f8, 0xe033, rtl92cu_hal_cfg)}, /*Hercules - Edimax*/ + {RTL_USB_DEVICE(0x07b8, 0x8188, rtl92cu_hal_cfg)}, /*Abocom - Abocom*/ + {RTL_USB_DEVICE(0x07b8, 0x8189, rtl92cu_hal_cfg)}, /*Funai - Abocom*/ diff --git a/queue-3.4/scsi-isci-copy-fis-0x34-response-into-proper-buffer.patch b/queue-3.4/scsi-isci-copy-fis-0x34-response-into-proper-buffer.patch new file mode 100644 index 00000000000..97e57e52441 --- /dev/null +++ b/queue-3.4/scsi-isci-copy-fis-0x34-response-into-proper-buffer.patch @@ -0,0 +1,36 @@ +From 49bd665c5407a453736d3232ee58f2906b42e83c Mon Sep 17 00:00:00 2001 +From: Maciej Patelczyk +Date: Mon, 15 Oct 2012 14:29:03 +0200 +Subject: SCSI: isci: copy fis 0x34 response into proper buffer + +From: Maciej Patelczyk + +commit 49bd665c5407a453736d3232ee58f2906b42e83c upstream. + +SATA MICROCODE DOWNALOAD fails on isci driver. After receiving Register +Device to Host (FIS 0x34) frame Initiator resets phy. +In the frame handler routine response (FIS 0x34) was copied into wrong +buffer and upper layer did not receive any answer which resulted in +timeout and reset. +This patch corrects this bug. + +Signed-off-by: Maciej Patelczyk +Signed-off-by: Lukasz Dorau +Signed-off-by: James Bottomley +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/isci/request.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/scsi/isci/request.c ++++ b/drivers/scsi/isci/request.c +@@ -1970,7 +1970,7 @@ sci_io_request_frame_handler(struct isci + frame_index, + (void **)&frame_buffer); + +- sci_controller_copy_sata_response(&ireq->stp.req, ++ sci_controller_copy_sata_response(&ireq->stp.rsp, + frame_header, + frame_buffer); + diff --git a/queue-3.4/series b/queue-3.4/series index b86f4413395..8d0cc33a31e 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -6,3 +6,25 @@ drivers-leds-leds-lp5521.c-fix-lp5521_read-error-handling.patch mvsas-remove-unused-variable-in-mvs_task_exec.patch scsi-aha152x-fix-sparse-warning-and-make-printing-pointer-address-more-portable.patch rtlwifi-rtl8192se-fix-gcc-4.7.x-warning.patch +x86-32-fix-invalid-stack-address-while-in-softirq.patch +x86-efi-fix-processor-specific-memcpy-build-error.patch +x86-microcode-amd-add-support-for-family-16h-processors.patch +rtlwifi-rtl8192cu-add-new-usb-id.patch +mwifiex-report-error-to-mmc-core-if-we-cannot-suspend.patch +mwifiex-fix-system-hang-issue-in-cmd-timeout-error-case.patch +scsi-isci-copy-fis-0x34-response-into-proper-buffer.patch +drm-radeon-add-new-si-pci-id.patch +alsa-ua101-usx2y-fix-broken-midi-output.patch +alsa-hda-cirrus-correctly-clear-line_out_pins-when-moving-to-speaker.patch +parisc-fix-virtual-aliasing-issue-in-get_shared_area.patch +parisc-fix-user-triggerable-panic-on-parisc.patch +mtd-slram-invalid-checking-of-absolute-end-address.patch +mtd-ofpart-fix-incorrect-null-check-in-parse_ofoldpart_partitions.patch +jffs2-fix-lock-acquisition-order-bug-in-jffs2_write_begin.patch +md-reassigned-the-parameters-if-read_seqretry-returned-true-in-func-md_is_badblock.patch +md-avoid-write-invalid-address-if-read_seqretry-returned-true.patch +md-raid10-decrement-correct-pending-counter-when-writing-to-replacement.patch +dm-fix-deadlock-with-request-based-dm-and-queue-request_fn-recursion.patch +futex-avoid-wake_futex-for-a-pi-futex_q.patch +mac80211-deinitialize-ibss-internals-after-emptiness-check.patch +radeon-add-agpmode-1-quirk-for-rv250.patch diff --git a/queue-3.4/x86-32-fix-invalid-stack-address-while-in-softirq.patch b/queue-3.4/x86-32-fix-invalid-stack-address-while-in-softirq.patch new file mode 100644 index 00000000000..df628ba5496 --- /dev/null +++ b/queue-3.4/x86-32-fix-invalid-stack-address-while-in-softirq.patch @@ -0,0 +1,144 @@ +From 1022623842cb72ee4d0dbf02f6937f38c92c3f41 Mon Sep 17 00:00:00 2001 +From: Robert Richter +Date: Mon, 3 Sep 2012 20:54:48 +0200 +Subject: x86-32: Fix invalid stack address while in softirq + +From: Robert Richter + +commit 1022623842cb72ee4d0dbf02f6937f38c92c3f41 upstream. + +In 32 bit the stack address provided by kernel_stack_pointer() may +point to an invalid range causing NULL pointer access or page faults +while in NMI (see trace below). This happens if called in softirq +context and if the stack is empty. The address at ®s->sp is then +out of range. + +Fixing this by checking if regs and ®s->sp are in the same stack +context. Otherwise return the previous stack pointer stored in struct +thread_info. If that address is invalid too, return address of regs. + + BUG: unable to handle kernel NULL pointer dereference at 0000000a + IP: [] print_context_stack+0x6e/0x8d + *pde = 00000000 + Oops: 0000 [#1] SMP + Modules linked in: + Pid: 4434, comm: perl Not tainted 3.6.0-rc3-oprofile-i386-standard-g4411a05 #4 Hewlett-Packard HP xw9400 Workstation/0A1Ch + EIP: 0060:[] EFLAGS: 00010093 CPU: 0 + EIP is at print_context_stack+0x6e/0x8d + EAX: ffffe000 EBX: 0000000a ECX: f4435f94 EDX: 0000000a + ESI: f4435f94 EDI: f4435f94 EBP: f5409ec0 ESP: f5409ea0 + DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 + CR0: 8005003b CR2: 0000000a CR3: 34ac9000 CR4: 000007d0 + DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 + DR6: ffff0ff0 DR7: 00000400 + Process perl (pid: 4434, ti=f5408000 task=f5637850 task.ti=f4434000) + Stack: + 000003e8 ffffe000 00001ffc f4e39b00 00000000 0000000a f4435f94 c155198c + f5409ef0 c1003723 c155198c f5409f04 00000000 f5409edc 00000000 00000000 + f5409ee8 f4435f94 f5409fc4 00000001 f5409f1c c12dce1c 00000000 c155198c + Call Trace: + [] dump_trace+0x7b/0xa1 + [] x86_backtrace+0x40/0x88 + [] ? oprofile_add_sample+0x56/0x84 + [] oprofile_add_sample+0x75/0x84 + [] op_amd_check_ctrs+0x46/0x260 + [] profile_exceptions_notify+0x23/0x4c + [] nmi_handle+0x31/0x4a + [] ? ftrace_define_fields_irq_handler_entry+0x45/0x45 + [] do_nmi+0xa0/0x2ff + [] ? ftrace_define_fields_irq_handler_entry+0x45/0x45 + [] nmi_stack_correct+0x28/0x2d + [] ? ftrace_define_fields_irq_handler_entry+0x45/0x45 + [] ? do_softirq+0x4b/0x7f + + [] irq_exit+0x35/0x5b + [] smp_apic_timer_interrupt+0x6c/0x7a + [] apic_timer_interrupt+0x2a/0x30 + Code: 89 fe eb 08 31 c9 8b 45 0c ff 55 ec 83 c3 04 83 7d 10 00 74 0c 3b 5d 10 73 26 3b 5d e4 73 0c eb 1f 3b 5d f0 76 1a 3b 5d e8 73 15 <8b> 13 89 d0 89 55 e0 e8 ad 42 03 00 85 c0 8b 55 e0 75 a6 eb cc + EIP: [] print_context_stack+0x6e/0x8d SS:ESP 0068:f5409ea0 + CR2: 000000000000000a + ---[ end trace 62afee3481b00012 ]--- + Kernel panic - not syncing: Fatal exception in interrupt + +V2: +* add comments to kernel_stack_pointer() +* always return a valid stack address by falling back to the address + of regs + +Reported-by: Yang Wei +Signed-off-by: Robert Richter +Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.com +Signed-off-by: H. Peter Anvin +Cc: Jun Zhang +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/ptrace.h | 15 ++++----------- + arch/x86/kernel/ptrace.c | 28 ++++++++++++++++++++++++++++ + 2 files changed, 32 insertions(+), 11 deletions(-) + +--- a/arch/x86/include/asm/ptrace.h ++++ b/arch/x86/include/asm/ptrace.h +@@ -205,21 +205,14 @@ static inline bool user_64bit_mode(struc + } + #endif + +-/* +- * X86_32 CPUs don't save ss and esp if the CPU is already in kernel mode +- * when it traps. The previous stack will be directly underneath the saved +- * registers, and 'sp/ss' won't even have been saved. Thus the '®s->sp'. +- * +- * This is valid only for kernel mode traps. +- */ +-static inline unsigned long kernel_stack_pointer(struct pt_regs *regs) +-{ + #ifdef CONFIG_X86_32 +- return (unsigned long)(®s->sp); ++extern unsigned long kernel_stack_pointer(struct pt_regs *regs); + #else ++static inline unsigned long kernel_stack_pointer(struct pt_regs *regs) ++{ + return regs->sp; +-#endif + } ++#endif + + #define GET_IP(regs) ((regs)->ip) + #define GET_FP(regs) ((regs)->bp) +--- a/arch/x86/kernel/ptrace.c ++++ b/arch/x86/kernel/ptrace.c +@@ -165,6 +165,34 @@ static inline bool invalid_selector(u16 + + #define FLAG_MASK FLAG_MASK_32 + ++/* ++ * X86_32 CPUs don't save ss and esp if the CPU is already in kernel mode ++ * when it traps. The previous stack will be directly underneath the saved ++ * registers, and 'sp/ss' won't even have been saved. Thus the '®s->sp'. ++ * ++ * Now, if the stack is empty, '®s->sp' is out of range. In this ++ * case we try to take the previous stack. To always return a non-null ++ * stack pointer we fall back to regs as stack if no previous stack ++ * exists. ++ * ++ * This is valid only for kernel mode traps. ++ */ ++unsigned long kernel_stack_pointer(struct pt_regs *regs) ++{ ++ unsigned long context = (unsigned long)regs & ~(THREAD_SIZE - 1); ++ unsigned long sp = (unsigned long)®s->sp; ++ struct thread_info *tinfo; ++ ++ if (context == (sp & ~(THREAD_SIZE - 1))) ++ return sp; ++ ++ tinfo = (struct thread_info *)context; ++ if (tinfo->previous_esp) ++ return tinfo->previous_esp; ++ ++ return (unsigned long)regs; ++} ++ + static unsigned long *pt_regs_access(struct pt_regs *regs, unsigned long regno) + { + BUILD_BUG_ON(offsetof(struct pt_regs, bx) != 0); diff --git a/queue-3.4/x86-efi-fix-processor-specific-memcpy-build-error.patch b/queue-3.4/x86-efi-fix-processor-specific-memcpy-build-error.patch new file mode 100644 index 00000000000..c4070f6d242 --- /dev/null +++ b/queue-3.4/x86-efi-fix-processor-specific-memcpy-build-error.patch @@ -0,0 +1,44 @@ +From 0f905a43ce955b638139bd84486194770a6a2c08 Mon Sep 17 00:00:00 2001 +From: Matt Fleming +Date: Tue, 20 Nov 2012 13:07:46 +0000 +Subject: x86, efi: Fix processor-specific memcpy() build error + +From: Matt Fleming + +commit 0f905a43ce955b638139bd84486194770a6a2c08 upstream. + +Building for Athlon/Duron/K7 results in the following build error, + +arch/x86/boot/compressed/eboot.o: In function `__constant_memcpy3d': +eboot.c:(.text+0x385): undefined reference to `_mmx_memcpy' +arch/x86/boot/compressed/eboot.o: In function `efi_main': +eboot.c:(.text+0x1a22): undefined reference to `_mmx_memcpy' + +because the boot stub code doesn't link with the kernel proper, and +therefore doesn't have access to the 3DNow version of memcpy. So, +follow the example of misc.c and #undef memcpy so that we use the +version provided by misc.c. + +See https://bugzilla.kernel.org/show_bug.cgi?id=50391 + +Reported-by: Al Viro +Reported-by: Ryan Underwood +Cc: H. Peter Anvin +Signed-off-by: Matt Fleming +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/boot/compressed/eboot.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/x86/boot/compressed/eboot.c ++++ b/arch/x86/boot/compressed/eboot.c +@@ -12,6 +12,8 @@ + #include + #include + ++#undef memcpy /* Use memcpy from misc.c */ ++ + #include "eboot.h" + + static efi_system_table_t *sys_table; diff --git a/queue-3.4/x86-microcode-amd-add-support-for-family-16h-processors.patch b/queue-3.4/x86-microcode-amd-add-support-for-family-16h-processors.patch new file mode 100644 index 00000000000..709e9c8a05b --- /dev/null +++ b/queue-3.4/x86-microcode-amd-add-support-for-family-16h-processors.patch @@ -0,0 +1,43 @@ +From 36c46ca4f322a7bf89aad5462a3a1f61713edce7 Mon Sep 17 00:00:00 2001 +From: Boris Ostrovsky +Date: Thu, 15 Nov 2012 13:41:50 -0500 +Subject: x86, microcode, AMD: Add support for family 16h processors + +From: Boris Ostrovsky + +commit 36c46ca4f322a7bf89aad5462a3a1f61713edce7 upstream. + +Add valid patch size for family 16h processors. + +[ hpa: promoting to urgent/stable since it is hw enabling and trivial ] + +Signed-off-by: Boris Ostrovsky +Acked-by: Andreas Herrmann +Link: http://lkml.kernel.org/r/1353004910-2204-1-git-send-email-boris.ostrovsky@amd.com +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/microcode_amd.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/x86/kernel/microcode_amd.c ++++ b/arch/x86/kernel/microcode_amd.c +@@ -97,6 +97,7 @@ static unsigned int verify_ucode_size(in + #define F1XH_MPB_MAX_SIZE 2048 + #define F14H_MPB_MAX_SIZE 1824 + #define F15H_MPB_MAX_SIZE 4096 ++#define F16H_MPB_MAX_SIZE 3458 + + switch (c->x86) { + case 0x14: +@@ -105,6 +106,9 @@ static unsigned int verify_ucode_size(in + case 0x15: + max_size = F15H_MPB_MAX_SIZE; + break; ++ case 0x16: ++ max_size = F16H_MPB_MAX_SIZE; ++ break; + default: + max_size = F1XH_MPB_MAX_SIZE; + break;