rpms
/
kernel
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Linux v3.9.8

This commit is contained in:
Josh Boyer 2013-06-27 14:57:33 -04:00
parent ea007cb669
commit 871f73f857
8 changed files with 6 additions and 406 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

160
carl9170-fix-frame-drop-and-WARN-due-to-minstrel_ht-.patch
View File

@ -1,160 +0,0 @@
From 5f34608fa2acbfef5a06d0072a978c9943c28a2d Mon Sep 17 00:00:00 2001
From: Christian Lamparter <chunkeey@googlemail.com>
Date: Fri, 22 Feb 2013 01:30:44 +0100
Subject: [PATCH] carl9170: fix frame drop and WARN due to minstrel_ht change
With "mac80211/minstrel_ht: add support for using CCK rates"
minstrel_ht selects legacy CCK rates as viable rates for
outgoing frames which might be sent as part of an A-MPDU
[IEEE80211_TX_CTL_AMPDU is set].
This behavior triggered the following WARN_ON in the driver:
> WARNING: at carl9170/tx.c:995 carl9170_op_tx+0x1dd/0x6fd
The driver assumed that the rate control algorithm made a
mistake and dropped the frame.
This patch removes the noisy warning altogether and allows
said A-MPDU frames with CCK sample and/or fallback rates to
be transmitted seamlessly.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/carl9170/tx.c | 69 ++++++++++++++--------------------
1 file changed, 28 insertions(+), 41 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/tx.c b/drivers/net/wireless/ath/carl9170/tx.c
index 9c0b150..c61cafa 100644
--- a/drivers/net/wireless/ath/carl9170/tx.c
+++ b/drivers/net/wireless/ath/carl9170/tx.c
@@ -387,8 +387,7 @@ static void carl9170_tx_status_process_ampdu(struct ar9170 *ar,
u8 tid;
if (!(txinfo->flags & IEEE80211_TX_CTL_AMPDU) ||
- txinfo->flags & IEEE80211_TX_CTL_INJECTED ||
- (!(super->f.mac_control & cpu_to_le16(AR9170_TX_MAC_AGGR))))
+ txinfo->flags & IEEE80211_TX_CTL_INJECTED)
return;
rcu_read_lock();
@@ -981,30 +980,6 @@ static int carl9170_tx_prepare(struct ar9170 *ar,
SET_VAL(CARL9170_TX_SUPER_AMPDU_FACTOR,
txc->s.ampdu_settings, factor);
-
- for (i = 0; i < CARL9170_TX_MAX_RATES; i++) {
- txrate = &info->control.rates[i];
- if (txrate->idx >= 0) {
- txc->s.ri[i] =
- CARL9170_TX_SUPER_RI_AMPDU;
-
- if (WARN_ON(!(txrate->flags &
- IEEE80211_TX_RC_MCS))) {
- /*
- * Not sure if it's even possible
- * to aggregate non-ht rates with
- * this HW.
- */
- goto err_out;
- }
- continue;
- }
-
- txrate->idx = 0;
- txrate->count = ar->hw->max_rate_tries;
- }
-
- mac_tmp |= cpu_to_le16(AR9170_TX_MAC_AGGR);
}
/*
@@ -1012,11 +987,31 @@ static int carl9170_tx_prepare(struct ar9170 *ar,
* taken from mac_control. For all fallback rate, the firmware
* updates the mac_control flags from the rate info field.
*/
- for (i = 1; i < CARL9170_TX_MAX_RATES; i++) {
+ for (i = 0; i < CARL9170_TX_MAX_RATES; i++) {
+ __le32 phy_set;
txrate = &info->control.rates[i];
if (txrate->idx < 0)
break;
+ phy_set = carl9170_tx_physet(ar, info, txrate);
+ if (i == 0) {
+ /* first rate - part of the hw's frame header */
+ txc->f.phy_control = phy_set;
+
+ if (ampdu && txrate->flags & IEEE80211_TX_RC_MCS)
+ mac_tmp |= cpu_to_le16(AR9170_TX_MAC_AGGR);
+ if (carl9170_tx_rts_check(ar, txrate, ampdu, no_ack))
+ mac_tmp |= cpu_to_le16(AR9170_TX_MAC_PROT_RTS);
+ else if (carl9170_tx_cts_check(ar, txrate))
+ mac_tmp |= cpu_to_le16(AR9170_TX_MAC_PROT_CTS);
+
+ } else {
+ /* fallback rates are stored in the firmware's
+ * retry rate set array.
+ */
+ txc->s.rr[i - 1] = phy_set;
+ }
+
SET_VAL(CARL9170_TX_SUPER_RI_TRIES, txc->s.ri[i],
txrate->count);
@@ -1027,21 +1022,13 @@ static int carl9170_tx_prepare(struct ar9170 *ar,
txc->s.ri[i] |= (AR9170_TX_MAC_PROT_CTS <<
CARL9170_TX_SUPER_RI_ERP_PROT_S);
- txc->s.rr[i - 1] = carl9170_tx_physet(ar, info, txrate);
+ if (ampdu && (txrate->flags & IEEE80211_TX_RC_MCS))
+ txc->s.ri[i] |= CARL9170_TX_SUPER_RI_AMPDU;
}
- txrate = &info->control.rates[0];
- SET_VAL(CARL9170_TX_SUPER_RI_TRIES, txc->s.ri[0], txrate->count);
-
- if (carl9170_tx_rts_check(ar, txrate, ampdu, no_ack))
- mac_tmp |= cpu_to_le16(AR9170_TX_MAC_PROT_RTS);
- else if (carl9170_tx_cts_check(ar, txrate))
- mac_tmp |= cpu_to_le16(AR9170_TX_MAC_PROT_CTS);
-
txc->s.len = cpu_to_le16(skb->len);
txc->f.length = cpu_to_le16(len + FCS_LEN);
txc->f.mac_control = mac_tmp;
- txc->f.phy_control = carl9170_tx_physet(ar, info, txrate);
arinfo = (void *)info->rate_driver_data;
arinfo->timeout = jiffies;
@@ -1381,9 +1368,9 @@ static void carl9170_tx(struct ar9170 *ar)
}
static bool carl9170_tx_ampdu_queue(struct ar9170 *ar,
- struct ieee80211_sta *sta, struct sk_buff *skb)
+ struct ieee80211_sta *sta, struct sk_buff *skb,
+ struct ieee80211_tx_info *txinfo)
{
- struct _carl9170_tx_superframe *super = (void *) skb->data;
struct carl9170_sta_info *sta_info;
struct carl9170_sta_tid *agg;
struct sk_buff *iter;
@@ -1450,7 +1437,7 @@ err_unlock:
err_unlock_rcu:
rcu_read_unlock();
- super->f.mac_control &= ~cpu_to_le16(AR9170_TX_MAC_AGGR);
+ txinfo->flags &= ~IEEE80211_TX_CTL_AMPDU;
carl9170_tx_status(ar, skb, false);
ar->tx_dropped++;
return false;
@@ -1492,7 +1479,7 @@ void carl9170_op_tx(struct ieee80211_hw *hw,
* sta == NULL checks are redundant in this
* special case.
*/
- run = carl9170_tx_ampdu_queue(ar, sta, skb);
+ run = carl9170_tx_ampdu_queue(ar, sta, skb, info);
if (run)
carl9170_tx_ampdu(ar);
--
1.7.11.7

1
config-armv7-generic
View File

@ -54,6 +54,7 @@ CONFIG_ARM_ERRATA_430973=y
CONFIG_ARM_ERRATA_458693=y
CONFIG_ARM_ERRATA_460075=y
# Cortex-A9
CONFIG_ARM_ERRATA_643719=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_ARM_ERRATA_742230=y
CONFIG_ARM_ERRATA_742231=y

27
kernel.spec
View File

@ -74,7 +74,7 @@ Summary: The Linux kernel
%if 0%{?released_kernel}
# Do we have a -stable update to apply?
%define stable_update 7
%define stable_update 8
# Is it a -stable RC?
%define stable_rc 0
# Set rpm version accordingly
@ -772,14 +772,6 @@ Patch25036: scsi-ipr-possible-irq-lock-inversion-dependency-detected.patch
#CVE-2013-2164 rhbz 973100 973109
Patch25038: cdrom-use-kzalloc-for-failing-hardware.patch
#rhbz 954181
Patch25039: vhost_net-clear-msg.control-for-non-zerocopy-case-during-tx.patch
Patch25040: tuntap-set-SOCK_ZEROCOPY-flag-during-open.patch
#rhbz 973185
Patch25041: x86-mtrr-Fix-original-mtrr-range-get-for-mtrr_cleanup.patch
Patch25042: x86-range-make-add_range-use-blank-slot.patch
#rhbz 967230
Patch25043: vfio-Set-container-device-mode.patch
Patch25044: vfio-fix-crash-on-rmmod.patch
@ -795,9 +787,6 @@ Patch25047: drm-radeon-Disable-writeback-by-default-on-ppc.patch
#rhbz 956732
Patch25048: tulip-dma-debug-error.patch
#rhbz 967271
Patch25049: carl9170-fix-frame-drop-and-WARN-due-to-minstrel_ht-.patch
Patch25050: iwlwifi-pcie-fix-race-in-queue-unmapping.patch
Patch25051: iwlwifi-pcie-wake-the-queue-if-stopped-when-being-unmapped.patch
@ -1532,14 +1521,6 @@ ApplyPatch scsi-ipr-possible-irq-lock-inversion-dependency-detected.patch
#CVE-2013-2164 rhbz 973100 973109
ApplyPatch cdrom-use-kzalloc-for-failing-hardware.patch
#rhbz 954181
ApplyPatch vhost_net-clear-msg.control-for-non-zerocopy-case-during-tx.patch
ApplyPatch tuntap-set-SOCK_ZEROCOPY-flag-during-open.patch
#rhbz 973185
ApplyPatch x86-mtrr-Fix-original-mtrr-range-get-for-mtrr_cleanup.patch
ApplyPatch x86-range-make-add_range-use-blank-slot.patch
#rhbz 967230
ApplyPatch vfio-Set-container-device-mode.patch
ApplyPatch vfio-fix-crash-on-rmmod.patch
@ -1555,9 +1536,6 @@ ApplyPatch drm-radeon-Disable-writeback-by-default-on-ppc.patch
#rhbz 956732
ApplyPatch tulip-dma-debug-error.patch
#rhbz 967271
ApplyPatch carl9170-fix-frame-drop-and-WARN-due-to-minstrel_ht-.patch
ApplyPatch iwlwifi-pcie-fix-race-in-queue-unmapping.patch
ApplyPatch iwlwifi-pcie-wake-the-queue-if-stopped-when-being-unmapped.patch
@ -2387,6 +2365,9 @@ fi
# and build.
%changelog
* Thu Jun 27 2013 Josh Boyer <jwboyer@redhat.com>
- Linux v3.9.8
* Thu Jun 27 2013 Josh Boyer <jwboyer@redhat.com>
- Fix stack memory usage for DMA in ath3k (rhbz 977558)

2
sources
View File

@ -1,2 +1,2 @@
4348c9b6b2eb3144d601e87c19d5d909 linux-3.9.tar.xz
74005c469fbd309ab631d981e2d3a6e7 patch-3.9.7.xz
c5f2166686a913abf550bfed8b77df27 patch-3.9.8.xz

26
tuntap-set-SOCK_ZEROCOPY-flag-during-open.patch
View File

@ -1,26 +0,0 @@
tuntap: set SOCK_ZEROCOPY flag during open
Commit 54f968d6efdbf7dec36faa44fc11f01b0e4d1990
(tuntap: move socket to tun_file) forgets to set SOCK_ZEROCOPY flag, which will
prevent vhost_net from doing zercopy w/ tap. This patch fixes this by setting
it during file open.
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
---
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 89776c5..ff5312d 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2159,6 +2159,8 @@ static int tun_chr_open(struct inode *inode, struct file * file)
set_bit(SOCK_EXTERNALLY_ALLOCATED, &tfile->socket.flags);
INIT_LIST_HEAD(&tfile->next);
+ sock_set_flag(&tfile->sk, SOCK_ZEROCOPY);
+
return 0;
}

60
vhost_net-clear-msg.control-for-non-zerocopy-case-during-tx.patch
View File

@ -1,60 +0,0 @@
From 3add6ae9e1b854a9ddbe0dc17ff4ec48a2dac9fe Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 5 Jun 2013 07:40:46 +0000
Subject: [PATCH] vhost_net: clear msg.control for non-zerocopy case during tx
When we decide not use zero-copy, msg.control should be set to NULL otherwise
macvtap/tap may set zerocopy callbacks which may decrease the kref of ubufs
wrongly.
Bug were introduced by commit cedb9bdce099206290a2bdd02ce47a7b253b6a84
(vhost-net: skip head management if no outstanding).
This solves the following warnings:
WARNING: at include/linux/kref.h:47 handle_tx+0x477/0x4b0 [vhost_net]()
Modules linked in: vhost_net macvtap macvlan tun nfsd exportfs bridge stp llc openvswitch kvm_amd kvm bnx2 megaraid_sas [last unloaded: tun]
CPU: 5 PID: 8670 Comm: vhost-8668 Not tainted 3.10.0-rc2+ #1566
Hardware name: Dell Inc. PowerEdge R715/00XHKG, BIOS 1.5.2 04/19/2011
ffffffffa0198323 ffff88007c9ebd08 ffffffff81796b73 ffff88007c9ebd48
ffffffff8103d66b 000000007b773e20 ffff8800779f0000 ffff8800779f43f0
ffff8800779f8418 000000000000015c 0000000000000062 ffff88007c9ebd58
Call Trace:
[<ffffffff81796b73>] dump_stack+0x19/0x1e
[<ffffffff8103d66b>] warn_slowpath_common+0x6b/0xa0
[<ffffffff8103d6b5>] warn_slowpath_null+0x15/0x20
[<ffffffffa0197627>] handle_tx+0x477/0x4b0 [vhost_net]
[<ffffffffa0197690>] handle_tx_kick+0x10/0x20 [vhost_net]
[<ffffffffa019541e>] vhost_worker+0xfe/0x1a0 [vhost_net]
[<ffffffffa0195320>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net]
[<ffffffffa0195320>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net]
[<ffffffff81061f46>] kthread+0xc6/0xd0
[<ffffffff81061e80>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff817a1aec>] ret_from_fork+0x7c/0xb0
[<ffffffff81061e80>] ? kthread_freezable_should_stop+0x70/0x70
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/vhost/net.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index ec6fb3f..3980e66 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -353,7 +353,9 @@ static void handle_tx(struct vhost_net *net)
kref_get(&ubufs->kref);
}
vq->upend_idx = (vq->upend_idx + 1) % UIO_MAXIOV;
- }
+ } else
+ msg.msg_control = NULL;
+
/* TODO: Check specific error and bomb out unless ENOBUFS? */
err = sock->ops->sendmsg(NULL, sock, &msg, len);
if (unlikely(err < 0)) {
--
1.8.1.4

63
x86-mtrr-Fix-original-mtrr-range-get-for-mtrr_cleanup.patch
View File

@ -1,63 +0,0 @@
Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
during add range) broke mtrr cleanup on his setup in 3.9.5.
corresponding commit in upstream is fbe06b7bae7c.
*BAD*gran_size: 64K chunk_size: 16M num_reg: 6 lose cover RAM: -0G
https://bugzilla.kernel.org/show_bug.cgi?id=59491
So it rejects new var mtrr layout.
It turns out we have some problem with initial mtrr range retrievel.
current sequence is:
x86_get_mtrr_mem_range
==> bunchs of add_range_with_merge
==> bunchs of subract_range
==> clean_sort_range
add_range_with_merge for [0,1M)
sort_range()
add_range_with_merge could have blank slots, so we can not just
sort only, that will have final result have extra blank slot in head.
So move that calling add_range_with_merge for [0,1M), with that we
could avoid extra clean_sort_range calling.
Reported-by: Joshua Covington <joshuacov@googlemail.com>
Tested-by: Joshua Covington <joshuacov@googlemail.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: <stable@vger.kernel.org> v3.9
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpu/mtrr/cleanup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -714,15 +714,15 @@ int __init mtrr_cleanup(unsigned address
if (mtrr_tom2)
x_remove_size = (mtrr_tom2 >> PAGE_SHIFT) - x_remove_base;
- nr_range = x86_get_mtrr_mem_range(range, 0, x_remove_base, x_remove_size);
/*
* [0, 1M) should always be covered by var mtrr with WB
* and fixed mtrrs should take effect before var mtrr for it:
*/
- nr_range = add_range_with_merge(range, RANGE_NUM, nr_range, 0,
+ nr_range = add_range_with_merge(range, RANGE_NUM, 0, 0,
1ULL<<(20 - PAGE_SHIFT));
- /* Sort the ranges: */
- sort_range(range, nr_range);
+ /* add from var mtrr at last */
+ nr_range = x86_get_mtrr_mem_range(range, nr_range,
+ x_remove_base, x_remove_size);
range_sums = sum_ranges(range, nr_range);
printk(KERN_INFO "total RAM covered: %ldM\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

73
x86-range-make-add_range-use-blank-slot.patch
View File

@ -1,73 +0,0 @@
Now add_range_with_merge will generate blank slot as subtract_range.
we could reach the array limit because of blank slots.
We can let add_range to have second try to use blank slot.
Also use WARN_ONCE to print trace.
Reported-by: Joshua Covington <joshuacov@googlemail.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: <stable@vger.kernel.org> v3.9
---
kernel/range.c | 34 ++++++++++++++++++++++------------
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/kernel/range.c b/kernel/range.c
index 98883ed..8ca718a 100644
--- a/kernel/range.c
+++ b/kernel/range.c
@@ -3,23 +3,34 @@
*/
#include <linux/kernel.h>
#include <linux/init.h>
+#include <linux/bug.h>
#include <linux/sort.h>
-
#include <linux/range.h>
int add_range(struct range *range, int az, int nr_range, u64 start, u64 end)
{
- if (start >= end)
- return nr_range;
+ int i;
- /* Out of slots: */
- if (nr_range >= az)
+ if (start >= end)
return nr_range;
- range[nr_range].start = start;
- range[nr_range].end = end;
+ /* Out of slots ? */
+ if (nr_range < az) {
+ i = nr_range;
+ nr_range++;
+ } else {
+ /* find blank slot */
+ for (i = 0; i < az; i++)
+ if (!range[i].end)
+ break;
+ if (i == az) {
+ WARN_ONCE(1, "run out of slot in ranges\n");
+ return az;
+ }
+ }
- nr_range++;
+ range[i].start = start;
+ range[i].end = end;
return nr_range;
}
@@ -99,7 +110,7 @@ void subtract_range(struct range *range, int az, u64 start, u64 end)
range[i].end = range[j].end;
range[i].start = end;
} else {
- printk(KERN_ERR "run of slot in ranges\n");
+ WARN_ONCE(1,"run of slot in ranges\n");
}
range[j].end = start;
continue;
--
1.8.1.4