* Re: [net-next 6/10] bnx2x: Update vlan_features
From: Or Gerlitz @ 2009-07-23 11:14 UTC (permalink / raw)
To: Patrick McHardy; +Cc: eilong, David Miller, netdev, Jay Vosburgh, Eric Dumazet
In-Reply-To: <4A683F83.1060701@trash.net>
Patrick McHardy wrote:
> vlan_features doesn't need to be updated, the resulting dev->features
> of the VLAN device is computed as the intersection of dev->features
> and dev->vlan_features.
I'm not sure to follow, do you claim that the patches to bnx2x and bonding aren't needed to make vlans set on top of such devices to support these features?
For example, on two 2.6.30 systems I have here, where one uses Intel/igb and the second uses Broadcom/tg3 I can see that vlan devices on top of igb have features while those on top of tg3 has none
2.6.30/igb/8021q
# cat /sys/class/net/eth1/features
0x114bb3
# cat /sys/class/net/eth1.4004/features
0x110803
2.6.30/tg3/8021q
# cat /sys/class/net/eth1/features
0x109a3
# cat /sys/class/net/eth1.4001/features
0x0
Or.
^ permalink raw reply
* [PATCH v3 RESEND] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Mark Ware @ 2009-07-23 11:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxppc-dev
In-Reply-To: <20090722.094059.113003489.davem@davemloft.net>
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when using the mdio-ofgpio driver.
This patch replicates similar changes made to the fs_enet mii-bitbang drivers. It has been tested on a custom mpc8280 based board using an NFS mounted root.
Signed-off-by: Mark Ware <mware@elphinstone.net>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
The only changes in v3 are to the commit message.
Resent due to patch mangling by mail client.
This time for sure...
drivers/net/phy/mdio-gpio.c | 77 ++++++++++++++++++++-----------------------
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include <linux/of_gpio.h>
+#include <linux/of_mdio.h>
#include <linux/of_platform.h>
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data *pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
new_bus->name = "GPIO Bitbanged MDIO",
- ret = -ENODEV;
-
new_bus->phy_mask = pdata->phy_mask;
new_bus->irq = pdata->irqs;
new_bus->parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdio);
out_free_mdc:
gpio_free(bitbang->mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus->priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdc);
gpio_free(bitbang->mdio);
+ gpio_free(bitbang->mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ new_bus = mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(&pdev->dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, "reg", &len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata->phy_mask &= ~(1 << id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata->irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct mdio_gpio_platform_data *pdata;
+ struct mii_bus *new_bus;
int ret;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
@@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
ret = of_get_gpio(ofdev->node, 1);
if (ret < 0)
- goto out_free;
+ goto out_free;
pdata->mdio = ret;
- while ((np = of_get_next_child(ofdev->node, np)))
- if (!strcmp(np->type, "ethernet-phy"))
- add_phy(pdata, np);
+ new_bus = mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ if (!new_bus)
+ return -ENODEV;
- return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ ret = of_mdiobus_register(new_bus, ofdev->node);
+ if (ret)
+ mdio_gpio_bus_deinit(&ofdev->dev);
+
+ return ret;
out_free:
kfree(pdata);
--
1.5.6.5
^ permalink raw reply related
* Re: [net-next 6/10] bnx2x: Update vlan_features
From: Patrick McHardy @ 2009-07-23 11:21 UTC (permalink / raw)
To: Or Gerlitz; +Cc: eilong, David Miller, netdev, Jay Vosburgh, Eric Dumazet
In-Reply-To: <4A68462C.1080709@Voltaire.com>
Or Gerlitz wrote:
> Patrick McHardy wrote:
>> vlan_features doesn't need to be updated, the resulting dev->features
>> of the VLAN device is computed as the intersection of dev->features
>> and dev->vlan_features.
>
> I'm not sure to follow, do you claim that the patches to bnx2x and bonding aren't needed to make vlans set on top of such devices to support these features?
In case of bnx2x, its enough to initialize dev->vlan_features once
to a static set and update only dev->features when appropriately.
vlan_features is meant to contain the hardware supported features
for VLANs, which are not necessarily active.
In case of bonding, its necessary to update vlan_features so it
contains the intersection of all underlying devices. But a
change will only take effect for existing VLANs (f.i. when
enslaving a new device) if you call netdev_features_change().
^ permalink raw reply
* Re: [net-next 6/10] bnx2x: Update vlan_features
From: Or Gerlitz @ 2009-07-23 11:30 UTC (permalink / raw)
To: Patrick McHardy, Jay Vosburgh; +Cc: eilong, David Miller, netdev, Eric Dumazet
In-Reply-To: <4A68479F.1000807@trash.net>
okay, understood. So the patches to bnx2 and bnx2x can/should be made
simpler and the patch to bonding has to change and include a call to
netdev_features_change(), Jay, I assume you prefer to do that, if not,
let me know and I will.
Or.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bnx2: Update vlan_features
From: Eric Dumazet @ 2009-07-23 12:01 UTC (permalink / raw)
To: Or Gerlitz
Cc: Patrick McHardy, Jay Vosburgh, David Miller, netdev,
Eilon Greenstein, Michael Chan
In-Reply-To: <4A681F63.7060001@gmail.com>
Eric Dumazet a écrit :
> Or Gerlitz a écrit :
>> Eric Dumazet wrote:
>>> Jay Vosburgh a écrit :
>>>> Propogate the vlan_features of the slave devices to the bonding
>>>> master device, using the same logic as for regular features.
>>> Seems pretty cool, but I could not test it on my dev machine, since
>>> tg3 and bnx2 drivers dont advertize yet vlan_features
>> The bnx2x maintainer posted yesterday a patch that does so, I assume a
>> similar patch could work for at least one of tg3 or bnx2. I copied both
>> maintainers on this email, in the hope they can come up with a patch.
>>
>
> Here is the bnx2 patch I cooked to test this vlan_features propagation on bonding.
>
> Everything fine so far !
>
> # cat /proc/net/bonding/bond0
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
>
> Bonding Mode: fault-tolerance (active-backup)
> Primary Slave: None
> Currently Active Slave: eth1
> MII Status: up
> MII Polling Interval (ms): 100
> Up Delay (ms): 0
> Down Delay (ms): 0
>
> Slave Interface: eth1 (bnx2 driver)
> MII Status: up
> Link Failure Count: 2
> Permanent HW addr: 00:1e:0b:ec:d3:d2
>
> Slave Interface: eth2 (tg3 driver)
> MII Status: up
> Link Failure Count: 0
> Permanent HW addr: 00:1e:0b:92:78:50
>
>
> # ethtool -k bond0
> Offload parameters for bond0:
> Cannot get device rx csum settings: Operation not supported
> rx-checksumming: off
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: on
> udp-fragmentation-offload: off
> generic-segmentation-offload: off
> generic-receive-offload: off
> large-receive-offload: off
>
> # ip link add link bond0 vlan.103 type vlan id 103
> # ethtool -k vlan.103
> Offload parameters for vlan.103:
> rx-checksumming: off
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: on
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: off
> large-receive-offload: off
>
>
> Thanks Or & Jay
>
Updated to take into account Patrick feedback : We dont need to
change vlan_features in bnx2_set_tso()
Quoting Patrick from another thread :
"vlan_features doesn't need to be updated, the resulting dev->features
of the VLAN device is computed as the intersection of dev->features
and dev->vlan_features."
[PATCH net-next-2.6] bnx2: Update vlan_features
In order to get full use of some advanced features of BNX2, we now need to
fill dev->vlan_features.
Patch successfully tested with vlan devices built on top of bonding.
(bond0 : one bnx2 slave, one tg3 slave (not yet vlan_features enabled)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/bnx2.c | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index b70cc99..cec1b17 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -8023,6 +8023,13 @@ static const struct net_device_ops bnx2_netdev_ops = {
#endif
};
+static void inline vlan_features_add(struct net_device *dev, unsigned long flags)
+{
+#ifdef BCM_VLAN
+ dev->vlan_features |= flags;
+#endif
+}
+
static int __devinit
bnx2_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
@@ -8064,16 +8071,20 @@ bnx2_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
memcpy(dev->perm_addr, bp->mac_addr, 6);
dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ vlan_features_add(dev, NETIF_F_IP_CSUM | NETIF_F_SG);
+ if (CHIP_NUM(bp) == CHIP_NUM_5709) {
dev->features |= NETIF_F_IPV6_CSUM;
-
+ vlan_features_add(dev, NETIF_F_IPV6_CSUM);
+ }
#ifdef BCM_VLAN
dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
#endif
dev->features |= NETIF_F_TSO | NETIF_F_TSO_ECN;
- if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ vlan_features_add(dev, NETIF_F_TSO | NETIF_F_TSO_ECN);
+ if (CHIP_NUM(bp) == CHIP_NUM_5709) {
dev->features |= NETIF_F_TSO6;
-
+ vlan_features_add(dev, NETIF_F_TSO6);
+ }
if ((rc = register_netdev(dev))) {
dev_err(&pdev->dev, "Cannot register net device\n");
goto error;
^ permalink raw reply related
* netfilter -stable 00/08: netfilter -stable fixes
From: Patrick McHardy @ 2009-07-23 14:15 UTC (permalink / raw)
To: stable; +Cc: netdev, Patrick McHardy, netfilter-devel
Following are couple of netfilter fixes for -stable, fixing
- various races in nf_conntrack introduced by the conversion to use
RCU for the conntrack hash and follow-up patch to use SLAB_DESTROY_BY_RCU
for the conntrack slab
- direct userspace memory access in the nf_log /proc handler
- a missing initialization in the quota match, possibly causing malfunction
on SMP
- an incorrect comparison in the rateest match
- unacknowledged data detection in TCP conntrack in combination with
NAT helpers reducing the packet size
Please apply, thanks.
Documentation/RCU/rculist_nulls.txt | 7 +++++-
include/net/netfilter/nf_conntrack.h | 4 +-
net/ipv4/netfilter/nf_nat_helper.c | 17 +++++++++-----
net/netfilter/nf_conntrack_core.c | 36 ++++++++++++++++++++++++++-----
net/netfilter/nf_conntrack_proto_tcp.c | 6 ++--
net/netfilter/nf_log.c | 22 ++++++++++++-------
net/netfilter/xt_quota.c | 1 +
net/netfilter/xt_rateest.c | 2 +-
8 files changed, 68 insertions(+), 27 deletions(-)
Patrick McHardy (8):
netfilter: nf_log: fix sleeping function called from invalid context
netfilter: nf_conntrack: fix confirmation race condition
netfilter: nf_conntrack: fix conntrack lookup race
netfilter: nf_log: fix direct userspace memory access in proc handler
netfilter: xt_quota: fix incomplete initialization
netfilter: xt_rateest: fix comparison with self
netfilter: tcp conntrack: fix unacknowledged data detection with NAT
netfilter: nf_conntrack: nf_conntrack_alloc() fixes
^ permalink raw reply
* netfilter -stable 01/08: nf_log: fix sleeping function called from invalid context
From: Patrick McHardy @ 2009-07-23 14:15 UTC (permalink / raw)
To: stable; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20090723141523.19029.89290.sendpatchset@x2.localnet>
commit c45f59bca9d15e911636f9083035f6f847cff125
Author: Patrick McHardy <kaber@trash.net>
Date: Fri Jul 3 10:31:15 2009 +0200
netfilter: nf_log: fix sleeping function called from invalid context
Upstream commit 266d07cb1:
Fix regression introduced by 17625274 "netfilter: sysctl support of
logger choice":
BUG: sleeping function called from invalid context at /mnt/s390test/linux-2.6-tip/arch/s390/include/as
in_atomic(): 1, irqs_disabled(): 0, pid: 3245, name: sysctl
CPU: 1 Not tainted 2.6.30-rc8-tipjun10-02053-g39ae214 #1
Process sysctl (pid: 3245, task: 000000007f675da0, ksp: 000000007eb17cf0)
0000000000000000 000000007eb17be8 0000000000000002 0000000000000000
000000007eb17c88 000000007eb17c00 000000007eb17c00 0000000000048156
00000000003e2de8 000000007f676118 000000007eb17f10 0000000000000000
0000000000000000 000000007eb17be8 000000000000000d 000000007eb17c58
00000000003e2050 000000000001635c 000000007eb17be8 000000007eb17c30
Call Trace:
(Ý<00000000000162e6>¨ show_trace+0x13a/0x148)
Ý<00000000000349ea>¨ __might_sleep+0x13a/0x164
Ý<0000000000050300>¨ proc_dostring+0x134/0x22c
Ý<0000000000312b70>¨ nf_log_proc_dostring+0xfc/0x188
Ý<0000000000136f5e>¨ proc_sys_call_handler+0xf6/0x118
Ý<0000000000136fda>¨ proc_sys_read+0x26/0x34
Ý<00000000000d6e9c>¨ vfs_read+0xac/0x158
Ý<00000000000d703e>¨ SyS_read+0x56/0x88
Ý<0000000000027f42>¨ sysc_noemu+0x10/0x16
Use the nf_log_mutex instead of RCU to fix this.
Reported-and-tested-by: Maran Pakkirisamy <maranpsamy@in.ibm.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nf_log.c b/net/netfilter/nf_log.c
index beb3731..2fefe14 100644
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@ -248,14 +248,14 @@ static int nf_log_proc_dostring(ctl_table *table, int write, struct file *filp,
rcu_assign_pointer(nf_loggers[tindex], logger);
mutex_unlock(&nf_log_mutex);
} else {
- rcu_read_lock();
- logger = rcu_dereference(nf_loggers[tindex]);
+ mutex_lock(&nf_log_mutex);
+ logger = nf_loggers[tindex];
if (!logger)
table->data = "NONE";
else
table->data = logger->name;
r = proc_dostring(table, write, filp, buffer, lenp, ppos);
- rcu_read_unlock();
+ mutex_unlock(&nf_log_mutex);
}
return r;
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* netfilter -stable 02/08: nf_conntrack: fix confirmation race condition
From: Patrick McHardy @ 2009-07-23 14:15 UTC (permalink / raw)
To: stable; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20090723141523.19029.89290.sendpatchset@x2.localnet>
commit 0293f8bc787be0f6a0ff9dba877c2f87f43dc60f
Author: Patrick McHardy <kaber@trash.net>
Date: Fri Jul 3 10:33:04 2009 +0200
netfilter: nf_conntrack: fix confirmation race condition
Upstream commit 5c8ec910:
New connection tracking entries are inserted into the hash before they
are fully set up, namely the CONFIRMED bit is not set and the timer not
started yet. This can theoretically lead to a race with timer, which
would set the timeout value to a relative value, most likely already in
the past.
Perform hash insertion as the final step to fix this.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 8020db6..c8bd559 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -385,7 +385,6 @@ __nf_conntrack_confirm(struct sk_buff *skb)
/* Remove from unconfirmed list */
hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
- __nf_conntrack_hash_insert(ct, hash, repl_hash);
/* Timer relative to confirmation time, not original
setting time, otherwise we'd get timer wrap in
weird delay cases. */
@@ -393,8 +392,16 @@ __nf_conntrack_confirm(struct sk_buff *skb)
add_timer(&ct->timeout);
atomic_inc(&ct->ct_general.use);
set_bit(IPS_CONFIRMED_BIT, &ct->status);
+
+ /* Since the lookup is lockless, hash insertion must be done after
+ * starting the timer and setting the CONFIRMED bit. The RCU barriers
+ * guarantee that no other CPU can find the conntrack before the above
+ * stores are visible.
+ */
+ __nf_conntrack_hash_insert(ct, hash, repl_hash);
NF_CT_STAT_INC(net, insert);
spin_unlock_bh(&nf_conntrack_lock);
+
help = nfct_help(ct);
if (help && help->helper)
nf_conntrack_event_cache(IPCT_HELPER, ct);
^ permalink raw reply related
* netfilter -stable 04/08: nf_log: fix direct userspace memory access in proc handler
From: Patrick McHardy @ 2009-07-23 14:15 UTC (permalink / raw)
To: stable; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20090723141523.19029.89290.sendpatchset@x2.localnet>
commit b8fe73c51f6edb0efe547765bf47fad382d9fc98
Author: Patrick McHardy <kaber@trash.net>
Date: Fri Jul 3 10:34:28 2009 +0200
netfilter: nf_log: fix direct userspace memory access in proc handler
Upstream commit 24955619.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nf_log.c b/net/netfilter/nf_log.c
index 2fefe14..4e62030 100644
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@ -47,7 +47,6 @@ int nf_log_register(u_int8_t pf, struct nf_logger *logger)
mutex_lock(&nf_log_mutex);
if (pf == NFPROTO_UNSPEC) {
- int i;
for (i = NFPROTO_UNSPEC; i < NFPROTO_NUMPROTO; i++)
list_add_tail(&(logger->list[i]), &(nf_loggers_l[i]));
} else {
@@ -216,7 +215,7 @@ static const struct file_operations nflog_file_ops = {
#endif /* PROC_FS */
#ifdef CONFIG_SYSCTL
-struct ctl_path nf_log_sysctl_path[] = {
+static struct ctl_path nf_log_sysctl_path[] = {
{ .procname = "net", .ctl_name = CTL_NET, },
{ .procname = "netfilter", .ctl_name = NET_NETFILTER, },
{ .procname = "nf_log", .ctl_name = CTL_UNNUMBERED, },
@@ -228,19 +227,26 @@ static struct ctl_table nf_log_sysctl_table[NFPROTO_NUMPROTO+1];
static struct ctl_table_header *nf_log_dir_header;
static int nf_log_proc_dostring(ctl_table *table, int write, struct file *filp,
- void *buffer, size_t *lenp, loff_t *ppos)
+ void __user *buffer, size_t *lenp, loff_t *ppos)
{
const struct nf_logger *logger;
+ char buf[NFLOGGER_NAME_LEN];
+ size_t size = *lenp;
int r = 0;
int tindex = (unsigned long)table->extra1;
if (write) {
- if (!strcmp(buffer, "NONE")) {
+ if (size > sizeof(buf))
+ size = sizeof(buf);
+ if (copy_from_user(buf, buffer, size))
+ return -EFAULT;
+
+ if (!strcmp(buf, "NONE")) {
nf_log_unbind_pf(tindex);
return 0;
}
mutex_lock(&nf_log_mutex);
- logger = __find_logger(tindex, buffer);
+ logger = __find_logger(tindex, buf);
if (logger == NULL) {
mutex_unlock(&nf_log_mutex);
return -ENOENT;
^ permalink raw reply related
* netfilter -stable 03/08: nf_conntrack: fix conntrack lookup race
From: Patrick McHardy @ 2009-07-23 14:15 UTC (permalink / raw)
To: stable; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20090723141523.19029.89290.sendpatchset@x2.localnet>
commit 1c91562def07c7186c2e17fc23efef75fb4dbd14
Author: Patrick McHardy <kaber@trash.net>
Date: Fri Jul 3 10:33:45 2009 +0200
netfilter: nf_conntrack: fix conntrack lookup race
Upstream commit 8d8890b7:
The RCU protected conntrack hash lookup only checks whether the entry
has a refcount of zero to decide whether it is stale. This is not
sufficient, entries are explicitly removed while there is at least
one reference left, possibly more. Explicitly check whether the entry
has been marked as dying to fix this.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index c8bd559..2d3584f 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -295,7 +295,8 @@ begin:
h = __nf_conntrack_find(net, tuple);
if (h) {
ct = nf_ct_tuplehash_to_ctrack(h);
- if (unlikely(!atomic_inc_not_zero(&ct->ct_general.use)))
+ if (unlikely(nf_ct_is_dying(ct) ||
+ !atomic_inc_not_zero(&ct->ct_general.use)))
h = NULL;
else {
if (unlikely(!nf_ct_tuple_equal(tuple, &h->tuple))) {
@@ -474,7 +475,8 @@ static noinline int early_drop(struct net *net, unsigned int hash)
cnt++;
}
- if (ct && unlikely(!atomic_inc_not_zero(&ct->ct_general.use)))
+ if (ct && unlikely(nf_ct_is_dying(ct) ||
+ !atomic_inc_not_zero(&ct->ct_general.use)))
ct = NULL;
if (ct || cnt >= NF_CT_EVICTION_RANGE)
break;
^ permalink raw reply related
* netfilter -stable 05/08: xt_quota: fix incomplete initialization
From: Patrick McHardy @ 2009-07-23 14:15 UTC (permalink / raw)
To: stable; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20090723141523.19029.89290.sendpatchset@x2.localnet>
commit 60cc46b2f32e6829efa4067914da11e4d64f421a
Author: Patrick McHardy <kaber@trash.net>
Date: Fri Jul 3 10:35:12 2009 +0200
netfilter: xt_quota: fix incomplete initialization
Upstream commit 6d62182f:
Commit v2.6.29-rc5-872-gacc738f ("xtables: avoid pointer to self")
forgot to copy the initial quota value supplied by iptables into the
private structure, thus counting from whatever was in the memory
kmalloc returned.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/xt_quota.c b/net/netfilter/xt_quota.c
index 01dd07b..98fc190 100644
--- a/net/netfilter/xt_quota.c
+++ b/net/netfilter/xt_quota.c
@@ -54,6 +54,7 @@ static bool quota_mt_check(const struct xt_mtchk_param *par)
if (q->master == NULL)
return -ENOMEM;
+ q->master->quota = q->quota;
return true;
}
^ permalink raw reply related
* netfilter -stable 06/08: xt_rateest: fix comparison with self
From: Patrick McHardy @ 2009-07-23 14:15 UTC (permalink / raw)
To: stable; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20090723141523.19029.89290.sendpatchset@x2.localnet>
commit 77609e5aca9bc8cd4e9ea960177df1e980b3d040
Author: Patrick McHardy <kaber@trash.net>
Date: Fri Jul 3 10:35:55 2009 +0200
netfilter: xt_rateest: fix comparison with self
Upstream commit 4d900f9df:
As noticed by Török Edwin <edwintorok@gmail.com>:
Compiling the kernel with clang has shown this warning:
net/netfilter/xt_rateest.c:69:16: warning: self-comparison always results in a
constant value
ret &= pps2 == pps2;
^
Looking at the code:
if (info->flags & XT_RATEEST_MATCH_BPS)
ret &= bps1 == bps2;
if (info->flags & XT_RATEEST_MATCH_PPS)
ret &= pps2 == pps2;
Judging from the MATCH_BPS case it seems to be a typo, with the intention of
comparing pps1 with pps2.
http://bugzilla.kernel.org/show_bug.cgi?id=13535
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/xt_rateest.c b/net/netfilter/xt_rateest.c
index 220a1d5..4fc6a91 100644
--- a/net/netfilter/xt_rateest.c
+++ b/net/netfilter/xt_rateest.c
@@ -66,7 +66,7 @@ xt_rateest_mt(const struct sk_buff *skb, const struct xt_match_param *par)
if (info->flags & XT_RATEEST_MATCH_BPS)
ret &= bps1 == bps2;
if (info->flags & XT_RATEEST_MATCH_PPS)
- ret &= pps2 == pps2;
+ ret &= pps1 == pps2;
break;
}
^ permalink raw reply related
* netfilter -stable 07/08: tcp conntrack: fix unacknowledged data detection with NAT
From: Patrick McHardy @ 2009-07-23 14:15 UTC (permalink / raw)
To: stable; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20090723141523.19029.89290.sendpatchset@x2.localnet>
commit e7a42c94e8d0845d10163f6c2695a8342c2ce1cd
Author: Patrick McHardy <kaber@trash.net>
Date: Fri Jul 3 10:37:27 2009 +0200
netfilter: tcp conntrack: fix unacknowledged data detection with NAT
Upstream commit a3a9f79e:
When NAT helpers change the TCP packet size, the highest seen sequence
number needs to be corrected. This is currently only done upwards, when
the packet size is reduced the sequence number is unchanged. This causes
TCP conntrack to falsely detect unacknowledged data and decrease the
timeout.
Fix by updating the highest seen sequence number in both directions after
packet mangling.
Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index 6c3f964..5d9a848 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -255,8 +255,8 @@ static inline bool nf_ct_kill(struct nf_conn *ct)
/* Update TCP window tracking data when NAT mangles the packet */
extern void nf_conntrack_tcp_update(const struct sk_buff *skb,
unsigned int dataoff,
- struct nf_conn *ct,
- int dir);
+ struct nf_conn *ct, int dir,
+ s16 offset);
/* Fake conntrack entry for untracked connections */
extern struct nf_conn nf_conntrack_untracked;
diff --git a/net/ipv4/netfilter/nf_nat_helper.c b/net/ipv4/netfilter/nf_nat_helper.c
index cf7a42b..05ede41 100644
--- a/net/ipv4/netfilter/nf_nat_helper.c
+++ b/net/ipv4/netfilter/nf_nat_helper.c
@@ -191,7 +191,8 @@ nf_nat_mangle_tcp_packet(struct sk_buff *skb,
ct, ctinfo);
/* Tell TCP window tracking about seq change */
nf_conntrack_tcp_update(skb, ip_hdrlen(skb),
- ct, CTINFO2DIR(ctinfo));
+ ct, CTINFO2DIR(ctinfo),
+ (int)rep_len - (int)match_len);
nf_conntrack_event_cache(IPCT_NATSEQADJ, ct);
}
@@ -377,6 +378,7 @@ nf_nat_seq_adjust(struct sk_buff *skb,
struct tcphdr *tcph;
int dir;
__be32 newseq, newack;
+ s16 seqoff, ackoff;
struct nf_conn_nat *nat = nfct_nat(ct);
struct nf_nat_seq *this_way, *other_way;
@@ -390,15 +392,18 @@ nf_nat_seq_adjust(struct sk_buff *skb,
tcph = (void *)skb->data + ip_hdrlen(skb);
if (after(ntohl(tcph->seq), this_way->correction_pos))
- newseq = htonl(ntohl(tcph->seq) + this_way->offset_after);
+ seqoff = this_way->offset_after;
else
- newseq = htonl(ntohl(tcph->seq) + this_way->offset_before);
+ seqoff = this_way->offset_before;
if (after(ntohl(tcph->ack_seq) - other_way->offset_before,
other_way->correction_pos))
- newack = htonl(ntohl(tcph->ack_seq) - other_way->offset_after);
+ ackoff = other_way->offset_after;
else
- newack = htonl(ntohl(tcph->ack_seq) - other_way->offset_before);
+ ackoff = other_way->offset_before;
+
+ newseq = htonl(ntohl(tcph->seq) + seqoff);
+ newack = htonl(ntohl(tcph->ack_seq) - ackoff);
inet_proto_csum_replace4(&tcph->check, skb, tcph->seq, newseq, 0);
inet_proto_csum_replace4(&tcph->check, skb, tcph->ack_seq, newack, 0);
@@ -413,7 +418,7 @@ nf_nat_seq_adjust(struct sk_buff *skb,
if (!nf_nat_sack_adjust(skb, tcph, ct, ctinfo))
return 0;
- nf_conntrack_tcp_update(skb, ip_hdrlen(skb), ct, dir);
+ nf_conntrack_tcp_update(skb, ip_hdrlen(skb), ct, dir, seqoff);
return 1;
}
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 97a6e93..a38bc22 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -706,8 +706,8 @@ static bool tcp_in_window(const struct nf_conn *ct,
/* Caller must linearize skb at tcp header. */
void nf_conntrack_tcp_update(const struct sk_buff *skb,
unsigned int dataoff,
- struct nf_conn *ct,
- int dir)
+ struct nf_conn *ct, int dir,
+ s16 offset)
{
const struct tcphdr *tcph = (const void *)skb->data + dataoff;
const struct ip_ct_tcp_state *sender = &ct->proto.tcp.seen[dir];
@@ -720,7 +720,7 @@ void nf_conntrack_tcp_update(const struct sk_buff *skb,
/*
* We have to worry for the ack in the reply packet only...
*/
- if (after(end, ct->proto.tcp.seen[dir].td_end))
+ if (ct->proto.tcp.seen[dir].td_end + offset == end)
ct->proto.tcp.seen[dir].td_end = end;
ct->proto.tcp.last_end = end;
write_unlock_bh(&tcp_lock);
^ permalink raw reply related
* netfilter -stable 08/08: nf_conntrack: nf_conntrack_alloc() fixes
From: Patrick McHardy @ 2009-07-23 14:15 UTC (permalink / raw)
To: stable; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20090723141523.19029.89290.sendpatchset@x2.localnet>
commit 2b12e9634d9676c55f576195a7f950956179d881
Author: Patrick McHardy <kaber@trash.net>
Date: Thu Jul 23 16:02:18 2009 +0200
netfilter: nf_conntrack: nf_conntrack_alloc() fixes
Upstream commit 941297f4:
When a slab cache uses SLAB_DESTROY_BY_RCU, we must be careful when allocating
objects, since slab allocator could give a freed object still used by lockless
readers.
In particular, nf_conntrack RCU lookups rely on ct->tuplehash[xxx].hnnode.next
being always valid (ie containing a valid 'nulls' value, or a valid pointer to next
object in hash chain.)
kmem_cache_zalloc() setups object with NULL values, but a NULL value is not valid
for ct->tuplehash[xxx].hnnode.next.
Fix is to call kmem_cache_alloc() and do the zeroing ourself.
As spotted by Patrick, we also need to make sure lookup keys are committed to
memory before setting refcount to 1, or a lockless reader could get a reference
on the old version of the object. Its key re-check could then pass the barrier.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt
index 6389dec..d0c017e 100644
--- a/Documentation/RCU/rculist_nulls.txt
+++ b/Documentation/RCU/rculist_nulls.txt
@@ -83,11 +83,12 @@ not detect it missed following items in original chain.
obj = kmem_cache_alloc(...);
lock_chain(); // typically a spin_lock()
obj->key = key;
-atomic_inc(&obj->refcnt);
/*
* we need to make sure obj->key is updated before obj->next
+ * or obj->refcnt
*/
smp_wmb();
+atomic_set(&obj->refcnt, 1);
hlist_add_head_rcu(&obj->obj_node, list);
unlock_chain(); // typically a spin_unlock()
@@ -159,6 +160,10 @@ out:
obj = kmem_cache_alloc(cachep);
lock_chain(); // typically a spin_lock()
obj->key = key;
+/*
+ * changes to obj->key must be visible before refcnt one
+ */
+smp_wmb();
atomic_set(&obj->refcnt, 1);
/*
* insert obj in RCU way (readers might be traversing chain)
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 2d3584f..0d961ee 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -525,22 +525,37 @@ struct nf_conn *nf_conntrack_alloc(struct net *net,
}
}
- ct = kmem_cache_zalloc(nf_conntrack_cachep, gfp);
+ /*
+ * Do not use kmem_cache_zalloc(), as this cache uses
+ * SLAB_DESTROY_BY_RCU.
+ */
+ ct = kmem_cache_alloc(nf_conntrack_cachep, gfp);
if (ct == NULL) {
pr_debug("nf_conntrack_alloc: Can't alloc conntrack.\n");
atomic_dec(&net->ct.count);
return ERR_PTR(-ENOMEM);
}
-
- atomic_set(&ct->ct_general.use, 1);
+ /*
+ * Let ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.next
+ * and ct->tuplehash[IP_CT_DIR_REPLY].hnnode.next unchanged.
+ */
+ memset(&ct->tuplehash[IP_CT_DIR_MAX], 0,
+ sizeof(*ct) - offsetof(struct nf_conn, tuplehash[IP_CT_DIR_MAX]));
ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple = *orig;
+ ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev = NULL;
ct->tuplehash[IP_CT_DIR_REPLY].tuple = *repl;
+ ct->tuplehash[IP_CT_DIR_REPLY].hnnode.pprev = NULL;
/* Don't set timer yet: wait for confirmation */
setup_timer(&ct->timeout, death_by_timeout, (unsigned long)ct);
#ifdef CONFIG_NET_NS
ct->ct_net = net;
#endif
+ /*
+ * changes to lookup keys must be done before setting refcnt to 1
+ */
+ smp_wmb();
+ atomic_set(&ct->ct_general.use, 1);
return ct;
}
EXPORT_SYMBOL_GPL(nf_conntrack_alloc);
^ permalink raw reply related
* Re: [PATCH] USB host CDC Phonet network interface driver
From: Dan Williams @ 2009-07-23 14:34 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: ext Marcel Holtmann, Alan Cox, Oliver Neukum,
netdev@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <200907221407.29275.remi.denis-courmont@nokia.com>
On Wed, 2009-07-22 at 14:07 +0300, Rémi Denis-Courmont wrote:
> On Wednesday 22 July 2009 12:15:34 ext Marcel Holtmann wrote:
> > Hi Alan,
> >
> > > > The AT stuff is really problematic. Look at the hoops ISDN and software
> > > > modem drivers go through to emulate AT commands. I know even of a
> > > > CDC-ACM modem which can't deal with AT commands inline (that's within
> > > > spec). It seems to me we should have a modem API in kernel.
> > >
> > > For devices which don't deal in AT commands probably but for devices
> > > whose firmware provides an AT command interface over serial I would
> > > disagree.
> >
> > I fully agree here. Even if you think you get AT commands under control,
> > you really won't in the end. That standard is so wildly mis-interpreted
> > that it is not even funny anymore.
>
> Possibly. Does anyone known of any "species" bypassing AT commands entirely,
> other than Phonet? as far as GPRS is concerned?
There are any number of devices that expose only one AT port (which of
course gets used by PPP for data) and then a proprietary port. The
proprietary port usually uses a custom USB protocol that can also handle
SMS, status, RSSI, etc while the AT/PPP port is being used by ppp.
So if that's the case for phonet, maybe you just want to provide either
(a) documentation of the setup/status/sms/etc protocols, or (b) a shim
library implementation for them that handles communication with the
device itself.
But IMHO, the call setup stuff is probably better done from userspace.
It's a really hard API to abstract. I guess you could write a netlink
API for it like we have for 802.11, but with GSM/CDMA the standards are
so widely ignored that it's just going to be impossible to get a stable
kernel API for anything like this. The actual logic and higher-level
stuff has gotta be in userspace, while the low-level communication
channel bits (serial, USB, phonet, etc) should live in the kernel.
Dan
^ permalink raw reply
* md5 on listening sockets
From: Martin Djernæs @ 2009-07-23 14:38 UTC (permalink / raw)
To: netdev
Hi,
I've been looking at using the md5 keys on a listening socket as one
means of restricting access to the socket. When I specify an md5 key
(with or without a peer ip address in the option) any tcp connect from
another IP address will be accepted by this connection if the source
IP is not found in the "md5sig->keys4" array.
The question is if this is intentional - and if does anyone know why?
It does not look like this is the best option as md5 keys appear to be
ignored and new connections will be accepted without keys if the peer
is not aware of this. Since a correctly specified peer will always be
expected to provide an md5 key, this does not cause an issue for TCP
sessions where both sides configure a key - only if the client fail to
provide it and the client is an unknown/rogue client from the point of
the server.
In the code in tcp_ipv4.c I do see the following comment which I think
Rick Payne from AYR added:
/*
* RFC2385 MD5 checksumming requires a mapping of
* IP address->MD5 Key.
* We need to maintain these in the sk structure.
*/
But besides the mention of the TCP psudo header (which can/will use
the ip address from the socket) I do not see any mention of this
mapping in the RFC.
This additional "destination ip" (or "peer ip") check cause us to
blindly accept incoming connections without md5 keys on them
Lookup is doing the following:
for (i = 0; i < tp->md5sig_info->entries4; i++) {
if (tp->md5sig_info->keys4[i].addr == addr)
return &tp->md5sig_info->keys4[i].base;
}
return NULL;
When a listener receive a new connection from a sender who is not
using the md5 hash the TCP code will do:
tcp_v4_inbound_md5_hash()
..
hash_expected = tcp_v4_md5_do_lookup(sk, iph->saddr);
hash_location = tcp_parse_md5sig_option(th);
..
/* We've parsed the options - do we have a hash? */
if (!hash_expected && !hash_location)
return 0;
which in turn is causing tcp not to discard this peer:
tcp_v4_do_rcv()
..
if (tcp_v4_inbound_md5_hash(sk, skb))
goto discard;
I have tested this on 2.6.28-13 (stock Ubuntu) and traced the code on
2.6.32-RC4 and both looks like they have the same behavior.
I'm aware of the recently committed fix:
http://marc.info/?l=linux-netdev&m=124785861111892&w=4 by John
Dykstra, but I believe that since this is only on copy this should
make no difference here.
Regards,
Martin Djernaes
^ permalink raw reply
* Re: ixgbe: panic in ixgbe_clean_rx_irq()
From: Jesper Dangaard Brouer @ 2009-07-23 15:21 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: netdev@vger.kernel.org
In-Reply-To: <1248338779.17215.23.camel@localhost.localdomain>
On Thu, 2009-07-23 at 10:46 +0200, Jesper Dangaard Brouer wrote:
> > > Hi Peter,
> > >
> > > Got a panic from the ixgbe driver on my 82599 based NICs, while
> running
> > > two pktgen tests (1500 bytes packets) against the machine.
> > >
> > > Kernel: 2.6.31-rc1-net-2.6-00122-ge594e96 with preemption
>
> Got a new panic. The strange thing its not happening in the same
> place... and the anoying thing is that its hard to reproduce, as I
> have to run pktgen a very long time before it dies.
Got yet another panic... now its in skb_put() in the line
SKB_LINEAR_ASSERT(skb).
I'm going to run a test with a no-preempt kernel over night...
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network developer
Cand. Scient Datalog / MSc.
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
[ 531.614873] ------------[ cut here ]------------
[ 531.628869] kernel BUG at net/core/skbuff.c:1014!
[ 531.643116] invalid opcode: 0000 [#1] PREEMPT SMP
[ 531.657774] last sysfs file: /sys/devices/system/cpu/cpu7/cpufreq/scaling_governor
[ 531.680753] CPU 2
[ 531.686970] Modules linked in: asus_atk0110 ixgbe hwmon mdio r8169
[ 531.705922] Pid: 0, comm: swapper Not tainted 2.6.31-rc1-net-2.6-00122-ge594e96 #8 System Product Name
[ 531.734109] RIP: 0010:[<ffffffff81382538>] [<ffffffff81382538>] skb_put+0x1d/0x89
[ 531.757137] RSP: 0000:ffff8800018b1d90 EFLAGS: 00010286
[ 531.773208] RAX: 0000000000000000 RBX: ffff8800a11b6200 RCX: 000000000000002a
[ 531.794752] RDX: 0000000000000022 RSI: 000000000000002a RDI: ffff8800a11b6200
[ 531.816292] RBP: ffff8800018b1db0 R08: ffff8800a107f400 R09: ffff880080000000
[ 531.837833] R10: ffff8800a107d948 R11: 0100880000000000 R12: ffffc90011a90710
[ 531.859375] R13: ffff8800376430c0 R14: ffff8800bb442580 R15: 0000000040000073
[ 531.880916] FS: 0000000000000000(0000) GS:ffff8800018ae000(0000) knlGS:0000000000000000
[ 531.905458] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 531.922825] CR2: 0000000000607000 CR3: 00000000a9ca7000 CR4: 00000000000006a0
[ 531.944370] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 531.965909] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 531.987452] Process swapper (pid: 0, threadinfo ffff8800beec8000, task ffff8800bee94380)
[ 532.011995] Stack:
[ 532.018162] ffff8800018b1db0 ffffffff8138a699 ffff8800a11b6600 ffffc90011a906e8
[ 532.040107] <0> ffff8800018b1e50 ffffffffa001a677 00000040018b1de0 ffff8800018b1e6c
[ 532.063587] <0> ffff8800bbd47b00 ffff8800be5aa000 ffff8800bd790fa0 ffff8800bd790fa0
[ 532.087770] Call Trace:
[ 532.095243] <IRQ>
[ 532.101724] [<ffffffff8138a699>] ? napi_gro_receive+0x2a/0x2f
[ 532.119359] [<ffffffffa001a677>] ixgbe_clean_rx_irq+0x17f/0x53b [ixgbe]
[ 532.139599] [<ffffffffa001aa81>] ixgbe_clean_rxonly+0x4e/0xd2 [ixgbe]
[ 532.159314] [<ffffffff8138a7b5>] net_rx_action+0xb2/0x234
[ 532.175908] [<ffffffff8103fb35>] __do_softirq+0x10c/0x211
[ 532.192503] [<ffffffff8100cc2c>] call_softirq+0x1c/0x28
[ 532.208577] [<ffffffff8100de84>] do_softirq+0x34/0x72
[ 532.224131] [<ffffffff8103f83f>] irq_exit+0x36/0x85
[ 532.239164] [<ffffffff8100d75f>] do_IRQ+0xa6/0xbd
[ 532.253677] [<ffffffff8100c493>] ret_from_intr+0x0/0xa
[ 532.273123] <EOI>
[ 532.279611] [<ffffffff81012355>] ? mwait_idle+0x89/0x9f
[ 532.295681] [<ffffffff81012348>] ? mwait_idle+0x7c/0x9f
[ 532.311755] [<ffffffff8142c948>] ? atomic_notifier_call_chain+0xf/0x11
[ 532.331737] [<ffffffff8100aedb>] ? cpu_idle+0x4f/0xb3
[ 532.347288] [<ffffffff81424478>] ? start_secondary+0x17f/0x184
[ 532.365185] Code: e8 04 58 0a 00 0f 0b eb fe 48 89 c8 c9 c3 55 89 f1 48 89 e5 48 83 ec 20 4c 8b 87 d0 00 00 00 8b 97 c4 00 00 00 83 7f
64 00 74 04 <0f> 0b eb fe 8d 04 11 01 77 60 89 87 c4 00 00 00 3b 87 c8 00 00
[ 532.425076] RIP [<ffffffff81382538>] skb_put+0x1d/0x89
[ 532.440935] RSP <ffff8800018b1d90>
[ 532.451539] ---[ end trace 2bb373a2a0219cb4 ]---
[ 532.465527] Kernel panic - not syncing: Fatal exception in interrupt
[ 532.484728] Pid: 0, comm: swapper Tainted: G D 2.6.31-rc1-net-2.6-00122-ge594e96 #8
[ 532.510052] Call Trace:
[ 532.517535] <IRQ> [<ffffffff81427c6b>] panic+0xaa/0x155
[ 532.533924] [<ffffffff8103f88c>] ? irq_exit+0x83/0x85
[ 532.549483] [<ffffffff8100c493>] ? ret_from_intr+0x0/0xa
[ 532.565815] [<ffffffff8142b039>] ? oops_end+0x6b/0xba
[ 532.581369] [<ffffffff8142b078>] oops_end+0xaa/0xba
[ 532.596403] [<ffffffff8100f0d1>] die+0x55/0x5e
[ 532.610136] [<ffffffff8142aad9>] do_trap+0x110/0x11f
[ 532.625430] [<ffffffff8100d44f>] do_invalid_op+0x91/0x9a
[ 532.641764] [<ffffffff81382538>] ? skb_put+0x1d/0x89
[ 532.657058] [<ffffffff813b4d2a>] ? ip_forward+0x288/0x2e2
[ 532.673652] [<ffffffff813b36ec>] ? ip_rcv_finish+0x37c/0x396
[ 532.691030] [<ffffffff8100c8c5>] invalid_op+0x15/0x20
[ 532.706582] [<ffffffff81382538>] ? skb_put+0x1d/0x89
[ 532.721876] [<ffffffff8138a699>] ? napi_gro_receive+0x2a/0x2f
[ 532.739518] [<ffffffffa001a677>] ixgbe_clean_rx_irq+0x17f/0x53b [ixgbe]
[ 532.759759] [<ffffffffa001aa81>] ixgbe_clean_rxonly+0x4e/0xd2 [ixgbe]
[ 532.779474] [<ffffffff8138a7b5>] net_rx_action+0xb2/0x234
[ 532.796068] [<ffffffff8103fb35>] __do_softirq+0x10c/0x211
[ 532.812664] [<ffffffff8100cc2c>] call_softirq+0x1c/0x28
[ 532.828738] [<ffffffff8100de84>] do_softirq+0x34/0x72
[ 532.844291] [<ffffffff8103f83f>] irq_exit+0x36/0x85
[ 532.859324] [<ffffffff8100d75f>] do_IRQ+0xa6/0xbd
[ 532.873838] [<ffffffff8100c493>] ret_from_intr+0x0/0xa
[ 532.889651] <EOI> [<ffffffff81012355>] ? mwait_idle+0x89/0x9f
[ 532.907599] [<ffffffff81012348>] ? mwait_idle+0x7c/0x9f
[ 532.923676] [<ffffffff8142c948>] ? atomic_notifier_call_chain+0xf/0x11
[ 532.943658] [<ffffffff8100aedb>] ? cpu_idle+0x4f/0xb3
[ 532.959210] [<ffffffff81424478>] ? start_secondary+0x17f/0x184
^ permalink raw reply
* Re: [net-next-2.6 PATCH][be2net] Add GRO support to the be2net driver. LRO is not supported anymore.
From: David Miller @ 2009-07-23 16:13 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20090723061824.GE7646@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Thu, 23 Jul 2009 11:48:26 +0530
> On 21/07/09 12:36 -0700, David Miller wrote:
>> From: Ajit Khaparde <ajitk@serverengines.com>
>> Date: Tue, 21 Jul 2009 17:37:11 +0530
>>
>> >
>> > This patch removes support for INET_LRO and switches over to GRO.
>> >
>> > Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
>>
>> Applied, thanks a lot for doing this work.
>
> Dave, I just finished a git pull, but don't see the changes.
> What could be the reason?
I don't always push things immediately, sometimes I give it a few days
before pushing to kernel.org so that build failures and objections to
changes can be dealt with more cleanly.
^ permalink raw reply
* Re: accelerated vlan gives pcap tagged packets untagged
From: Malcolm Scott @ 2009-07-23 16:08 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Pierre Ossman, Francois Romieu, netdev
In-Reply-To: <49902E35.6060506@trash.net>
(apologies for reviving an ancient thread, but I've hit this problem myself)
On Mon, 9 Feb 2009, Patrick McHardy wrote:
> Pierre Ossman wrote:
>> I'm having some problems with r8169 and vlans. The basic problem is
>> that pcap on eth1 gives me tagged packets, but in a form where it is
>> impossible to tell it is tagged. This is causing problems for dhcpd:
>>
>> Feb 6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via
>> eth1.2
>> Feb 6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via eth1
>> Feb 6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.2.230 to 00:15:00:08:98:1f
>> via eth1.2
>> Feb 6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.0.128 to 00:15:00:08:98:1f
>> via eth1
>> Feb 6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254) from
>> 00:15:00:08:98:1f via eth1.2
>> Feb 6 20:04:23 asgard dhcpd: DHCPACK on 10.8.2.230 to 00:15:00:08:98:1f
>> via eth1.2
>> Feb 6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254) from
>> 00:15:00:08:98:1f via eth1: wrong network.
>> Feb 6 20:04:23 asgard dhcpd: DHCPNAK on 10.8.2.230 to 00:15:00:08:98:1f
>> via eth1
>>
>> I assume this is because the hardware supports vlans and handles all
>> the tag stripping.
>>
>> (I've confirmed with tcpdump that the packets lack tags when they are
>> presented to userspace)
>>
>> From what I can tell, I cannot fix this without rebuilding the kernel
>> and removing the acceleration support from the r8169 driver. Is there
>> some method I've overlooked?
>>
>> Preferably, I'd like the kernel to expose to pcap what's on the wire
>> (i.e. accelerated vs non-accelerated looks the same from userspace). If
>> that means too much processing to be desirable, the next best thing
>> would be to simply not show tagged packets on the raw interface. The
>> ability to turn vlan acceleration on and off in the latter case would
>> also be desirable for network debugging.
>
> Current kernel version (I think starting with 2.6.28) relay the
> VLAN tag information to userspace through packet sockets. The
> current libpcap release from tcpdump.org (or the one Dave keeps
> in a git tree on kernel.org) supports reconstructing the tags.
So to clarify: as of 2.6.28, an app (e.g. dhcpd) listening on eth0 will by
default see packets from all VLANs with tags removed; if it wishes to do
otherwise, it should query the kernel for the VLAN tag of every packet and
discard those with a tag?
Unless I misunderstand, this seems like absolutely the wrong behaviour:
untagged packets are expected to be treated as from another VLAN just like
any other, and should be kept separate (from userspace's perspective) from
all tagged packets. Prior to 2.6.28 this was indeed the case (on my NICs at
least -- tg3 and others): listening on eth0, one would see the tagged
packets with the tags still in place, so these would be correctly ignored by
apps which were not specifically able to handle tagged packets.
In my case, this is manifesting as the DHCP misbehaviour which Pierre
mentioned. (ISC dhcp3d does not use libpcap, and does not query the packet
socket for the VLAN tag, so it treats every VLAN's packets as for the
default VLAN.)
--
Malcolm Scott
University of Cambridge Computer Laboratory
^ permalink raw reply
* Re: [Bugme-new] [Bug 13760] New: 2.6.30 kernel locks up with pppoe in back trace (regression)
From: David Miller @ 2009-07-23 16:14 UTC (permalink / raw)
To: for.poige+bugzilla.kernel.org; +Cc: akpm, bugzilla-daemon, bugme-daemon, netdev
In-Reply-To: <43d009740907222339n50ebe411ya6453dc5a294b9a0@mail.gmail.com>
From: Igor M Podlesny <for.poige+bugzilla.kernel.org@gmail.com>
Date: Thu, 23 Jul 2009 14:39:29 +0800
> Just repeating the same thing I had written in the Bugzilla: I
> haven't noticed any changes to pppoe during last commits to 2.6.30.
> Why do you think there's a chance that bug(s) would have been fixed?
There were TTY layer changes that have an effect on PPP and
the like.
^ permalink raw reply
* Re: [Bugme-new] [Bug 13760] New: 2.6.30 kernel locks up with pppoe in back trace (regression)
From: David Miller @ 2009-07-23 16:15 UTC (permalink / raw)
To: akpm; +Cc: for.poige+bugzilla.kernel.org, bugzilla-daemon, bugme-daemon,
netdev
In-Reply-To: <20090723000100.d74d6b1c.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Thu, 23 Jul 2009 00:01:00 -0700
> Below is a ppp fix from 2.6.31, but it seems unlikely to fix your problem.
Andrew, that change was reverted, it's a NOP in the current tree.
There were various TTY layer fixups from Alan that could effect
PPP and related drivers.
^ permalink raw reply
* Re: [PATCH] be2net: Adding support for 802.1ad (q-in-q mode)
From: David Miller @ 2009-07-23 16:23 UTC (permalink / raw)
To: kaber; +Cc: sarveshwarb, netdev
In-Reply-To: <4A6837A8.9040208@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 23 Jul 2009 12:12:56 +0200
> Sarveshwar Bandi wrote:
>> On 23/07/09 11:48 +0200, Patrick McHardy wrote:
>>> Sarveshwar Bandi wrote:
>>>> On 23/07/09 11:25 +0200, Patrick McHardy wrote:
>>>>> adapter->vlan_grp will always be the VLAN group associated directly with
>>>>> the device, which is the group for the outer tag, not the inner one. So
>>>>> this can't properly associate packets with the correct VLAN device.
>>>>>
>>>> In this case, vid is the inner vlan id in the packet. This is also the
>>>> vlan id configured by vconfig.
>>>
>>> So where does the outer tag come from then? Please provide an example
>>> how to configure this using Q-in-Q.
>>>
>> The outer vlan is totally transparent to the host. It is used by the NIC
>> to demux packets across multiple pci network functions. Currently the
>> outer vlan tags are configured on the NIC by OEM provided utilities.
>
> I see. A proper changelog entry would have explained that and avoided
> all this confusion. Not that I think using another tool for this is a
> good solution, but no objections from a functional POV.
Using OEM tools makes no sense, there should be something like an
ethtool interface for changing this setting and appropriate changes
to the common userland tools to provide access to them.
I'm not putting this change in until there is common infrastructure
submitted to common tools to control this configuration.
^ permalink raw reply
* Re: [PATCH] be2net: Adding support for 802.1ad (q-in-q mode)
From: Patrick McHardy @ 2009-07-23 16:33 UTC (permalink / raw)
To: David Miller; +Cc: sarveshwarb, netdev
In-Reply-To: <20090723.092301.115261115.davem@davemloft.net>
David Miller wrote:
>> Sarveshwar Bandi wrote:
>>> The outer vlan is totally transparent to the host. It is used by the NIC
>>> to demux packets across multiple pci network functions. Currently the
>>> outer vlan tags are configured on the NIC by OEM provided utilities.
>> I see. A proper changelog entry would have explained that and avoided
>> all this confusion. Not that I think using another tool for this is a
>> good solution, but no objections from a functional POV.
>
> Using OEM tools makes no sense, there should be something like an
> ethtool interface for changing this setting and appropriate changes
> to the common userland tools to provide access to them.
>
> I'm not putting this change in until there is common infrastructure
> submitted to common tools to control this configuration.
Thanks, thats my opinion as well. But I think we should handle
Q-in-Q using the VLAN netlink API and iproute instead of ethtool
for consistency.
^ permalink raw reply
* Re: accelerated vlan gives pcap tagged packets untagged
From: Patrick McHardy @ 2009-07-23 16:35 UTC (permalink / raw)
To: Malcolm Scott; +Cc: Pierre Ossman, Francois Romieu, netdev
In-Reply-To: <alpine.DEB.2.00.0907231656000.12037@callisto.malc.org.uk>
Malcolm Scott wrote:
> (apologies for reviving an ancient thread, but I've hit this problem
> myself)
>
> On Mon, 9 Feb 2009, Patrick McHardy wrote:
>
>> Pierre Ossman wrote:
>>> I'm having some problems with r8169 and vlans. The basic problem is
>>> that pcap on eth1 gives me tagged packets, but in a form where it is
>>> impossible to tell it is tagged. This is causing problems for dhcpd:
>>>
>>> Feb 6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via
>>> eth1.2
>>> Feb 6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via
>>> eth1
>>> Feb 6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.2.230 to
>>> 00:15:00:08:98:1f via eth1.2
>>> Feb 6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.0.128 to
>>> 00:15:00:08:98:1f via eth1
>>> Feb 6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254)
>>> from 00:15:00:08:98:1f via eth1.2
>>> Feb 6 20:04:23 asgard dhcpd: DHCPACK on 10.8.2.230 to
>>> 00:15:00:08:98:1f via eth1.2
>>> Feb 6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254)
>>> from 00:15:00:08:98:1f via eth1: wrong network.
>>> Feb 6 20:04:23 asgard dhcpd: DHCPNAK on 10.8.2.230 to
>>> 00:15:00:08:98:1f via eth1
>>>
>>> I assume this is because the hardware supports vlans and handles all
>>> the tag stripping.
>>>
>>> (I've confirmed with tcpdump that the packets lack tags when they are
>>> presented to userspace)
>>>
>>> From what I can tell, I cannot fix this without rebuilding the kernel
>>> and removing the acceleration support from the r8169 driver. Is there
>>> some method I've overlooked?
>>>
>>> Preferably, I'd like the kernel to expose to pcap what's on the wire
>>> (i.e. accelerated vs non-accelerated looks the same from userspace). If
>>> that means too much processing to be desirable, the next best thing
>>> would be to simply not show tagged packets on the raw interface. The
>>> ability to turn vlan acceleration on and off in the latter case would
>>> also be desirable for network debugging.
>>
>> Current kernel version (I think starting with 2.6.28) relay the
>> VLAN tag information to userspace through packet sockets. The
>> current libpcap release from tcpdump.org (or the one Dave keeps
>> in a git tree on kernel.org) supports reconstructing the tags.
>
> So to clarify: as of 2.6.28, an app (e.g. dhcpd) listening on eth0 will
> by default see packets from all VLANs with tags removed; if it wishes to
> do otherwise, it should query the kernel for the VLAN tag of every
> packet and discard those with a tag?
No, exactly the opposite. Starting with 2.6.28 and a recent libpcap,
VLAN tags are present in userspace independant of whether the driver
uses VLAN acceleration or not.
> Unless I misunderstand, this seems like absolutely the wrong behaviour:
> untagged packets are expected to be treated as from another VLAN just
> like any other, and should be kept separate (from userspace's
> perspective) from all tagged packets. Prior to 2.6.28 this was indeed
> the case (on my NICs at least -- tg3 and others): listening on eth0, one
> would see the tagged packets with the tags still in place, so these
> would be correctly ignored by apps which were not specifically able to
> handle tagged packets.
This depends on the driver implementation.
> In my case, this is manifesting as the DHCP misbehaviour which Pierre
> mentioned. (ISC dhcp3d does not use libpcap, and does not query the
> packet socket for the VLAN tag, so it treats every VLAN's packets as for
> the default VLAN.)
It needs to get the VLAN tag from the auxilliary data.
^ permalink raw reply
* Re: [PATCH] be2net: Adding support for 802.1ad (q-in-q mode)
From: David Miller @ 2009-07-23 17:01 UTC (permalink / raw)
To: kaber; +Cc: sarveshwarb, netdev
In-Reply-To: <4A6890C1.2000108@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 23 Jul 2009 18:33:05 +0200
> David Miller wrote:
>>> Sarveshwar Bandi wrote:
>>>> The outer vlan is totally transparent to the host. It is used by the NIC
>>>> to demux packets across multiple pci network functions. Currently the
>>>> outer vlan tags are configured on the NIC by OEM provided utilities.
>>> I see. A proper changelog entry would have explained that and avoided
>>> all this confusion. Not that I think using another tool for this is a
>>> good solution, but no objections from a functional POV.
>>
>> Using OEM tools makes no sense, there should be something like an
>> ethtool interface for changing this setting and appropriate changes
>> to the common userland tools to provide access to them.
>>
>> I'm not putting this change in until there is common infrastructure
>> submitted to common tools to control this configuration.
>
> Thanks, thats my opinion as well. But I think we should handle
> Q-in-Q using the VLAN netlink API and iproute instead of ethtool
> for consistency.
That works for me too.
^ 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