--- /dev/null
+From c7abf25af0f41be4b50d44c5b185d52eea360cb8 Mon Sep 17 00:00:00 2001
+From: Karl Beldan <karl.beldan@rivierawaves.com>
+Date: Mon, 13 Oct 2014 14:34:41 +0200
+Subject: mac80211: fix typo in starting baserate for rts_cts_rate_idx
+
+From: Karl Beldan <karl.beldan@rivierawaves.com>
+
+commit c7abf25af0f41be4b50d44c5b185d52eea360cb8 upstream.
+
+It affects non-(V)HT rates and can lead to selecting an rts_cts rate
+that is not a basic rate or way superior to the reference rate (ATM
+rates[0] used for the 1st attempt of the protected frame data).
+
+E.g, assuming drivers register growing (bitrate) sorted tables of
+ieee80211_rate-s, having :
+- rates[0].idx == d'2 and basic_rates == b'10100
+will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise
+- rates[0].idx == d'2 and basic_rates == b'10001
+will select rts_cts idx b'10000
+The first is not a basic rate and the second is > rates[0].
+
+Also, wrt severity of the addressed misbehavior, ATM we only have one
+rts_cts_rate_idx rather than one per rate table entry, so this idx might
+still point to bitrates > rates[1..MAX_RATES].
+
+Fixes: 5253ffb8c9e1 ("mac80211: always pick a basic rate to tx RTS/CTS for pre-HT rates")
+Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/rate.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mac80211/rate.c
++++ b/net/mac80211/rate.c
+@@ -448,7 +448,7 @@ static void rate_fixup_ratelist(struct i
+ */
+ if (!(rates[0].flags & IEEE80211_TX_RC_MCS)) {
+ u32 basic_rates = vif->bss_conf.basic_rates;
+- s8 baserate = basic_rates ? ffs(basic_rates - 1) : 0;
++ s8 baserate = basic_rates ? ffs(basic_rates) - 1 : 0;
+
+ rate = &sband->bitrates[rates[0].idx];
+
--- /dev/null
+From 94fb823fcb4892614f57e59601bb9d4920f24711 Mon Sep 17 00:00:00 2001
+From: Imre Deak <imre.deak@intel.com>
+Date: Fri, 24 Oct 2014 20:29:10 +0300
+Subject: PM / Sleep: fix recovery during resuming from hibernation
+
+From: Imre Deak <imre.deak@intel.com>
+
+commit 94fb823fcb4892614f57e59601bb9d4920f24711 upstream.
+
+If a device's dev_pm_ops::freeze callback fails during the QUIESCE
+phase, we don't rollback things correctly calling the thaw and complete
+callbacks. This could leave some devices in a suspended state in case of
+an error during resuming from hibernation.
+
+Signed-off-by: Imre Deak <imre.deak@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/power/hibernate.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/kernel/power/hibernate.c
++++ b/kernel/power/hibernate.c
+@@ -491,8 +491,14 @@ int hibernation_restore(int platform_mod
+ error = dpm_suspend_start(PMSG_QUIESCE);
+ if (!error) {
+ error = resume_target_kernel(platform_mode);
+- dpm_resume_end(PMSG_RECOVER);
++ /*
++ * The above should either succeed and jump to the new kernel,
++ * or return with an error. Otherwise things are just
++ * undefined, so let's be paranoid.
++ */
++ BUG_ON(!error);
+ }
++ dpm_resume_end(PMSG_RECOVER);
+ pm_restore_gfp_mask();
+ ftrace_start();
+ resume_console();
nfsd4-fix-crash-on-unknown-operation-number.patch
ext3-don-t-check-quota-format-when-there-are-no-quota-files.patch
quota-properly-return-errors-from-dquot_writeback_dquots.patch
+tty-fix-high-cpu-load-if-tty-is-unreleaseable.patch
+pm-sleep-fix-recovery-during-resuming-from-hibernation.patch
+mac80211-fix-typo-in-starting-baserate-for-rts_cts_rate_idx.patch
--- /dev/null
+From 37b164578826406a173ca7c20d9ba7430134d23e Mon Sep 17 00:00:00 2001
+From: Peter Hurley <peter@hurleysoftware.com>
+Date: Thu, 16 Oct 2014 13:51:30 -0400
+Subject: tty: Fix high cpu load if tty is unreleaseable
+
+From: Peter Hurley <peter@hurleysoftware.com>
+
+commit 37b164578826406a173ca7c20d9ba7430134d23e upstream.
+
+Kernel oops can cause the tty to be unreleaseable (for example, if
+n_tty_read() crashes while on the read_wait queue). This will cause
+tty_release() to endlessly loop without sleeping.
+
+Use a killable sleep timeout which grows by 2n+1 jiffies over the interval
+[0, 120 secs.) and then jumps to forever (but still killable).
+
+NB: killable just allows for the task to be rewoken manually, not
+to be terminated.
+
+Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/tty_io.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/tty_io.c
++++ b/drivers/tty/tty_io.c
+@@ -1698,6 +1698,7 @@ int tty_release(struct inode *inode, str
+ int pty_master, tty_closing, o_tty_closing, do_sleep;
+ int idx;
+ char buf[64];
++ long timeout = 0;
+
+ if (tty_paranoia_check(tty, inode, __func__))
+ return 0;
+@@ -1782,7 +1783,11 @@ int tty_release(struct inode *inode, str
+ __func__, tty_name(tty, buf));
+ tty_unlock_pair(tty, o_tty);
+ mutex_unlock(&tty_mutex);
+- schedule();
++ schedule_timeout_killable(timeout);
++ if (timeout < 120 * HZ)
++ timeout = 2 * timeout + 1;
++ else
++ timeout = MAX_SCHEDULE_TIMEOUT;
+ }
+
+ /*
projects / thirdparty / kernel / stable-queue.git / commitdiff
