* Re: [PATCH] be2net: Fix a potential crash during shutdown.
From: David Miller @ 2011-04-06 19:40 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20110406155313.GA2246@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@emulex.com>
Date: Wed, 6 Apr 2011 10:53:13 -0500
> adapter could remain uninitialized if probe fails for some reason.
> A null pointer access could cause a crash if be_shutdown
> is called after that.
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Applied to net-2.6, thank you.
^ permalink raw reply
* [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets (v2)
From: Neil Horman @ 2011-04-06 19:37 UTC (permalink / raw)
To: netdev
Cc: Neil Horman, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Tom Herbert
In-Reply-To: <1302112465-6842-1-git-send-email-nhorman@tuxdriver.com>
properly record sk_rxhash in ipv6 sockets (v2)
Noticed while working on another project that flows to sockets which I had open
on a test systems weren't getting steered properly when I had RFS enabled.
Looking more closely I found that:
1) The affected sockets were all ipv6
2) They weren't getting steered because sk->sk_rxhash was never set from the
incomming skbs on that socket.
This was occuring because there are several points in the IPv4 tcp and udp code
which save the rxhash value when a new connection is established. Those calls
to sock_rps_save_rxhash were never added to the corresponding ipv6 code paths.
This patch adds those calls. Tested by myself to properly enable RFS
functionalty on ipv6.
Change notes:
v2:
Filtered UDP to only arm RFS on bound sockets (Eric Dumazet)
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
CC: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
CC: James Morris <jmorris@namei.org>
CC: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
CC: Patrick McHardy <kaber@trash.net>
CC: Tom Herbert <therbert@google.com>
---
net/ipv6/tcp_ipv6.c | 4 +++-
net/ipv6/udp.c | 3 +++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 2b0c186..97917bb 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1621,6 +1621,7 @@ static int tcp_v6_do_rcv(struct sock *sk, struct sk_buff *skb)
opt_skb = skb_clone(skb, GFP_ATOMIC);
if (sk->sk_state == TCP_ESTABLISHED) { /* Fast path */
+ sock_rps_save_rxhash(sk, skb->rxhash);
if (tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len))
goto reset;
if (opt_skb)
@@ -1648,7 +1649,8 @@ static int tcp_v6_do_rcv(struct sock *sk, struct sk_buff *skb)
__kfree_skb(opt_skb);
return 0;
}
- }
+ } else
+ sock_rps_save_rxhash(sk, skb->rxhash);
if (tcp_rcv_state_process(sk, skb, tcp_hdr(skb), skb->len))
goto reset;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index d7037c0..15c3774 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -505,6 +505,9 @@ int udpv6_queue_rcv_skb(struct sock * sk, struct sk_buff *skb)
int rc;
int is_udplite = IS_UDPLITE(sk);
+ if (!ipv6_addr_any(&inet6_sk(sk)->daddr))
+ sock_rps_save_rxhash(sk, skb->rxhash);
+
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto drop;
--
1.7.4
^ permalink raw reply related
* Re: [PATCH 0/9 net-next-2.6] qlcnic: Code cleanup and fixes
From: David Miller @ 2011-04-06 19:48 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, amit.salecha, ameen.rahman
In-Reply-To: <1301703950-4178-1-git-send-email-anirban.chakraborty@qlogic.com>
From: anirban.chakraborty@qlogic.com
Date: Fri, 1 Apr 2011 17:25:50 -0700
> Please apply. Thanks for bearing with me.
All applied to net-next-2.6, thank you.
^ permalink raw reply
* Re: [PATCH] skge: convert to hw_features
From: David Miller @ 2011-04-06 19:48 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, shemminger
In-Reply-To: <20110331110135.9625513A68@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Thu, 31 Mar 2011 13:01:35 +0200 (CEST)
>>From the code it looks like the hardware might support full HW_CSUM not
> just IP_CSUM. This needs testing and so is not changed here.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Stephen, did you get a chance to test this patch like you said you
would?
^ permalink raw reply
* Re: [PATCH 01/24] sysctl: net: call unregister_net_sysctl_table where needed
From: David Miller @ 2011-04-06 19:52 UTC (permalink / raw)
To: lucian.grijincu; +Cc: adobriyan, ebiederm, tavi, linux-kernel, netdev
In-Reply-To: <05ae3c2fdd2db1f6a2fd3cd900164667e615f4f8.1301711868.git.lucian.grijincu@gmail.com>
From: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Date: Sat, 2 Apr 2011 04:53:15 +0200
> ctl_table_headers registered with register_net_sysctl_table should
> have been unregistered with the equivalent unregister_net_sysctl_table
>
> Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Oops, hmmm... Can this actually cause any real problems currently?
If so I'd like to toss this specific patch into net-2.6
Thanks.
^ permalink raw reply
* Re: [PATCH 02/24] sysctl: cookie: add ctl_header_cookie
From: David Miller @ 2011-04-06 19:53 UTC (permalink / raw)
To: lucian.grijincu; +Cc: adobriyan, ebiederm, tavi, linux-kernel, netdev
In-Reply-To: <059405611ddd6d70415081e0261805935e95d345.1301711868.git.lucian.grijincu@gmail.com>
From: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Date: Sat, 2 Apr 2011 04:53:16 +0200
> @@ -205,6 +205,7 @@ static struct ctl_table_header root_table_header = {
> .ctl_entry = LIST_HEAD_INIT(sysctl_table_root.default_set.list),}},
> .root = &sysctl_table_root,
> .set = &sysctl_table_root.default_set,
> + .ctl_header_cookie = NULL,
> };
Such explicit setting of structure members to NULL in an assignment is
never necessary. Please remove these, there were a few cases in this
patch.
Thanks.
^ permalink raw reply
* Re: [PATCH 03/24] sysctl: cookie: pass ctl_header_cookie to proc_handler
From: David Miller @ 2011-04-06 19:54 UTC (permalink / raw)
To: lucian.grijincu; +Cc: adobriyan, ebiederm, tavi, linux-kernel, netdev
In-Reply-To: <2c7dffeffbbb6cc768816a904a1dde2d969a1c4e.1301711868.git.lucian.grijincu@gmail.com>
From: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Date: Sat, 2 Apr 2011 04:53:17 +0200
> The bulk of this patch changes all proc_handlers in the kernel to
> receive the cookie.
>
> Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Since this stuff is pretty invasive outside of the networking I really
need to see two things:
1) Feedback from sysctl folks.
2) Some coordination with whoever maintains sysctl stuff so we can
decide how to stage these changes in various maintainer trees,
including mine.
^ permalink raw reply
* Re: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: David Miller @ 2011-04-06 19:56 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, bhutchings
In-Reply-To: <1301720283-25038-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Fri, 1 Apr 2011 21:58:03 -0700
> o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
> but it is tigtly coupled with RX flow hash configuration.
> o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
> soon.
> o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
> dropping the affinity control from it.
>
> Ben Hutching:
> o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
> queues so that most channels combine RX and TX work.
> o Please could you use a kernel-doc comment to describe the structure.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Ben, are you currently OK with this patch?
There was some back and forth, and I just want to make sure all of the
issues you raised were addressed to your satisfaction.
Thanks.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Arnaldo Carvalho de Melo @ 2011-04-06 19:57 UTC (permalink / raw)
To: David Miller
Cc: jesse.brandeburg, fedora-kernel-list, netdev, jesse.brandeburg
In-Reply-To: <20110406.121208.189703414.davem@davemloft.net>
Em Wed, Apr 06, 2011 at 12:12:08PM -0700, David Miller escreveu:
> From: Jesse Brandeburg <jesse.brandeburg@gmail.com>
> Date: Wed, 6 Apr 2011 11:51:06 -0700
> > perf showed netfilter being prominent, and removing it gives me much
> > higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
> > good thing to be able to disable netfilter if you want to?
>
> CONFIG_NETFILTER=y is the only possible non-disabled setting, as it's
> a boolean.
>
> All that is enabling is the hooks, and it's not possible to provide
> netfilter at all without the hooks being compiled into the kernel
> image.
>
> Fedora by default is also probably installing several defauly
> netfilter rules, make sure to remove them.
Was there ever any attempt to try to have netfilter built-in but not
causing the performance impact?
Something like ftrace code changing when the user inserts the first
rule?
People wanting top performance disable it in the build, but thos wanting
to stick to vendor provided kernels don't have that choice :)
- Arnaldo
^ permalink raw reply
* pull request: wireless-2.6 2011-04-06
From: John W. Linville @ 2011-04-06 20:00 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another batch of fixes intended for 2.6.39...
This includes a fix to avoid receiving duplicate frames in "cooked"
monitor mode, a mac80211 documentation fix to avoid developer
confusion, an rt2x00 fix to avoid cancelling some uninitialized work,
a wl12xx buffer overflow fix, an email address correction for wl12xx
module info, a zd1211rw regression fix, a zd1211rw WARNING fix,
and rtlwifi fix to avoid using some uninitialized variables, a fix
to broaden the iwl600 hardware supported by iwlagn to match what the
Windows driver is supporting, a b43 fix to allocate properly sized
receive buffers, and some stuff related to device IDs.
Please let me know if there are problems!
John
---
The following changes since commit 738faca34335cd1d5d87fa7c58703139c7fa15bd:
ipv6: Don't pass invalid dst_entry pointer to dst_release(). (2011-04-04 13:07:26 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Christian Lamparter (1):
p54usb: IDs for two new devices
Helmut Schaa (1):
mac80211: Fix duplicate frames on cooked monitor
Johannes Berg (1):
mac80211: fix comment regarding aggregation buf_size
John W. Linville (2):
b43: allocate receive buffers big enough for max frame len + offset
iwlwifi: accept EEPROM version 0x423 for iwl6000
Jussi Kivilinna (2):
zd1211rw: remove URB_SHORT_NOT_OK flag in zd_usb_iowrite16v_async()
zd1211rw: reset rx idle timer from tasklet
Larry Finger (1):
rtlwifi: Fix some warnings/bugs
Luciano Coelho (2):
wl12xx: fix module author's email address in the spi and sdio modules
wl12xx: fix potential buffer overflow in testmode nvs push
Senthil Balasubramanian (1):
ath9k: Fix phy info print message with AR9485 chipset.
Stanislaw Gruszka (1):
rt2x00: fix cancelling uninitialized work
drivers/net/wireless/ath/ath9k/hw.c | 1 +
drivers/net/wireless/b43/dma.c | 2 +-
drivers/net/wireless/b43/dma.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 2 +-
drivers/net/wireless/p54/p54usb.c | 2 ++
drivers/net/wireless/rt2x00/rt2x00dev.c | 6 ++++--
drivers/net/wireless/rtlwifi/efuse.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c | 2 +-
drivers/net/wireless/rtlwifi/usb.c | 2 +-
drivers/net/wireless/wl12xx/sdio.c | 2 +-
drivers/net/wireless/wl12xx/spi.c | 2 +-
drivers/net/wireless/wl12xx/testmode.c | 5 ++++-
drivers/net/wireless/zd1211rw/zd_usb.c | 20 ++++++++++++++++++--
drivers/net/wireless/zd1211rw/zd_usb.h | 1 +
include/net/mac80211.h | 15 +++++++++++++--
net/mac80211/rx.c | 2 +-
16 files changed, 52 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 338b075..1ec9bcd 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2546,6 +2546,7 @@ static struct {
{ AR_SREV_VERSION_9287, "9287" },
{ AR_SREV_VERSION_9271, "9271" },
{ AR_SREV_VERSION_9300, "9300" },
+ { AR_SREV_VERSION_9485, "9485" },
};
/* For devices with external radios */
diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index 3d5566e..ff0f5ba 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1536,7 +1536,7 @@ static void dma_rx(struct b43_dmaring *ring, int *slot)
dmaaddr = meta->dmaaddr;
goto drop_recycle_buffer;
}
- if (unlikely(len > ring->rx_buffersize)) {
+ if (unlikely(len + ring->frameoffset > ring->rx_buffersize)) {
/* The data did not fit into one descriptor buffer
* and is split over multiple buffers.
* This should never happen, as we try to allocate buffers
diff --git a/drivers/net/wireless/b43/dma.h b/drivers/net/wireless/b43/dma.h
index a01c210..e8a80a1 100644
--- a/drivers/net/wireless/b43/dma.h
+++ b/drivers/net/wireless/b43/dma.h
@@ -163,7 +163,7 @@ struct b43_dmadesc_generic {
/* DMA engine tuning knobs */
#define B43_TXRING_SLOTS 256
#define B43_RXRING_SLOTS 64
-#define B43_DMA0_RX_BUFFERSIZE IEEE80211_MAX_FRAME_LEN
+#define B43_DMA0_RX_BUFFERSIZE (B43_DMA0_RX_FRAMEOFFSET + IEEE80211_MAX_FRAME_LEN)
/* Pointer poison */
#define B43_DMA_PTR_POISON ((void *)ERR_PTR(-ENOMEM))
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index 98aa8af..20b6646 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -241,7 +241,7 @@ struct iwl_eeprom_enhanced_txpwr {
/* 6x00 Specific */
#define EEPROM_6000_TX_POWER_VERSION (4)
-#define EEPROM_6000_EEPROM_VERSION (0x434)
+#define EEPROM_6000_EEPROM_VERSION (0x423)
/* 6x50 Specific */
#define EEPROM_6050_TX_POWER_VERSION (4)
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index 9b344a9..e183587 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -56,6 +56,7 @@ static struct usb_device_id p54u_table[] __devinitdata = {
{USB_DEVICE(0x0846, 0x4210)}, /* Netgear WG121 the second ? */
{USB_DEVICE(0x0846, 0x4220)}, /* Netgear WG111 */
{USB_DEVICE(0x09aa, 0x1000)}, /* Spinnaker Proto board */
+ {USB_DEVICE(0x0bf8, 0x1007)}, /* Fujitsu E-5400 USB */
{USB_DEVICE(0x0cde, 0x0006)}, /* Medion 40900, Roper Europe */
{USB_DEVICE(0x0db0, 0x6826)}, /* MSI UB54G (MS-6826) */
{USB_DEVICE(0x107b, 0x55f2)}, /* Gateway WGU-210 (Gemtek) */
@@ -68,6 +69,7 @@ static struct usb_device_id p54u_table[] __devinitdata = {
{USB_DEVICE(0x1915, 0x2235)}, /* Linksys WUSB54G Portable OEM */
{USB_DEVICE(0x2001, 0x3701)}, /* DLink DWL-G120 Spinnaker */
{USB_DEVICE(0x2001, 0x3703)}, /* DLink DWL-G122 */
+ {USB_DEVICE(0x2001, 0x3762)}, /* Conceptronic C54U */
{USB_DEVICE(0x5041, 0x2234)}, /* Linksys WUSB54G */
{USB_DEVICE(0x5041, 0x2235)}, /* Linksys WUSB54G Portable */
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 9de9dbe..84eb6ad 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -1062,8 +1062,10 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
* Stop all work.
*/
cancel_work_sync(&rt2x00dev->intf_work);
- cancel_work_sync(&rt2x00dev->rxdone_work);
- cancel_work_sync(&rt2x00dev->txdone_work);
+ if (rt2x00_is_usb(rt2x00dev)) {
+ cancel_work_sync(&rt2x00dev->rxdone_work);
+ cancel_work_sync(&rt2x00dev->txdone_work);
+ }
destroy_workqueue(rt2x00dev->workqueue);
/*
diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
index f74a870..590f14f 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -685,7 +685,7 @@ static int efuse_pg_packet_read(struct ieee80211_hw *hw, u8 offset, u8 *data)
u8 efuse_data, word_cnts = 0;
u16 efuse_addr = 0;
- u8 hworden;
+ u8 hworden = 0;
u8 tmpdata[8];
if (data == NULL)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c b/drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c
index 5ef9137..28a6ce3 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c
@@ -303,7 +303,7 @@ static void _rtl92c_fill_h2c_command(struct ieee80211_hw *hw,
u16 box_reg, box_extreg;
u8 u1b_tmp;
bool isfw_read = false;
- u8 buf_index;
+ u8 buf_index = 0;
bool bwrite_sucess = false;
u8 wait_h2c_limmit = 100;
u8 wait_writeh2c_limmit = 100;
diff --git a/drivers/net/wireless/rtlwifi/usb.c b/drivers/net/wireless/rtlwifi/usb.c
index a4b2613..f5d8573 100644
--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -246,7 +246,7 @@ static void _rtl_usb_io_handler_init(struct device *dev,
static void _rtl_usb_io_handler_release(struct ieee80211_hw *hw)
{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
+ struct rtl_priv __maybe_unused *rtlpriv = rtl_priv(hw);
mutex_destroy(&rtlpriv->io.bb_mutex);
}
diff --git a/drivers/net/wireless/wl12xx/sdio.c b/drivers/net/wireless/wl12xx/sdio.c
index 5b9dbea..b1c7d03 100644
--- a/drivers/net/wireless/wl12xx/sdio.c
+++ b/drivers/net/wireless/wl12xx/sdio.c
@@ -340,7 +340,7 @@ module_init(wl1271_init);
module_exit(wl1271_exit);
MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com>");
+MODULE_AUTHOR("Luciano Coelho <coelho@ti.com>");
MODULE_AUTHOR("Juuso Oikarinen <juuso.oikarinen@nokia.com>");
MODULE_FIRMWARE(WL1271_FW_NAME);
MODULE_FIRMWARE(WL1271_AP_FW_NAME);
diff --git a/drivers/net/wireless/wl12xx/spi.c b/drivers/net/wireless/wl12xx/spi.c
index 18cf017..ffc745b 100644
--- a/drivers/net/wireless/wl12xx/spi.c
+++ b/drivers/net/wireless/wl12xx/spi.c
@@ -487,7 +487,7 @@ module_init(wl1271_init);
module_exit(wl1271_exit);
MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com>");
+MODULE_AUTHOR("Luciano Coelho <coelho@ti.com>");
MODULE_AUTHOR("Juuso Oikarinen <juuso.oikarinen@nokia.com>");
MODULE_FIRMWARE(WL1271_FW_NAME);
MODULE_FIRMWARE(WL1271_AP_FW_NAME);
diff --git a/drivers/net/wireless/wl12xx/testmode.c b/drivers/net/wireless/wl12xx/testmode.c
index e64403b..6ec06a4 100644
--- a/drivers/net/wireless/wl12xx/testmode.c
+++ b/drivers/net/wireless/wl12xx/testmode.c
@@ -204,7 +204,10 @@ static int wl1271_tm_cmd_nvs_push(struct wl1271 *wl, struct nlattr *tb[])
kfree(wl->nvs);
- wl->nvs = kzalloc(sizeof(struct wl1271_nvs_file), GFP_KERNEL);
+ if (len != sizeof(struct wl1271_nvs_file))
+ return -EINVAL;
+
+ wl->nvs = kzalloc(len, GFP_KERNEL);
if (!wl->nvs) {
wl1271_error("could not allocate memory for the nvs file");
ret = -ENOMEM;
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index 58236e6..ab607bb 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -643,7 +643,7 @@ static void rx_urb_complete(struct urb *urb)
usb = urb->context;
rx = &usb->rx;
- zd_usb_reset_rx_idle_timer(usb);
+ tasklet_schedule(&rx->reset_timer_tasklet);
if (length%rx->usb_packet_size > rx->usb_packet_size-4) {
/* If there is an old first fragment, we don't care. */
@@ -812,6 +812,7 @@ void zd_usb_disable_rx(struct zd_usb *usb)
__zd_usb_disable_rx(usb);
mutex_unlock(&rx->setup_mutex);
+ tasklet_kill(&rx->reset_timer_tasklet);
cancel_delayed_work_sync(&rx->idle_work);
}
@@ -1106,6 +1107,13 @@ static void zd_rx_idle_timer_handler(struct work_struct *work)
zd_usb_reset_rx(usb);
}
+static void zd_usb_reset_rx_idle_timer_tasklet(unsigned long param)
+{
+ struct zd_usb *usb = (struct zd_usb *)param;
+
+ zd_usb_reset_rx_idle_timer(usb);
+}
+
void zd_usb_reset_rx_idle_timer(struct zd_usb *usb)
{
struct zd_usb_rx *rx = &usb->rx;
@@ -1127,6 +1135,7 @@ static inline void init_usb_interrupt(struct zd_usb *usb)
static inline void init_usb_rx(struct zd_usb *usb)
{
struct zd_usb_rx *rx = &usb->rx;
+
spin_lock_init(&rx->lock);
mutex_init(&rx->setup_mutex);
if (interface_to_usbdev(usb->intf)->speed == USB_SPEED_HIGH) {
@@ -1136,11 +1145,14 @@ static inline void init_usb_rx(struct zd_usb *usb)
}
ZD_ASSERT(rx->fragment_length == 0);
INIT_DELAYED_WORK(&rx->idle_work, zd_rx_idle_timer_handler);
+ rx->reset_timer_tasklet.func = zd_usb_reset_rx_idle_timer_tasklet;
+ rx->reset_timer_tasklet.data = (unsigned long)usb;
}
static inline void init_usb_tx(struct zd_usb *usb)
{
struct zd_usb_tx *tx = &usb->tx;
+
spin_lock_init(&tx->lock);
atomic_set(&tx->enabled, 0);
tx->stopped = 0;
@@ -1671,6 +1683,10 @@ static void iowrite16v_urb_complete(struct urb *urb)
if (urb->status && !usb->cmd_error)
usb->cmd_error = urb->status;
+
+ if (!usb->cmd_error &&
+ urb->actual_length != urb->transfer_buffer_length)
+ usb->cmd_error = -EIO;
}
static int zd_submit_waiting_urb(struct zd_usb *usb, bool last)
@@ -1805,7 +1821,7 @@ int zd_usb_iowrite16v_async(struct zd_usb *usb, const struct zd_ioreq16 *ioreqs,
usb_fill_int_urb(urb, udev, usb_sndintpipe(udev, EP_REGS_OUT),
req, req_len, iowrite16v_urb_complete, usb,
ep->desc.bInterval);
- urb->transfer_flags |= URB_FREE_BUFFER | URB_SHORT_NOT_OK;
+ urb->transfer_flags |= URB_FREE_BUFFER;
/* Submit previous URB */
r = zd_submit_waiting_urb(usb, false);
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.h b/drivers/net/wireless/zd1211rw/zd_usb.h
index b3df2c8..325d0f9 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.h
+++ b/drivers/net/wireless/zd1211rw/zd_usb.h
@@ -183,6 +183,7 @@ struct zd_usb_rx {
spinlock_t lock;
struct mutex setup_mutex;
struct delayed_work idle_work;
+ struct tasklet_struct reset_timer_tasklet;
u8 fragment[2 * USB_MAX_RX_SIZE];
unsigned int fragment_length;
unsigned int usb_packet_size;
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cefe1b3..965f1b1 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1753,8 +1753,19 @@ enum ieee80211_ampdu_mlme_action {
* that TX/RX_STOP can pass NULL for this parameter.
* The @buf_size parameter is only valid when the action is set to
* %IEEE80211_AMPDU_TX_OPERATIONAL and indicates the peer's reorder
- * buffer size (number of subframes) for this session -- aggregates
- * containing more subframes than this may not be transmitted to the peer.
+ * buffer size (number of subframes) for this session -- the driver
+ * may neither send aggregates containing more subframes than this
+ * nor send aggregates in a way that lost frames would exceed the
+ * buffer size. If just limiting the aggregate size, this would be
+ * possible with a buf_size of 8:
+ * - TX: 1.....7
+ * - RX: 2....7 (lost frame #1)
+ * - TX: 8..1...
+ * which is invalid since #1 was now re-transmitted well past the
+ * buffer size of 8. Correct ways to retransmit #1 would be:
+ * - TX: 1 or 18 or 81
+ * Even "189" would be wrong since 1 could be lost again.
+ *
* Returns a negative error code on failure.
* The callback can sleep.
*
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index aa5cc37..2afeac9 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2541,7 +2541,6 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx)
* same TID from the same station
*/
rx->skb = skb;
- rx->flags = 0;
CALL_RXH(ieee80211_rx_h_decrypt)
CALL_RXH(ieee80211_rx_h_check_more_data)
@@ -2612,6 +2611,7 @@ void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid)
.sdata = sta->sdata,
.local = sta->local,
.queue = tid,
+ .flags = 0,
};
struct tid_ampdu_rx *tid_agg_rx;
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: fedora 14 kernel performance with ip forwarding workload
From: David Miller @ 2011-04-06 20:02 UTC (permalink / raw)
To: acme; +Cc: jesse.brandeburg, fedora-kernel-list, netdev, jesse.brandeburg
In-Reply-To: <20110406195719.GE14697@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Wed, 6 Apr 2011 16:57:19 -0300
> Something like ftrace code changing when the user inserts the first
> rule?
>
> People wanting top performance disable it in the build, but thos wanting
> to stick to vendor provided kernels don't have that choice :)
Using ftrace-like stubs would be an interesting idea, and I highly encourage
people to work on something like that.
However I want to reiterate that I think that real rules are installed
in Jesse's case, and once he removes those the majority of the
overhead will disappear. The FC14 workstation I'm using right now, on
which I've made no modifications to the installer's netfilter settings,
has the following rules:
--------------------
[root@ilbolle davem]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
ACCEPT udp -- anywhere 224.0.0.251 state NEW udp dpt:mdns
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ipp
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@ilbolle davem]#
--------------------
I suspect Jesse has something similar on his test box.
When no rules are loaded, all the stubs make happen is a function call
plus a list_empty() check. Nothing more. I really can't see that, all
by itself, obliterating routing performance.
In fact I've done udp flood tests, as recently as a month ago, with just
NETFILTER=y and no rules installed, and the impact was minimal.
And that was on sparc64 where function calls are expensive :)
^ permalink raw reply
* Re: [PATCH 01/24] sysctl: net: call unregister_net_sysctl_table where needed
From: Lucian Adrian Grijincu @ 2011-04-06 20:04 UTC (permalink / raw)
To: David Miller; +Cc: adobriyan, ebiederm, tavi, linux-kernel, netdev
In-Reply-To: <20110406.125256.102558618.davem@davemloft.net>
On Wed, Apr 6, 2011 at 9:52 PM, David Miller <davem@davemloft.net> wrote:
> Oops, hmmm... Can this actually cause any real problems currently?
>
> If so I'd like to toss this specific patch into net-2.6
Nope:
void unregister_net_sysctl_table(struct ctl_table_header *header)
{
unregister_sysctl_table(header);
}
EXPORT_SYMBOL_GPL(unregister_net_sysctl_table);
But I thought that in the future, if something special needs to be
done for unregister_net_sysctl_table, it would be better to have these
consistent. I'll do a check on all the tree to see if there are other
cases.
Another approach would be to remove unregister_net_sysctl_table, as it
does nothing different of unregister_sysctl_table and let our future
selves deal with the problem.
Can you tell me what you'd like?
--
.
..: Lucian
^ permalink raw reply
* Re: [PATCH 01/24] sysctl: net: call unregister_net_sysctl_table where needed
From: David Miller @ 2011-04-06 20:06 UTC (permalink / raw)
To: lucian.grijincu; +Cc: adobriyan, ebiederm, tavi, linux-kernel, netdev
In-Reply-To: <BANLkTik6PKYFyjnGLWoeRBrwF4sPZaaGWw@mail.gmail.com>
From: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Date: Wed, 6 Apr 2011 22:04:53 +0200
> On Wed, Apr 6, 2011 at 9:52 PM, David Miller <davem@davemloft.net> wrote:
>> Oops, hmmm... Can this actually cause any real problems currently?
>>
>> If so I'd like to toss this specific patch into net-2.6
>
>
> Nope:
>
> void unregister_net_sysctl_table(struct ctl_table_header *header)
> {
> unregister_sysctl_table(header);
> }
> EXPORT_SYMBOL_GPL(unregister_net_sysctl_table);
Ok, that's good.
> But I thought that in the future, if something special needs to be
> done for unregister_net_sysctl_table, it would be better to have these
> consistent. I'll do a check on all the tree to see if there are other
> cases.
>
> Another approach would be to remove unregister_net_sysctl_table, as it
> does nothing different of unregister_sysctl_table and let our future
> selves deal with the problem.
>
> Can you tell me what you'd like?
I think the thing to do is to keep this patch as it is, and only apply
it along with this cookie patch series, for -next.
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets (v2)
From: David Miller @ 2011-04-06 20:07 UTC (permalink / raw)
To: nhorman; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber, therbert
In-Reply-To: <1302118647-7931-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed, 6 Apr 2011 15:37:27 -0400
> properly record sk_rxhash in ipv6 sockets (v2)
>
> Noticed while working on another project that flows to sockets which I had open
> on a test systems weren't getting steered properly when I had RFS enabled.
> Looking more closely I found that:
>
> 1) The affected sockets were all ipv6
> 2) They weren't getting steered because sk->sk_rxhash was never set from the
> incomming skbs on that socket.
>
> This was occuring because there are several points in the IPv4 tcp and udp code
> which save the rxhash value when a new connection is established. Those calls
> to sock_rps_save_rxhash were never added to the corresponding ipv6 code paths.
> This patch adds those calls. Tested by myself to properly enable RFS
> functionalty on ipv6.
>
> Change notes:
> v2:
> Filtered UDP to only arm RFS on bound sockets (Eric Dumazet)
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Ok, I've decided to apply this to net-2.6
The current behavior even surprised me, I was pretty sure we had added
the hooks to both ipv4 and ipv6.
Thanks a lot Neil.
^ permalink raw reply
* Re: [Patch] isdn: remove deprecated ISDN_CAPI_CAPIFS
From: David Miller @ 2011-04-06 20:12 UTC (permalink / raw)
To: amwang; +Cc: netdev, isdn, jan.kiszka
In-Reply-To: <1302080739-4029-1-git-send-email-amwang@redhat.com>
From: Amerigo Wang <amwang@redhat.com>
Date: Wed, 6 Apr 2011 17:05:39 +0800
> Cc: Jan Kiszka <jan.kiszka@web.de>
> Cc: Karsten Keil <isdn@linux-pingi.de>
> Signed-off-by: WANG Cong <amwang@redhat.com>
capi.c still includes capifs.h, which you are deleting here.
How did you build test this?
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Arnaldo Carvalho de Melo @ 2011-04-06 20:13 UTC (permalink / raw)
To: David Miller
Cc: fedora-kernel-list-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA,
jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w,
jesse.brandeburg-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20110406.130239.232756965.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Em Wed, Apr 06, 2011 at 01:02:39PM -0700, David Miller escreveu:
> From: Arnaldo Carvalho de Melo <acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
> Date: Wed, 6 Apr 2011 16:57:19 -0300
>
> > Something like ftrace code changing when the user inserts the first
> > rule?
> >
> > People wanting top performance disable it in the build, but thos wanting
> > to stick to vendor provided kernels don't have that choice :)
>
> Using ftrace-like stubs would be an interesting idea, and I highly encourage
> people to work on something like that.
cool, these code modification and JIT mechanizms open up a lot of
possibilities indeed ;-)
> However I want to reiterate that I think that real rules are installed
> in Jesse's case, and once he removes those the majority of the
> overhead will disappear. The FC14 workstation I'm using right now, on
>
> which I've made no modifications to the installer's netfilter settings,
> has the following rules:
<SNIP>
> I suspect Jesse has something similar on his test box.
>
> When no rules are loaded, all the stubs make happen is a function call
> plus a list_empty() check. Nothing more. I really can't see that, all
> by itself, obliterating routing performance.
Yeah, would be nice, since he is playing with it, for him to post
numbers about the overheads.
> In fact I've done udp flood tests, as recently as a month ago, with just
> NETFILTER=y and no rules installed, and the impact was minimal.
>
> And that was on sparc64 where function calls are expensive :)
:-)
- Arnaldo
^ permalink raw reply
* Re: [PatchV2 : PL25A1 Support - 1/3] whitespace
From: David Miller @ 2011-04-06 20:17 UTC (permalink / raw)
To: simon; +Cc: gregkh, david-b, sshtylyov, linux-usb, netdev, linux-kernel
In-Reply-To: <1302063406-13077-1-git-send-email-simon@mungewell.org>
There are some problems with this patch series:
1) Please compose your subject lines more correctly. When I such these
patches into GIT, everything in the initial "[]" brackets is removed
and the commit header line for this patch (for example) ends up being
just "whitespace".
We want more than that.
Try something like:
Subject: [PATCH v2 1/3] usb: plusb: Whitespace.
Subject: [PATCH v2 2/3] usb: plusb: Add PL25A1 support.
Subject: [PATCH v2 3/3] usb: plusb: Add reset debugging.
2) Patch 2 doesn't apply cleanly to the current tree, you'll need to
refresh these patches.
Thanks.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Eric Dumazet @ 2011-04-06 20:18 UTC (permalink / raw)
To: David Miller
Cc: acme, jesse.brandeburg, fedora-kernel-list, netdev,
jesse.brandeburg
In-Reply-To: <20110406.130239.232756965.davem@davemloft.net>
Le mercredi 06 avril 2011 à 13:02 -0700, David Miller a écrit :
> From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> Date: Wed, 6 Apr 2011 16:57:19 -0300
>
> > Something like ftrace code changing when the user inserts the first
> > rule?
> >
> > People wanting top performance disable it in the build, but thos wanting
> > to stick to vendor provided kernels don't have that choice :)
>
> Using ftrace-like stubs would be an interesting idea, and I highly encourage
> people to work on something like that.
>
> However I want to reiterate that I think that real rules are installed
> in Jesse's case, and once he removes those the majority of the
> overhead will disappear. The FC14 workstation I'm using right now, on
> which I've made no modifications to the installer's netfilter settings,
> has the following rules:
>
> --------------------
> [root@ilbolle davem]# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
> ACCEPT icmp -- anywhere anywhere
> ACCEPT all -- anywhere anywhere
> ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
> ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
> ACCEPT udp -- anywhere 224.0.0.251 state NEW udp dpt:mdns
> ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ipp
> ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
> REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
> REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> [root@ilbolle davem]#
> --------------------
>
> I suspect Jesse has something similar on his test box.
>
I suspect problem is worse than that.
I remember last time I work on a fedora kernel, it had conntrack enabled
And yes, conntrack can really slowdown a router, because of default
parameters.
cat /proc/sys/net/nf_conntrack_max
^ permalink raw reply
* Re: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: Ben Hutchings @ 2011-04-06 20:20 UTC (permalink / raw)
To: David Miller; +Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <20110406.125637.70201394.davem@davemloft.net>
On Wed, 2011-04-06 at 12:56 -0700, David Miller wrote:
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Date: Fri, 1 Apr 2011 21:58:03 -0700
>
> > o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
> > but it is tigtly coupled with RX flow hash configuration.
> > o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
> > soon.
> > o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
> > dropping the affinity control from it.
> >
> > Ben Hutching:
> > o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
> > queues so that most channels combine RX and TX work.
> > o Please could you use a kernel-doc comment to describe the structure.
> >
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> Ben, are you currently OK with this patch?
>
> There was some back and forth, and I just want to make sure all of the
> issues you raised were addressed to your satisfaction.
I'm afraid not.
On Fri, 2011-04-01 at 21:58 -0700, Amit Kumar Salecha wrote:
o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
> but it is tigtly coupled with RX flow hash configuration.
> o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
> soon.
> o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
> dropping the affinity control from it.
>
> Ben Hutching:
> o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
> queues so that most channels combine RX and TX work.
> o Please could you use a kernel-doc comment to describe the structure.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Amit, I told you already that you must not use my Signed-off-by line
since you are changing the patch significantly.
> ---
> include/linux/ethtool.h | 41 +++++++++++++++++++++++++++++++++++++++++
> net/core/ethtool.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 82 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index c8fcbdd..3c4d968 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -229,6 +229,42 @@ struct ethtool_ringparam {
> __u32 tx_pending;
> };
>
> +/**
> + * struct ethtool_channels - configuring number of network channel
> + * @cmd: ETHTOOL_{G,S}CHANNELS
> + * @type: Channel type defined in ethtool_channel_type
> + * @max_XX: Read only. Maximum number of channel the driver support
> + * @XX_count: Valid values are in the range 1 to the "max_XX" counterpart above.
The kernel-doc tools are going to complain about these field names with
'XX' in them. You'll have to describe each field individually.
> + * This can be used to configure RX,TX and other channels.
> + */
> +
> +struct ethtool_channels {
> + __u32 cmd;
> + __u32 type;
> + __u32 max_rx;
> + __u32 max_tx;
> + __u32 max_other;
> + __u32 rx_count;
> + __u32 tx_count;
> + __u32 other_count;
> +};
> +
> +/* Channel type */
> +/* Channel type should be pass in type field of ethtool_channels.
> + * TYPE_ALL indicates set all channels to XX_count values.
> + * TYPE_RX and TYPE_TX is to get and set RX and TX channels correspondingly.
> + * TYPE_COMBINED is to set both RX and TX channels to rx_count and tx_count
> + * correspondingly.
That's not what I meant by 'combined'. I meant a set of RX queues and
TX queues (usually 1 of each) with an IRQ and maybe an event queue
shared between them. It should be possible for ethtool to distinguish
combined channels, so it doesn't just report 'Invalid argument' if the
user tries to set rx_count != tx_count.
I think this requires that there are max_combined and combined_count (or
similar) fields in struct ethtool_channels, so a driver that only
supports combined channels can report max_rx = 0, max_tx = 0,
max_combined = N.
> TYPE_OTHER is to configure other channel.
> + */
> +enum ethtool_channel_type {
> + ETH_CHAN_TYPE_ALL = 0,
> + ETH_CHAN_TYPE_RX,
> + ETH_CHAN_TYPE_TX,
> + ETH_CHAN_TYPE_COMBINED,
> + ETH_CHAN_TYPE_OTHER,
> +};
[...]
Really I'm not sure whether there's a need to be able to specify which
channel counts are being changed. ethtool or whatever utility is used
can do ETHTOOL_GCHANNELS, modify channel counts, ETHTOOL_SCHANNELS and
all the counts the user didn't want to change will be unchanged. If you
still think it is useful then use flags for the different channel types
so there is no arbitrary restriction on which counts can be changed at
the same time.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."
From: David Miller @ 2011-04-06 20:28 UTC (permalink / raw)
To: hirofumi; +Cc: netdev
In-Reply-To: <87oc4kj1bt.fsf@devron.myhome.or.jp>
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date: Tue, 05 Apr 2011 22:05:10 +0900
> ipv4: Set rt->rt_iif more sanely on output routes.
> (1018b5c01636c7c6bda31a719bda34fc631db29a)
>
> The above patch seems to be caused of avahi breakage.
>
> I'm not debugging fully though, avahi is using IP_PKTINFO and checking
> in_pktinfo->ipi_ifindex > 0.
>
> And if I reverted above patch, it seems to fix avahi's IP_PKTINFO problem.
in_pktinfo is given to the application only during recvmsg() calls, the
call chain is (for example):
udp_recvmsg()
--> ip_cmsg_recv()
--> ip_cmsg_recv_pktinfo()
Therefore we will only be working with receive packets, whose routes are
computed using ip_route_input*() which will fill in the rt_iif field
appropriately.
The only exception to this would be packets which are looped back, in
which case the cached output route attached to the packet will be used.
Your RFC patch should work, but we're trying to make "struct rtable"
smaller rather than larger.
In what way does routing break if you simply restore the original
rt_iif assignment in output route creation? That's the most preferred
fix for this.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: David Miller @ 2011-04-06 20:29 UTC (permalink / raw)
To: eric.dumazet
Cc: acme, jesse.brandeburg, fedora-kernel-list, netdev,
jesse.brandeburg
In-Reply-To: <1302121136.2701.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Apr 2011 22:18:56 +0200
> I remember last time I work on a fedora kernel, it had conntrack enabled
>
> And yes, conntrack can really slowdown a router, because of default
> parameters.
Yes, if conntrack is enabled performance will indeed tank.
^ permalink raw reply
* Kernel crash in 2.6.39-rc2-wl
From: Ben Greear @ 2011-04-06 20:30 UTC (permalink / raw)
To: netdev
This is from today's wireless-testing kernel, with a few non-tainting
patches related to wireless stuff. In general, 39-rc2 seems pretty
flaky, but on this boot, this is the first kernel splat.
I had reloaded our user-space network-config DB, which would have deleted
and created some VETH and MAC-VLAN interfaces, and a bunch of
protocol sockets, virtual-routers (xorp with unique routing tables) etc.
BUG: unable to handle kernel paging request at 50435453
IP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sda/sda1/stat
Modules linked in: xt_CT iptable_raw xt_DSCP xt_dscp xt_string xt_owner xt_NFQUEUE xt_multiport xt_mark xt_iprange xt_hashlimit xt_connmark xt_addrty]
Pid: 12747, comm: xorp_rtrmgr Not tainted 2.6.39-rc2-wl+ #56 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
EIP: 0060:[<c04d8ac6>] EFLAGS: 00210206 CPU: 0
EIP is at __kmalloc_track_caller+0xd8/0x117
EAX: c0b18ee0 EBX: f5402500 ECX: 0001d3c9 EDX: 00000000
ESI: 50435453 EDI: 0001d3c8 EBP: f17ddd00 ESP: f17ddce8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process xorp_rtrmgr (pid: 12747, ti=f17dc000 task=f147bde0 task.ti=f17dc000)
Stack:
c07869c6 000000d0 000001fc f1284fc0 000000d0 f5487f80 f17ddd1c c07468b9
00000001 00000140 f15e0000 f15e0000 00000000 f17ddd34 c07869c6 ffffffff
f15e0000 00010000 f17ddd88 f17ddd98 c0787005 00004040 00000000 00000002
Call Trace:
[<c07869c6>] ? sk_stream_alloc_skb+0x2c/0xc4
[<c07468b9>] __alloc_skb+0x5d/0xf9
[<c07869c6>] sk_stream_alloc_skb+0x2c/0xc4
[<c0787005>] tcp_sendmsg+0x16d/0x714
[<c07a1776>] inet_sendmsg+0x55/0x5e
[<c073ef79>] __sock_sendmsg+0x56/0x5f
[<c073f608>] sock_sendmsg+0x98/0xac
[<c0461879>] ? mark_lock+0x1e/0x1de
[<c042b66d>] ? pick_next_highest_task_rt+0x148/0x148
[<c04e643e>] ? fget_light+0x30/0xa4
[<c073f686>] ? sockfd_lookup_light+0x1b/0x4b
[<c073fc0f>] sys_sendto+0xaf/0xcb
[<c045500b>] ? __run_hrtimer+0xbc/0x106
[<c04633b5>] ? lock_release_non_nested+0x86/0x1d8
[<c04c10a1>] ? might_fault+0x4c/0x86
[<c073fc48>] sys_send+0x1d/0x1f
[<c0740bb7>] sys_socketcall+0xe6/0x1aa
[<c07fa19c>] sysenter_do_call+0x12/0x38
[<c07f0000>] ? timer_cpu_notify+0x47/0x222
Code: d2 75 13 8b 4d e8 8b 55 ec 50 89 d8 e8 e9 f6 ff ff 5f 89 c6 eb 21 8b 03 64 8b 30 39 d6 75 d2 64 8b 48 04 39 f9 75 ca 8b 53 14 41 <8b> 14 16 64
EIP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117 SS:ESP 0068:f17ddce8
CR2: 0000000050435453
BUG: unable to handle kernel paging request
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: David Miller @ 2011-04-06 20:30 UTC (permalink / raw)
To: bhutchings; +Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1302121247.2840.50.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 06 Apr 2011 21:20:47 +0100
> Amit, I told you already that you must not use my Signed-off-by line
> since you are changing the patch significantly.
Amit, this is a very serious infraction.
You must not ever add someone else's signed-off-by when you make
changes to a patch, unless you have their very clear and explicit
permission to do so.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Eric Dumazet @ 2011-04-06 20:32 UTC (permalink / raw)
To: David Miller
Cc: acme, jesse.brandeburg, fedora-kernel-list, netdev,
jesse.brandeburg
In-Reply-To: <20110406.132906.200378990.davem@davemloft.net>
Le mercredi 06 avril 2011 à 13:29 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 06 Apr 2011 22:18:56 +0200
>
> > I remember last time I work on a fedora kernel, it had conntrack enabled
> >
> > And yes, conntrack can really slowdown a router, because of default
> > parameters.
>
> Yes, if conntrack is enabled performance will indeed tank.
I just check on latest fedora14 (yum updated) :
- conntrack is statically included in kernel, you cannot remove it.
Hmm...
^ permalink raw reply
* Re: [PATCH] dsa/mv88e6131: add support for mv88e6085 switch
From: David Miller @ 2011-04-06 20:33 UTC (permalink / raw)
To: buytenh; +Cc: jacmet, netdev
In-Reply-To: <20110405133944.GG22881@wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Tue, 5 Apr 2011 15:39:44 +0200
> On Tue, Apr 05, 2011 at 03:03:56PM +0200, Peter Korsgaard wrote:
>
>> The mv88e6085 is identical to the mv88e6095, except that all ports are
>> 10/100 Mb/s, so use the existing setup code except for the cpu/dsa speed
>> selection in _setup_port().
>>
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>
> I don't have access to DSA chip docs anymore, but assuming that you've
> tested this:
>
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox