* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Williams, Mitch A @ 2009-11-23 19:52 UTC (permalink / raw)
To: Ben Hutchings
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1258982570.2845.8.camel@achroite.uk.solarflarecom.com>
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Monday, November 23, 2009 5:23 AM
[snip]
>
>How does this interact with use of multiple queues within a single
>function? Are the specified queue numbers really interpreted as RX
>queue indices or as function numbers?
>
>Ben.
Yeah, that is ambiguous. Would it be better if we changed the name of the parameter to 'vf' instead of 'queue' to make it explicit?
This would give us:
$ ip link set eth1 vf 1 mac <blah>
The issue of which VF goes with which PF device can be deduced in userspace via sysfs.
If we want to make this apply to non SR-IOV queues, then we'll add a new parameter later.
Works for you?
-Mitch
^ permalink raw reply
* [-next PATCH 0/4] Minor fixes for alacrityvm/linux-next branch
From: Gregory Haskins @ 2009-11-23 19:54 UTC (permalink / raw)
To: linux-next; +Cc: netdev, linux-kernel, alacrityvm-devel
The following are trivial fixes for the drivers in alacrityvm/linux-next
Patches 1-3 were necessary to enable the building of these drivers
as a KMP package for older distribution kernels. Patch 4/4 is just
a cleanup discovered during testing.
Kind Regards,
-Greg
---
Gregory Haskins (4):
vbus: fix pcibridge busmaster support
vbus: add autoprobe capability to guest
venet: add missing ethtool include
vbus: make library code properly declared as GPL
drivers/net/vbus-enet.c | 3 +++
drivers/vbus/bus-proxy.c | 33 ++++++++++++++++++++++++++++++++-
drivers/vbus/pci-bridge.c | 2 ++
include/linux/vbus_driver.h | 2 ++
lib/ioq.c | 4 ++++
lib/shm_signal.c | 4 ++++
6 files changed, 47 insertions(+), 1 deletions(-)
--
Signature
^ permalink raw reply
* [-next PATCH 1/4] vbus: make library code properly declared as GPL
From: Gregory Haskins @ 2009-11-23 19:54 UTC (permalink / raw)
To: linux-next; +Cc: netdev, linux-kernel, alacrityvm-devel
In-Reply-To: <20091123195136.8184.68042.stgit@dev.haskins.net>
This facilitates building the shm-signal and ioq libraries as kernel
modules.
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---
lib/ioq.c | 4 ++++
lib/shm_signal.c | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/lib/ioq.c b/lib/ioq.c
index a6c8664..d5e57be 100644
--- a/lib/ioq.c
+++ b/lib/ioq.c
@@ -25,6 +25,10 @@
#include <linux/bitops.h>
#include <linux/module.h>
+MODULE_AUTHOR("Gregory Haskins");
+MODULE_LICENSE("GPL");
+MODULE_VERSION("1");
+
#ifndef NULL
#define NULL 0
#endif
diff --git a/lib/shm_signal.c b/lib/shm_signal.c
index fbba74f..8d3e9b4 100644
--- a/lib/shm_signal.c
+++ b/lib/shm_signal.c
@@ -24,6 +24,10 @@
#include <linux/interrupt.h>
#include <linux/shm_signal.h>
+MODULE_AUTHOR("Gregory Haskins");
+MODULE_LICENSE("GPL");
+MODULE_VERSION("1");
+
int shm_signal_enable(struct shm_signal *s, int flags)
{
struct shm_signal_irq *irq = &s->desc->irq[s->locale];
^ permalink raw reply related
* [-next PATCH 2/4] venet: add missing ethtool include
From: Gregory Haskins @ 2009-11-23 19:54 UTC (permalink / raw)
To: linux-next; +Cc: netdev, linux-kernel, alacrityvm-devel
In-Reply-To: <20091123195136.8184.68042.stgit@dev.haskins.net>
It's sloppy to use the facility without officially including its header
file.
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---
drivers/net/vbus-enet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/vbus-enet.c b/drivers/net/vbus-enet.c
index 29b388f..25c6bea 100644
--- a/drivers/net/vbus-enet.c
+++ b/drivers/net/vbus-enet.c
@@ -22,6 +22,7 @@
#include <linux/in.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/skbuff.h>
^ permalink raw reply related
* [-next PATCH 3/4] vbus: add autoprobe capability to guest
From: Gregory Haskins @ 2009-11-23 19:54 UTC (permalink / raw)
To: linux-next; +Cc: netdev, linux-kernel, alacrityvm-devel
In-Reply-To: <20091123195136.8184.68042.stgit@dev.haskins.net>
This enables the guest to automatically load the appropriate driver
when vbus devices are detected.
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---
drivers/net/vbus-enet.c | 2 ++
drivers/vbus/bus-proxy.c | 33 ++++++++++++++++++++++++++++++++-
include/linux/vbus_driver.h | 2 ++
3 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/drivers/net/vbus-enet.c b/drivers/net/vbus-enet.c
index 25c6bea..4e9ecac 100644
--- a/drivers/net/vbus-enet.c
+++ b/drivers/net/vbus-enet.c
@@ -1556,3 +1556,5 @@ vbus_enet_cleanup(void)
module_init(vbus_enet_init_module);
module_exit(vbus_enet_cleanup);
+
+VBUS_DRIVER_AUTOPROBE(VENET_TYPE);
diff --git a/drivers/vbus/bus-proxy.c b/drivers/vbus/bus-proxy.c
index 5d34942..106e2fe 100644
--- a/drivers/vbus/bus-proxy.c
+++ b/drivers/vbus/bus-proxy.c
@@ -48,6 +48,16 @@ static int vbus_dev_proxy_match(struct device *_dev, struct device_driver *_drv)
return !strcmp(dev->type, drv->type);
}
+static int vbus_dev_proxy_uevent(struct device *_dev, struct kobj_uevent_env *env)
+{
+ struct vbus_device_proxy *dev = to_dev(_dev);
+
+ if (add_uevent_var(env, "MODALIAS=vbus-proxy:%s", dev->type))
+ return -ENOMEM;
+
+ return 0;
+}
+
/*
* This function is invoked after the bus infrastructure has already made a
* match. The device will contain a reference to the paired driver which
@@ -68,6 +78,7 @@ static int vbus_dev_proxy_probe(struct device *_dev)
static struct bus_type vbus_proxy = {
.name = VBUS_PROXY_NAME,
.match = vbus_dev_proxy_match,
+ .uevent = vbus_dev_proxy_uevent,
};
static struct device vbus_proxy_rootdev = {
@@ -99,18 +110,38 @@ static void device_release(struct device *dev)
_dev->ops->release(_dev);
}
+static ssize_t _show_modalias(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "vbus-proxy:%s\n", to_dev(dev)->type);
+}
+DEVICE_ATTR(modalias, S_IRUSR | S_IRGRP | S_IROTH, _show_modalias, NULL);
+
int vbus_device_proxy_register(struct vbus_device_proxy *new)
{
+ int ret;
+
new->dev.parent = &vbus_proxy_rootdev;
new->dev.bus = &vbus_proxy;
new->dev.release = &device_release;
- return device_register(&new->dev);
+ ret = device_register(&new->dev);
+ if (ret < 0)
+ return ret;
+
+ ret = device_create_file(&new->dev, &dev_attr_modalias);
+ if (ret < 0) {
+ device_unregister(&new->dev);
+ return ret;
+ }
+
+ return 0;
}
EXPORT_SYMBOL_GPL(vbus_device_proxy_register);
void vbus_device_proxy_unregister(struct vbus_device_proxy *dev)
{
+ device_remove_file(&dev->dev, &dev_attr_modalias);
device_unregister(&dev->dev);
}
EXPORT_SYMBOL_GPL(vbus_device_proxy_unregister);
diff --git a/include/linux/vbus_driver.h b/include/linux/vbus_driver.h
index 2b1dac4..8a7acb1 100644
--- a/include/linux/vbus_driver.h
+++ b/include/linux/vbus_driver.h
@@ -78,4 +78,6 @@ void vbus_driver_unregister(struct vbus_driver *drv);
int vbus_driver_ioq_alloc(struct vbus_device_proxy *dev, const char *name,
int id, int prio, size_t ringsize, struct ioq **ioq);
+#define VBUS_DRIVER_AUTOPROBE(name) MODULE_ALIAS("vbus-proxy:" name)
+
#endif /* _LINUX_VBUS_DRIVER_H */
^ permalink raw reply related
* [-next PATCH 4/4] vbus: fix pcibridge busmaster support
From: Gregory Haskins @ 2009-11-23 19:54 UTC (permalink / raw)
To: linux-next; +Cc: netdev, linux-kernel, alacrityvm-devel
In-Reply-To: <20091123195136.8184.68042.stgit@dev.haskins.net>
We should technically enable the busmaster bit, even though its not
actually used on the host side
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---
drivers/vbus/pci-bridge.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/vbus/pci-bridge.c b/drivers/vbus/pci-bridge.c
index ddc3f39..962ef58 100644
--- a/drivers/vbus/pci-bridge.c
+++ b/drivers/vbus/pci-bridge.c
@@ -932,6 +932,8 @@ vbus_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (ret < 0)
return ret;
+ pci_set_master(pdev);
+
ret = pci_request_regions(pdev, VBUS_PCI_NAME);
if (ret < 0) {
printk(KERN_ERR "VBUS_PCI: Could not init BARs: %d\n", ret);
^ permalink raw reply related
* pull request: SCTP updates for net-next
From: Vlad Yasevich @ 2009-11-23 21:06 UTC (permalink / raw)
To: David Miller; +Cc: Linux SCTP Dev Mailing list, netdev
Hi David
Here is a set of SCTP patches for net-next. Please pull.
The following changes since commit dc63d3771cc6492220f53caf5fded6090d45d9ce:
Alexander Duyck (1):
ixgbe: Only set/clear VFE in ixgbe_set_rx_mode
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vxy/lksctp-dev.git net-next
Amerigo Wang (1):
sctp: remove deprecated SCTP_GET_*_OLD stuffs
Andrei Pelinescu-Onciul (3):
sctp: allow setting path_maxrxt independent of SPP_PMTUD_ENABLE
sctp: limit maximum autoclose setsockopt value
sctp: fix integer overflow when setting the autoclose timer
Neil Horman (1):
sctp: Fix mis-ordering of user space data when multihoming in use
Vlad Yasevich (7):
sctp: Fix malformed "Invalid Stream Identifier" error
sctp: Select a working primary during sctp_connectx()
sctp: Update SWS avaoidance receiver side algorithm
sctp: Remove useless last_time_used variable
sctp: Turn the enum socket options into defines
sctp: Update max.burst implementation
sctp: prevent too-fast association id reuse
Wei Yongjun (3):
sctp: implement definition for SACK-IMMEDIATELY extension
sctp: implement the receiver side for SACK-IMMEDIATELY extension
sctp: implement the sender side for SACK-IMMEDIATELY extension
Documentation/feature-removal-schedule.txt | 12 -
include/linux/sctp.h | 1 +
include/net/sctp/constants.h | 4 +
include/net/sctp/sm.h | 3 +-
include/net/sctp/structs.h | 16 +-
include/net/sctp/user.h | 132 ++++--------
net/sctp/associola.c | 27 ++-
net/sctp/chunk.c | 15 ++-
net/sctp/output.c | 50 +---
net/sctp/outqueue.c | 22 ++
net/sctp/protocol.c | 3 +
net/sctp/sm_make_chunk.c | 13 +-
net/sctp/sm_sideeffect.c | 5 +-
net/sctp/sm_statefuns.c | 26 ++-
net/sctp/socket.c | 335 +---------------------------
net/sctp/sysctl.c | 13 +
net/sctp/transport.c | 45 ++++-
17 files changed, 223 insertions(+), 499 deletions(-)
^ permalink raw reply
* Re: ixgbe question
From: David Miller @ 2009-11-23 21:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: peter.p.waskiewicz.jr, netdev
In-Reply-To: <4B0A65E0.7060403@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 23 Nov 2009 11:37:20 +0100
> (Fedora Core 12 installer was not able to recognize disks on this machine :( )
I ran into this problem too on my laptop, but only with the Live-CD images.
The DVD image recognized the disks and installed just fine.
^ permalink raw reply
* Re: ixgbe question
From: David Miller @ 2009-11-23 21:28 UTC (permalink / raw)
To: robert; +Cc: eric.dumazet, hawk, peter.p.waskiewicz.jr, netdev
In-Reply-To: <19210.63123.814368.292600@gargle.gargle.HOWL>
From: robert@herjulf.net
Date: Mon, 23 Nov 2009 21:54:43 +0100
> Something mysterious or very obvious...
It seem very obvious to me that, for whatever reason, the MSI-X vectors
are only being sent to cpu 1 on Eric's system.
I also suspect, as a result, that it has nothing to do with the IXGBE
driver but rather is some IRQ controller programming or some bug or
limitation in the IRQ affinity mask handling in the kernel.
^ permalink raw reply
* pull request: wireless-2.6 2009-11-23
From: John W. Linville @ 2009-11-23 21:42 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are a few more fixes intended for 2.6.32. They are small and
self-contained and mostly speak for themselves.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 70e3bb504ccfe6ba725ab120bdb516d205d834f9:
Divy Le Ray (1):
cxgb3: fix premature page unmap
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Johannes Berg (3):
mac80211: fix addba timer (again...)
mac80211: fix resume
rfkill: fix miscdev ops
John W. Linville (1):
ath9k: set ps_default as false
drivers/net/wireless/ath/ath9k/main.c | 2 ++
net/mac80211/agg-tx.c | 18 ++++++++----------
net/mac80211/ieee80211_i.h | 8 ++++++++
net/mac80211/util.c | 19 +++++++++----------
net/rfkill/core.c | 1 +
5 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 52bed89..43d2be9 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1555,6 +1555,8 @@ void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
BIT(NL80211_IFTYPE_ADHOC) |
BIT(NL80211_IFTYPE_MESH_POINT);
+ hw->wiphy->ps_default = false;
+
hw->queues = 4;
hw->max_rates = 4;
hw->channel_change_time = 5000;
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index b09948c..206fd82 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -173,12 +173,14 @@ static void sta_addba_resp_timer_expired(unsigned long data)
/* check if the TID waits for addBA response */
spin_lock_bh(&sta->lock);
- if (!(*state & HT_ADDBA_REQUESTED_MSK)) {
+ if ((*state & (HT_ADDBA_REQUESTED_MSK | HT_ADDBA_RECEIVED_MSK)) !=
+ HT_ADDBA_REQUESTED_MSK) {
spin_unlock_bh(&sta->lock);
*state = HT_AGG_STATE_IDLE;
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "timer expired on tid %d but we are not "
- "expecting addBA response there", tid);
+ "(or no longer) expecting addBA response there",
+ tid);
#endif
return;
}
@@ -666,21 +668,21 @@ void ieee80211_process_addba_resp(struct ieee80211_local *local,
state = &sta->ampdu_mlme.tid_state_tx[tid];
- del_timer_sync(&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer);
-
spin_lock_bh(&sta->lock);
if (!(*state & HT_ADDBA_REQUESTED_MSK))
- goto timer_still_needed;
+ goto out;
if (mgmt->u.action.u.addba_resp.dialog_token !=
sta->ampdu_mlme.tid_tx[tid]->dialog_token) {
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "wrong addBA response token, tid %d\n", tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
- goto timer_still_needed;
+ goto out;
}
+ del_timer(&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer);
+
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "switched off addBA timer for tid %d \n", tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
@@ -699,10 +701,6 @@ void ieee80211_process_addba_resp(struct ieee80211_local *local,
___ieee80211_stop_tx_ba_session(sta, tid, WLAN_BACK_INITIATOR);
}
- goto out;
-
- timer_still_needed:
- add_timer(&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer);
out:
spin_unlock_bh(&sta->lock);
}
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 588005c..a910bf1 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -662,6 +662,14 @@ struct ieee80211_local {
bool suspended;
/*
+ * Resuming is true while suspended, but when we're reprogramming the
+ * hardware -- at that time it's allowed to use ieee80211_queue_work()
+ * again even though some other parts of the stack are still suspended
+ * and we still drop received frames to avoid waking the stack.
+ */
+ bool resuming;
+
+ /*
* quiescing is true during the suspend process _only_ to
* ease timer cancelling etc.
*/
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index aeb65b3..e6c08da 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -520,9 +520,9 @@ EXPORT_SYMBOL_GPL(ieee80211_iterate_active_interfaces_atomic);
*/
static bool ieee80211_can_queue_work(struct ieee80211_local *local)
{
- if (WARN(local->suspended, "queueing ieee80211 work while "
- "going to suspend\n"))
- return false;
+ if (WARN(local->suspended && !local->resuming,
+ "queueing ieee80211 work while going to suspend\n"))
+ return false;
return true;
}
@@ -1025,13 +1025,9 @@ int ieee80211_reconfig(struct ieee80211_local *local)
struct sta_info *sta;
unsigned long flags;
int res;
- bool from_suspend = local->suspended;
- /*
- * We're going to start the hardware, at that point
- * we are no longer suspended and can RX frames.
- */
- local->suspended = false;
+ if (local->suspended)
+ local->resuming = true;
/* restart hardware */
if (local->open_count) {
@@ -1129,11 +1125,14 @@ int ieee80211_reconfig(struct ieee80211_local *local)
* If this is for hw restart things are still running.
* We may want to change that later, however.
*/
- if (!from_suspend)
+ if (!local->suspended)
return 0;
#ifdef CONFIG_PM
+ /* first set suspended false, then resuming */
local->suspended = false;
+ mb();
+ local->resuming = false;
list_for_each_entry(sdata, &local->interfaces, list) {
switch(sdata->vif.type) {
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index dbeaf29..7cb57ff 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1188,6 +1188,7 @@ static long rfkill_fop_ioctl(struct file *file, unsigned int cmd,
#endif
static const struct file_operations rfkill_fops = {
+ .owner = THIS_MODULE,
.open = rfkill_fop_open,
.read = rfkill_fop_read,
.write = rfkill_fop_write,
--
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: icmp redirects problem
From: Jarek Poplawski @ 2009-11-23 21:58 UTC (permalink / raw)
To: Alex Samad; +Cc: netdev
In-Reply-To: <20091123043124.GA14795@samad.com.au>
Alex Samad wrote, On 11/23/2009 05:31 AM:
> Hi
Hi
>
>
> I seem to be having problems with icmp redirects
> I have
...
>
> net.ipv4.conf.all.accept_redirects = 0
> net.ipv4.conf.all.secure_redirects = 1
> (presume all the interface ones are 1)
>
> as my default, the documentation seems to suggest that I don't need the
> former for the later to work ie I can have either one.
...
>
> But for me to get this to work I had to set
>
> net.ipv4.conf.all.accept_redirects = 1
> net.ipv4.conf.all.secure_redirects = 1
>
> to get it to work properly.
>
> My understanding is secure_redirects means that the kernel should listen
> to icmp redirect if the redirect comes from the default gateway as per
> the route table.
>
> laptop gets its ip from dchp server that make 192.168.11.1 the default
> gateway and its 192.168.11.1 that sends out the icmp redirect.
Btw, it seems you should fix your routing (by adding sydrt01's eth0
the second ip or advertising 192.168.11.10 more) to avoid those
redirects.
>
> I had a quick look at the kernel tree for 2.6.31 (which is what I am
> using).
...
> Line 680
> secure_redirects - BOOLEAN
> 681 Accept ICMP redirect messages only for gateways,
> 682 listed in default gateway list.
> 683 secure_redirects for the interface will be enabled if at
> least one of
> 684 conf/{all,interface}/secure_redirects is set to TRUE,
> 685 it will be disabled otherwise
> 686 default TRUE
Very helpful links. So, as you wrote "the documentation seems to suggest"
something, and IMHO even if it doesn't, it's needlessly too concise
considering your "lost time", and I'd suggest you sending a patch to fix
this. (It seems it could "touch" shared_media, as well.)
Thanks,
Jarek P.
^ permalink raw reply
* Re: [Resend][PATCH] Wireless / ath5k: Simplify suspend and resume callbacks
From: John W. Linville @ 2009-11-23 21:33 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: ath5k-devel, linux-wireless, Bob Copeland, LKML, pm list, netdev,
Luis R. Rodriguez
In-Reply-To: <200911212344.24170.rjw@sisk.pl>
On Sat, Nov 21, 2009 at 11:44:24PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rjw@sisk.pl>
> Subject: Wireless / ath5k: Simplify suspend and resume callbacks
>
> Simplify the suspend and resume callbacks of ath5k by converting the
> driver to struct dev_pm_ops and allowing the PCI PM core to do the
> PCI-specific suspend/resume handling.
>
> Tested with Atheros Communications Inc. AR2413 802.11bg NIC (rev 01)
> D-Link CardBus.adapter.
>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
This is already queued for -next.
John
--
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
* Re: pull request: wireless-2.6 2009-11-23
From: David Miller @ 2009-11-23 22:02 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091123214251.GB9045-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Mon, 23 Nov 2009 16:42:52 -0500
> Here are a few more fixes intended for 2.6.32. They are small and
> self-contained and mostly speak for themselves.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
--
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: [net-next-2.6 PATCH] net/ipv4: Move && and || to end of previous line
From: Ilpo Järvinen @ 2009-11-23 22:08 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, william.allen.simpson, Netdev
In-Reply-To: <1259000895.16503.77.camel@Joe-Laptop.home>
On Mon, 23 Nov 2009, Joe Perches wrote:
> On Sun, 2009-11-22 at 16:31 -0800, David Miller wrote:
> > It should be of the form:
> > if (x &&
> > y)
> >
> > or:
> > if (x && y)
> >
> > Fix patches, rather than complaints, for existing cases where things
> > do not follow this pattern are certainly welcome.
>
> Also collapsed some multiple tabs to single space.
>
> Compiled tested only:
>
> net/ipv4/inet_lro.c | 36 ++++++++++++++++++------------------
> net/ipv4/ip_output.c | 6 ++++--
> net/ipv4/ipconfig.c | 13 ++++++-------
> net/ipv4/route.c | 19 ++++++++++---------
> net/ipv4/tcp_htcp.c | 10 +++++-----
> net/ipv4/tcp_input.c | 4 ++--
> net/ipv4/tcp_lp.c | 4 ++--
> net/ipv4/tcp_output.c | 4 ++--
> net/ipv4/tcp_probe.c | 4 ++--
> net/ipv4/tcp_veno.c | 5 ++---
> net/ipv4/tcp_yeah.c | 4 ++--
> net/ipv4/udp.c | 36 ++++++++++++++++++------------------
> 12 files changed, 73 insertions(+), 72 deletions(-)
>
> diff --git a/net/ipv4/inet_lro.c b/net/ipv4/inet_lro.c
> index 6a667da..47038cb 100644
> --- a/net/ipv4/inet_lro.c
> +++ b/net/ipv4/inet_lro.c
> @@ -64,15 +64,15 @@ static int lro_tcp_ip_check(struct iphdr *iph, struct tcphdr *tcph,
> if (iph->ihl != IPH_LEN_WO_OPTIONS)
> return -1;
>
> - if (tcph->cwr || tcph->ece || tcph->urg || !tcph->ack
> - || tcph->rst || tcph->syn || tcph->fin)
> + if (tcph->cwr || tcph->ece || tcph->urg || !tcph->ack ||
> + tcph->rst || tcph->syn || tcph->fin)
> return -1;
>
> if (INET_ECN_is_ce(ipv4_get_dsfield(iph)))
> return -1;
>
> - if (tcph->doff != TCPH_LEN_WO_OPTIONS
> - && tcph->doff != TCPH_LEN_W_TIMESTAMP)
> + if (tcph->doff != TCPH_LEN_WO_OPTIONS &&
> + tcph->doff != TCPH_LEN_W_TIMESTAMP)
> return -1;
>
> /* check tcp options (only timestamp allowed) */
> @@ -262,10 +262,10 @@ static int lro_check_tcp_conn(struct net_lro_desc *lro_desc,
> struct iphdr *iph,
> struct tcphdr *tcph)
> {
> - if ((lro_desc->iph->saddr != iph->saddr)
> - || (lro_desc->iph->daddr != iph->daddr)
> - || (lro_desc->tcph->source != tcph->source)
> - || (lro_desc->tcph->dest != tcph->dest))
> + if ((lro_desc->iph->saddr != iph->saddr) ||
> + (lro_desc->iph->daddr != iph->daddr) ||
> + (lro_desc->tcph->source != tcph->source) ||
> + (lro_desc->tcph->dest != tcph->dest))
> return -1;
> return 0;
> }
> @@ -339,9 +339,9 @@ static int __lro_proc_skb(struct net_lro_mgr *lro_mgr, struct sk_buff *skb,
> u64 flags;
> int vlan_hdr_len = 0;
>
> - if (!lro_mgr->get_skb_header
> - || lro_mgr->get_skb_header(skb, (void *)&iph, (void *)&tcph,
> - &flags, priv))
> + if (!lro_mgr->get_skb_header ||
> + lro_mgr->get_skb_header(skb, (void *)&iph, (void *)&tcph,
> + &flags, priv))
> goto out;
>
> if (!(flags & LRO_IPV4) || !(flags & LRO_TCP))
> @@ -351,8 +351,8 @@ static int __lro_proc_skb(struct net_lro_mgr *lro_mgr, struct sk_buff *skb,
> if (!lro_desc)
> goto out;
>
> - if ((skb->protocol == htons(ETH_P_8021Q))
> - && !(lro_mgr->features & LRO_F_EXTRACT_VLAN_ID))
> + if ((skb->protocol == htons(ETH_P_8021Q)) &&
> + !(lro_mgr->features & LRO_F_EXTRACT_VLAN_ID))
> vlan_hdr_len = VLAN_HLEN;
>
> if (!lro_desc->active) { /* start new lro session */
> @@ -446,9 +446,9 @@ static struct sk_buff *__lro_proc_segment(struct net_lro_mgr *lro_mgr,
> int hdr_len = LRO_MAX_PG_HLEN;
> int vlan_hdr_len = 0;
>
> - if (!lro_mgr->get_frag_header
> - || lro_mgr->get_frag_header(frags, (void *)&mac_hdr, (void *)&iph,
> - (void *)&tcph, &flags, priv)) {
> + if (!lro_mgr->get_frag_header ||
> + lro_mgr->get_frag_header(frags, (void *)&mac_hdr, (void *)&iph,
> + (void *)&tcph, &flags, priv)) {
> mac_hdr = page_address(frags->page) + frags->page_offset;
> goto out1;
> }
> @@ -472,8 +472,8 @@ static struct sk_buff *__lro_proc_segment(struct net_lro_mgr *lro_mgr,
> if (!skb)
> goto out;
>
> - if ((skb->protocol == htons(ETH_P_8021Q))
> - && !(lro_mgr->features & LRO_F_EXTRACT_VLAN_ID))
> + if ((skb->protocol == htons(ETH_P_8021Q)) &&
> + !(lro_mgr->features & LRO_F_EXTRACT_VLAN_ID))
> vlan_hdr_len = VLAN_HLEN;
>
> iph = (void *)(skb->data + vlan_hdr_len);
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 322b408..b78e615 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -264,9 +264,11 @@ int ip_mc_output(struct sk_buff *skb)
>
> This check is duplicated in ip_mr_input at the moment.
> */
> - && ((rt->rt_flags&RTCF_LOCAL) || !(IPCB(skb)->flags&IPSKB_FORWARDED))
> + &&
> + ((rt->rt_flags & RTCF_LOCAL) ||
> + !(IPCB(skb)->flags & IPSKB_FORWARDED))
> #endif
> - ) {
> + ) {
Certainly better in general already but there is still some work to be
done here as now you have an && only line. I guess it mostly has to do
with comments but #if... blahblahs could be another type of failure (in
automation like this).
--
i.
^ permalink raw reply
* Re: macvlan: fix gso_max_size setting
From: Patrick McHardy @ 2009-11-23 22:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091123.101013.40629093.davem@davemloft.net>
David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 23 Nov 2009 11:33:06 +0100
>
>
>> Fix macvlan gso_max_size setting. Based on net-next-2.6.git.
>
> Pretty serious defect, maybe net-2.6 material?
Sure, please take it in net-2.6.
>
> If someone hits this, it's going to trigger something awful.
Don't drivers simply drop the packet? Otherwise I think you
should be able to trigger the same problem using the TC mirred
action.
^ permalink raw reply
* Re: [Resend][PATCH] Wireless / ath5k: Simplify suspend and resume callbacks
From: Rafael J. Wysocki @ 2009-11-23 22:12 UTC (permalink / raw)
To: John W. Linville
Cc: ath5k-devel, linux-wireless, Bob Copeland, LKML, pm list, netdev,
Luis R. Rodriguez
In-Reply-To: <20091123213353.GA9045@tuxdriver.com>
On Monday 23 November 2009, John W. Linville wrote:
> On Sat, Nov 21, 2009 at 11:44:24PM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> > Subject: Wireless / ath5k: Simplify suspend and resume callbacks
> >
> > Simplify the suspend and resume callbacks of ath5k by converting the
> > driver to struct dev_pm_ops and allowing the PCI PM core to do the
> > PCI-specific suspend/resume handling.
> >
> > Tested with Atheros Communications Inc. AR2413 802.11bg NIC (rev 01)
> > D-Link CardBus.adapter.
> >
> > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
>
> This is already queued for -next.
Thanks!
Rafael
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net/ipv4: Move && and || to end of previous line
From: Joe Perches @ 2009-11-23 22:14 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Miller, william.allen.simpson, Netdev
In-Reply-To: <alpine.DEB.2.00.0911240004530.19211@melkinpaasi.cs.helsinki.fi>
On Tue, 2009-11-24 at 00:08 +0200, Ilpo Järvinen wrote:
> Certainly better in general already but there is still some work to be
> done here as now you have an && only line. I guess it mostly has to do
> with comments but #if... blahblahs could be another type of failure (in
> automation like this).
The current form is
if (foo
#ifdef BAR
&& bar
#endif
)
Another option could be:
#ifdef BAR
if (foo && bar)
#else
if (foo)
#endif
In any case, it won't be pretty.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net/ipv[46]/netfilter: Move && and || to end of previous line
From: Patrick McHardy @ 2009-11-23 22:20 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, netdev, netfilter-devel
In-Reply-To: <1259005771.16503.90.camel@Joe-Laptop.home>
Joe Perches wrote:
> On Sun, 2009-11-22 at 16:31 -0800, David Miller wrote:
>
>> It should be of the form:
>> if (x &&
>> y)
>>
>> or:
>> if (x && y)
>>
>> Fix patches, rather than complaints, for existing cases where things
>> do not follow this pattern are certainly welcome.
>>
>
> Compile tested only.
>
Applied, thanks for cleaning this up.
^ permalink raw reply
* Re: macvlan: fix gso_max_size setting
From: David Miller @ 2009-11-23 22:22 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <4B0B087B.3020000@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Mon, 23 Nov 2009 23:11:07 +0100
> David Miller wrote:
>> From: Patrick McHardy <kaber@trash.net>
>> Date: Mon, 23 Nov 2009 11:33:06 +0100
>>
>>
>>> Fix macvlan gso_max_size setting. Based on net-next-2.6.git.
>>
>> Pretty serious defect, maybe net-2.6 material?
>
> Sure, please take it in net-2.6.
Done, thanks.
>>
>> If someone hits this, it's going to trigger something awful.
>
> Don't drivers simply drop the packet? Otherwise I think you
> should be able to trigger the same problem using the TC mirred
> action.
I see nothing in the IXGBE driver's transmit code paths which guard
against this.
^ permalink raw reply
* Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
From: Rusty Russell @ 2009-11-23 22:24 UTC (permalink / raw)
To: Shirley Ma
Cc: Eric Dumazet, Michael S. Tsirkin, Avi Kivity, netdev, kvm,
linux-kernel, Hollis Blanchard
In-Reply-To: <1258992421.5022.19.camel@localhost.localdomain>
On Tue, 24 Nov 2009 02:37:01 am Shirley Ma wrote:
> > > + skb = (struct sk_buff *)buf;
> > This cast is unnecessary, but a comment would be nice:
>
> Without this cast there is a compile warning.
Hi Shirley,
Looks like buf is a void *, so no cast should be necessary. But I could
be reading the patch wrong.
> > However, I question whether making it 16 byte is the right thing: the
> > ethernet header is 14 bytes long, so don't we want 8 bytes of padding?
>
> Because in QEMU it requires 10 bytes header in a separately, so one page
> is used to share between virtio_net_hdr header which is 10 bytes head
> and rest of data. So I put 6 bytes offset here between two buffers. I
> didn't look at the reason why a seperate buf is used for virtio_net_hdr
> in QEMU.
It's a qemu bug. It insists the header be an element in the scatterlist by
itself. Unfortunately we have to accommodate it.
However, there's no reason for the merged rxbuf and big packet layout to be
the same: for the big packet case you should layout as follows:
#define BIG_PACKET_PAD (NET_SKB_PAD - sizeof(struct virtio_net_hdr) + NET_IP_ALIGN)
struct big_packet_page {
struct virtio_net_hdr hdr;
char pad[BIG_PACKET_PAD];
/* Actual packet data starts here */
unsigned char data[PAGE_SIZE - BIG_PACKET_PAD - sizeof(struct virtio_net_hdr)];
};
Then use this type as the template for registering the sg list for the
big packet case.
> > I think you can move the memcpy outside the if, like so:
> >
> > memcpy(&hdr, p, hdr_len);
>
> I didn't move it out, because num_buf = hdr->mhdr.num_buffers;
Yes, that has to stay inside, but the memcpy can move out. It's just a bit
neater to have more common code.
Thanks,
Rusty.
^ permalink raw reply
* Re: [Bugme-new] [Bug 14677] New: multicast client application does not receive packets
From: Andrew Morton @ 2009-11-23 22:31 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, berndp
In-Reply-To: <bug-14677-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 23 Nov 2009 22:00:45 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14677
>
> Summary: multicast client application does not receive packets
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.31.4-2.6.32-rc8
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: berndp@optonline.net
> Regression: Yes
>
>
> When upgrading the kernel from 2.6.29.1 to 2.6.31.4, we discovered that packets
> no longer get delivered to an application that is subscribing to the multicast
> data.
>
> We verified that multicast support was compiled into the kernel
> (CONFIG_IP_MULTICAST). A dump on the interface with tcpdump shows the multicast
> packets arriving on the network interface. However, they do not get delivered
> to the application.
>
> /proc/net/igmp clearly showed that we were subscribed to the relevant multicast
> groups, and netstat showed that the application was listening.
>
> Upgrading to 2.6.32-rc8 did not fix the problem, but downgrading to 2.6.29.1
> did.
>
> This problem was seen on two different supermicro systems: one with a single
> (4-core) i7 940 Intel CPU, and another one with dual X5570 Xeon CPUS. In both
> cases the interface was on a quad-port NIC card 82571EB gigabit ethernet
> controller, rev 06.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net/ipv4: Move && and || to end of previous line
From: Ilpo Järvinen @ 2009-11-23 22:32 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, william.allen.simpson, Netdev
In-Reply-To: <1259014446.16503.116.camel@Joe-Laptop.home>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1051 bytes --]
On Mon, 23 Nov 2009, Joe Perches wrote:
> On Tue, 2009-11-24 at 00:08 +0200, Ilpo Järvinen wrote:
> > Certainly better in general already but there is still some work to be
> > done here as now you have an && only line. I guess it mostly has to do
> > with comments but #if... blahblahs could be another type of failure (in
> > automation like this).
>
> The current form is
>
> if (foo
> #ifdef BAR
> && bar
> #endif
> )
>
> Another option could be:
>
> #ifdef BAR
> if (foo && bar)
> #else
> if (foo)
> #endif
>
> In any case, it won't be pretty.
But wouldn't your automation produce:
#ifdef BAR
if (foo
#endif
&&
bar
? Like it did for the case where there was a comment between.
As I didn't go through the whole patch I don't know if there were in fact
any #if things that got made into that kind of construct or not (just
mentioned it that such places might also be affected incorrectly by your
automation). I only noticed one of such after comment (ie., && on
otherwise empty line) and hit reply.
--
i.
^ permalink raw reply
* Re: macvlan: fix gso_max_size setting
From: Patrick McHardy @ 2009-11-23 22:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Herbert Xu
In-Reply-To: <20091123.142207.14190542.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 23 Nov 2009 23:11:07 +0100
>
>
>> David Miller wrote:
>>
>>> From: Patrick McHardy <kaber@trash.net>
>>> Date: Mon, 23 Nov 2009 11:33:06 +0100
>>>
>>>
>>>
>>>> Fix macvlan gso_max_size setting. Based on net-next-2.6.git.
>>>>
>>> Pretty serious defect, maybe net-2.6 material?
>>>
>> Sure, please take it in net-2.6.
>>
>
> Done, thanks.
>
>
>>> If someone hits this, it's going to trigger something awful.
>>>
>> Don't drivers simply drop the packet? Otherwise I think you
>> should be able to trigger the same problem using the TC mirred
>> action.
>>
>
> I see nothing in the IXGBE driver's transmit code paths which guard
> against this.
>
Perhaps we should simply fall back to software in that case.
Compile tested only.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 685 bytes --]
net: fall back to software segmentation if skb length exceeds dev->gso_max_size
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index ffc3106..edd1e2b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1943,7 +1943,8 @@ static inline int netif_needs_gso(struct net_device *dev, struct sk_buff *skb)
{
return skb_is_gso(skb) &&
(!skb_gso_ok(skb, dev->features) ||
- unlikely(skb->ip_summed != CHECKSUM_PARTIAL));
+ unlikely(skb->ip_summed != CHECKSUM_PARTIAL) ||
+ unlikely(skb->len > dev->gso_max_size));
}
static inline void netif_set_gso_max_size(struct net_device *dev,
^ permalink raw reply related
* Re: ixgbe question
From: Robert Olsson @ 2009-11-23 22:14 UTC (permalink / raw)
To: David Miller; +Cc: robert, eric.dumazet, hawk, peter.p.waskiewicz.jr, netdev
In-Reply-To: <20091123.132823.162855593.davem@davemloft.net>
David Miller writes:
> It seem very obvious to me that, for whatever reason, the MSI-X vectors
> are only being sent to cpu 1 on Eric's system.
>
> I also suspect, as a result, that it has nothing to do with the IXGBE
> driver but rather is some IRQ controller programming or some bug or
> limitation in the IRQ affinity mask handling in the kernel.
Probably so yes. I'll guess Eric will dig into this.
Cheers
--ro
^ permalink raw reply
* Diagnostic Monitoring Interface Monitoring (DOM) PATCH 0/5 for net-next-2.6
From: Robert Olsson @ 2009-11-23 22:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, robert
Here are basic support to bring Diagnostic Monitoring Interface Monitoring (DOM)
to Linux this is more or less mandatory when building optical networks.
Optical modules as SFP, SFP+, XFP, GBIC etc holds transceiver and link diagnostic
data needed to monitor and troubleshoot optical links, Talks to networks cards
via the I2C-bus (DOM lives in memory page 0xA2).
In essential:
Usage example: ethtool -D eth5
Ext-Calbr: Avr RX-Power: Alarm & Warn: RX_LOS: Wavelength: 1310 nm
Alarms, warnings in beginning of line, Ie. AH = Alarm High, WL == Warn Low etc
Temp: 35.9 C Thresh: Lo: -12.0/-8.0 Hi: 103.0/110.0 C
Vcc: 3.33 V Thresh: Lo: 3.0/3.0 Hi: 3.7/4.0 V
Tx-Bias: 13.4 mA Thresh: Lo: 2.0/4.0 Hi: 70.0/84.0 mA
ALWL TX-pwr: -5.9 dBm ( 0.26 mW) Thresh: Lo: -4.0/-2.0 Hi: 7.0/8.2 dBm
AHWH RX-pwr: -5.0 dBm ( 0.31 mW) Thresh: Lo: -35.2/-28.0 Hi: -8.2/-6.0 dBm
Read more in Documentation/networking/dom.txt
It's tested with the igb driver, there is also a patch for the ixgbe driver but I
haven't any SFP+ with DOM support yet.
There are room for improvements an clean-ups.
Cheers
--ro
^ 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