* pull request: wireless-2.6 2009-11-11
From: John W. Linville @ 2009-11-11 17:22 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another batch of small fixes intended for 2.6.32. Along with a
number of simple fixes, there is also a MAINTAINERS update, some LED
handling quirks for ath5k, a libertas beautification that is a prereq
for a libertas fix, and an iwlwifi fix that was already sent for
net-next-2.6 but which is needed to support an iwlwifi regression fix.
My personal favorite is the ath5k mcast filtering fix. The problem
only revealed itself when using IP autoconf w/ multicast DNS... :-)
Please let me know if there are problems!
Thanks,
John
P.S. Due to the aformentioned iwlwifi fix, this will cause -next
conflicts for sfr. You may want to pull net-2.6 into net-next-2.6 after
pulling this. The iwlwifi conflicts can be resolved by taking the bigger
hunks...
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 2606289779cb297320a185db5997729d29b6700b:
Sebastian Siewior (1):
net/fsl_pq_mdio: add module license GPL
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Bing Zhao (2):
Libertas: coding style cleanup in ethtool.c
Libertas: fix issues while configuring host sleep using ethtool wol
Bob Copeland (3):
ath5k: don't reset mcast filter when configuring the mode
ath5k: add LED support for HP Compaq CQ60
ath5k: add LED definition for BenQ Joybook R55v
Felix Fietkau (1):
b43: work around a locking issue in ->set_tim()
Ivo van Doorn (1):
rt2x00: update MAINTAINERS
Larry Finger (1):
rtl8187: Fix sparse warnings
Martin Fuzzey (1):
ssb-pcmcia: Fix 32bit register access in early bus scanning
Wey-Yi Guy (2):
iwlwifi: Use RTS/CTS as the preferred protection mechanism for 6000 series
iwlwifi: Fix issue on file transfer stalled in HT mode
MAINTAINERS | 1 +
drivers/net/wireless/ath/ath5k/base.c | 1 -
drivers/net/wireless/ath/ath5k/led.c | 4 ++++
drivers/net/wireless/b43/main.c | 3 +--
drivers/net/wireless/iwlwifi/iwl-1000.c | 1 +
drivers/net/wireless/iwlwifi/iwl-6000.c | 5 +++++
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 9 +++++++++
drivers/net/wireless/iwlwifi/iwl-agn.c | 10 +++++++---
drivers/net/wireless/iwlwifi/iwl-core.h | 2 ++
drivers/net/wireless/libertas/ethtool.c | 17 ++++++++++-------
drivers/net/wireless/rtl818x/rtl8187_rfkill.c | 1 +
drivers/ssb/scan.c | 6 +++++-
12 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c856aee..b37e0cd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4280,6 +4280,7 @@ F: drivers/video/aty/aty128fb.c
RALINK RT2X00 WIRELESS LAN DRIVER
P: rt2x00 project
+M: Ivo van Doorn <IvDoorn@gmail.com>
L: linux-wireless@vger.kernel.org
L: users@rt2x00.serialmonkey.com (moderated for non-subscribers)
W: http://rt2x00.serialmonkey.com/
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9c6ab53..95a8e23 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1125,7 +1125,6 @@ ath5k_mode_setup(struct ath5k_softc *sc)
/* configure operational mode */
ath5k_hw_set_opmode(ah);
- ath5k_hw_set_mcast_filter(ah, 0, 0);
ATH5K_DBG(sc, ATH5K_DEBUG_MODE, "RX filter 0x%x\n", rfilt);
}
diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
index b767c3b..b548c8e 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -63,12 +63,16 @@ static const struct pci_device_id ath5k_led_devices[] = {
{ ATH_SDEVICE(PCI_VENDOR_ID_AMBIT, 0x0422), ATH_LED(1, 1) },
/* E-machines E510 (tuliom@gmail.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_AMBIT, 0x0428), ATH_LED(3, 0) },
+ /* BenQ Joybook R55v (nowymarluk@wp.pl) */
+ { ATH_SDEVICE(PCI_VENDOR_ID_QMI, 0x0100), ATH_LED(1, 0) },
/* Acer Extensa 5620z (nekoreeve@gmail.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_QMI, 0x0105), ATH_LED(3, 0) },
/* Fukato Datacask Jupiter 1014a (mrb74@gmx.at) */
{ ATH_SDEVICE(PCI_VENDOR_ID_AZWAVE, 0x1026), ATH_LED(3, 0) },
/* IBM ThinkPad AR5BXB6 (legovini@spiro.fisica.unipd.it) */
{ ATH_SDEVICE(PCI_VENDOR_ID_IBM, 0x058a), ATH_LED(1, 0) },
+ /* HP Compaq CQ60-206US (ddreggors@jumptv.com) */
+ { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137a), ATH_LED(3, 1) },
/* HP Compaq C700 (nitrousnrg@gmail.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
/* IBM-specific AR5212 (all others) */
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 86f3582..098dda1 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4521,9 +4521,8 @@ static int b43_op_beacon_set_tim(struct ieee80211_hw *hw,
{
struct b43_wl *wl = hw_to_b43_wl(hw);
- mutex_lock(&wl->mutex);
+ /* FIXME: add locking */
b43_update_templates(wl);
- mutex_unlock(&wl->mutex);
return 0;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c b/drivers/net/wireless/iwlwifi/iwl-1000.c
index 2716b91..950267a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -161,5 +161,6 @@ struct iwl_cfg iwl1000_bgn_cfg = {
.max_ll_items = OTP_MAX_LL_ITEMS_1000,
.shadow_ram_support = false,
.ht_greenfield_support = true,
+ .use_rts_for_ht = true, /* use rts/cts protection */
};
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index c295b8e..1473452 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -175,6 +175,7 @@ struct iwl_cfg iwl6000h_2agn_cfg = {
.max_ll_items = OTP_MAX_LL_ITEMS_6x00,
.shadow_ram_support = true,
.ht_greenfield_support = true,
+ .use_rts_for_ht = true, /* use rts/cts protection */
};
/*
@@ -198,6 +199,7 @@ struct iwl_cfg iwl6000i_2agn_cfg = {
.max_ll_items = OTP_MAX_LL_ITEMS_6x00,
.shadow_ram_support = true,
.ht_greenfield_support = true,
+ .use_rts_for_ht = true, /* use rts/cts protection */
};
struct iwl_cfg iwl6050_2agn_cfg = {
@@ -218,6 +220,7 @@ struct iwl_cfg iwl6050_2agn_cfg = {
.max_ll_items = OTP_MAX_LL_ITEMS_6x00,
.shadow_ram_support = true,
.ht_greenfield_support = true,
+ .use_rts_for_ht = true, /* use rts/cts protection */
};
struct iwl_cfg iwl6000_3agn_cfg = {
@@ -238,6 +241,7 @@ struct iwl_cfg iwl6000_3agn_cfg = {
.max_ll_items = OTP_MAX_LL_ITEMS_6x00,
.shadow_ram_support = true,
.ht_greenfield_support = true,
+ .use_rts_for_ht = true, /* use rts/cts protection */
};
struct iwl_cfg iwl6050_3agn_cfg = {
@@ -258,6 +262,7 @@ struct iwl_cfg iwl6050_3agn_cfg = {
.max_ll_items = OTP_MAX_LL_ITEMS_6x00,
.shadow_ram_support = true,
.ht_greenfield_support = true,
+ .use_rts_for_ht = true, /* use rts/cts protection */
};
MODULE_FIRMWARE(IWL6000_MODULE_FIRMWARE(IWL6000_UCODE_API_MAX));
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 346dc06..81726ee 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -418,6 +418,15 @@ static void rs_tl_turn_on_agg(struct iwl_priv *priv, u8 tid,
else if (tid == IWL_AGG_ALL_TID)
for (tid = 0; tid < TID_MAX_LOAD_COUNT; tid++)
rs_tl_turn_on_agg_for_tid(priv, lq_data, tid, sta);
+ if (priv->cfg->use_rts_for_ht) {
+ /*
+ * switch to RTS/CTS if it is the prefer protection method
+ * for HT traffic
+ */
+ IWL_DEBUG_HT(priv, "use RTS/CTS protection for HT\n");
+ priv->staging_rxon.flags &= ~RXON_FLG_SELF_CTS_EN;
+ iwlcore_commit_rxon(priv);
+ }
}
static inline int get_num_of_ant_from_rate(u32 rate_n_flags)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 9b5ea8b..877af44 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -115,9 +115,6 @@ int iwl_commit_rxon(struct iwl_priv *priv)
/* always get timestamp with Rx frame */
priv->staging_rxon.flags |= RXON_FLG_TSF2HOST_MSK;
- /* allow CTS-to-self if possible. this is relevant only for
- * 5000, but will not damage 4965 */
- priv->staging_rxon.flags |= RXON_FLG_SELF_CTS_EN;
ret = iwl_check_rxon_cmd(priv);
if (ret) {
@@ -217,6 +214,13 @@ int iwl_commit_rxon(struct iwl_priv *priv)
"Could not send WEP static key.\n");
}
+ /*
+ * allow CTS-to-self if possible for new association.
+ * this is relevant only for 5000 series and up,
+ * but will not damage 4965
+ */
+ priv->staging_rxon.flags |= RXON_FLG_SELF_CTS_EN;
+
/* Apply the new configuration
* RXON assoc doesn't clear the station table in uCode,
*/
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index e50103a..7754538 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -213,6 +213,7 @@ struct iwl_mod_params {
* @pa_type: used by 6000 series only to identify the type of Power Amplifier
* @max_ll_items: max number of OTP blocks
* @shadow_ram_support: shadow support for OTP memory
+ * @use_rts_for_ht: use rts/cts protection for HT traffic
*
* We enable the driver to be backward compatible wrt API version. The
* driver specifies which APIs it supports (with @ucode_api_max being the
@@ -255,6 +256,7 @@ struct iwl_cfg {
const bool shadow_ram_support;
const bool ht_greenfield_support;
const bool broken_powersave;
+ bool use_rts_for_ht;
};
/***************************
diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
index 039b555..53d56ab 100644
--- a/drivers/net/wireless/libertas/ethtool.c
+++ b/drivers/net/wireless/libertas/ethtool.c
@@ -169,16 +169,19 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
struct lbs_private *priv = dev->ml_priv;
uint32_t criteria = 0;
- if (priv->wol_criteria == 0xffffffff && wol->wolopts)
- return -EOPNOTSUPP;
-
if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
return -EOPNOTSUPP;
- if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
- if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
- if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
- if (wol->wolopts & WAKE_PHY) criteria |= EHS_WAKE_ON_MAC_EVENT;
+ if (wol->wolopts & WAKE_UCAST)
+ criteria |= EHS_WAKE_ON_UNICAST_DATA;
+ if (wol->wolopts & WAKE_MCAST)
+ criteria |= EHS_WAKE_ON_MULTICAST_DATA;
+ if (wol->wolopts & WAKE_BCAST)
+ criteria |= EHS_WAKE_ON_BROADCAST_DATA;
+ if (wol->wolopts & WAKE_PHY)
+ criteria |= EHS_WAKE_ON_MAC_EVENT;
+ if (wol->wolopts == 0)
+ criteria |= EHS_REMOVE_WAKEUP;
return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
}
diff --git a/drivers/net/wireless/rtl818x/rtl8187_rfkill.c b/drivers/net/wireless/rtl818x/rtl8187_rfkill.c
index 9fab13e..cad8037 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_rfkill.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_rfkill.c
@@ -18,6 +18,7 @@
#include <net/mac80211.h>
#include "rtl8187.h"
+#include "rtl8187_rfkill.h"
static bool rtl8187_is_radio_enabled(struct rtl8187_priv *priv)
{
diff --git a/drivers/ssb/scan.c b/drivers/ssb/scan.c
index b74212d..e8b89e8 100644
--- a/drivers/ssb/scan.c
+++ b/drivers/ssb/scan.c
@@ -162,6 +162,8 @@ static u8 chipid_to_nrcores(u16 chipid)
static u32 scan_read32(struct ssb_bus *bus, u8 current_coreidx,
u16 offset)
{
+ u32 lo, hi;
+
switch (bus->bustype) {
case SSB_BUSTYPE_SSB:
offset += current_coreidx * SSB_CORE_SIZE;
@@ -174,7 +176,9 @@ static u32 scan_read32(struct ssb_bus *bus, u8 current_coreidx,
offset -= 0x800;
} else
ssb_pcmcia_switch_segment(bus, 0);
- break;
+ lo = readw(bus->mmio + offset);
+ hi = readw(bus->mmio + offset + 2);
+ return lo | (hi << 16);
case SSB_BUSTYPE_SDIO:
offset += current_coreidx * SSB_CORE_SIZE;
return ssb_sdio_scan_read32(bus, offset);
--
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: [net-next-2.6 PATCH v5 5/5 RFC] TCPCT part1e: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-11-11 17:35 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Eric Dumazet, Linux Kernel Network Developers, Joe Perches
In-Reply-To: <alpine.DEB.2.00.0911110235270.2864@melkinpaasi.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Tue, 10 Nov 2009, William Allen Simpson wrote:
>> Well, that's what I did with the (now) parts 1b, 1c, and 1d, but somebody
>> complained that the callers didn't exist yet.
>
> I guess there's misunderstanding here. Yes, if you bring in new helpers
> that solely are used with your feature, then it that feature patch (and
> I found DaveM commenting specifically this point I think), or right
> beforehand with a clear note that it will be used in the subsequent patch.
If I understand correctly, in that case I look forward to your Ack for
part 1d, a self-contained "helper" feature patch "with a clear note".
^ permalink raw reply
* Re: [PATCH resent] Documentation: rw_lock lessons learned
From: Stephen Hemminger @ 2009-11-11 17:37 UTC (permalink / raw)
To: William Allen Simpson
Cc: Paul E. McKenney, Linus Torvalds, Linux Kernel Developers,
Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <4AFAEF78.4080807@gmail.com>
On Wed, 11 Nov 2009 12:08:08 -0500
William Allen Simpson <william.allen.simpson@gmail.com> wrote:
> Stephen Hemminger wrote:
> > I would rather see the text in Documentation/spinlocks give an explaination
> > as to why reader/writer locks are normally not desirable.
> >
> > The whole document needs work to make it a developer document, rather than
> > a historical mail thread.. A good document says what should be done today,
> > and does not have old junk or ask the reader to overly new context
> > on old information.
> >
> You wish me to merge our patches?
Sure, I am more concerned about document structure being readable than
preserving my sloppy prose.
> Or this is a second patch in a proposed series?
No. But taking more input from others (maybe Randy will help he is a good
editor) would get this back in shape.
--
^ permalink raw reply
* [PATCH 1/2] decnet: add RTNL lock when reading address list
From: Stephen Hemminger @ 2009-11-11 17:39 UTC (permalink / raw)
To: steve, David Miller
Cc: Eric Dumazet, Christine Caulfield, Hannes Eder, Alexey Dobriyan,
Steven Whitehouse, netdev, linux-decnet-users
In-Reply-To: <20091110182436.GA13374@fogou.chygwyn.com>
Add missing locking in the case of auto binding to the
default device. The address list might change while this code is looking
at the list.
Compile tested only, I am not a decnet user.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/decnet/dn_dev.c 2009-11-11 09:18:02.935313559 -0800
+++ b/net/decnet/dn_dev.c 2009-11-11 09:22:32.157313924 -0800
@@ -828,13 +828,17 @@ static int dn_dev_get_first(struct net_d
struct dn_dev *dn_db = (struct dn_dev *)dev->dn_ptr;
struct dn_ifaddr *ifa;
int rv = -ENODEV;
+
if (dn_db == NULL)
goto out;
+
+ rtnl_lock();
ifa = dn_db->ifa_list;
if (ifa != NULL) {
*addr = ifa->ifa_local;
rv = 0;
}
+ rtnl_unlock();
out:
return rv;
}
^ permalink raw reply
* [PATCH 2/2] decnet: convert dndev_lock to spinlock
From: Stephen Hemminger @ 2009-11-11 17:40 UTC (permalink / raw)
To: steve, David Miller
Cc: Eric Dumazet, Christine Caulfield, Hannes Eder, Alexey Dobriyan,
Steven Whitehouse, netdev, linux-decnet-users
In-Reply-To: <20091111093927.4a08999d@nehalam>
There is no reason for this lock to be reader/writer since
the reader only has lock held for a very brief period.
The overhead of read_lock is more expensive than spinlock.
Compile tested only, I am not a decnet user.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/decnet/dn_dev.c 2009-11-10 17:39:53.652984752 -0800
+++ b/net/decnet/dn_dev.c 2009-11-10 17:41:15.942736073 -0800
@@ -68,7 +68,7 @@ extern struct neigh_table dn_neigh_table
*/
__le16 decnet_address = 0;
-static DEFINE_RWLOCK(dndev_lock);
+static DEFINE_SPINLOCK(dndev_lock);
static struct net_device *decnet_default_device;
static BLOCKING_NOTIFIER_HEAD(dnaddr_chain);
@@ -557,7 +557,8 @@ rarok:
struct net_device *dn_dev_get_default(void)
{
struct net_device *dev;
- read_lock(&dndev_lock);
+
+ spin_lock(&dndev_lock);
dev = decnet_default_device;
if (dev) {
if (dev->dn_ptr)
@@ -565,7 +566,8 @@ struct net_device *dn_dev_get_default(vo
else
dev = NULL;
}
- read_unlock(&dndev_lock);
+ spin_unlock(&dndev_lock);
+
return dev;
}
@@ -575,13 +577,15 @@ int dn_dev_set_default(struct net_device
int rv = -EBUSY;
if (!dev->dn_ptr)
return -ENODEV;
- write_lock(&dndev_lock);
+
+ spin_lock(&dndev_lock);
if (force || decnet_default_device == NULL) {
old = decnet_default_device;
decnet_default_device = dev;
rv = 0;
}
- write_unlock(&dndev_lock);
+ spin_unlock(&dndev_lock);
+
if (old)
dev_put(old);
return rv;
@@ -589,13 +593,14 @@ int dn_dev_set_default(struct net_device
static void dn_dev_check_default(struct net_device *dev)
{
- write_lock(&dndev_lock);
+ spin_lock(&dndev_lock);
if (dev == decnet_default_device) {
decnet_default_device = NULL;
} else {
dev = NULL;
}
- write_unlock(&dndev_lock);
+ spin_unlock(&dndev_lock);
+
if (dev)
dev_put(dev);
}
^ permalink raw reply
* RE: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Sean Hefty @ 2009-11-11 18:18 UTC (permalink / raw)
To: 'Eric Dumazet', David S. Miller
Cc: Linux Netdev List, Roland Dreier, Hal Rosenstock, linux-rdma
In-Reply-To: <4AF8EBA4.2070102-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>for_each_netdev() should be used with RTNL or dev_base_lock held,
>or risk a crash.
>
>Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thanks - I'm working on a patch set in this area. Roland, I can merge Eric's
changes into that patch set if it makes things easier.
> drivers/infiniband/core/addr.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
>index bd07803..5ca0b2c 100644
>--- a/drivers/infiniband/core/addr.c
>+++ b/drivers/infiniband/core/addr.c
>@@ -131,6 +131,7 @@ int rdma_translate_ip(struct sockaddr *addr, struct
The changes to this function are still valid.
>@@ -391,15 +393,17 @@ static int addr_resolve_local(struct sockaddr *src_in,
This function is going away.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] sctp: Fix regression introduced by new sctp_connectx api
From: Vlad Yasevich @ 2009-11-11 18:19 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-sctp, Vlad Yasevich
A new (unrealeased to the user) sctp_connectx api
c6ba68a26645dbc5029a9faa5687ebe6fcfc53e4
sctp: support non-blocking version of the new sctp_connectx() API
introduced a regression cought by the user regression test
suite. In particular, the API requires the user library to
re-allocate the buffer and could potentially trigger a SIGFAULT.
This change corrects that regression by passing the original
address buffer to the kernel unmodified, but still allows for
a returned association id.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
net/sctp/socket.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index bf705ba..3a95fcb 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1276,22 +1276,30 @@ SCTP_STATIC int sctp_setsockopt_connectx(struct sock* sk,
}
/*
- * New (hopefully final) interface for the API. The option buffer is used
- * both for the returned association id and the addresses.
+ * New (hopefully final) interface for the API.
+ * We use the sctp_getaddrs_old structure so that use-space library
+ * can avoid any unnecessary allocations. The only defferent part
+ * is that we store the actual length of the address buffer into the
+ * addrs_num structure member. That way we can re-use the existing
+ * code.
*/
SCTP_STATIC int sctp_getsockopt_connectx3(struct sock* sk, int len,
char __user *optval,
int __user *optlen)
{
+ struct sctp_getaddrs_old param;
sctp_assoc_t assoc_id = 0;
int err = 0;
- if (len < sizeof(assoc_id))
+ if (len < sizeof(param))
return -EINVAL;
+ if (copy_from_user(¶m, optval, sizeof(param)))
+ return -EFAULT;
+
err = __sctp_setsockopt_connectx(sk,
- (struct sockaddr __user *)(optval + sizeof(assoc_id)),
- len - sizeof(assoc_id), &assoc_id);
+ (struct sockaddr __user *)param.addrs,
+ param.addr_num, &assoc_id);
if (err == 0 || err == -EINPROGRESS) {
if (copy_to_user(optval, &assoc_id, sizeof(assoc_id)))
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 2/2] rps: changes to bnx2x to get device hash
From: Stephen Hemminger @ 2009-11-11 18:19 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <65634d660911102253lbfc0927i4e4c0eba6d7d765d@mail.gmail.com>
On Tue, 10 Nov 2009 22:53:36 -0800
Tom Herbert <therbert@google.com> wrote:
> +
> + if (get_hdrhash && (cqe_fp_status_flags &
> + ETH_FAST_PATH_RX_CQE_RSS_HASH_FLG)) {
> + u8 hash_type = cqe_fp_status_flags &
> + ETH_FAST_PATH_RX_CQE_RSS_HASH_TYPE;
> +
> + skb->rxhash = le32_to_cpu(
> + cqe->fast_path_cqe.rss_hash_result);
> + if (!skb->rxhash)
> + skb->rxhash = 1;
> +
> + /* unicast IPv4 packet? */
> + if (((hash_type == IPV4_HASH_TYPE) ||
> + (hash_type == TCP_IPV4_HASH_TYPE)) &&
> + (cqe_fp_pars_flags &
> + PARSING_FLAGS_ETHERNET_ADDRESS_TYPE)) {
> + skb->dev = bp->dev;
> + skb_reset_mac_header(skb);
> + skb_pull(skb, ETH_HLEN);
> + skb->protocol =
> + __constant_htons(ETH_P_IP);
> + } else
> + skb->protocol =
> + eth_type_trans(skb, bp->dev);
> + } else
> + skb->protocol = eth_type_trans(skb, bp->dev);
How about putting this all in an inline function:
static inline u16 bn2x_get_type(...) {
}
skb->protocol = bn2x_get_type(...);
Then you won't have two calls to eth_type_trans,
Also: __constant_htons() should not be used directly (except switch statements),
macro for htons() does it automatically if argument is constant.
^ permalink raw reply
* r8169: fix driver drop incoming packets >= 1515 if MTU is set between 1515 and 1536
From: Raimonds Cicans @ 2009-11-11 18:20 UTC (permalink / raw)
To: romieu; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: r8169-mtu1536.patch --]
[-- Type: text/plain, Size: 938 bytes --]
Driver drop incoming packets >= 1515(1) if MTU is set between 1515(1) and 1536.
1) exact number depends on some factors:
- VLAN tagged or not
- patch "r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames"
applied or not
Bonus: got rid of magic number 8
Signed-off-by: Raimonds Cicans <ray@apollo.lv>
---
--- linux-2.6.31/drivers/net/r8169.c.orig 2009-11-06 21:52:12.722326601 +0200
+++ linux-2.6.31/drivers/net/r8169.c 2009-11-06 22:09:17.242224014 +0200
@@ -2229,9 +2229,9 @@ static void __devexit rtl8169_remove_one
static void rtl8169_set_rxbufsize(struct rtl8169_private *tp,
struct net_device *dev)
{
- unsigned int mtu = dev->mtu;
+ unsigned int max_frame = dev->mtu + VLAN_ETH_HLEN + ETH_FCS_LEN;
- tp->rx_buf_sz = (mtu > RX_BUF_SIZE) ? mtu + ETH_HLEN + 8 : RX_BUF_SIZE;
+ tp->rx_buf_sz = (max_frame > RX_BUF_SIZE) ? max_frame : RX_BUF_SIZE;
}
static int rtl8169_open(struct net_device *dev)
^ permalink raw reply
* [PATCH] SUNRPC: Address buffer overrun in rpc_uaddr2sockaddr()
From: Chuck Lever @ 2009-11-11 18:22 UTC (permalink / raw)
To: argp-YZAGAMbGdGKGw+nKnLezzg
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
The size of buf[] must account for the string termination needed for
the first strict_strtoul() call.
Fábio Olivé Leite points out that strict_strtoul() requires _either_
'\n\0' _or_ '\0' termination, so use the simpler '\0' here instead.
See http://bugzilla.kernel.org/show_bug.cgi?id=14546 .
Reported-by: argp-YZAGAMbGdGKGw+nKnLezzg@public.gmane.org
Signed-off-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Fábio Olivé Leite <fleite-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Would you please test this fix to see if it addresses the problem?
net/sunrpc/addr.c | 18 ++++++++----------
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index 22e8fd8..c7450c8 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -306,24 +306,25 @@ EXPORT_SYMBOL_GPL(rpc_sockaddr2uaddr);
* @sap: buffer into which to plant socket address
* @salen: size of buffer
*
+ * @uaddr does not have to be '\0'-terminated, but strict_strtoul() and
+ * rpc_pton() require proper string termination to be successful.
+ *
* Returns the size of the socket address if successful; otherwise
* zero is returned.
*/
size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
struct sockaddr *sap, const size_t salen)
{
- char *c, buf[RPCBIND_MAXUADDRLEN];
+ char *c, buf[RPCBIND_MAXUADDRLEN + sizeof('\0')];
unsigned long portlo, porthi;
unsigned short port;
- if (uaddr_len > sizeof(buf))
+ if (uaddr_len > RPCBIND_MAXUADDRLEN)
return 0;
memcpy(buf, uaddr, uaddr_len);
- buf[uaddr_len] = '\n';
- buf[uaddr_len + 1] = '\0';
-
+ buf[uaddr_len] = '\0';
c = strrchr(buf, '.');
if (unlikely(c == NULL))
return 0;
@@ -332,9 +333,7 @@ size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
if (unlikely(portlo > 255))
return 0;
- c[0] = '\n';
- c[1] = '\0';
-
+ *c = '\0';
c = strrchr(buf, '.');
if (unlikely(c == NULL))
return 0;
@@ -345,8 +344,7 @@ size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
port = (unsigned short)((porthi << 8) | portlo);
- c[0] = '\0';
-
+ *c = '\0';
if (rpc_pton(buf, strlen(buf), sap, salen) == 0)
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: net 01/02: allow to propagate errors through ->ndo_hard_start_xmit()
From: Patrick McHardy @ 2009-11-11 18:25 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
In-Reply-To: <4AF99156.9050301@trash.net>
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
Patrick McHardy wrote:
> The following two patches add support for error propagation
> through ->ndo_hard_start_xmit() and use it to propagate qdisc
> submission state through VLAN and macvlan devices.
>
> I'm also experimenting with returning errno codes from
> tunnel devices to the originating socket, but those patches
> still need some work.
>
> The only change relative to the patch posted yesterday is
> removal of an unnecessary initialization in dev_hard_start_xmit().
Attached is a new version with a more detailed changelog entry,
as requested by Jarek.
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 6447 bytes --]
commit 9c0290f7b05fdb5c3ef4a98d16b7acc8f0ffc119
Author: Patrick McHardy <kaber@trash.net>
Date: Wed Nov 11 19:29:59 2009 +0100
net: allow to propagate errors through ->ndo_hard_start_xmit()
Currently the ->ndo_hard_start_xmit() callbacks are only permitted to return
one of the NETDEV_TX codes. This prevents any kind of error propagation for
virtual devices, like queue congestion of the underlying device in case of
layered devices, or unreachability in case of tunnels.
This patch changes the NET_XMIT codes to avoid clashes with the NETDEV_TX
codes and changes the two callers of dev_hard_start_xmit() to expect either
errno codes, NET_XMIT codes or NETDEV_TX codes as return value.
Drivers are expected to free the packet when returning an errno or NET_XMIT
error code. When this happens while transmitting GSO segments,
dev_hard_start_xmit() frees the remaining segments.
In case of qdisc_restart(), all non NETDEV_TX codes are mapped to NETDEV_TX_OK
since no error propagation is possible when using qdiscs. In case of
dev_queue_xmit(), the error is propagated upwards.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 465add6..ab2812c 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -63,27 +63,48 @@ struct wireless_dev;
#define HAVE_FREE_NETDEV /* free_netdev() */
#define HAVE_NETDEV_PRIV /* netdev_priv() */
-#define NET_XMIT_SUCCESS 0
-#define NET_XMIT_DROP 1 /* skb dropped */
-#define NET_XMIT_CN 2 /* congestion notification */
-#define NET_XMIT_POLICED 3 /* skb is shot by police */
-#define NET_XMIT_MASK 0xFFFF /* qdisc flags in net/sch_generic.h */
+/*
+ * Transmit return codes: transmit return codes originate from three different
+ * namespaces:
+ *
+ * - qdisc return codes
+ * - driver transmit return codes
+ * - errno values
+ *
+ * Drivers are allowed to return any one of those in their hard_start_xmit()
+ * function. Real network devices commonly used with qdiscs should only return
+ * the driver transmit return codes though - when qdiscs are used, the actual
+ * transmission happens asynchronously, so the value is not propagated to
+ * higher layers. Virtual network devices transmit synchronously, in this case
+ * the driver transmit return codes are consumed by dev_queue_xmit(), all
+ * others are propagated to higher layers.
+ */
+
+/* qdisc ->enqueue() return codes. */
+#define NET_XMIT_SUCCESS 0x00
+#define NET_XMIT_DROP 0x10 /* skb dropped */
+#define NET_XMIT_CN 0x20 /* congestion notification */
+#define NET_XMIT_POLICED 0x30 /* skb is shot by police */
+#define NET_XMIT_MASK 0xf0 /* qdisc flags in net/sch_generic.h */
/* Backlog congestion levels */
-#define NET_RX_SUCCESS 0 /* keep 'em coming, baby */
-#define NET_RX_DROP 1 /* packet dropped */
+#define NET_RX_SUCCESS 0 /* keep 'em coming, baby */
+#define NET_RX_DROP 1 /* packet dropped */
/* NET_XMIT_CN is special. It does not guarantee that this packet is lost. It
* indicates that the device will soon be dropping packets, or already drops
* some packets of the same priority; prompting us to send less aggressively. */
-#define net_xmit_eval(e) ((e) == NET_XMIT_CN? 0 : (e))
+#define net_xmit_eval(e) ((e) == NET_XMIT_CN ? 0 : (e))
#define net_xmit_errno(e) ((e) != NET_XMIT_CN ? -ENOBUFS : 0)
/* Driver transmit return codes */
+#define NETDEV_TX_MASK 0xf
+
enum netdev_tx {
- NETDEV_TX_OK = 0, /* driver took care of packet */
- NETDEV_TX_BUSY, /* driver tx path was busy*/
- NETDEV_TX_LOCKED = -1, /* driver tx lock was already taken */
+ __NETDEV_TX_MIN = INT_MIN, /* make sure enum is signed */
+ NETDEV_TX_OK = 0, /* driver took care of packet */
+ NETDEV_TX_BUSY = 1, /* driver tx path was busy*/
+ NETDEV_TX_LOCKED = 2, /* driver tx lock was already taken */
};
typedef enum netdev_tx netdev_tx_t;
diff --git a/net/core/dev.c b/net/core/dev.c
index bf629ac..babd45f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1756,7 +1756,7 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
struct netdev_queue *txq)
{
const struct net_device_ops *ops = dev->netdev_ops;
- int rc;
+ int rc = NETDEV_TX_OK;
if (likely(!skb->next)) {
if (!list_empty(&ptype_all))
@@ -1804,6 +1804,8 @@ gso:
nskb->next = NULL;
rc = ops->ndo_start_xmit(nskb, dev);
if (unlikely(rc != NETDEV_TX_OK)) {
+ if (rc & ~NETDEV_TX_MASK)
+ goto out_kfree_gso_skb;
nskb->next = skb->next;
skb->next = nskb;
return rc;
@@ -1813,11 +1815,12 @@ gso:
return NETDEV_TX_BUSY;
} while (skb->next);
- skb->destructor = DEV_GSO_CB(skb)->destructor;
-
+out_kfree_gso_skb:
+ if (likely(skb->next == NULL))
+ skb->destructor = DEV_GSO_CB(skb)->destructor;
out_kfree_skb:
kfree_skb(skb);
- return NETDEV_TX_OK;
+ return rc;
}
static u32 skb_tx_hashrnd;
@@ -1905,6 +1908,23 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
return rc;
}
+static inline bool dev_xmit_complete(int rc)
+{
+ /* successful transmission */
+ if (rc == NETDEV_TX_OK)
+ return true;
+
+ /* error while transmitting, driver consumed skb */
+ if (rc < 0)
+ return true;
+
+ /* error while queueing to a different device, driver consumed skb */
+ if (rc & NET_XMIT_MASK)
+ return true;
+
+ return false;
+}
+
/**
* dev_queue_xmit - transmit a buffer
* @skb: buffer to transmit
@@ -2002,8 +2022,8 @@ gso:
HARD_TX_LOCK(dev, txq, cpu);
if (!netif_tx_queue_stopped(txq)) {
- rc = NET_XMIT_SUCCESS;
- if (!dev_hard_start_xmit(skb, dev, txq)) {
+ rc = dev_hard_start_xmit(skb, dev, txq);
+ if (dev_xmit_complete(rc)) {
HARD_TX_UNLOCK(dev, txq);
goto out;
}
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 4ae6aa5..b13821a 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -120,8 +120,15 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
HARD_TX_LOCK(dev, txq, smp_processor_id());
if (!netif_tx_queue_stopped(txq) &&
- !netif_tx_queue_frozen(txq))
+ !netif_tx_queue_frozen(txq)) {
ret = dev_hard_start_xmit(skb, dev, txq);
+
+ /* an error implies that the skb was consumed */
+ if (ret < 0)
+ ret = NETDEV_TX_OK;
+ /* all NET_XMIT codes map to NETDEV_TX_OK */
+ ret &= ~NET_XMIT_MASK;
+ }
HARD_TX_UNLOCK(dev, txq);
spin_lock(root_lock);
^ permalink raw reply related
* Re: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Roland Dreier @ 2009-11-11 18:25 UTC (permalink / raw)
To: Sean Hefty
Cc: 'Eric Dumazet', David S. Miller, Linux Netdev List,
Roland Dreier, Hal Rosenstock, linux-rdma
In-Reply-To: <D5E1FB213939498DBFFEB5A3B83C08AD-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
> >for_each_netdev() should be used with RTNL or dev_base_lock held,
> >or risk a crash.
> >
> >Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Thanks - I'm working on a patch set in this area. Roland, I can merge Eric's
> changes into that patch set if it makes things easier.
Would it be possible for you to take Eric's patch as the first in your
set (keeping his From: of course) and base your fixes on top of that?
That seems the cleanest thing to me.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: r8169: fix driver drop incoming packets >= 1515 if MTU is set between 1515 and 1536
From: Ben Hutchings @ 2009-11-11 18:33 UTC (permalink / raw)
To: Raimonds Cicans; +Cc: romieu, netdev
In-Reply-To: <4AFB0061.7020908@apollo.lv>
On Wed, 2009-11-11 at 20:20 +0200, Raimonds Cicans wrote:
> Driver drop incoming packets >= 1515(1) if MTU is set between 1515(1) and 1536.
>
> 1) exact number depends on some factors:
> - VLAN tagged or not
> - patch "r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames"
> applied or not
[...]
MTU is a limit on transmission; it is not required to limit received
frames.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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
* Your email ID has been awarded 1,000,000,00 GBP in our BT promo !!!
From: Tobacco Alart @ 2009-11-11 18:35 UTC (permalink / raw)
Your Email ID has been awarded 1,000,000,00 GBP in British Promo
1.Full Name:
2.Full Address:
3.Status:
4.Occupation:
5.Phone Number:
6.Country:
^ permalink raw reply
* [PATCH] [next-next-2.6] net: configurable device name hash
From: Octavian Purdila @ 2009-11-11 19:16 UTC (permalink / raw)
To: netdev
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 0addd45..8a129d5 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -29,8 +29,7 @@ struct net_generic;
struct sock;
-#define NETDEV_HASHBITS 8
-#define NETDEV_HASHENTRIES (1 << NETDEV_HASHBITS)
+#define NETDEV_HASHENTRIES (1 << CONFIG_NETDEV_HASHBITS)
struct net {
atomic_t count; /* To decided when the network
diff --git a/net/Kconfig b/net/Kconfig
index 041c35e..f5db7b2 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -45,6 +45,13 @@ config COMPAT_NETLINK_MESSAGES
menu "Networking options"
+config NETDEV_HASHBITS
+ int "Network device hash size"
+ range 8 20
+ default 8
+ help
+ Select network device hash size as a power of 2.
+
source "net/packet/Kconfig"
source "net/unix/Kconfig"
source "net/xfrm/Kconfig"
^ permalink raw reply related
* Re: pull request: wireless-2.6 2009-11-11
From: David Miller @ 2009-11-11 19:20 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20091111172255.GH4392@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 11 Nov 2009 12:22:55 -0500
> Here is another batch of small fixes intended for 2.6.32. Along with a
> number of simple fixes, there is also a MAINTAINERS update, some LED
> handling quirks for ath5k, a libertas beautification that is a prereq
> for a libertas fix, and an iwlwifi fix that was already sent for
> net-next-2.6 but which is needed to support an iwlwifi regression fix.
>
> My personal favorite is the ath5k mcast filtering fix. The problem
> only revealed itself when using IP autoconf w/ multicast DNS... :-)
>
> Please let me know if there are problems!
Pulled, but that libertas "coding style cleanup" really pushes
the edge of what I'm willing to take into net-2.6 right now.
And I don't want to hear anything about how it "makes the bug fix
change simpler". That absolutely doesn't apply when we're this deep
in -rc territory.
> P.S. Due to the aformentioned iwlwifi fix, this will cause -next
> conflicts for sfr. You may want to pull net-2.6 into net-next-2.6 after
> pulling this. The iwlwifi conflicts can be resolved by taking the bigger
> hunks...
Yep, I noticed this, I'll sort it out, thanks.
^ permalink raw reply
* Re: [PATCH] [next-next-2.6] net: configurable device name hash
From: David Miller @ 2009-11-11 19:21 UTC (permalink / raw)
To: opurdila; +Cc: netdev
In-Reply-To: <200911112116.14103.opurdila@ixiacom.com>
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Wed, 11 Nov 2009 21:16:14 +0200
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
We're not doing this sorry.
Dynamically size it at boot time or something, but a config
option is out of the question.
^ permalink raw reply
* Re: [PATCH] add HAVE_UNREGISTER_NETDEV_QUEUE define for out-of-tree modules
From: David Miller @ 2009-11-11 19:24 UTC (permalink / raw)
To: bcrl; +Cc: netdev
In-Reply-To: <20091110220004.GT21704@kvack.org>
From: Benjamin LaHaise <bcrl@lhnet.ca>
Date: Tue, 10 Nov 2009 17:00:04 -0500
> I have an out of tree network driver (GPL'd) that would like to make use of
> the unregister_netdevice_queue interface for bulk unregister of devices.
> Add a #define HAVE_UNREGISTER_NETDEV_QUEUE to allow the source to detect
> that the kernel supports this.
Please get your code upstream :-)
We're already overcluttered with these "HAVE_PANTS", "HAVE_JACKET",
"HAVE_KITCHEN", "HAVE_SINK" ugly defines spewed all over netdevice.h,
and I'm not adding any more of that.
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-11-11
From: David Miller @ 2009-11-11 19:41 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091111.112031.184370997.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Wed, 11 Nov 2009 11:20:31 -0800 (PST)
> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Wed, 11 Nov 2009 12:22:55 -0500
>
>> P.S. Due to the aformentioned iwlwifi fix, this will cause -next
>> conflicts for sfr. You may want to pull net-2.6 into net-next-2.6 after
>> pulling this. The iwlwifi conflicts can be resolved by taking the bigger
>> hunks...
>
> Yep, I noticed this, I'll sort it out, thanks.
I just pushed out the merge to net-next-2.6, please double
check my work.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [next-next-2.6] net: configurable device name hash
From: Octavian Purdila @ 2009-11-11 19:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091111.112120.134023270.davem@davemloft.net>
On Wednesday 11 November 2009 21:21:20 you wrote:
> From: Octavian Purdila <opurdila@ixiacom.com>
> Date: Wed, 11 Nov 2009 21:16:14 +0200
>
> > Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
>
> We're not doing this sorry.
>
> Dynamically size it at boot time or something, but a config
> option is out of the question.
>
I don't think we can dynamically size it at boot time since it depends on the
usage pattern which is impossible to determine at boot time, right?
Would it be acceptable to grow it at runtime, in list_netdevice for instance?
^ permalink raw reply
* Re: [PATCH] add HAVE_UNREGISTER_NETDEV_QUEUE define for out-of-tree modules
From: Benjamin LaHaise @ 2009-11-11 19:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091111.112457.54237892.davem@davemloft.net>
On Wed, Nov 11, 2009 at 11:24:57AM -0800, David Miller wrote:
> From: Benjamin LaHaise <bcrl@lhnet.ca>
> Date: Tue, 10 Nov 2009 17:00:04 -0500
>
> > I have an out of tree network driver (GPL'd) that would like to make use of
> > the unregister_netdevice_queue interface for bulk unregister of devices.
> > Add a #define HAVE_UNREGISTER_NETDEV_QUEUE to allow the source to detect
> > that the kernel supports this.
>
> Please get your code upstream :-)
It's a completely separate PPP & L2TP / PPPoE from the existing code that
is in tree. Somehow, I don't think people are interested in merging duplicate
functionality regardless of what differences there are in the interfaces.
> We're already overcluttered with these "HAVE_PANTS", "HAVE_JACKET",
> "HAVE_KITCHEN", "HAVE_SINK" ugly defines spewed all over netdevice.h,
> and I'm not adding any more of that.
If there was some other way of detecting that the interface is present,
I'd use it, but there isn't.
-ben
^ permalink raw reply
* Re: r8169: fix driver drop incoming packets >= 1515 if MTU is set between 1515 and 1536
From: Raimonds Cicans @ 2009-11-11 20:05 UTC (permalink / raw)
To: Ben Hutchings; +Cc: romieu, netdev
In-Reply-To: <1257964419.2839.58.camel@achroite.uk.solarflarecom.com>
Ben Hutchings:
> On Wed, 2009-11-11 at 20:20 +0200, Raimonds Cicans wrote:
>> Driver drop incoming packets >= 1515(1) if MTU is set between 1515(1) and 1536.
>>
>> 1) exact number depends on some factors:
>> - VLAN tagged or not
>> - patch "r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames"
>> applied or not
> [...]
>
> MTU is a limit on transmission; it is not required to limit received
> frames.
???
In r8169 driver MTU is used to calculate receive buffer size.
Receive buffer size is used to configure hardware incoming packet filter.
For jumbo frames:
Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
(vlan header) + 4 (ethernet checksum) = MTU + 22
Bug:
driver for all MTU up to 1536 use receive buffer size 1536
As you can see from formula, this mean all IP packets > 1536 - 22
(for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware
filter.
Example:
host_good> ifconfig eth0 mtu 1536
host_r8169> ifconfig eth0 mtu 1536
host_good> ping host_r8169
Ok
host_good> ping -s 1500 host_r8169
Fail
host_good> ifconfig eth0 mtu 7000
host_r8169> ifconfig eth0 mtu 7000
host_good> ping -s 1500 host_r8169
Ok
Raimonds Cicans
^ permalink raw reply
* Re: [PATCH] [next-next-2.6] net: configurable device name hash
From: Eric Dumazet @ 2009-11-11 20:08 UTC (permalink / raw)
To: Octavian Purdila; +Cc: David Miller, netdev
In-Reply-To: <200911112138.44074.opurdila@ixiacom.com>
Octavian Purdila a écrit :
> On Wednesday 11 November 2009 21:21:20 you wrote:
>> From: Octavian Purdila <opurdila@ixiacom.com>
>> Date: Wed, 11 Nov 2009 21:16:14 +0200
>>
>>> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
>> We're not doing this sorry.
>>
>> Dynamically size it at boot time or something, but a config
>> option is out of the question.
>>
>
> I don't think we can dynamically size it at boot time since it depends on the
> usage pattern which is impossible to determine at boot time, right?
>
> Would it be acceptable to grow it at runtime, in list_netdevice for instance?
It will be really hard, now we use RCU lookups...
What workload could reasonably need 1.000.000 hash slots, and 16.000.000 netdevices ?
^ permalink raw reply
* Re: r8169: fix driver drop incoming packets >= 1515 if MTU is set between 1515 and 1536
From: Ben Hutchings @ 2009-11-11 20:15 UTC (permalink / raw)
To: Raimonds Cicans; +Cc: romieu, netdev
In-Reply-To: <4AFB190F.2020009@apollo.lv>
On Wed, 2009-11-11 at 22:05 +0200, Raimonds Cicans wrote:
> Ben Hutchings:
> > On Wed, 2009-11-11 at 20:20 +0200, Raimonds Cicans wrote:
> >> Driver drop incoming packets >= 1515(1) if MTU is set between 1515(1) and 1536.
> >>
> >> 1) exact number depends on some factors:
> >> - VLAN tagged or not
> >> - patch "r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames"
> >> applied or not
> > [...]
> >
> > MTU is a limit on transmission; it is not required to limit received
> > frames.
>
> ???
>
> In r8169 driver MTU is used to calculate receive buffer size.
> Receive buffer size is used to configure hardware incoming packet filter.
>
> For jumbo frames:
> Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
> (vlan header) + 4 (ethernet checksum) = MTU + 22
>
> Bug:
> driver for all MTU up to 1536 use receive buffer size 1536
[...]
OK, now I understand. The subject line you used is not grammatical and
I originally thought you considered it a bug that the driver might
accept packets with payload greater than MTU.
To make it clear, perhaps you could change the subject to:
'r8169: Fix receive buffer length when MTU is between 1515 and 1536'
and then explain the current behaviour below that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-11 20:19 UTC (permalink / raw)
To: Frans Pop; +Cc: linux-kernel, netdev
In-Reply-To: <200910311944.35922.elendil@planet.nl>
not to be impatient or ungrateful, but has anyone had time to look at
this? will I be able to upgrade to 31.6? will 32.0 work?
On Sat, Oct 31, 2009 at 1:44 PM, Frans Pop <elendil@planet.nl> wrote:
> Adding netdev in CC. Original message + attachments follow.
>
> =========
> so ever since arch rolled out 2.6.31.x I've been having problems with
> my network (again) where I've been losing a large amount of packets
> (just testing with mtr somewhere between 30/50%). first I figured it
> was the same problem as I had in 2.6.30.x (and maybe it is?) but that
> appeared to get fixed. when I started bisecting the bug wasn't
> apparent in 2.6.31.0 but I knew for sure it was in .5 (I couldn't
> remember if I had noticed it again in .3)
>
> I'm attaching the bisection log and a 'good' dmesg output.
>
> c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9 is the first bad commit
>
> I'm not going to pretend to understand why this patch is breaking my
> networking but between bisection and testing it appears to be... I've
> never bisected before and I'm definitely not a kernel hacker (I can
> barely read C).
>
> I should also note that the wireshark dump here
> http://bugzilla.kernel.org/show_bug.cgi?id=13835 is related to this.
> and if it's not the same bug then possibly a new one should be opened.
>
> P.S. I'm not subscribed to the list please CC me
>
> Caleb Cushing
> http://xenoterracide.blogspot.com
>
>
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ 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