Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net-next v2 1/2] net: Add skb_get_hash_noeval
From: Eric Dumazet @ 2014-01-15  0:20 UTC (permalink / raw)
  To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.02.1401141556350.25158@tomh.mtv.corp.google.com>

On Tue, 2014-01-14 at 16:01 -0800, Tom Herbert wrote:
> Function to just return skb->rxhash without checking to see if it needs
> to be recomputed.
> 
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
>  include/linux/skbuff.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index d97f2d0..bbdc847 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -771,6 +771,11 @@ static inline __u32 skb_get_hash(struct sk_buff *skb)
>  	return skb->rxhash;
>  }
>  
> +static inline __u32 skb_get_hash_noeval(struct sk_buff *skb)

const struct sk_buff *skb

> +{
> +	return skb->rxhash;
> +}
> +
>  static inline void skb_clear_hash(struct sk_buff *skb)
>  {
>  	skb->rxhash = 0;

^ permalink raw reply

* Re: [PATCH net-next v2 2/2] net: Check skb->rxhash in gro_receive
From: Eric Dumazet @ 2014-01-15  0:20 UTC (permalink / raw)
  To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.02.1401141555560.25161@tomh.mtv.corp.google.com>

On Tue, 2014-01-14 at 16:02 -0800, Tom Herbert wrote:
> When initializing a gro_list for a packet, first check the rxhash of
> the incoming skb against that of the skb's in the list. This should be
> a very strong inidicator of whether the flow is going to be matched,
> and potentially allows a lot of other checks to be short circuited.
> Use skb_hash_noeval so that we don't force the hash to be calculated.
> 
> Tested by running netperf 200 TCP_STREAMs between two machines with
> GRO, HW rxhash, and 1G. Saw no performance degration, slight reduction
> of time in dev_gro_receive.
> 
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
>  net/core/dev.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)

Acked-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply

* Re: [BUG] eth_type_trans() can access stale data
From: Ben Hutchings @ 2014-01-15  0:21 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1389743541.31367.279.camel@edumazet-glaptop2.roam.corp.google.com>

On Tue, 2014-01-14 at 15:52 -0800, Eric Dumazet wrote:
> Following code :
> 
> if (unlikely(skb->len >= 2 && *(unsigned short *)(skb->data) == 0xFFFF))
> 	return htons(ETH_P_802_3);
> 
> expects the additional bytes are in skb->head
>
> I do not think all eth_type_trans() are ready for a pskb_may_pull()
> (I am too lazy to perform a whole check)
> 
> Would following workaround be OK ?

It seems to be an improvement, as LLC packets will no longer falsely be
marked as Netware raw 802.3.  You don't fix errors in the other
direction, which should be more common, but the lack of bug reports
about that suggests that no-one is using the old Netware protocol any
more, or they're being very careful about which drivers they use.

Ben.

> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
> index 8f032bae60ad..d95403098f09 100644
> --- a/net/ethernet/eth.c
> +++ b/net/ethernet/eth.c
> @@ -194,7 +194,8 @@ __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev)
>  	 *      layer. We look for FFFF which isn't a used 802.2 SSAP/DSAP. This
>  	 *      won't work for fault tolerant netware but does for the rest.
>  	 */
> -	if (unlikely(skb->len >= 2 && *(unsigned short *)(skb->data) == 0xFFFF))
> +	if (unlikely(skb_headlen(skb) >= 2 &&
> +		     *(unsigned short *)(skb->data) == 0xFFFF))
>  		return htons(ETH_P_802_3);
>  
>  	/*



-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply

* [PATCH net-next] tcp: do not export tcp_gso_segment() and tcp_gro_receive()
From: Eric Dumazet @ 2014-01-15  0:31 UTC (permalink / raw)
  To: David Miller; +Cc: netdev

From: Eric Dumazet <edumazet@google.com>

tcp_gso_segment() and tcp_gro_receive() no longer need to be
exported. IPv4 and IPv6 offloads are statically linked.

Note that tcp_gro_complete() is still used by bnx2x, unfortunately.

Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/ipv4/tcp_offload.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
index 771a3950d87a..b92b81718ca4 100644
--- a/net/ipv4/tcp_offload.c
+++ b/net/ipv4/tcp_offload.c
@@ -138,7 +138,6 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb,
 out:
 	return segs;
 }
-EXPORT_SYMBOL(tcp_gso_segment);
 
 struct sk_buff **tcp_gro_receive(struct sk_buff **head, struct sk_buff *skb)
 {
@@ -235,7 +234,6 @@ out:
 
 	return pp;
 }
-EXPORT_SYMBOL(tcp_gro_receive);
 
 int tcp_gro_complete(struct sk_buff *skb)
 {

^ permalink raw reply related

* Re: [PATCH net 0/2] tcp: delete redundant calls of tcp_mtup_init() and
From: David Miller @ 2014-01-15  0:41 UTC (permalink / raw)
  To: panweiping3; +Cc: netdev
In-Reply-To: <cover.1389513042.git.panweiping3@gmail.com>

From: Weiping Pan <panweiping3@gmail.com>
Date: Sun, 12 Jan 2014 15:54:29 +0800

> I find that both tcp_v4_syn_recv_sock() and tcp_v6_syn_recv_sock() call them
> for new sock, so delete redundant calls of them. 
> 
> Weiping Pan (2):
>   tcp: delete redundant calls of tcp_mtup_init()
>   tcp: delete redundant call of tcp_initialize_rcv_mss()

I do not agree with the approach of these two patches.

It is better to have tcp_rcv_state_process() (one location) make these
calls rather than each and every inet sock operations instance.

Therefore you should remove the calls from tcp_v{4,6}_recv_sock() and
keep the one in tcp_rcv_state_process().

Thanks.

^ permalink raw reply

* Re: [RFC PATCH net-next 0/4] net_cls for sys container
From: Eric W. Biederman @ 2014-01-15  0:50 UTC (permalink / raw)
  To: Libo Chen
  Cc: Gao feng, Cong Wang, Simon Horman, Patrick McHardy,
	Linux Kernel Network Developers, jasowang-H+wXaHxf7aLQT0dZR+AlfA,
	Serge Hallyn, pshelar-l0M0P4e3n4LQT0dZR+AlfA, Eric Dumazet,
	cgroups-u79uwXL29TY76Z2rM5mHXA,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	David Miller, LKML, xemul-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <52CA8026.4010106-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> writes:

> yes
> On 2014/1/6 16:42, Gao feng wrote:
>> On 01/06/2014 03:54 PM, Libo Chen wrote:
>>> On 2014/1/3 13:20, Cong Wang wrote:
>>>> On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>>>>> Hi guys,
>>>>>
>>>>> Now, lxc created with veth can not be under control by
>>>>> cls_cgroup.
>>>>>
>>>>> the former discussion:
>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/00214.html
>>>>>
>>>>> In short, because cls_cgroup relys classid attached to sock
>>>>> filter skb, but sock will be cleared inside dev_forward_skb()
>>>>> in veth_xmit().
>>>>
>>>>
>>>> So what are you trying to achieve here?
>>>
>>> sys container using veth can be controlled by cls_cgroup basing on physic network interface
>>>
>> 
>> It's a problem about virtual nic, not container/net namespace.
>
> yes
>
>> 
>> If veth device is running in host. the skb is transmitted firstly by veth device and then delivered
>> by physical device. if you set both qdisc rule on veth and physical device. which qdisc rule will take
>> effect?
>
> both, the end result depends on a smaller.
>
>> 
>> In your patch, both qdisc rule are effective. it looks strange.
>> 
>
> qdisc is based nic, does not distinguish virtual or physics. if you are all set,
> it means that what you want.  so the logic is not the problemI and this appears to be normal.

My personal opinion on the matter is that the network class cgroup is
brain dead and should not be used.  It is impossible to use for
incomming packets, and it is part of the the problem plagued cgroup
subsystem.

You have real network interfaces to do your classification with you
don't need to enhance the network class cgroup.

The more this is asked about the more I think the network class cgroup
should be be taken out into the woods some dark night and left in a
shallow grave, never to bother us again.


Eric

^ permalink raw reply

* Re: [PATCH net-next V4 1/3] net: Add GRO support for UDP encapsulating protocols
From: Eric Dumazet @ 2014-01-15  0:50 UTC (permalink / raw)
  To: Or Gerlitz
  Cc: Tom Herbert, Or Gerlitz, David Miller, Linux Netdev List,
	Jerry Chu, Eric Dumazet, Herbert Xu, Yan Burman, Shlomo Pongratz
In-Reply-To: <CAJZOPZ+1JrMiuh3csp8P56NJ5LphszneO_zwmShut3KxFuxaTQ@mail.gmail.com>

On Tue, 2014-01-14 at 23:51 +0200, Or Gerlitz wrote:

> >> +       rcu_read_lock();
> >> +
> >> +       uo_priv = rcu_dereference(udp_offload_base);
> >> +       for (; uo_priv != NULL; uo_priv = rcu_dereference(uo_priv->next)) {
> >> +               if (uo_priv->offload->port == uh->dest &&
> >> +                   uo_priv->offload->callbacks.gro_complete)
> >> +                       goto found;
> >> +       }
> >> +
> >> +       rcu_read_unlock();
> >> +       return err;
> >> +
> >> +found:
> >> +       atomic_inc(&uo_priv->refcount);
> >
> > This is an expensive operation in the critical path.
> 
> I know, but I don't see how to get away without having the ref/unref
> wrapping, ideas welcome
> 
> > Can uo_priv be protected by rcu also?
> 
> uo_priv is the actual element which is rcu protected, not sure to
> follow on your question.
> 

Seems pretty easy : unlock rcu after calling gro_complete() as in :

found:
       err = uo_priv->offload->callbacks.gro_complete(skb, nhoff + sizeof(struct udphdr));
       rcu_read_unlock();
       return err;

^ permalink raw reply

* Re: [PATCH 0/5] Assorted mvneta fixes
From: David Miller @ 2014-01-15  0:58 UTC (permalink / raw)
  To: w; +Cc: netdev, thomas.petazzoni, gregory.clement, arno, eric.dumazet
In-Reply-To: <1389519069-1619-1-git-send-email-w@1wt.eu>

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 12 Jan 2014 10:31:04 +0100

> this series provides some fixes for a number of issues met with the
> mvneta driver :

These do not apply cleanly to net-next, particularly patch #5 has
different file offsets and patch #6 gets rejects.

Please respin this series, thanks.

^ permalink raw reply

* Re: [PATCH net-next 3/3] ipv6: add ip6_flowlabel_consistency sysctl
From: Hannes Frederic Sowa @ 2014-01-15  0:59 UTC (permalink / raw)
  To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1389721816-21165-3-git-send-email-florent.fourcot@enst-bretagne.fr>

On Tue, Jan 14, 2014 at 06:50:16PM +0100, Florent Fourcot wrote:
> diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
> index 653cbbd..7c32501 100644
> --- a/kernel/sysctl_binary.c
> +++ b/kernel/sysctl_binary.c
> @@ -557,6 +557,7 @@ static const struct bin_table bin_net_ipv6_table[] = {
>  	{ CTL_DIR,	NET_IPV6_ROUTE,		"route",	bin_net_ipv6_route_table },
>  	{ CTL_DIR,	NET_IPV6_ICMP,		"icmp",		bin_net_ipv6_icmp_table },
>  	{ CTL_INT,	NET_IPV6_BINDV6ONLY,		"bindv6only" },
> +	{ CTL_INT,	NET_IPV6_FLOWLABEL_CONSISTENCY,	"ip6_flowlabel_consistency" },
>  	{ CTL_INT,	NET_IPV6_IP6FRAG_HIGH_THRESH,	"ip6frag_high_thresh" },
>  	{ CTL_INT,	NET_IPV6_IP6FRAG_LOW_THRESH,	"ip6frag_low_thresh" },
>  	{ CTL_INT,	NET_IPV6_IP6FRAG_TIME,		"ip6frag_time" },

This hunk is not necessary and should get removed. bin_tables are legacy. Also
I didn't see NET_IPV6_FLOWLABEL_CONSISTENCY getting defined. ;)

Greetings,

  Hannes

^ permalink raw reply

* Re: [PATCH net-next 0/6] mvneta driver performance improvements
From: David Miller @ 2014-01-15  1:00 UTC (permalink / raw)
  To: w; +Cc: netdev
In-Reply-To: <1389525848-1814-1-git-send-email-w@1wt.eu>

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 12 Jan 2014 12:24:02 +0100

> this patch series implements several performance improvements on the
> mvneta driver.

Ignore that last email, I meant to say that this series did not apply
cleanly to net-next, sorry for the confusion.

^ permalink raw reply

* [Patch net-next] net_sched: act: remove headers in include/net/tc_act/
From: Cong Wang @ 2014-01-15  1:01 UTC (permalink / raw)
  To: netdev; +Cc: Cong Wang, Jamal Hadi Salim, David S. Miller

These headers are not necessary because those definitions in them
are action specific and are not shared for others. Just move them
into the C files.

Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
 include/net/tc_act/tc_csum.h    | 15 ---------------
 include/net/tc_act/tc_defact.h  | 14 --------------
 include/net/tc_act/tc_gact.h    | 17 -----------------
 include/net/tc_act/tc_ipt.h     | 17 -----------------
 include/net/tc_act/tc_mirred.h  | 17 -----------------
 include/net/tc_act/tc_nat.h     | 21 ---------------------
 include/net/tc_act/tc_pedit.h   | 15 ---------------
 include/net/tc_act/tc_skbedit.h | 35 -----------------------------------
 net/sched/act_csum.c            | 10 +++++++++-
 net/sched/act_gact.c            | 14 +++++++++++++-
 net/sched/act_ipt.c             | 12 +++++++++++-
 net/sched/act_mirred.c          | 13 ++++++++++++-
 net/sched/act_nat.c             | 17 ++++++++++++++++-
 net/sched/act_pedit.c           | 11 ++++++++++-
 net/sched/act_simple.c          | 10 +++++++++-
 net/sched/act_skbedit.c         | 13 ++++++++++++-
 16 files changed, 92 insertions(+), 159 deletions(-)
 delete mode 100644 include/net/tc_act/tc_csum.h
 delete mode 100644 include/net/tc_act/tc_defact.h
 delete mode 100644 include/net/tc_act/tc_gact.h
 delete mode 100644 include/net/tc_act/tc_ipt.h
 delete mode 100644 include/net/tc_act/tc_mirred.h
 delete mode 100644 include/net/tc_act/tc_nat.h
 delete mode 100644 include/net/tc_act/tc_pedit.h
 delete mode 100644 include/net/tc_act/tc_skbedit.h

diff --git a/include/net/tc_act/tc_csum.h b/include/net/tc_act/tc_csum.h
deleted file mode 100644
index 9e8710b..0000000
--- a/include/net/tc_act/tc_csum.h
+++ /dev/null
@@ -1,15 +0,0 @@
-#ifndef __NET_TC_CSUM_H
-#define __NET_TC_CSUM_H
-
-#include <linux/types.h>
-#include <net/act_api.h>
-
-struct tcf_csum {
-	struct tcf_common common;
-
-	u32 update_flags;
-};
-#define to_tcf_csum(pc) \
-	container_of(pc,struct tcf_csum,common)
-
-#endif /* __NET_TC_CSUM_H */
diff --git a/include/net/tc_act/tc_defact.h b/include/net/tc_act/tc_defact.h
deleted file mode 100644
index 65f024b..0000000
--- a/include/net/tc_act/tc_defact.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef __NET_TC_DEF_H
-#define __NET_TC_DEF_H
-
-#include <net/act_api.h>
-
-struct tcf_defact {
-	struct tcf_common	common;
-	u32     		tcfd_datalen;
-	void    		*tcfd_defdata;
-};
-#define to_defact(pc) \
-	container_of(pc, struct tcf_defact, common)
-
-#endif /* __NET_TC_DEF_H */
diff --git a/include/net/tc_act/tc_gact.h b/include/net/tc_act/tc_gact.h
deleted file mode 100644
index 9e3f676..0000000
--- a/include/net/tc_act/tc_gact.h
+++ /dev/null
@@ -1,17 +0,0 @@
-#ifndef __NET_TC_GACT_H
-#define __NET_TC_GACT_H
-
-#include <net/act_api.h>
-
-struct tcf_gact {
-	struct tcf_common	common;
-#ifdef CONFIG_GACT_PROB
-        u16			tcfg_ptype;
-        u16			tcfg_pval;
-        int			tcfg_paction;
-#endif
-};
-#define to_gact(pc) \
-	container_of(pc, struct tcf_gact, common)
-
-#endif /* __NET_TC_GACT_H */
diff --git a/include/net/tc_act/tc_ipt.h b/include/net/tc_act/tc_ipt.h
deleted file mode 100644
index f7d25df..0000000
--- a/include/net/tc_act/tc_ipt.h
+++ /dev/null
@@ -1,17 +0,0 @@
-#ifndef __NET_TC_IPT_H
-#define __NET_TC_IPT_H
-
-#include <net/act_api.h>
-
-struct xt_entry_target;
-
-struct tcf_ipt {
-	struct tcf_common	common;
-	u32			tcfi_hook;
-	char			*tcfi_tname;
-	struct xt_entry_target	*tcfi_t;
-};
-#define to_ipt(pc) \
-	container_of(pc, struct tcf_ipt, common)
-
-#endif /* __NET_TC_IPT_H */
diff --git a/include/net/tc_act/tc_mirred.h b/include/net/tc_act/tc_mirred.h
deleted file mode 100644
index cfe2943..0000000
--- a/include/net/tc_act/tc_mirred.h
+++ /dev/null
@@ -1,17 +0,0 @@
-#ifndef __NET_TC_MIR_H
-#define __NET_TC_MIR_H
-
-#include <net/act_api.h>
-
-struct tcf_mirred {
-	struct tcf_common	common;
-	int			tcfm_eaction;
-	int			tcfm_ifindex;
-	int			tcfm_ok_push;
-	struct net_device	*tcfm_dev;
-	struct list_head	tcfm_list;
-};
-#define to_mirred(pc) \
-	container_of(pc, struct tcf_mirred, common)
-
-#endif /* __NET_TC_MIR_H */
diff --git a/include/net/tc_act/tc_nat.h b/include/net/tc_act/tc_nat.h
deleted file mode 100644
index 4a691f3..0000000
--- a/include/net/tc_act/tc_nat.h
+++ /dev/null
@@ -1,21 +0,0 @@
-#ifndef __NET_TC_NAT_H
-#define __NET_TC_NAT_H
-
-#include <linux/types.h>
-#include <net/act_api.h>
-
-struct tcf_nat {
-	struct tcf_common common;
-
-	__be32 old_addr;
-	__be32 new_addr;
-	__be32 mask;
-	u32 flags;
-};
-
-static inline struct tcf_nat *to_tcf_nat(struct tcf_common *pc)
-{
-	return container_of(pc, struct tcf_nat, common);
-}
-
-#endif /* __NET_TC_NAT_H */
diff --git a/include/net/tc_act/tc_pedit.h b/include/net/tc_act/tc_pedit.h
deleted file mode 100644
index e6f6e15..0000000
--- a/include/net/tc_act/tc_pedit.h
+++ /dev/null
@@ -1,15 +0,0 @@
-#ifndef __NET_TC_PED_H
-#define __NET_TC_PED_H
-
-#include <net/act_api.h>
-
-struct tcf_pedit {
-	struct tcf_common	common;
-	unsigned char		tcfp_nkeys;
-	unsigned char		tcfp_flags;
-	struct tc_pedit_key	*tcfp_keys;
-};
-#define to_pedit(pc) \
-	container_of(pc, struct tcf_pedit, common)
-
-#endif /* __NET_TC_PED_H */
diff --git a/include/net/tc_act/tc_skbedit.h b/include/net/tc_act/tc_skbedit.h
deleted file mode 100644
index dd5d86f..0000000
--- a/include/net/tc_act/tc_skbedit.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright (c) 2008, Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, see <http://www.gnu.org/licenses/>.
- *
- * Author: Alexander Duyck <alexander.h.duyck@intel.com>
- */
-
-#ifndef __NET_TC_SKBEDIT_H
-#define __NET_TC_SKBEDIT_H
-
-#include <net/act_api.h>
-
-struct tcf_skbedit {
-	struct tcf_common	common;
-	u32			flags;
-	u32     		priority;
-	u32     		mark;
-	u16			queue_mapping;
-	/* XXX: 16-bit pad here? */
-};
-#define to_skbedit(pc) \
-	container_of(pc, struct tcf_skbedit, common)
-
-#endif /* __NET_TC_SKBEDIT_H */
diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
index ee28e1c..c0da35b 100644
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -34,7 +34,15 @@
 #include <net/act_api.h>
 
 #include <linux/tc_act/tc_csum.h>
-#include <net/tc_act/tc_csum.h>
+#include <linux/types.h>
+
+struct tcf_csum {
+	struct tcf_common common;
+
+	u32 update_flags;
+};
+#define to_tcf_csum(pc) \
+	container_of(pc,struct tcf_csum,common)
 
 #define CSUM_TAB_MASK 15
 static struct tcf_hashinfo csum_hash_info;
diff --git a/net/sched/act_gact.c b/net/sched/act_gact.c
index f26e6b8..c5e7491 100644
--- a/net/sched/act_gact.c
+++ b/net/sched/act_gact.c
@@ -21,7 +21,19 @@
 #include <net/netlink.h>
 #include <net/pkt_sched.h>
 #include <linux/tc_act/tc_gact.h>
-#include <net/tc_act/tc_gact.h>
+
+#include <net/act_api.h>
+
+struct tcf_gact {
+	struct tcf_common	common;
+#ifdef CONFIG_GACT_PROB
+        u16			tcfg_ptype;
+        u16			tcfg_pval;
+        int			tcfg_paction;
+#endif
+};
+#define to_gact(pc) \
+	container_of(pc, struct tcf_gact, common)
 
 #define GACT_TAB_MASK	15
 static struct tcf_hashinfo gact_hash_info;
diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
index 484bd19..469c066 100644
--- a/net/sched/act_ipt.c
+++ b/net/sched/act_ipt.c
@@ -23,10 +23,20 @@
 #include <net/netlink.h>
 #include <net/pkt_sched.h>
 #include <linux/tc_act/tc_ipt.h>
-#include <net/tc_act/tc_ipt.h>
 
+#include <net/act_api.h>
 #include <linux/netfilter_ipv4/ip_tables.h>
 
+struct xt_entry_target;
+
+struct tcf_ipt {
+	struct tcf_common	common;
+	u32			tcfi_hook;
+	char			*tcfi_tname;
+	struct xt_entry_target	*tcfi_t;
+};
+#define to_ipt(pc) \
+	container_of(pc, struct tcf_ipt, common)
 
 #define IPT_TAB_MASK     15
 static struct tcf_hashinfo ipt_hash_info;
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 5d05b57..0024525 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -25,9 +25,20 @@
 #include <net/netlink.h>
 #include <net/pkt_sched.h>
 #include <linux/tc_act/tc_mirred.h>
-#include <net/tc_act/tc_mirred.h>
 
 #include <linux/if_arp.h>
+#include <net/act_api.h>
+
+struct tcf_mirred {
+	struct tcf_common	common;
+	int			tcfm_eaction;
+	int			tcfm_ifindex;
+	int			tcfm_ok_push;
+	struct net_device	*tcfm_dev;
+	struct list_head	tcfm_list;
+};
+#define to_mirred(pc) \
+	container_of(pc, struct tcf_mirred, common)
 
 #define MIRRED_TAB_MASK     7
 static LIST_HEAD(mirred_list);
diff --git a/net/sched/act_nat.c b/net/sched/act_nat.c
index a49fa23..4039399 100644
--- a/net/sched/act_nat.c
+++ b/net/sched/act_nat.c
@@ -24,10 +24,25 @@
 #include <net/icmp.h>
 #include <net/ip.h>
 #include <net/netlink.h>
-#include <net/tc_act/tc_nat.h>
 #include <net/tcp.h>
 #include <net/udp.h>
 
+#include <linux/types.h>
+#include <net/act_api.h>
+
+struct tcf_nat {
+	struct tcf_common common;
+
+	__be32 old_addr;
+	__be32 new_addr;
+	__be32 mask;
+	u32 flags;
+};
+
+static inline struct tcf_nat *to_tcf_nat(struct tcf_common *pc)
+{
+	return container_of(pc, struct tcf_nat, common);
+}
 
 #define NAT_TAB_MASK	15
 
diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index f361e4e..9222ac7 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -21,7 +21,16 @@
 #include <net/netlink.h>
 #include <net/pkt_sched.h>
 #include <linux/tc_act/tc_pedit.h>
-#include <net/tc_act/tc_pedit.h>
+#include <net/act_api.h>
+
+struct tcf_pedit {
+	struct tcf_common	common;
+	unsigned char		tcfp_nkeys;
+	unsigned char		tcfp_flags;
+	struct tc_pedit_key	*tcfp_keys;
+};
+#define to_pedit(pc) \
+	container_of(pc, struct tcf_pedit, common)
 
 #define PEDIT_TAB_MASK	15
 
diff --git a/net/sched/act_simple.c b/net/sched/act_simple.c
index f7d5406..8f695bb 100644
--- a/net/sched/act_simple.c
+++ b/net/sched/act_simple.c
@@ -22,7 +22,15 @@
 #define TCA_ACT_SIMP 22
 
 #include <linux/tc_act/tc_defact.h>
-#include <net/tc_act/tc_defact.h>
+#include <net/act_api.h>
+
+struct tcf_defact {
+	struct tcf_common	common;
+	u32     		tcfd_datalen;
+	void    		*tcfd_defdata;
+};
+#define to_defact(pc) \
+	container_of(pc, struct tcf_defact, common)
 
 #define SIMP_TAB_MASK     7
 static struct tcf_hashinfo simp_hash_info;
diff --git a/net/sched/act_skbedit.c b/net/sched/act_skbedit.c
index 74af461..b9d27e7 100644
--- a/net/sched/act_skbedit.c
+++ b/net/sched/act_skbedit.c
@@ -25,7 +25,18 @@
 #include <net/pkt_sched.h>
 
 #include <linux/tc_act/tc_skbedit.h>
-#include <net/tc_act/tc_skbedit.h>
+#include <net/act_api.h>
+
+struct tcf_skbedit {
+	struct tcf_common	common;
+	u32			flags;
+	u32     		priority;
+	u32     		mark;
+	u16			queue_mapping;
+	/* XXX: 16-bit pad here? */
+};
+#define to_skbedit(pc) \
+	container_of(pc, struct tcf_skbedit, common)
 
 #define SKBEDIT_TAB_MASK     15
 static struct tcf_hashinfo skbedit_hash_info;
-- 
1.8.3.1

^ permalink raw reply related

* Re: [PATCH] ipv4: delete the statements limit icmp message in ip_error()
From: David Miller @ 2014-01-15  1:04 UTC (permalink / raw)
  To: duanj.fnst; +Cc: netdev
In-Reply-To: <52D265D4.9050600@cn.fujitsu.com>

From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Sun, 12 Jan 2014 17:52:20 +0800

> Because after the icmp_send() is called, the icmpv4_xrlim_allow()
> will be called to limit the icmp message too.
> 
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>

icmpv4_xrlim_allow() is different from what this code is doing.

There are seperate controls for ip_error() reporting, namely:

> -		if (peer->rate_tokens > ip_rt_error_burst)
 ...
> -		if (peer->rate_tokens >= ip_rt_error_cost)

And this is the only place where that is taken into account.

The icmpv4_xrlim_allow() is a top level limiting on all ICMPs,
this function is limiting specific kinds.

I am not applying this patch, sorry.

^ permalink raw reply

* Re: [PATCH] MAINTAINERS: add virtio-dev ML for virtio
From: David Miller @ 2014-01-15  1:10 UTC (permalink / raw)
  To: mst
  Cc: virtio-dev, gregkh, linux-kernel, virtualization, amit.shah,
	netdev, joe, akpm, m.chehab
In-Reply-To: <20140112113756.GA9127@redhat.com>

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 12 Jan 2014 13:37:56 +0200

> Since virtio is an OASIS standard draft now, virtio implementation
> discussions are taking place on the virtio-dev OASIS mailing list.
> Update MAINTAINERS.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next] bnx2x: Correct default Tx switching behaviour
From: David Miller @ 2014-01-15  1:11 UTC (permalink / raw)
  To: yuvalmin; +Cc: netdev, ariele
In-Reply-To: <1389530279-14963-1-git-send-email-yuvalmin@broadcom.com>

From: Yuval Mintz <yuvalmin@broadcom.com>
Date: Sun, 12 Jan 2014 14:37:59 +0200

> With this patch bnx2x will configure the PF to perform Tx switching on
> out-going traffic as soon as SR-IOV is dynamically enabled and de-activate
> it when it is disabled.
> This will allow VFs to communicate with their parent PFs.
> 
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>

Applied.

^ permalink raw reply

* Re: [PATCH TRIVIAL] net: amd8111e: Spelling s/recive/receive/
From: David Miller @ 2014-01-15  1:11 UTC (permalink / raw)
  To: geert; +Cc: trivial, netdev, geert+renesas
In-Reply-To: <1389531772-6154-1-git-send-email-geert@linux-m68k.org>

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sun, 12 Jan 2014 14:02:52 +0100

> From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>

Applied.

^ permalink raw reply

* Re: [PATCH TRIVIAL] net: Spelling s/transmition/transmission/
From: David Miller @ 2014-01-15  1:11 UTC (permalink / raw)
  To: geert; +Cc: andy, trivial, netdev, linux-wireless, geert+renesas
In-Reply-To: <1389531976-6350-1-git-send-email-geert@linux-m68k.org>

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sun, 12 Jan 2014 14:06:16 +0100

> From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>

Applied.

^ permalink raw reply

* Re: [Patch net-next] net_sched: act: remove headers in include/net/tc_act/
From: Eric Dumazet @ 2014-01-15  1:11 UTC (permalink / raw)
  To: Cong Wang; +Cc: netdev, Jamal Hadi Salim, David S. Miller
In-Reply-To: <1389747699-32508-1-git-send-email-xiyou.wangcong@gmail.com>

On Tue, 2014-01-14 at 17:01 -0800, Cong Wang wrote:
> These headers are not necessary because those definitions in them
> are action specific and are not shared for others. Just move them
> into the C files.
> 
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---

I find this change very dubious.

^ permalink raw reply

* Re: [PATCH net-next 3/3] packet: use percpu mmap tx frame pending refcount
From: David Miller @ 2014-01-15  1:16 UTC (permalink / raw)
  To: dborkman; +Cc: netdev
In-Reply-To: <1389543768-20234-4-git-send-email-dborkman@redhat.com>

From: Daniel Borkmann <dborkman@redhat.com>
Date: Sun, 12 Jan 2014 17:22:48 +0100

> +static int packet_read_pending(const struct packet_ring_buffer *rb)
> +{
> +	int i, refcnt = 0;
> +
> +	/* We don't use pending refcount in rx_ring. */
> +	if (rb->pending_refcnt == NULL)
> +		return 0;
> +
> +	for_each_possible_cpu(i)
> +		refcnt += *per_cpu_ptr(rb->pending_refcnt, i);
> +
> +	return refcnt;
> +}

David Laight stated that this works properly only if all the arithmetic
is unsigned.

Therefore, maybe use "unsigned int" for refcnt here?

Can you respin this series with that fixed?

Thanks.

^ permalink raw reply

* Re: [Patch net-next] net_sched: act: remove headers in include/net/tc_act/
From: Cong Wang @ 2014-01-15  1:17 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Cong Wang, netdev, Jamal Hadi Salim, David S. Miller
In-Reply-To: <1389748310.31367.298.camel@edumazet-glaptop2.roam.corp.google.com>

On Tue, Jan 14, 2014 at 5:11 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-01-14 at 17:01 -0800, Cong Wang wrote:
>> These headers are not necessary because those definitions in them
>> are action specific and are not shared for others. Just move them
>> into the C files.
>>
>> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>> ---
>
> I find this change very dubious.

grep told me it isn't:

$ git grep 'include.*tc_act/'
net/sched/act_csum.c:#include <linux/tc_act/tc_csum.h>
net/sched/act_gact.c:#include <linux/tc_act/tc_gact.h>
net/sched/act_ipt.c:#include <linux/tc_act/tc_ipt.h>
net/sched/act_mirred.c:#include <linux/tc_act/tc_mirred.h>
net/sched/act_nat.c:#include <linux/tc_act/tc_nat.h>
net/sched/act_pedit.c:#include <linux/tc_act/tc_pedit.h>
net/sched/act_simple.c:#include <linux/tc_act/tc_defact.h>
net/sched/act_skbedit.c:#include <linux/tc_act/tc_skbedit.h>

(those are uapi headers, which I don't touch.)

^ permalink raw reply

* Re: [PATCH net-next 10/10] net: nl80211: __dev_get_by_index instead of dev_get_by_index to find interface
From: Ying Xue @ 2014-01-15  1:18 UTC (permalink / raw)
  To: Johannes Berg
  Cc: davem, vfalico, john.r.fastabend, stephen, antonio,
	dmitry.tarnyagin, socketcan, netdev, linux-kernel
In-Reply-To: <1389701498.23430.1.camel@jlt4.sipsolutions.net>

On 01/14/2014 08:11 PM, Johannes Berg wrote:
> On Tue, 2014-01-14 at 15:41 +0800, Ying Xue wrote:
> 
>> @@ -2218,10 +2194,6 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
>>  			rdev->wiphy.coverage_class = old_coverage_class;
>>  		}
>>  	}
>> -
>> - bad_res:
>> -	if (netdev)
>> -		dev_put(netdev);
>>  	return result;
> 
> I believe that could be "return 0;" now, which would make the code
> easier to read.
> 

Yes, I will change it in next version.

Thanks,
Ying

> johannes
> 
> 
> 

^ permalink raw reply

* Re: [PATCH v2 0/3] atheros: modify statistics code
From: David Miller @ 2014-01-15  1:18 UTC (permalink / raw)
  To: sd; +Cc: netdev, bhutchings, jcliburn, chris.snook
In-Reply-To: <1389549040-8785-1-git-send-email-sd@queasysnail.net>

From: Sabrina Dubroca <sd@queasysnail.net>
Date: Sun, 12 Jan 2014 18:50:37 +0100

> Following Ben Hutchings's advice on how to fill net_stats in alx [1],
> this patch modifies the other atheros ethernet drivers
> similarly. Minor whitespace/empty line changes in atl1c and atl1e to
> make the code completely consistent between atl1c, atl1e, and alx.
> 
> I don't have this hardware, so these patches have only been
> compile-tested.

Series applied, thanks Sabrina.

^ permalink raw reply

* Re: [PATCH] net: Check skb->rxhash in gro_receive
From: Ben Hutchings @ 2014-01-15  1:31 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, therbert, netdev
In-Reply-To: <1389649061.31367.236.camel@edumazet-glaptop2.roam.corp.google.com>

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

On Mon, 2014-01-13 at 13:37 -0800, Eric Dumazet wrote:
> On Mon, 2014-01-13 at 20:50 +0000, Ben Hutchings wrote:
> 
> > According to the original report of that vulnerability:
> > 
> > > skb_flow_dissect() were used by several places:                         
> > > - packet scheduler that want classify flows                             
> > > - skb_get_rxhash() that will be used by RPS, vxlan, multiqueue          
> > > tap,macvtap packet fanout                                               
> > > - skb_probe_transport_header() which was used for probing transport     
> > > header for DODGY packets                                                
> > > - __skb_get_poff() which will be used by socket filter             
> > 
> > So flow dissector is already part of the attack surface for both local
> > and remote users in common configurations.
> 
> Take a debian or Android distro, and this bug is not hit on 'common
> configurations'. Send them a 'packet of death', they will not hang,
> unless some admin set up RPS/RFS on the incoming device.
[...]

When I investigated the scope of this for Debian, I tried sending a
'packet of death' to a VM and actually triggered the lockup in the TX
path of the *host*, running Debian unstable with Linux 3.11.  I didn't
track down exactly why that was but I think that libvirt's default
networking configuration includes multiqueue devices that use flow
dissector.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
                                                               - John Lennon

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* Re: [RFC] sysfs_rename_link() and its usage
From: Eric W. Biederman @ 2014-01-15  1:35 UTC (permalink / raw)
  To: Veaceslav Falico; +Cc: Greg KH, linux-kernel, netdev, Tejun Heo
In-Reply-To: <20140114210610.GC9942@redhat.com>

Veaceslav Falico <vfalico@redhat.com> writes:

> On Tue, Jan 14, 2014 at 11:31:39AM -0800, Greg KH wrote:
>>On Tue, Jan 14, 2014 at 08:12:08PM +0100, Veaceslav Falico wrote:
>>> On Tue, Jan 14, 2014 at 10:21:35AM -0800, Greg KH wrote:
>>> >On Tue, Jan 14, 2014 at 06:17:40PM +0100, Veaceslav Falico wrote:
>>> >>Hi,
>>> >>
>>> >>I'm hitting a strange issue and/or I'm completely lost in sysfs internals.
>>> >>
>>> >>Consider having two net_device *a, *b; which are registered normally.
>>> >>Now, to create a link from /sys/class/net/a->name/linkname to b, one should
>>> >>use:
>>> >>
>>> >>sysfs_create_link(&(a->dev.kobj), &(b->dev.kobj), linkname);
>>> >>
>>> >>To remove it, even simpler:
>>> >>
>>> >>sysfs_remove_link(&(a->dev.kobj), linkname);
>>> >>
>>> >>This works like a charm. However, if I want to use (obviously, with the
>>> >>symlink present):
>>> >>
>>> >>sysfs_rename_link(&(a->dev.kobj), &(b->dev.kobj), oldname, newname);
>>> >
>>> >You forgot the namespace option to this call, what kernel version are
>>> >you using here?
>>>
>>> It's git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next ,
>>> 3.13-rc6 with some networking patches on top of it.
>>>
>>> And wrt namespace - there are two functions, one is sysfs_rename_link(),
>>> which calls the second one - sysfs_rename_link_ns() with NULL namespace.
>>>
>>> >
>>> >>this fails with:
>>> >>
>>> >>"sysfs: ns invalid in 'a->name' for 'oldname'"
>>> >
>>> >Looks like the namespace for this link isn't valid.
>>>
>>> Yep, though dunno why.
>>
>>Are you testing this with network namespaces enabled?  Perhaps that is
>>why, you need to specify the namespace of the link that you are
>>changing.
>>
>>The fact that the bridge link works is odd to me, I would think that it
>>too needs to specify the network namespace involved, but perhaps bridge
>>objects aren't part of any specific network namespace?  I don't know the
>>bridging code at all, sorry.
>
> Yep, might be it, will test soon and come back with the results.
>
> What still bugs me, though, is the logic - why is it possible to remove/add
> without specifying namespace, while it fails to rename it? Maybe the rename
> function should do a better job at detecting the namespace?

The basic sysfs_rename primitive and device_rename support moving
network devices across namespaces.  Since the new name can be in a new
namespace the network namespace the new network namespace needs to be
specified.

The reason the bridge code is different is that apparently Tejun broke
the bridge code when he converted sysfs.  Apparently no one has tested
the appropriate bridge path with network namespaces enabled and screamed
yet.

sysfs_rename_link was originally written to infer figure everything out
based on the target device.  Because symlinks only make sense being in
the same namespace of their devices.  Tejun broke the inference and now
you are having hard time using the code.

Tejun could you please take care of this breakage.

The commit that broke things was:

commit 4b30ee58ee64c64f59fd876e4afa6ed82caef3a4
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 11 22:29:06 2013 -0400

    sysfs: remove ktype->namespace() invocations in symlink code
    
    There's no reason for sysfs to be calling ktype->namespace().  It is
    backwards, obfuscates what's going on and unnecessarily tangles two
    separate layers.
    
    There are two places where symlink code calls ktype->namespace().
    
    * sysfs_do_create_link_sd() calls it to find out the namespace tag of
      the target directory.  Unless symlinking races with cross-namespace
      renaming, this equals @target_sd->s_ns.
    
    * sysfs_rename_link() uses it to find out the new namespace to rename
      to and the new namespace can be different from the existing one.
      The function is renamed to sysfs_rename_link_ns() with an explicit
      @ns argument and the ktype->namespace() invocation is shifted to the
      device layer.
    
    While this patch replaces ktype->namespace() invocation with the
    recorded result in @target_sd, this shouldn't result in any behvior
    difference.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Kay Sievers <kay@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Eric

^ permalink raw reply

* Re: [PATCH] dm9601: add USB IDs for new dm96xx variants
From: David Miller @ 2014-01-15  1:36 UTC (permalink / raw)
  To: peter; +Cc: netdev, joseph_chang
In-Reply-To: <1389564951-7049-1-git-send-email-peter@korsgaard.com>

From: Peter Korsgaard <peter@korsgaard.com>
Date: Sun, 12 Jan 2014 23:15:51 +0100

> A number of new dm96xx variants now exist.
> 
> Reported-by: Joseph Chang <joseph_chang@davicom.com.tw>
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

Applied, thank you.

^ permalink raw reply

* unable to send TCP SYNs from ports below 1024
From: Stuart Kendrick @ 2014-01-15  1:37 UTC (permalink / raw)
  To: netdev

I'm working on a box which refuses to send TCP SYNs from source ports below 1024
[This breaks NFS-mounting, as the NFS client wants to use source ports
below 1024]

Linux ubuntu 3.8.0-35-generic #50~precise1-Ubuntu SMP Wed Dec 4
17:25:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

In a fit of pique, I wiped and rebuilt from scratch a couple weeks ago
... didn't help


VALIDATION
I verify the problem by using netcat plus two instances of tcpdump,
one running on the box itself, the other running on a second box
plugged into a SPAN port on the local Ethernet switch

This invocation produces TCP SYNs in both traces
ubuntu# nc -4 -p 1024 10.1.1.1 2049

Whereas this invocation produces TCP SYNs only in the on-board pcap --
the pcap taken from the switch's SPAN port contains nothing (well, it
contains the ARP exchange for 10.1.1.1, but not TCP frames).
ubuntu# nc -4 -p 1023 10.1.1.1 2049

The NIC carries all sorts of other traffic just fine ... http, https,
sftp, ftp, ssh ... but all those employ TCP source ports above 1024.


RULED OUT
(1) No iptables rules
ubuntu# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ubuntu#


(2) ufw disabled
ubuntu# ufw status
Status: inactive
ubuntu#


(3) I've tried two different NICs, one employing the e1000e driver,
the other the e1000 driver:
ubuntu# modinfo e1000e | more
filename:
/lib/modules/3.8.0-35-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
version:        2.1.4-k
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
[...]

ubuntu# modinfo e1000 | more
filename:
/lib/modules/3.8.0-35-generic/kernel/drivers/net/ethernet/intel/e1000/e1000.ko
version:        7.3.21-k8-NAPI
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
[...]


(4) I've tried upgrading the e1000e driver to 2.5.4; no change in behavior


(5) Ports & Addresses
I've tried various TCP source & destination ports, and from those
results am claiming that the problem is limited to situations in which
the source port is below 1024.  I've also tried using UDP ... but I
don't see frames in either pcap when I use the '-u' option
ubuntu# nc -4 -p 1023 10.1.1.1 2049

ubuntu# nc -4 -p 1024 10.1.1.1 2049


Suggestions?

(A) I have modified the source of the e1000e-2.5.4 driver to add
'printk' statements at key points ...
(B) and I've enabled kernel tracing:
mount -t debugfs nodev /sys/kernel/debug
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/events/net/enable
echo 1 > /sys/kernel/debug/tracing/tracing_on
(C) But the output is daunting ... and I haven't figured out how to
distinguish, for example, the TCP SYN events from the ARP
transmissions.  More work needed.

(D) I have SystemTap installed ... but the particular example scripts
(networking-oriented) which might offer insight are throwing semantic
errors ... I'm not sure I'm smart enough to debug these
http://sourceware-org.1504.n7.nabble.com/updated-example-scripts-td256998.html

Before I crawl farther down either of these paths, I figured I'd ask
for input/ideas.

?

tia,

--sk

Stuart Kendrick

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox