* [PATCH 6/9] netfilter: complete the deprecation of CONFIG_NF_CT_ACCT
From: kaber @ 2010-07-02 9:52 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1278064342-19059-1-git-send-email-kaber@trash.net>
From: Tim Gardner <tim.gardner@canonical.com>
CONFIG_NF_CT_ACCT has been deprecated for awhile and
was originally scheduled for removal by 2.6.29.
Removing support for this config option also stops
this deprecation warning message in the kernel log.
[ 61.669627] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 61.669850] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
[ 61.669852] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
[ 61.669853] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
[Patrick: changed default value to 0]
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
Documentation/feature-removal-schedule.txt | 9 ---------
Documentation/kernel-parameters.txt | 3 +--
net/netfilter/Kconfig | 22 ----------------------
net/netfilter/nf_conntrack_acct.c | 14 +-------------
4 files changed, 2 insertions(+), 46 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 672be01..92f021a 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -303,15 +303,6 @@ Who: Johannes Berg <johannes@sipsolutions.net>
---------------------------
-What: CONFIG_NF_CT_ACCT
-When: 2.6.29
-Why: Accounting can now be enabled/disabled without kernel recompilation.
- Currently used only to set a default value for a feature that is also
- controlled by a kernel/module/sysfs/sysctl parameter.
-Who: Krzysztof Piotr Oledzki <ole@ans.pl>
-
----------------------------
-
What: sysfs ui for changing p4-clockmod parameters
When: September 2009
Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 1808f11..cee6251 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1597,8 +1597,7 @@ and is between 256 and 4096 characters. It is defined in the file
[NETFILTER] Enable connection tracking flow accounting
0 to disable accounting
1 to enable accounting
- Default value depends on CONFIG_NF_CT_ACCT that is
- going to be removed in 2.6.29.
+ Default value is 0.
nfsaddrs= [NFS]
See Documentation/filesystems/nfs/nfsroot.txt.
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 21be535..aa2f106 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -40,27 +40,6 @@ config NF_CONNTRACK
if NF_CONNTRACK
-config NF_CT_ACCT
- bool "Connection tracking flow accounting"
- depends on NETFILTER_ADVANCED
- help
- If this option is enabled, the connection tracking code will
- keep per-flow packet and byte counters.
-
- Those counters can be used for flow-based accounting or the
- `connbytes' match.
-
- Please note that currently this option only sets a default state.
- You may change it at boot time with nf_conntrack.acct=0/1 kernel
- parameter or by loading the nf_conntrack module with acct=0/1.
-
- You may also disable/enable it on a running system with:
- sysctl net.netfilter.nf_conntrack_acct=0/1
-
- This option will be removed in 2.6.29.
-
- If unsure, say `N'.
-
config NF_CONNTRACK_MARK
bool 'Connection mark tracking support'
depends on NETFILTER_ADVANCED
@@ -630,7 +609,6 @@ config NETFILTER_XT_MATCH_CONNBYTES
tristate '"connbytes" per-connection counter match support'
depends on NF_CONNTRACK
depends on NETFILTER_ADVANCED
- select NF_CT_ACCT
help
This option adds a `connbytes' match, which allows you to match the
number of bytes and/or packets for each direction within a connection.
diff --git a/net/netfilter/nf_conntrack_acct.c b/net/netfilter/nf_conntrack_acct.c
index ab81b38..5178c69 100644
--- a/net/netfilter/nf_conntrack_acct.c
+++ b/net/netfilter/nf_conntrack_acct.c
@@ -17,13 +17,7 @@
#include <net/netfilter/nf_conntrack_extend.h>
#include <net/netfilter/nf_conntrack_acct.h>
-#ifdef CONFIG_NF_CT_ACCT
-#define NF_CT_ACCT_DEFAULT 1
-#else
-#define NF_CT_ACCT_DEFAULT 0
-#endif
-
-static int nf_ct_acct __read_mostly = NF_CT_ACCT_DEFAULT;
+static int nf_ct_acct __read_mostly;
module_param_named(acct, nf_ct_acct, bool, 0644);
MODULE_PARM_DESC(acct, "Enable connection tracking flow accounting.");
@@ -114,12 +108,6 @@ int nf_conntrack_acct_init(struct net *net)
net->ct.sysctl_acct = nf_ct_acct;
if (net_eq(net, &init_net)) {
-#ifdef CONFIG_NF_CT_ACCT
- printk(KERN_WARNING "CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use\n");
- printk(KERN_WARNING "nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or\n");
- printk(KERN_WARNING "sysctl net.netfilter.nf_conntrack_acct=1 to enable it.\n");
-#endif
-
ret = nf_ct_extend_register(&acct_extend);
if (ret < 0) {
printk(KERN_ERR "nf_conntrack_acct: Unable to register extension\n");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 8/9] netfilter: ipt_LOG/ip6t_LOG: add option to print decoded MAC header
From: kaber @ 2010-07-02 9:52 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1278064342-19059-1-git-send-email-kaber@trash.net>
From: Patrick McHardy <kaber@trash.net>
The LOG targets print the entire MAC header as one long string, which is not
readable very well:
IN=eth0 OUT= MAC=00:15:f2:24:91:f8:00:1b:24:dc:61:e6:08:00 ...
Add an option to decode known header formats (currently just ARPHRD_ETHER devices)
in their individual fields:
IN=eth0 OUT= MACSRC=00:1b:24:dc:61:e6 MACDST=00:15:f2:24:91:f8 MACPROTO=0800 ...
IN=eth0 OUT= MACSRC=00:1b:24:dc:61:e6 MACDST=00:15:f2:24:91:f8 MACPROTO=86dd ...
The option needs to be explicitly enabled by userspace to avoid breaking
existing parsers.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
include/linux/netfilter_ipv4/ipt_LOG.h | 3 +-
include/linux/netfilter_ipv6/ip6t_LOG.h | 3 +-
net/ipv4/netfilter/ipt_LOG.c | 54 +++++++++++++++-----
net/ipv6/netfilter/ip6t_LOG.c | 81 ++++++++++++++++++++-----------
4 files changed, 97 insertions(+), 44 deletions(-)
diff --git a/include/linux/netfilter_ipv4/ipt_LOG.h b/include/linux/netfilter_ipv4/ipt_LOG.h
index 90fa652..dcdbadf 100644
--- a/include/linux/netfilter_ipv4/ipt_LOG.h
+++ b/include/linux/netfilter_ipv4/ipt_LOG.h
@@ -7,7 +7,8 @@
#define IPT_LOG_IPOPT 0x04 /* Log IP options */
#define IPT_LOG_UID 0x08 /* Log UID owning local socket */
#define IPT_LOG_NFLOG 0x10 /* Unsupported, don't reuse */
-#define IPT_LOG_MASK 0x1f
+#define IPT_LOG_MACDECODE 0x20 /* Decode MAC header */
+#define IPT_LOG_MASK 0x2f
struct ipt_log_info {
unsigned char level;
diff --git a/include/linux/netfilter_ipv6/ip6t_LOG.h b/include/linux/netfilter_ipv6/ip6t_LOG.h
index 0d0119b..9dd5579 100644
--- a/include/linux/netfilter_ipv6/ip6t_LOG.h
+++ b/include/linux/netfilter_ipv6/ip6t_LOG.h
@@ -7,7 +7,8 @@
#define IP6T_LOG_IPOPT 0x04 /* Log IP options */
#define IP6T_LOG_UID 0x08 /* Log UID owning local socket */
#define IP6T_LOG_NFLOG 0x10 /* Unsupported, don't use */
-#define IP6T_LOG_MASK 0x1f
+#define IP6T_LOG_MACDECODE 0x20 /* Decode MAC header */
+#define IP6T_LOG_MASK 0x2f
struct ip6t_log_info {
unsigned char level;
diff --git a/net/ipv4/netfilter/ipt_LOG.c b/net/ipv4/netfilter/ipt_LOG.c
index 0a452a5..915fc17 100644
--- a/net/ipv4/netfilter/ipt_LOG.c
+++ b/net/ipv4/netfilter/ipt_LOG.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/spinlock.h>
#include <linux/skbuff.h>
+#include <linux/if_arp.h>
#include <linux/ip.h>
#include <net/icmp.h>
#include <net/udp.h>
@@ -363,6 +364,42 @@ static void dump_packet(const struct nf_loginfo *info,
/* maxlen = 230+ 91 + 230 + 252 = 803 */
}
+static void dump_mac_header(const struct nf_loginfo *info,
+ const struct sk_buff *skb)
+{
+ struct net_device *dev = skb->dev;
+ unsigned int logflags = 0;
+
+ if (info->type == NF_LOG_TYPE_LOG)
+ logflags = info->u.log.logflags;
+
+ if (!(logflags & IPT_LOG_MACDECODE))
+ goto fallback;
+
+ switch (dev->type) {
+ case ARPHRD_ETHER:
+ printk("MACSRC=%pM MACDST=%pM MACPROTO=%04x ",
+ eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest,
+ ntohs(eth_hdr(skb)->h_proto));
+ return;
+ default:
+ break;
+ }
+
+fallback:
+ printk("MAC=");
+ if (dev->hard_header_len &&
+ skb->mac_header != skb->network_header) {
+ const unsigned char *p = skb_mac_header(skb);
+ unsigned int i;
+
+ printk("%02x", *p++);
+ for (i = 1; i < dev->hard_header_len; i++, p++)
+ printk(":%02x", *p);
+ }
+ printk(" ");
+}
+
static struct nf_loginfo default_loginfo = {
.type = NF_LOG_TYPE_LOG,
.u = {
@@ -404,20 +441,9 @@ ipt_log_packet(u_int8_t pf,
}
#endif
- if (in && !out) {
- /* MAC logging for input chain only. */
- printk("MAC=");
- if (skb->dev && skb->dev->hard_header_len &&
- skb->mac_header != skb->network_header) {
- int i;
- const unsigned char *p = skb_mac_header(skb);
-
- printk("%02x", *p++);
- for (i = 1; i < skb->dev->hard_header_len; i++, p++)
- printk(":%02x", *p);
- }
- printk(" ");
- }
+ /* MAC logging for input path only. */
+ if (in && !out)
+ dump_mac_header(loginfo, skb);
dump_packet(loginfo, skb, 0);
printk("\n");
diff --git a/net/ipv6/netfilter/ip6t_LOG.c b/net/ipv6/netfilter/ip6t_LOG.c
index 4c7ddac..0a07ae7 100644
--- a/net/ipv6/netfilter/ip6t_LOG.c
+++ b/net/ipv6/netfilter/ip6t_LOG.c
@@ -373,6 +373,56 @@ static void dump_packet(const struct nf_loginfo *info,
printk("MARK=0x%x ", skb->mark);
}
+static void dump_mac_header(const struct nf_loginfo *info,
+ const struct sk_buff *skb)
+{
+ struct net_device *dev = skb->dev;
+ unsigned int logflags = 0;
+
+ if (info->type == NF_LOG_TYPE_LOG)
+ logflags = info->u.log.logflags;
+
+ if (!(logflags & IP6T_LOG_MACDECODE))
+ goto fallback;
+
+ switch (dev->type) {
+ case ARPHRD_ETHER:
+ printk("MACSRC=%pM MACDST=%pM MACPROTO=%04x ",
+ eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest,
+ ntohs(eth_hdr(skb)->h_proto));
+ return;
+ default:
+ break;
+ }
+
+fallback:
+ printk("MAC=");
+ if (dev->hard_header_len &&
+ skb->mac_header != skb->network_header) {
+ const unsigned char *p = skb_mac_header(skb);
+ unsigned int len = dev->hard_header_len;
+ unsigned int i;
+
+ if (dev->type == ARPHRD_SIT &&
+ (p -= ETH_HLEN) < skb->head)
+ p = NULL;
+
+ if (p != NULL) {
+ printk("%02x", *p++);
+ for (i = 1; i < len; i++)
+ printk(":%02x", p[i]);
+ }
+ printk(" ");
+
+ if (dev->type == ARPHRD_SIT) {
+ const struct iphdr *iph =
+ (struct iphdr *)skb_mac_header(skb);
+ printk("TUNNEL=%pI4->%pI4 ", &iph->saddr, &iph->daddr);
+ }
+ } else
+ printk(" ");
+}
+
static struct nf_loginfo default_loginfo = {
.type = NF_LOG_TYPE_LOG,
.u = {
@@ -400,35 +450,10 @@ ip6t_log_packet(u_int8_t pf,
prefix,
in ? in->name : "",
out ? out->name : "");
- if (in && !out) {
- unsigned int len;
- /* MAC logging for input chain only. */
- printk("MAC=");
- if (skb->dev && (len = skb->dev->hard_header_len) &&
- skb->mac_header != skb->network_header) {
- const unsigned char *p = skb_mac_header(skb);
- int i;
-
- if (skb->dev->type == ARPHRD_SIT &&
- (p -= ETH_HLEN) < skb->head)
- p = NULL;
-
- if (p != NULL) {
- printk("%02x", *p++);
- for (i = 1; i < len; i++)
- printk(":%02x", p[i]);
- }
- printk(" ");
- if (skb->dev->type == ARPHRD_SIT) {
- const struct iphdr *iph =
- (struct iphdr *)skb_mac_header(skb);
- printk("TUNNEL=%pI4->%pI4 ",
- &iph->saddr, &iph->daddr);
- }
- } else
- printk(" ");
- }
+ /* MAC logging for input path only. */
+ if (in && !out)
+ dump_mac_header(loginfo, skb);
dump_packet(loginfo, skb, skb_network_offset(skb), 1);
printk("\n");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 9/9] bridge: add per bridge device controls for invoking iptables
From: kaber @ 2010-07-02 9:52 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1278064342-19059-1-git-send-email-kaber@trash.net>
From: Patrick McHardy <kaber@trash.net>
Support more fine grained control of bridge netfilter iptables invocation
by adding seperate brnf_call_*tables parameters for each device using the
sysfs interface. Packets are passed to layer 3 netfilter when either the
global parameter or the per bridge parameter is enabled.
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/bridge/br_netfilter.c | 31 ++++++++++++++-----
net/bridge/br_private.h | 3 ++
net/bridge/br_sysfs_br.c | 72 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 97 insertions(+), 9 deletions(-)
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 6bb6f7c..f1d49ae 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -55,6 +55,9 @@ static int brnf_call_arptables __read_mostly = 1;
static int brnf_filter_vlan_tagged __read_mostly = 0;
static int brnf_filter_pppoe_tagged __read_mostly = 0;
#else
+#define brnf_call_iptables 1
+#define brnf_call_ip6tables 1
+#define brnf_call_arptables 1
#define brnf_filter_vlan_tagged 0
#define brnf_filter_pppoe_tagged 0
#endif
@@ -543,25 +546,30 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
+ struct net_bridge_port *p;
+ struct net_bridge *br;
struct iphdr *iph;
__u32 len = nf_bridge_encap_header_len(skb);
if (unlikely(!pskb_may_pull(skb, len)))
goto out;
+ p = rcu_dereference(in->br_port);
+ if (p == NULL)
+ goto out;
+ br = p->br;
+
if (skb->protocol == htons(ETH_P_IPV6) || IS_VLAN_IPV6(skb) ||
IS_PPPOE_IPV6(skb)) {
-#ifdef CONFIG_SYSCTL
- if (!brnf_call_ip6tables)
+ if (!brnf_call_ip6tables && !br->nf_call_ip6tables)
return NF_ACCEPT;
-#endif
+
nf_bridge_pull_encap_header_rcsum(skb);
return br_nf_pre_routing_ipv6(hook, skb, in, out, okfn);
}
-#ifdef CONFIG_SYSCTL
- if (!brnf_call_iptables)
+
+ if (!brnf_call_iptables && !br->nf_call_iptables)
return NF_ACCEPT;
-#endif
if (skb->protocol != htons(ETH_P_IP) && !IS_VLAN_IP(skb) &&
!IS_PPPOE_IP(skb))
@@ -714,12 +722,17 @@ static unsigned int br_nf_forward_arp(unsigned int hook, struct sk_buff *skb,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
+ struct net_bridge_port *p;
+ struct net_bridge *br;
struct net_device **d = (struct net_device **)(skb->cb);
-#ifdef CONFIG_SYSCTL
- if (!brnf_call_arptables)
+ p = rcu_dereference(out->br_port);
+ if (p == NULL)
+ return NF_ACCEPT;
+ br = p->br;
+
+ if (!brnf_call_arptables && !br->nf_call_arptables)
return NF_ACCEPT;
-#endif
if (skb->protocol != htons(ETH_P_ARP)) {
if (!IS_VLAN_ARP(skb))
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index c83519b..7484065 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -164,6 +164,9 @@ struct net_bridge
unsigned long feature_mask;
#ifdef CONFIG_BRIDGE_NETFILTER
struct rtable fake_rtable;
+ bool nf_call_iptables;
+ bool nf_call_ip6tables;
+ bool nf_call_arptables;
#endif
unsigned long flags;
#define BR_SET_MAC_ADDR 0x00000001
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 486b8f3..5c1e555 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -611,6 +611,73 @@ static DEVICE_ATTR(multicast_startup_query_interval, S_IRUGO | S_IWUSR,
show_multicast_startup_query_interval,
store_multicast_startup_query_interval);
#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+static ssize_t show_nf_call_iptables(
+ struct device *d, struct device_attribute *attr, char *buf)
+{
+ struct net_bridge *br = to_bridge(d);
+ return sprintf(buf, "%u\n", br->nf_call_iptables);
+}
+
+static int set_nf_call_iptables(struct net_bridge *br, unsigned long val)
+{
+ br->nf_call_iptables = val ? true : false;
+ return 0;
+}
+
+static ssize_t store_nf_call_iptables(
+ struct device *d, struct device_attribute *attr, const char *buf,
+ size_t len)
+{
+ return store_bridge_parm(d, buf, len, set_nf_call_iptables);
+}
+static DEVICE_ATTR(nf_call_iptables, S_IRUGO | S_IWUSR,
+ show_nf_call_iptables, store_nf_call_iptables);
+
+static ssize_t show_nf_call_ip6tables(
+ struct device *d, struct device_attribute *attr, char *buf)
+{
+ struct net_bridge *br = to_bridge(d);
+ return sprintf(buf, "%u\n", br->nf_call_ip6tables);
+}
+
+static int set_nf_call_ip6tables(struct net_bridge *br, unsigned long val)
+{
+ br->nf_call_ip6tables = val ? true : false;
+ return 0;
+}
+
+static ssize_t store_nf_call_ip6tables(
+ struct device *d, struct device_attribute *attr, const char *buf,
+ size_t len)
+{
+ return store_bridge_parm(d, buf, len, set_nf_call_ip6tables);
+}
+static DEVICE_ATTR(nf_call_ip6tables, S_IRUGO | S_IWUSR,
+ show_nf_call_ip6tables, store_nf_call_ip6tables);
+
+static ssize_t show_nf_call_arptables(
+ struct device *d, struct device_attribute *attr, char *buf)
+{
+ struct net_bridge *br = to_bridge(d);
+ return sprintf(buf, "%u\n", br->nf_call_arptables);
+}
+
+static int set_nf_call_arptables(struct net_bridge *br, unsigned long val)
+{
+ br->nf_call_arptables = val ? true : false;
+ return 0;
+}
+
+static ssize_t store_nf_call_arptables(
+ struct device *d, struct device_attribute *attr, const char *buf,
+ size_t len)
+{
+ return store_bridge_parm(d, buf, len, set_nf_call_arptables);
+}
+static DEVICE_ATTR(nf_call_arptables, S_IRUGO | S_IWUSR,
+ show_nf_call_arptables, store_nf_call_arptables);
+#endif
static struct attribute *bridge_attrs[] = {
&dev_attr_forward_delay.attr,
@@ -645,6 +712,11 @@ static struct attribute *bridge_attrs[] = {
&dev_attr_multicast_query_response_interval.attr,
&dev_attr_multicast_startup_query_interval.attr,
#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+ &dev_attr_nf_call_iptables.attr,
+ &dev_attr_nf_call_ip6tables.attr,
+ &dev_attr_nf_call_arptables.attr,
+#endif
NULL
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/9] netfilter: netfilter update
From: kaber @ 2010-07-02 9:52 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
Hi Dave,
following is a small netfilter update for net-next, containing:
- a patch to support user-defined SNAT rules in the nat/INPUT chain,
from myself
- one-packet scheduling for IPVS from Nick Chalk
- missing kdev_t.h inclusion in xt_IDLETIMER from Randy Dunlap
- the removal of CONFIG_NF_CT_ACCT, originally scheduled for 2.6.29,
from Tim Gardner
- a patch to support MAC header decoding in the netfilter LOG targets,
from myself
- a patch for per bridge device controls for iptables invocation, from
myself
Please apply or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Thanks!
Arnd Hannemann (1):
netfilter: fix simple typo in KConfig for netfiltert xt_TEE
Nick Chalk (1):
IPVS: one-packet scheduling
Patrick McHardy (4):
netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
netfilter: ipt_LOG/ip6t_LOG: remove comparison within loop
netfilter: ipt_LOG/ip6t_LOG: add option to print decoded MAC header
bridge: add per bridge device controls for invoking iptables
Randy Dunlap (1):
netfilter: xt_IDLETIMER needs kdev_t.h
Tim Gardner (2):
netfilter: xt_connbytes: Force CT accounting to be enabled
netfilter: complete the deprecation of CONFIG_NF_CT_ACCT
^ permalink raw reply
* [PATCH 4/9] netfilter: fix simple typo in KConfig for netfiltert xt_TEE
From: kaber @ 2010-07-02 9:52 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1278064342-19059-1-git-send-email-kaber@trash.net>
From: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
Destination was spelled wrong in KConfig.
Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/netfilter/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 413ed24..21be535 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -515,7 +515,7 @@ config NETFILTER_XT_TARGET_RATEEST
To compile it as a module, choose M here. If unsure, say N.
config NETFILTER_XT_TARGET_TEE
- tristate '"TEE" - packet cloning to alternate destiantion'
+ tristate '"TEE" - packet cloning to alternate destination'
depends on NETFILTER_ADVANCED
depends on (IPV6 || IPV6=n)
depends on !NF_CONNTRACK || NF_CONNTRACK
--
1.7.0.4
^ permalink raw reply related
* [PATCH 7/9] netfilter: ipt_LOG/ip6t_LOG: remove comparison within loop
From: kaber @ 2010-07-02 9:52 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1278064342-19059-1-git-send-email-kaber@trash.net>
From: Patrick McHardy <kaber@trash.net>
Remove the comparison within the loop to print the macheader by prepending
the colon to all but the first printk.
Based on suggestion by Jan Engelhardt <jengelh@medozas.de>.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/ipv4/netfilter/ipt_LOG.c | 12 ++++++------
net/ipv6/netfilter/ip6t_LOG.c | 6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_LOG.c b/net/ipv4/netfilter/ipt_LOG.c
index 5234f4f..0a452a5 100644
--- a/net/ipv4/netfilter/ipt_LOG.c
+++ b/net/ipv4/netfilter/ipt_LOG.c
@@ -411,12 +411,12 @@ ipt_log_packet(u_int8_t pf,
skb->mac_header != skb->network_header) {
int i;
const unsigned char *p = skb_mac_header(skb);
- for (i = 0; i < skb->dev->hard_header_len; i++,p++)
- printk("%02x%c", *p,
- i==skb->dev->hard_header_len - 1
- ? ' ':':');
- } else
- printk(" ");
+
+ printk("%02x", *p++);
+ for (i = 1; i < skb->dev->hard_header_len; i++, p++)
+ printk(":%02x", *p);
+ }
+ printk(" ");
}
dump_packet(loginfo, skb, 0);
diff --git a/net/ipv6/netfilter/ip6t_LOG.c b/net/ipv6/netfilter/ip6t_LOG.c
index af4ee11..4c7ddac 100644
--- a/net/ipv6/netfilter/ip6t_LOG.c
+++ b/net/ipv6/netfilter/ip6t_LOG.c
@@ -414,9 +414,9 @@ ip6t_log_packet(u_int8_t pf,
p = NULL;
if (p != NULL) {
- for (i = 0; i < len; i++)
- printk("%02x%s", p[i],
- i == len - 1 ? "" : ":");
+ printk("%02x", *p++);
+ for (i = 1; i < len; i++)
+ printk(":%02x", p[i]);
}
printk(" ");
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Jan Engelhardt @ 2010-07-02 10:14 UTC (permalink / raw)
To: kaber; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <1278064342-19059-2-git-send-email-kaber@trash.net>
On Friday 2010-07-02 11:52, kaber@trash.net wrote:
>
>2.6.34 introduced 'conntrack zones' to deal with cases where packets
>from multiple identical networks are handled by conntrack/NAT. Packets
>are looped through veth devices, during which they are NATed to private
>addresses, after which they can continue normally through the stack
>and possibly have NAT rules applied a second time.
>
>This works well, but is needlessly complicated for cases where only
>a single SNAT/DNAT mapping needs to be applied to these packets.
I still have not grasped why SNAT is needed in the INPUT path. For the
tunnel scenario that you wanted to build I could not find a reason to
do SNAT in that place - since the non-encapsulated packets don't go
through INPUT anyway.
^ permalink raw reply
* Re: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Patrick McHardy @ 2010-07-02 10:17 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <alpine.LSU.2.01.1007021212490.16691@obet.zrqbmnf.qr>
Jan Engelhardt wrote:
> On Friday 2010-07-02 11:52, kaber@trash.net wrote:
>
>> 2.6.34 introduced 'conntrack zones' to deal with cases where packets
>>
> >from multiple identical networks are handled by conntrack/NAT. Packets
>
>> are looped through veth devices, during which they are NATed to private
>> addresses, after which they can continue normally through the stack
>> and possibly have NAT rules applied a second time.
>>
>> This works well, but is needlessly complicated for cases where only
>> a single SNAT/DNAT mapping needs to be applied to these packets.
>>
>
> I still have not grasped why SNAT is needed in the INPUT path. For the
> tunnel scenario that you wanted to build I could not find a reason to
> do SNAT in that place - since the non-encapsulated packets don't go
> through INPUT anyway.
>
Sure they do, if they are destined for the host itself. I'm not sure
what's so hard to understand about this patch, you have f.i. multiple
tunnels using the same remote network, on INPUT and POSTROUTING you SNAT
them to seperate networks based on criteria like the network device or
the IPsec tunnel to be able to distinguish them.
^ permalink raw reply
* [PATCH] xfrm bugs with mark logic
From: Peter Kosyh @ 2010-07-02 10:40 UTC (permalink / raw)
To: netdev
Hello! I am currently working with 2.6.34, trying to use iptables ...
-j MARK with XFRM policy. So, i found at least
two bugs in 2.6.34 kernel.
First bug is just typo in xfrm_mark_get (net/xfrm.h):
memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
must be:
memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(*m));
The second one, is clearing mark in flowi structure via memset in
_decode_session4 (net/ipv4/xfrm4_policy.c).
(see net/ipv4/netfilter.c, ip_route_me_harder function)
int ip_route_me_harder(struct sk_buff *skb, unsigned addr_type)
/* ... */
if (addr_type == RTN_LOCAL) {
/* ... */
fl.mark = skb->mark; /* here, set mark from skb */
/* ... */
#ifdef CONFIG_XFRM
if (!(IPCB(skb)->flags & IPSKB_XFRM_TRANSFORMED) &&
xfrm_decode_session(skb, &fl, AF_INET) == 0) { /* here
fl->mark will be zeroed */
/* ... */
if (xfrm_lookup(net, &dst, &fl, skb->sk, 0)) /* here
policy lookup will fail */
Do not know about ipv6 anything, but it's like that it affected by
this bug too. :(
P.S. Sorry for my bad English. :)
w.b.r. Peter Kosyh
diff -Nur linux-2.6.34/include/net/xfrm.h linux-2.6.34.fix/include/net/xfrm.h
--- linux-2.6.34/include/net/xfrm.h 2010-05-16 21:17:36.000000000 +0000
+++ linux-2.6.34.fix/include/net/xfrm.h 2010-07-02 10:05:33.000000000 +0000
@@ -1587,7 +1587,7 @@
static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
{
if (attrs[XFRMA_MARK])
- memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
+ memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(*m));
else
m->v = m->m = 0;
diff -Nur linux-2.6.34/net/ipv4/xfrm4_policy.c
linux-2.6.34.fix/net/ipv4/xfrm4_policy.c
--- linux-2.6.34/net/ipv4/xfrm4_policy.c 2010-05-16 21:17:36.000000000 +0000
+++ linux-2.6.34.fix/net/ipv4/xfrm4_policy.c 2010-07-02 10:17:51.000000000 +0000
@@ -186,6 +186,7 @@
fl->fl4_dst = reverse ? iph->saddr : iph->daddr;
fl->fl4_src = reverse ? iph->daddr : iph->saddr;
fl->fl4_tos = iph->tos;
+ fl->mark = skb->mark;
}
static inline int xfrm4_garbage_collect(struct dst_ops *ops)
^ permalink raw reply
* [PATCH 0/1] netfilter: netfilter fix
From: kaber @ 2010-07-02 11:40 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
the following patch for 2.6.35 fixes a dst leak in ip6t_REJECT when
dst->error is set, from Eric Dumazet.
Please apply or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Thanks!
^ permalink raw reply
* [PATCH] netfilter: ip6t_REJECT: fix a dst leak in ipv6 REJECT
From: kaber @ 2010-07-02 11:42 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
From: Eric Dumazet <eric.dumazet@gmail.com>
We should release dst if dst->error is set.
Bug introduced in 2.6.14 by commit e104411b82f5c
([XFRM]: Always release dst_entry on error in xfrm_lookup)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/ipv6/netfilter/ip6t_REJECT.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/netfilter/ip6t_REJECT.c b/net/ipv6/netfilter/ip6t_REJECT.c
index 47d2277..2933396 100644
--- a/net/ipv6/netfilter/ip6t_REJECT.c
+++ b/net/ipv6/netfilter/ip6t_REJECT.c
@@ -97,9 +97,11 @@ static void send_reset(struct net *net, struct sk_buff *oldskb)
fl.fl_ip_dport = otcph.source;
security_skb_classify_flow(oldskb, &fl);
dst = ip6_route_output(net, NULL, &fl);
- if (dst == NULL)
+ if (dst == NULL || dst->error) {
+ dst_release(dst);
return;
- if (dst->error || xfrm_lookup(net, &dst, &fl, NULL, 0))
+ }
+ if (xfrm_lookup(net, &dst, &fl, NULL, 0))
return;
hh_len = (dst->dev->hard_header_len + 15)&~15;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Jan Engelhardt @ 2010-07-02 12:17 UTC (permalink / raw)
To: Patrick McHardy; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <4C2DBCD3.20208@trash.net>
On Friday 2010-07-02 12:17, Patrick McHardy wrote:
>>
>> I still have not grasped why SNAT is needed in the INPUT path. For the
>> tunnel scenario that you wanted to build I could not find a reason to
>> do SNAT in that place - since the non-encapsulated packets don't go
>> through INPUT anyway.
>
> Sure they do, if they are destined for the host itself. I'm not sure
> what's so hard to understand about this patch, you have f.i. multiple
> tunnels using the same remote network, on INPUT and POSTROUTING you SNAT
> them to seperate networks based on criteria like the network device or
> the IPsec tunnel to be able to distinguish them.
But they are already distinguishable by the ctmark that is applied
to these connections to do routing of the reply, are they not?
^ permalink raw reply
* Re: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Patrick McHardy @ 2010-07-02 12:35 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <alpine.LSU.2.01.1007021416120.30410@obet.zrqbmnf.qr>
Jan Engelhardt wrote:
> On Friday 2010-07-02 12:17, Patrick McHardy wrote:
>
>>> I still have not grasped why SNAT is needed in the INPUT path. For the
>>> tunnel scenario that you wanted to build I could not find a reason to
>>> do SNAT in that place - since the non-encapsulated packets don't go
>>> through INPUT anyway.
>>>
>> Sure they do, if they are destined for the host itself. I'm not sure
>> what's so hard to understand about this patch, you have f.i. multiple
>> tunnels using the same remote network, on INPUT and POSTROUTING you SNAT
>> them to seperate networks based on criteria like the network device or
>> the IPsec tunnel to be able to distinguish them.
>>
>
> But they are already distinguishable by the ctmark that is applied
> to these connections to do routing of the reply, are they not?
>
Its not (only) about routing, you simply can't have two connections using
the same identity.
^ permalink raw reply
* Re: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Jan Engelhardt @ 2010-07-02 12:58 UTC (permalink / raw)
To: Patrick McHardy; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <4C2DDD29.7030503@trash.net>
On Friday 2010-07-02 14:35, Patrick McHardy wrote:
>>> Sure they do, if they are destined for the host itself. I'm not sure
>>> what's so hard to understand about this patch, you have f.i. multiple
>>> tunnels using the same remote network, on INPUT and POSTROUTING you SNAT
>>> them to seperate networks based on criteria like the network device or
>>> the IPsec tunnel to be able to distinguish them.
>>>
>>
>> But they are already distinguishable by the ctmark that is applied
>> to these connections to do routing of the reply, are they not?
>>
>
> Its not (only) about routing, you simply can't have two connections using
> the same identity.
Which is why the zone thing is added.
Ah, but I now see that you need to select a zone for it first.. touché.
Still this SNAT-on-INPUT leaves a second taste. Adding another address
to the tunnel master and using DNAT-on-PREROUTING for local deliveries
would have also made the connections unambiguous.
^ permalink raw reply
* [PATCH] usbnet: remove direct access to urb->status
From: Oliver Neukum @ 2010-07-02 13:58 UTC (permalink / raw)
To: netdev; +Cc: davem
>From a2e8da61490cba876b1b4814c4832822527c43dd Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oliver@neukum.org>
Date: Fri, 2 Jul 2010 15:51:55 +0200
Subject: [PATCH] usbnet: remove direct access to urb->status
USB drivers should not use urb->status directly because
it is scheduled to become a parameter. This does the conversion
for drivers/net/usb
Signed-off-by: Oliver Neukum <oneukum@suse.de>
---
drivers/net/usb/cdc-phonet.c | 8 +++++---
drivers/net/usb/ipheth.c | 13 +++++++------
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/cdc-phonet.c b/drivers/net/usb/cdc-phonet.c
index dc94445..109751b 100644
--- a/drivers/net/usb/cdc-phonet.c
+++ b/drivers/net/usb/cdc-phonet.c
@@ -97,8 +97,9 @@ static void tx_complete(struct urb *req)
struct sk_buff *skb = req->context;
struct net_device *dev = skb->dev;
struct usbpn_dev *pnd = netdev_priv(dev);
+ int status = req->status;
- switch (req->status) {
+ switch (status) {
case 0:
dev->stats.tx_bytes += skb->len;
break;
@@ -109,7 +110,7 @@ static void tx_complete(struct urb *req)
dev->stats.tx_aborted_errors++;
default:
dev->stats.tx_errors++;
- dev_dbg(&dev->dev, "TX error (%d)\n", req->status);
+ dev_dbg(&dev->dev, "TX error (%d)\n", status);
}
dev->stats.tx_packets++;
@@ -150,8 +151,9 @@ static void rx_complete(struct urb *req)
struct page *page = virt_to_page(req->transfer_buffer);
struct sk_buff *skb;
unsigned long flags;
+ int status = req->status;
- switch (req->status) {
+ switch (status) {
case 0:
spin_lock_irqsave(&pnd->rx_lock, flags);
skb = pnd->rx_skb;
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 197c352..08e7b6a 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -193,7 +193,7 @@ static void ipheth_rcvbulk_callback(struct urb *urb)
case 0:
break;
default:
- err("%s: urb status: %d", __func__, urb->status);
+ err("%s: urb status: %d", __func__, status);
return;
}
@@ -222,16 +222,17 @@ static void ipheth_rcvbulk_callback(struct urb *urb)
static void ipheth_sndbulk_callback(struct urb *urb)
{
struct ipheth_device *dev;
+ int status = urb->status;
dev = urb->context;
if (dev == NULL)
return;
- if (urb->status != 0 &&
- urb->status != -ENOENT &&
- urb->status != -ECONNRESET &&
- urb->status != -ESHUTDOWN)
- err("%s: urb status: %d", __func__, urb->status);
+ if (status != 0 &&
+ status != -ENOENT &&
+ status != -ECONNRESET &&
+ status != -ESHUTDOWN)
+ err("%s: urb status: %d", __func__, status);
dev_kfree_skb_irq(dev->tx_skb);
netif_wake_queue(dev->net);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Patrick McHardy @ 2010-07-02 14:07 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <alpine.LSU.2.01.1007021452430.11763@obet.zrqbmnf.qr>
Jan Engelhardt wrote:
> On Friday 2010-07-02 14:35, Patrick McHardy wrote:
>
>>>> Sure they do, if they are destined for the host itself. I'm not sure
>>>> what's so hard to understand about this patch, you have f.i. multiple
>>>> tunnels using the same remote network, on INPUT and POSTROUTING you SNAT
>>>> them to seperate networks based on criteria like the network device or
>>>> the IPsec tunnel to be able to distinguish them.
>>>>
>>>>
>>> But they are already distinguishable by the ctmark that is applied
>>> to these connections to do routing of the reply, are they not?
>>>
>>>
>> Its not (only) about routing, you simply can't have two connections using
>> the same identity.
>>
>
> Which is why the zone thing is added.
>
I'm not talking about conntrack at all. A connection needs
a unique identity. Just look at the socket lookup code.
> Ah, but I now see that you need to select a zone for it first.. touché.
>
> Still this SNAT-on-INPUT leaves a second taste. Adding another address
> to the tunnel master and using DNAT-on-PREROUTING for local deliveries
> would have also made the connections unambiguous
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-07-01
From: John W. Linville @ 2010-07-02 14:08 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100701.173550.172604489.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, Jul 01, 2010 at 05:35:50PM -0700, David Miller wrote:
> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Thu, 1 Jul 2010 14:15:27 -0400
>
> > Two weeks since the last request, plenty of new stuff intended for
> > 2.6.36...
> >
> > Included are the usual bunch of driver updates, including a big
> > dump from the rt2x00 team. This also includes cfg80211 support
> > for libertas, a flurry of (mostly trivial) stuff from me, and a
> > wireless-2.6 pull to resolve some patch dependencies.
> >
> > Please let me know if there are problems!
>
> This failed to pull cleanly, I got a conflict in
> drivers/net/wireless/libertas/host.h It was the
> usual "__packed" vs. "__attribute__((packed))" thing.
>
> I resolved it but I wonder if this happened because you
> did the wireless-2.6 --> wireless-next-2.6 merge here.
Sorry, Dave! I probably should have done 'for-davem' branch for you.
Thanks for resolving it!
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] xfrm bugs with mark logic
From: Eric Dumazet @ 2010-07-02 15:01 UTC (permalink / raw)
To: Peter Kosyh; +Cc: netdev
In-Reply-To: <AANLkTimsVHoNk3B1oTI6awlNtrmNED7vwe2flzTap9aP@mail.gmail.com>
Le vendredi 02 juillet 2010 à 14:40 +0400, Peter Kosyh a écrit :
> Hello! I am currently working with 2.6.34, trying to use iptables ...
> -j MARK with XFRM policy. So, i found at least
> two bugs in 2.6.34 kernel.
>
> First bug is just typo in xfrm_mark_get (net/xfrm.h):
>
> memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
>
> must be:
>
> memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(*m));
>
> The second one, is clearing mark in flowi structure via memset in
> _decode_session4 (net/ipv4/xfrm4_policy.c).
> (see net/ipv4/netfilter.c, ip_route_me_harder function)
> int ip_route_me_harder(struct sk_buff *skb, unsigned addr_type)
> /* ... */
> if (addr_type == RTN_LOCAL) {
> /* ... */
> fl.mark = skb->mark; /* here, set mark from skb */
> /* ... */
> #ifdef CONFIG_XFRM
> if (!(IPCB(skb)->flags & IPSKB_XFRM_TRANSFORMED) &&
> xfrm_decode_session(skb, &fl, AF_INET) == 0) { /* here
> fl->mark will be zeroed */
> /* ... */
> if (xfrm_lookup(net, &dst, &fl, skb->sk, 0)) /* here
> policy lookup will fail */
>
> Do not know about ipv6 anything, but it's like that it affected by
> this bug too. :(
>
> P.S. Sorry for my bad English. :)
>
> w.b.r. Peter Kosyh
>
> diff -Nur linux-2.6.34/include/net/xfrm.h linux-2.6.34.fix/include/net/xfrm.h
> --- linux-2.6.34/include/net/xfrm.h 2010-05-16 21:17:36.000000000 +0000
> +++ linux-2.6.34.fix/include/net/xfrm.h 2010-07-02 10:05:33.000000000 +0000
> @@ -1587,7 +1587,7 @@
> static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
> {
> if (attrs[XFRMA_MARK])
> - memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
> + memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(*m));
> else
> m->v = m->m = 0;
> diff -Nur linux-2.6.34/net/ipv4/xfrm4_policy.c
> linux-2.6.34.fix/net/ipv4/xfrm4_policy.c
> --- linux-2.6.34/net/ipv4/xfrm4_policy.c 2010-05-16 21:17:36.000000000 +0000
> +++ linux-2.6.34.fix/net/ipv4/xfrm4_policy.c 2010-07-02 10:17:51.000000000 +0000
> @@ -186,6 +186,7 @@
> fl->fl4_dst = reverse ? iph->saddr : iph->daddr;
> fl->fl4_src = reverse ? iph->daddr : iph->saddr;
> fl->fl4_tos = iph->tos;
> + fl->mark = skb->mark;
> }
>
> static inline int xfrm4_garbage_collect(struct dst_ops *ops)
> --
Hi Peter
XFRMA_MARK part already in net-2.6 tree :
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=4efd7e833591721bec21cc4730a7f6261417840f
Please submit another patch the second problem you spotted ?
^ permalink raw reply
* Practical performance change to qdisc_lookup
From: Bart @ 2010-07-02 15:51 UTC (permalink / raw)
To: netdev@vger.kernel.org
While looking to speed up our batch processing of many-thousands of TC
rules I stumbled across a usage-based optimization of qdisc_lookup().
while not a algorithmic optimization, I would wager that future rules
are likely to refer to the more recently created qdiscs and not the
oldest ones.
It is silly, but I thought I'd survey opinions on the change. It is far
less code entropy than say, implementing a hash lookup.
sch_api.c:
@@ -197,7 +197,7 @@
root->handle == handle)
return root;
- list_for_each_entry(q, &root->list, list) {
+ list_for_each_entry_reverse(q, &root->list, list) {
if (q->handle == handle)
return q;
}
^ permalink raw reply
* iwl3945: HARDWARE GONE??
From: Priit Laes @ 2010-07-02 16:02 UTC (permalink / raw)
To: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
Heya!
Bumped my kernel to version 2.6.35-rc3-00391-g97e0214 and ran into
HARDWARE GONE error message..
Hardware is Lenovo x60s and wireless card is intel 3945:
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
Subsystem: Intel Corporation ThinkPad R60e/X60s
Flags: bus master, fast devsel, latency 0, IRQ 47
Memory at edf00000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-xx-xx-xx-xx-xx-xx-xx
Kernel driver in use: iwl3945
Kernel modules: iwl3945
I have attached dmesg error message...
Cheers,
Priit :)
[-- Attachment #2: Type: text/plain, Size: 14319 bytes --]
[13813.347617] Uhhuh. NMI received for unknown reason a1 on CPU 0.
[13813.347617] You have some hardware problem, likely on the PCI bus.
[13813.347617] Dazed and confused, but trying to continue
[13813.347617] iwl3945 0000:03:00.0: HARDWARE GONE?? INTA == 0xffffffff
[13813.846039] iwl3945 0000:03:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
[13814.740056] iwl3945 0000:03:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
[13815.516037] iwl3945 0000:03:00.0: queue 4 stuck 3 time. Fw reload.
[13815.516043] iwl3945 0000:03:00.0: On demand firmware reload
[13815.517024] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.538452] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.559845] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.581247] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.602649] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.624045] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.645451] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.666844] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.688249] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.709654] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.731066] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.752493] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.774006] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.795593] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.817023] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.967302] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.987649] ieee80211 phy0: U iwl3945_nic_config SW RF KILL supported in EEPROM.
[13815.987654] ieee80211 phy0: U iwl3945_nic_config HW RF KILL supported in EEPROM.
[13815.988614] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.010153] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.031442] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.052709] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.073984] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.095257] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.116550] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.137824] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.159097] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.180368] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.201635] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.222901] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.244176] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.265448] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.288031] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.308002] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.329273] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.350609] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.371874] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.393154] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.414471] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.435737] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.457005] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.478340] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.499622] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.520902] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.542226] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.563495] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.584779] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.606071] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.627334] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.648597] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.669891] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.691175] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.712452] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.733736] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.755435] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.775720] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13816.775724] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13816.776714] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.797992] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.819257] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.841984] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.861813] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.883526] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.903809] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13816.903813] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13816.904803] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.926079] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.947349] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.968622] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.990258] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.011587] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.031866] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13817.031870] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13817.032860] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.063144] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.075525] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.096811] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.118256] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.141274] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.160076] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13817.160080] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13817.161068] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.182349] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.203619] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.224884] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.246257] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.267876] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.288161] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13817.288165] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13817.289155] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.310441] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.331715] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.352986] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.374266] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.395539] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.416831] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.438105] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.459382] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.480665] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.501954] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.533431] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.544529] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.567553] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.587377] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.607688] iwl3945 0000:03:00.0: Unable to initialize device after 5 attempts.
[13818.268038] No probe response from AP 00:13:10:15:0e:27 after 500ms, disconnecting.
[13818.268067] BUG: unable to handle kernel NULL pointer dereference at 0000000000000168
[13818.268076] IP: [<ffffffff812a88d2>] iwl_enqueue_hcmd+0xd5/0x54e
[13818.268088] PGD 0
[13818.268093] Oops: 0000 [#1] SMP
[13818.268099] last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
[13818.268104] CPU 1
[13818.268107] Modules linked in: ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc option usb_wwan usbserial sdhci_pci sdhci iwl3945 mmc_core
[13818.268131]
[13818.268138] Pid: 1382, comm: phy0 Not tainted 2.6.35-rc3-00391-g97e0214 #12 1702M3G/1702M3G
[13818.268143] RIP: 0010:[<ffffffff812a88d2>] [<ffffffff812a88d2>] iwl_enqueue_hcmd+0xd5/0x54e
[13818.268153] RSP: 0018:ffff8800bb2efbb0 EFLAGS: 00010006
[13818.268157] RAX: 0000000000000200 RBX: 0000000000000160 RCX: 0000000000000000
[13818.268162] RDX: 0000000000000020 RSI: 0000000000000024 RDI: 0000000000000013
[13818.268168] RBP: ffff8800bb991380 R08: 0000000000000000 R09: ffff8800bb991380
[13818.268173] R10: ffff8800bb999b78 R11: 0000000000000001 R12: ffff8800bb2efc90
[13818.268178] R13: ffffffff8158d563 R14: 0000000000000000 R15: ffff8800bb990460
[13818.268184] FS: 0000000000000000(0000) GS:ffff880001b00000(0000) knlGS:0000000000000000
[13818.268190] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[13818.268195] CR2: 0000000000000168 CR3: 0000000001625000 CR4: 00000000000006e0
[13818.268200] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[13818.268205] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[13818.268211] Process phy0 (pid: 1382, threadinfo ffff8800bb2ee000, task ffff8800bae31bc0)
[13818.268215] Stack:
[13818.268218] ffff880001b124c0 0000000000000001 ffff880001b124c0 ffff8800bae31bc0
[13818.268225] <0> ffff8800bae31bf8 ffff880001b124c0 ffff8800bb2efc20 ffffffff8104869f
[13818.268233] <0> ffff880001b124c0 ffff880000283e70 0000000000000000 0000000000000001
[13818.268242] Call Trace:
[13818.268253] [<ffffffff8104869f>] ? check_preempt_wakeup+0xf6/0x16e
[13818.268261] [<ffffffff812a3dcd>] ? iwl_send_cmd_async+0x4d/0xbd
[13818.268267] [<ffffffff812a3e76>] ? iwl_send_cmd_pdu_async+0x39/0x3e
[13818.268274] [<ffffffff812a3e7b>] ? iwl_generic_cmd_callback+0x0/0x13c
[13818.268283] [<ffffffff8129eb6b>] ? iwl_mac_config+0x644/0x842
[13818.268292] [<ffffffff8146d4c0>] ? _raw_spin_lock_bh+0x9/0x1f
[13818.268299] [<ffffffff81453fc0>] ? ieee80211_set_wmm_default+0x132/0x13d
[13818.268309] [<ffffffff8131f722>] ? led_trigger_event+0x22/0x5c
[13818.268317] [<ffffffff81444f39>] ? ieee80211_set_disassoc+0x116/0x1a5
[13818.268324] [<ffffffff81447c0d>] ? ieee80211_sta_work+0x584/0x5d3
[13818.268331] [<ffffffff814471ce>] ? ieee80211_beacon_connection_loss_work+0xaa/0xb5
[13818.268338] [<ffffffff81447689>] ? ieee80211_sta_work+0x0/0x5d3
[13818.268346] [<ffffffff810643ef>] ? worker_thread+0x13d/0x1c2
[13818.268354] [<ffffffff8106789b>] ? autoremove_wake_function+0x0/0x2a
[13818.268361] [<ffffffff810642b2>] ? worker_thread+0x0/0x1c2
[13818.268367] [<ffffffff810674e1>] ? kthread+0x75/0x7d
[13818.268376] [<ffffffff81022d94>] ? kernel_thread_helper+0x4/0x10
[13818.268383] [<ffffffff8106746c>] ? kthread+0x0/0x7d
[13818.268390] [<ffffffff81022d90>] ? kernel_thread_helper+0x0/0x10
[13818.268393] Code: e9 48 89 c6 48 89 da 48 c7 c7 5e df 5a 81 31 c0 e8 1d 27 1c 00 b8 fb ff ff ff e9 76 04 00 00 48 8b 5c 24 50 48 81 c3 60 01 00 00 <8b> 4b 08 8b 53 04 89 c8 29 d0 39 d1 7e 0b 48 8b 54 24 50 2b 82
[13818.268454] RIP [<ffffffff812a88d2>] iwl_enqueue_hcmd+0xd5/0x54e
[13818.268462] RSP <ffff8800bb2efbb0>
[13818.268465] CR2: 0000000000000168
[13818.268471] ---[ end trace a77a3dc99e96ee11 ]---
^ permalink raw reply
* Re: [PATCH] xfrm bugs with mark logic
From: Peter Kosyh @ 2010-07-02 16:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1278082898.2530.37.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
>
> Hi Peter
>
> XFRMA_MARK part already in net-2.6 tree :
>
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=4efd7e833591721bec21cc4730a7f6261417840f
>
> Please submit another patch the second problem you spotted ?
>
Yes, i see. Here it is, but i am little unsure about ipv6 fix.
--
w.b.r. Peter Kosyh
[-- Attachment #2: linux-2.6.36-xfrm-mark.patch --]
[-- Type: text/plain, Size: 1036 bytes --]
diff -Nur linux-2.6.35-rc3.orig/net/ipv4/xfrm4_policy.c linux-2.6.35-rc3/net/ipv4/xfrm4_policy.c
--- linux-2.6.35-rc3.orig/net/ipv4/xfrm4_policy.c 2010-06-12 06:14:04.000000000 +0400
+++ linux-2.6.35-rc3/net/ipv4/xfrm4_policy.c 2010-07-02 20:20:49.000000000 +0400
@@ -108,6 +108,8 @@
u8 *xprth = skb_network_header(skb) + iph->ihl * 4;
memset(fl, 0, sizeof(struct flowi));
+ fl->mark = skb->mark;
+
if (!(iph->frag_off & htons(IP_MF | IP_OFFSET))) {
switch (iph->protocol) {
case IPPROTO_UDP:
diff -Nur linux-2.6.35-rc3.orig/net/ipv6/xfrm6_policy.c linux-2.6.35-rc3/net/ipv6/xfrm6_policy.c
--- linux-2.6.35-rc3.orig/net/ipv6/xfrm6_policy.c 2010-06-12 06:14:04.000000000 +0400
+++ linux-2.6.35-rc3/net/ipv6/xfrm6_policy.c 2010-07-02 20:20:22.000000000 +0400
@@ -124,6 +124,8 @@
u8 nexthdr = nh[IP6CB(skb)->nhoff];
memset(fl, 0, sizeof(struct flowi));
+ fl->mark = skb->mark;
+
ipv6_addr_copy(&fl->fl6_dst, reverse ? &hdr->saddr : &hdr->daddr);
ipv6_addr_copy(&fl->fl6_src, reverse ? &hdr->daddr : &hdr->saddr);
^ permalink raw reply
* Re: iwl3945: HARDWARE GONE??
From: John W. Linville @ 2010-07-02 16:26 UTC (permalink / raw)
To: Priit Laes; +Cc: netdev, linux-kernel
In-Reply-To: <1278086575.2889.8.camel@chi>
On Fri, Jul 02, 2010 at 07:02:55PM +0300, Priit Laes wrote:
> Heya!
>
> Bumped my kernel to version 2.6.35-rc3-00391-g97e0214 and ran into
> HARDWARE GONE error message..
>
> Hardware is Lenovo x60s and wireless card is intel 3945:
>
> 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
> Subsystem: Intel Corporation ThinkPad R60e/X60s
> Flags: bus master, fast devsel, latency 0, IRQ 47
> Memory at edf00000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [c8] Power Management version 2
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [e0] Express Legacy Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number 00-xx-xx-xx-xx-xx-xx-xx
> Kernel driver in use: iwl3945
> Kernel modules: iwl3945
>
> I have attached dmesg error message...
>
> Cheers,
> Priit :)
> [13813.347617] Uhhuh. NMI received for unknown reason a1 on CPU 0.
> [13813.347617] You have some hardware problem, likely on the PCI bus.
> [13813.347617] Dazed and confused, but trying to continue
> [13813.347617] iwl3945 0000:03:00.0: HARDWARE GONE?? INTA == 0xffffffff
We've been seeing this sort of thing a lot -- somehow the iwl3945 gets
disconnected from the PCI bus. Anyone have any clue how that happens?
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
* soft lockup with conntrackd / keepalived / VLAN
From: Adam Gundy @ 2010-07-02 16:04 UTC (permalink / raw)
To: netdev
I've built a pair of router boxes which are using keepalived and conntrackd to
provide a redundant router setup. we're also using a single 802.1Q VLAN on the
box.
occasionally, the box will lockup for 5 minutes, during which time routed
traffic is extremely delayed (2 or 3 second ping times). initially, there were
no log messages about the lockup. we switched from using an internal nvidia
(forcedeth) NIC in the belief that it may have been causing the problem..
however: with the new gigabit NICs, we still see the hangs, but we also get
this in the kernel log:
> Jul 2 07:50:12 cerberus1 kernel: [31895.510006] BUG: soft lockup - CPU#0 stuck for 61s! [conntrackd:1951]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] Modules linked in: authenc xfrm_user ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_tr
> ansport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm6_tunnel af_key cls_u32 sch_sfq sch_htb nf_conntrack_netlink nfnetli
> nk deflate zlib_deflate ctr camellia cast5 rmd160 sha1_generic crypto_null ccm serpent blowfish twofish twofish_common xcbc sha256_generic sha512_generic des_generi
> c cryptd aes_x86_64 aes_generic tunnel4 xfrm_ipcomp tunnel6 xt_MARK xt_tcpudp xt_esp ipt_ah xt_TCPMSS xt_HL xt_DSCP ipt_MASQUERADE ipt_REDIRECT ipt_LOG ipt_REJECT x
> t_mac xt_length xt_hl xt_dscp xt_tcpmss nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp ip_queue iptable_mangle ip
> table_filter xt_mark xt_recent xt_iprange xt_multiport xt_state xt_limit xt_conntrack iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_t
> ables 8021q fbcon tileblit font bitblit garp s
> Jul 2 07:50:17 cerberus1 kernel: oftcursor stp vga16fb vgastate lp shpchp sis_agp parport 8139too 8139cp r8169 mii sata_sis [last unloaded: af_key]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] CPU 0:
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] Modules linked in: authenc xfrm_user ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_tr
> ansport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm6_tunnel af_key cls_u32 sch_sfq sch_htb nf_conntrack_netlink nfnetli
> nk deflate zlib_deflate ctr camellia cast5 rmd160 sha1_generic crypto_null ccm serpent blowfish twofish twofish_common xcbc sha256_generic sha512_generic des_generi
> c cryptd aes_x86_64 aes_generic tunnel4 xfrm_ipcomp tunnel6 xt_MARK xt_tcpudp xt_esp ipt_ah xt_TCPMSS xt_HL xt_DSCP ipt_MASQUERADE ipt_REDIRECT ipt_LOG ipt_REJECT x
> t_mac xt_length xt_hl xt_dscp xt_tcpmss nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp ip_queue iptable_mangle ip
> table_filter xt_mark xt_recent xt_iprange xt_multiport xt_state xt_limit xt_conntrack iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_t
> ables 8021q fbcon tileblit font bitblit garp s
> Jul 2 07:50:17 cerberus1 kernel: oftcursor stp vga16fb vgastate lp shpchp sis_agp parport 8139too 8139cp r8169 mii sata_sis [last unloaded: af_key]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] Pid: 1951, comm: conntrackd Not tainted 2.6.32-23-server #37-Ubuntu ps6002
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RIP: 0010:[<ffffffff814e9f52>] [<ffffffff814e9f52>] __xfrm4_find_bundle+0x52/0xc0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RSP: 0018:ffff880001c03a88 EFLAGS: 00000282
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RAX: 0000000000000000 RBX: ffff880001c03ab8 RCX: ffff880001c00000
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RDX: 000000180c2813ac RSI: ffff880073f9e800 RDI: ffff880073f9e828
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RBP: ffffffff81013cb3 R08: 0000000000000000 R09: ffff880001c03c44
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880001c03a00
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] R13: ffff880001c03c08 R14: ffff88000c299980 R15: ffffffff8155effc
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] FS: 00007fdec3db5700(0000) GS:ffff880001c00000(0000) knlGS:0000000000000000
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] CR2: 0000000000f1d078 CR3: 00000000715c0000 CR4: 00000000000006f0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] Call Trace:
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] <IRQ> [<ffffffff814e9f28>] ? __xfrm4_find_bundle+0x28/0xc0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814ee91e>] ? __xfrm_lookup+0x14e/0x4e0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8146c591>] ? __skb_checksum_complete+0x11/0x20
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814ee71d>] ? __xfrm_policy_check+0x57d/0x630
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814e9ee5>] ? _decode_session4+0x245/0x260
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814eecc6>] ? xfrm_lookup+0x16/0x40
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814eed5b>] ? __xfrm_route_forward+0x6b/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a355d>] ? ip_forward+0x2ed/0x420
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a15ed>] ? ip_rcv_finish+0x12d/0x440
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a1b75>] ? ip_rcv+0x275/0x360
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8153043d>] ? packet_rcv_spkt+0x4d/0x190
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8147236a>] ? netif_receive_skb+0x38a/0x5d0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81534be0>] ? __vlan_hwaccel_rx+0x140/0x230
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa0012596>] ? rtl8169_rx_interrupt+0x216/0x5b0 [r8169]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa0012aad>] ? rtl8169_poll+0x3d/0x270 [r8169]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81472e5f>] ? net_rx_action+0x10f/0x250
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8106e2f7>] ? __do_softirq+0xb7/0x1e0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff810142ec>] ? call_softirq+0x1c/0x30
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] <EOI> [<ffffffff81015cb5>] ? do_softirq+0x65/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8106e77a>] ? local_bh_enable+0x9a/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00b6185>] ? ipt_do_table+0x295/0x678 [ip_tables]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8106e77a>] ? local_bh_enable+0x9a/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00b6185>] ? ipt_do_table+0x295/0x678 [ip_tables]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8110ce7b>] ? __krealloc+0x3b/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00cb983>] ? __nf_ct_ext_add+0x143/0x180 [nf_conntrack]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff811330fd>] ? ksize+0x1d/0xd0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8110ce7b>] ? __krealloc+0x3b/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00f91d4>] ? nf_nat_rule_find+0x24/0x80 [iptable_nat]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00f9469>] ? nf_nat_fn+0x109/0x1b0 [iptable_nat]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00f9558>] ? nf_nat_local_fn+0x48/0xe0 [iptable_nat]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814997cc>] ? nf_iterate+0x6c/0xb0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a4b40>] ? dst_output+0x0/0x20
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81499884>] ? nf_hook_slow+0x74/0x100
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a4b40>] ? dst_output+0x0/0x20
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a6c9f>] ? __ip_local_out+0x9f/0xb0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a6cc6>] ? ip_local_out+0x16/0x30
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a6f72>] ? ip_push_pending_frames+0x292/0x420
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814c9210>] ? udp_push_pending_frames+0x170/0x410
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814c9ef2>] ? udp_sendmsg+0x4e2/0x850
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814d2249>] ? inet_sendmsg+0x29/0x60
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff812862ed>] ? aa_revalidate_sk+0x6d/0x90
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81283bb9>] ? apparmor_socket_sendmsg+0x19/0x20
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814618ab>] ? sock_sendmsg+0x10b/0x140
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81085090>] ? autoremove_wake_function+0x0/0x40
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81085090>] ? autoremove_wake_function+0x0/0x40
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8113f3d5>] ? __mem_cgroup_try_charge+0x55/0x1f0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff810fa819>] ? __alloc_pages_nodemask+0xd9/0x180
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81461a65>] ? sys_sendto+0x125/0x180
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81115d7f>] ? handle_mm_fault+0x31f/0x3c0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8155c883>] ? do_page_fault+0x153/0x3b0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff810131b2>] ? system_call_fastpath+0x16/0x1b
note, currently the second machine in the cluster is turned off.. same
behavior with or without it.
I'm seriously inclined to think that the VLAN is a big factor:
the reason for the VLAN is to separate VOIP phones (nothing else on that
VLAN). this morning, it was possible to trigger the lockup by placing a call.
as soon as the call was hungup, everything returned to normal...
it's not repeatable, exactly. what seems to happen is that pings through the
machine get slower and slower over the course of a few hours (from say 15ms to
50ms), then all of a sudden the machine will throw a five minute 'fit'.
PS: this is a Ubuntu Lucid kernel - 2.6.32. I'm working on a stock kernel to
see if it still happens..
^ permalink raw reply
* Re: iwl3945: HARDWARE GONE??
From: Stephen Hemminger @ 2010-07-02 16:48 UTC (permalink / raw)
To: John W. Linville; +Cc: Priit Laes, netdev, linux-kernel
In-Reply-To: <20100702162650.GC2381@tuxdriver.com>
On Fri, 2 Jul 2010 12:26:50 -0400
"John W. Linville" <linville@tuxdriver.com> wrote:
> On Fri, Jul 02, 2010 at 07:02:55PM +0300, Priit Laes wrote:
> > Heya!
> >
> > Bumped my kernel to version 2.6.35-rc3-00391-g97e0214 and ran into
> > HARDWARE GONE error message..
> >
> > Hardware is Lenovo x60s and wireless card is intel 3945:
> >
> > 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
> > Subsystem: Intel Corporation ThinkPad R60e/X60s
> > Flags: bus master, fast devsel, latency 0, IRQ 47
> > Memory at edf00000 (32-bit, non-prefetchable) [size=4K]
> > Capabilities: [c8] Power Management version 2
> > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> > Capabilities: [e0] Express Legacy Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [140] Device Serial Number 00-xx-xx-xx-xx-xx-xx-xx
> > Kernel driver in use: iwl3945
> > Kernel modules: iwl3945
> >
> > I have attached dmesg error message...
> >
> > Cheers,
> > Priit :)
>
> > [13813.347617] Uhhuh. NMI received for unknown reason a1 on CPU 0.
> > [13813.347617] You have some hardware problem, likely on the PCI bus.
> > [13813.347617] Dazed and confused, but trying to continue
> > [13813.347617] iwl3945 0000:03:00.0: HARDWARE GONE?? INTA == 0xffffffff
>
> We've been seeing this sort of thing a lot -- somehow the iwl3945 gets
> disconnected from the PCI bus. Anyone have any clue how that happens?
Usually this kind of problem is a power management issue.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/3] ethtool: Change ethtool_op_set_flags to validate flags
From: Randy Dunlap @ 2010-07-02 16:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: Amit Salecha, linux-net-drivers, Dimitris Michailidis,
Stanislaw Gruszka, Amerigo Wang, Jeff, e1000-devel, netdev,
Anirban Chakraborty, Garzik, Vasanthy Kolluri, Brice Goglin,
Andrew Gallatin, Scott Feldman, Stephen Hemminger, David Miller,
Lennert Buytenhek, Roopa Prabhu
In-Reply-To: <1277901872.2082.10.camel@achroite.uk.solarflarecom.com>
On Wed, 30 Jun 2010 13:44:32 +0100 Ben Hutchings wrote:
> ethtool_op_set_flags() does not check for unsupported flags, and has
> no way of doing so. This means it is not suitable for use as a
> default implementation of ethtool_ops::set_flags.
>
> Add a 'supported' parameter specifying the flags that the driver and
> hardware support, validate the requested flags against this, and
> change all current callers to pass this parameter.
>
> Change some other trivial implementations of ethtool_ops::set_flags to
> call ethtool_op_set_flags().
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
> ---
> drivers/net/cxgb4/cxgb4_main.c | 9 +--------
> drivers/net/enic/enic_main.c | 1 -
> drivers/net/ixgbe/ixgbe_ethtool.c | 5 ++++-
> drivers/net/mv643xx_eth.c | 7 ++++++-
> drivers/net/myri10ge/myri10ge.c | 10 +++++++---
> drivers/net/niu.c | 9 +--------
> drivers/net/sfc/ethtool.c | 5 +----
> drivers/net/sky2.c | 16 ++++++----------
> include/linux/ethtool.h | 2 +-
> net/core/ethtool.c | 28 +++++-----------------------
> 10 files changed, 32 insertions(+), 60 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 2c8af09..084ddb3 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -457,7 +457,7 @@ int ethtool_op_set_tso(struct net_device *dev, u32 data);
> u32 ethtool_op_get_ufo(struct net_device *dev);
> int ethtool_op_set_ufo(struct net_device *dev, u32 data);
> u32 ethtool_op_get_flags(struct net_device *dev);
> -int ethtool_op_set_flags(struct net_device *dev, u32 data);
> +int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported);
That one-line change is missing from linux-next-20100702, causing:
drivers/infiniband/ulp/ipoib/ipoib_ethtool.c:157: warning: initialization from incompatible pointer type
but the change (below) to net/core/ethtool.c is merged.
I don't quite see how this happened...
> void ethtool_ntuple_flush(struct net_device *dev);
>
> /**
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index a0f4964..5d42fae 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -144,31 +144,13 @@ u32 ethtool_op_get_flags(struct net_device *dev)
> }
> EXPORT_SYMBOL(ethtool_op_get_flags);
>
> -int ethtool_op_set_flags(struct net_device *dev, u32 data)
> +int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported)
> {
> - const struct ethtool_ops *ops = dev->ethtool_ops;
> - unsigned long features = dev->features;
> -
> - if (data & ETH_FLAG_LRO)
> - features |= NETIF_F_LRO;
> - else
> - features &= ~NETIF_F_LRO;
> -
> - if (data & ETH_FLAG_NTUPLE) {
> - if (!ops->set_rx_ntuple)
> - return -EOPNOTSUPP;
> - features |= NETIF_F_NTUPLE;
> - } else {
> - /* safe to clear regardless */
> - features &= ~NETIF_F_NTUPLE;
> - }
> -
> - if (data & ETH_FLAG_RXHASH)
> - features |= NETIF_F_RXHASH;
> - else
> - features &= ~NETIF_F_RXHASH;
> + if (data & ~supported)
> + return -EINVAL;
>
> - dev->features = features;
> + dev->features = ((dev->features & ~flags_dup_features) |
> + (data & flags_dup_features));
> return 0;
> }
> EXPORT_SYMBOL(ethtool_op_set_flags);
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ 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