* [PATCH 18/36] net,rcu: convert call_rcu(xps_dev_maps_release) to kfree_rcu()
From: Lai Jiangshan @ 2011-03-18 4:02 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, David S. Miller, Eric Dumazet,
Tom Herbert
The rcu callback xps_dev_maps_release() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(xps_dev_maps_release).
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
net/core/net-sysfs.c | 12 ++----------
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 9ae2e1d..06332e5 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -876,14 +876,6 @@ static ssize_t show_xps_map(struct netdev_queue *queue,
return len;
}
-static void xps_dev_maps_release(struct rcu_head *rcu)
-{
- struct xps_dev_maps *dev_maps =
- container_of(rcu, struct xps_dev_maps, rcu);
-
- kfree(dev_maps);
-}
-
static DEFINE_MUTEX(xps_map_mutex);
#define xmap_dereference(P) \
rcu_dereference_protected((P), lockdep_is_held(&xps_map_mutex))
@@ -993,7 +985,7 @@ static ssize_t store_xps_map(struct netdev_queue *queue,
}
if (dev_maps)
- call_rcu(&dev_maps->rcu, xps_dev_maps_release);
+ kfree_rcu(dev_maps, rcu);
netdev_queue_numa_node_write(queue, (numa_node >= 0) ? numa_node :
NUMA_NO_NODE);
@@ -1065,7 +1057,7 @@ static void netdev_queue_release(struct kobject *kobj)
if (!nonempty) {
RCU_INIT_POINTER(dev->xps_maps, NULL);
- call_rcu(&dev_maps->rcu, xps_dev_maps_release);
+ kfree_rcu(dev_maps, rcu);
}
}
--
1.7.4
^ permalink raw reply related
* [PATCH 21/36] net,rcu: convert call_rcu(netlbl_unlhsh_free_addr6) to kfree_rcu()
From: Lai Jiangshan @ 2011-03-18 4:04 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, Paul Moore, David S. Miller,
netdev, linux-ke
The rcu callback netlbl_unlhsh_free_addr6() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(netlbl_unlhsh_free_addr6).
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
net/netlabel/netlabel_unlabeled.c | 22 +---------------------
1 files changed, 1 insertions(+), 21 deletions(-)
diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
index 4e5ad90..9c38658 100644
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -153,26 +153,6 @@ static const struct nla_policy netlbl_unlabel_genl_policy[NLBL_UNLABEL_A_MAX + 1
* Unlabeled Connection Hash Table Functions
*/
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
-/**
- * netlbl_unlhsh_free_addr6 - Frees an IPv6 address entry from the hash table
- * @entry: the entry's RCU field
- *
- * Description:
- * This function is designed to be used as a callback to the call_rcu()
- * function so that memory allocated to a hash table address entry can be
- * released safely.
- *
- */
-static void netlbl_unlhsh_free_addr6(struct rcu_head *entry)
-{
- struct netlbl_unlhsh_addr6 *ptr;
-
- ptr = container_of(entry, struct netlbl_unlhsh_addr6, rcu);
- kfree(ptr);
-}
-#endif /* IPv6 */
-
/**
* netlbl_unlhsh_free_iface - Frees an interface entry from the hash table
* @entry: the entry's RCU field
@@ -611,7 +591,7 @@ static int netlbl_unlhsh_remove_addr6(struct net *net,
if (entry == NULL)
return -ENOENT;
- call_rcu(&entry->rcu, netlbl_unlhsh_free_addr6);
+ kfree_rcu(entry, rcu);
return 0;
}
#endif /* IPv6 */
--
1.7.4
^ permalink raw reply related
* [PATCH 20/36] net,rcu: convert call_rcu(netlbl_unlhsh_free_addr4) to kfree_rcu()
From: Lai Jiangshan @ 2011-03-18 4:03 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, Paul Moore, David S. Miller,
netdev, linux-ke
The rcu callback netlbl_unlhsh_free_addr4() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(netlbl_unlhsh_free_addr4).
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
net/netlabel/netlabel_unlabeled.c | 20 +-------------------
1 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
index e2b0a68..4e5ad90 100644
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -153,24 +153,6 @@ static const struct nla_policy netlbl_unlabel_genl_policy[NLBL_UNLABEL_A_MAX + 1
* Unlabeled Connection Hash Table Functions
*/
-/**
- * netlbl_unlhsh_free_addr4 - Frees an IPv4 address entry from the hash table
- * @entry: the entry's RCU field
- *
- * Description:
- * This function is designed to be used as a callback to the call_rcu()
- * function so that memory allocated to a hash table address entry can be
- * released safely.
- *
- */
-static void netlbl_unlhsh_free_addr4(struct rcu_head *entry)
-{
- struct netlbl_unlhsh_addr4 *ptr;
-
- ptr = container_of(entry, struct netlbl_unlhsh_addr4, rcu);
- kfree(ptr);
-}
-
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
/**
* netlbl_unlhsh_free_addr6 - Frees an IPv6 address entry from the hash table
@@ -568,7 +550,7 @@ static int netlbl_unlhsh_remove_addr4(struct net *net,
if (entry == NULL)
return -ENOENT;
- call_rcu(&entry->rcu, netlbl_unlhsh_free_addr4);
+ kfree_rcu(entry, rcu);
return 0;
}
--
1.7.4
^ permalink raw reply related
* [PATCH 24/36] net,rcu: convert call_rcu(net_generic_release) to kfree_rcu()
From: Lai Jiangshan @ 2011-03-18 4:06 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, David S. Miller, Jiri Pirko,
Eric Dumazet
The rcu callback net_generic_release() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(net_generic_release).
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
net/core/net_namespace.c | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 3f86026..297bb92 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -27,14 +27,6 @@ EXPORT_SYMBOL(init_net);
#define INITIAL_NET_GEN_PTRS 13 /* +1 for len +2 for rcu_head */
-static void net_generic_release(struct rcu_head *rcu)
-{
- struct net_generic *ng;
-
- ng = container_of(rcu, struct net_generic, rcu);
- kfree(ng);
-}
-
static int net_assign_generic(struct net *net, int id, void *data)
{
struct net_generic *ng, *old_ng;
@@ -68,7 +60,7 @@ static int net_assign_generic(struct net *net, int id, void *data)
memcpy(&ng->ptr, &old_ng->ptr, old_ng->len * sizeof(void*));
rcu_assign_pointer(net->gen, ng);
- call_rcu(&old_ng->rcu, net_generic_release);
+ kfree_rcu(old_ng, rcu);
assign:
ng->ptr[id - 1] = data;
return 0;
--
1.7.4
^ permalink raw reply related
* [PATCH 25/36] net,rcu: convert call_rcu(__nf_ct_ext_free_rcu) to kfree_rcu()
From: Lai Jiangshan @ 2011-03-18 4:07 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, Patrick McHardy, David S. Miller,
netfilter-devel
The rcu callback __nf_ct_ext_free_rcu() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(__nf_ct_ext_free_rcu).
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
net/netfilter/nf_conntrack_extend.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
index bd82450..cc0bcda 100644
--- a/net/netfilter/nf_conntrack_extend.c
+++ b/net/netfilter/nf_conntrack_extend.c
@@ -68,12 +68,6 @@ nf_ct_ext_create(struct nf_ct_ext **ext, enum nf_ct_ext_id id, gfp_t gfp)
return (void *)(*ext) + off;
}
-static void __nf_ct_ext_free_rcu(struct rcu_head *head)
-{
- struct nf_ct_ext *ext = container_of(head, struct nf_ct_ext, rcu);
- kfree(ext);
-}
-
void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp)
{
struct nf_ct_ext *old, *new;
@@ -114,7 +108,7 @@ void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp)
(void *)old + old->offset[i]);
rcu_read_unlock();
}
- call_rcu(&old->rcu, __nf_ct_ext_free_rcu);
+ kfree_rcu(old, rcu);
ct->ext = new;
}
--
1.7.4
^ permalink raw reply related
* Re: sctp panic
From: Wei Yongjun @ 2011-03-18 4:06 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: walter schloegl, linux-kernel, netdev
In-Reply-To: <AANLkTi=yN2MtaOwUQsKmYaYxfkc0+mKtZiDeJ=r-KACK@mail.gmail.com>
> On Thu, Mar 17, 2011 at 11:49 AM, walter schloegl <sctp@muskelshirt.de> wrote:
>> -------- Original-Nachricht --------
>>> Datum: Thu, 17 Mar 2011 08:56:47 +0100
>>> Von: richard -rw- weinberger <richard.weinberger@gmail.com>
>>> An: sctp@muskelshirt.de
>>> CC: linux-kernel@vger.kernel.org
>>> Betreff: Re: sctp panic
>>> On Thu, Mar 17, 2011 at 8:43 AM, <sctp@muskelshirt.de> wrote:
>>>> Hi
>>>>
>>>> when doing the actions below I get a panic.
>>>>
>>>> - echo 1 > /proc/sys/net/sctp/addip_enable
>>>> - In a C-Programm
>>>> - socket(AF_INET,SOCK_STREAM,IPPROTO_SCTP);
>>>> - connect(....) (with correct filled parameters)
>>>>
>>>> Its no process (waiting in accept) neccessary
>>> Can you show us the panic message and your C prorgam?
>>> This would help reproducing the panic...
>> ...snip...
>>
>> The crash says:
>>
>> crash> bt
>> PID: 14646 TASK: ffff8801f40c7560 CPU: 9 COMMAND: "x"
>> #0 [ffff8801f6f5f6f0] machine_kexec at ffffffff8103697b
>> #1 [ffff8801f6f5f750] crash_kexec at ffffffff810b9078
>> #2 [ffff8801f6f5f820] oops_end at ffffffff814cc900
>> #3 [ffff8801f6f5f850] die at ffffffff8101733b
>> #4 [ffff8801f6f5f880] do_trap at ffffffff814cc1d4
>> #5 [ffff8801f6f5f8e0] do_invalid_op at ffffffff81014ee5
>> #6 [ffff8801f6f5f980] invalid_op at ffffffff81013f5b
>> [exception RIP: skb_over_panic+93]
>> RIP: ffffffff81404bdd RSP: ffff8801f6f5fa38 RFLAGS: 00010296
>> RAX: 0000000000000083 RBX: 0000000000000040 RCX: 00000000000013f6
>> RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246
>> RBP: ffff8801f6f5fa58 R8: ffffffff818a3da0 R9: 0000000000000000
>> R10: 0000000000000001 R11: 0000000000000000 R12: ffff8801f4e11000
>> R13: 0000000000000004 R14: 000000000000003e R15: 0000000000000001
>> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
>> #7 [ffff8801f6f5fa60] skb_put at ffffffff81405c1c
>> #8 [ffff8801f6f5fa80] sctp_addto_chunk at ffffffffa0503c23
>> #9 [ffff8801f6f5fad0] sctp_make_init at ffffffffa0506705
>> #10 [ffff8801f6f5fba0] sctp_sf_do_prm_asoc at ffffffffa04f81d4
>> #11 [ffff8801f6f5fbd0] sctp_do_sm at ffffffffa04fd381
>> #12 [ffff8801f6f5fd60] sctp_primitive_ASSOCIATE at ffffffffa0513daf
>> #13 [ffff8801f6f5fd80] __sctp_connect at ffffffffa0510f09
>> #14 [ffff8801f6f5fe50] sctp_connect at ffffffffa0511248
>> #15 [ffff8801f6f5fe80] inet_dgram_connect at ffffffff81471b6c
>> #16 [ffff8801f6f5feb0] sys_connect at ffffffff813ff747
>> #17 [ffff8801f6f5ff80] system_call_fastpath at ffffffff81013172
>> RIP: 0000003015ee2150 RSP: 00007fffea7bdce8 RFLAGS: 00010206
>> RAX: 000000000000002a RBX: ffffffff81013172 RCX: 0000000000000000
>> RDX: 0000000000000010 RSI: 00007fffea7bdd00 RDI: 0000000000000003
>> RBP: 00007fffea7bdd40 R8: 0000000000759020 R9: ff00000000000000
>> R10: 00007fffea7bda70 R11: 0000000000000246 R12: 0000000000000000
>> R13: 00007fffea7bde20 R14: 00000000004006e0 R15: 0000000000000000
>> ORIG_RAX: 000000000000002a CS: 0033 SS: 002b
>>
>>
>>
Are you using old kernel? If it is, the following patch may fixed this
issue.
http://git.kernel.org/?p=linux/kernel/git/vxy/lksctp-dev.git;a=commitdiff;h=a8170c35e738d62e9919ce5b109cf4ed66e95bde;hp=81419d862db743fe4450a021893f24bab4698c1d
>>>> br
>>>> walter
>>>> --
>>>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
>>>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>>> in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>>
>>> --
>>> Thanks,
>>> //richard
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>> --
>> NEU: FreePhone - kostenlos mobil telefonieren und surfen!
>> Jetzt informieren: http://www.gmx.net/de/go/freephone
>>
> CC'ing netdev
>
^ permalink raw reply
* [PATCH 28/36] net,rcu: convert call_rcu(phonet_device_rcu_free) to kfree_rcu()
From: Lai Jiangshan @ 2011-03-18 4:09 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, Remi Denis-Courmont,
David S. Miller, netdev
The rcu callback phonet_device_rcu_free() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(phonet_device_rcu_free).
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
net/phonet/pn_dev.c | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
index 947038d..1566672 100644
--- a/net/phonet/pn_dev.c
+++ b/net/phonet/pn_dev.c
@@ -162,14 +162,6 @@ int phonet_address_add(struct net_device *dev, u8 addr)
return err;
}
-static void phonet_device_rcu_free(struct rcu_head *head)
-{
- struct phonet_device *pnd;
-
- pnd = container_of(head, struct phonet_device, rcu);
- kfree(pnd);
-}
-
int phonet_address_del(struct net_device *dev, u8 addr)
{
struct phonet_device_list *pndevs = phonet_device_list(dev_net(dev));
@@ -188,7 +180,7 @@ int phonet_address_del(struct net_device *dev, u8 addr)
mutex_unlock(&pndevs->lock);
if (pnd)
- call_rcu(&pnd->rcu, phonet_device_rcu_free);
+ kfree_rcu(pnd, rcu);
return err;
}
--
1.7.4
^ permalink raw reply related
* [PATCH 30/36] net,rcu: convert call_rcu(wq_free_rcu) to kfree_rcu()
From: Lai Jiangshan @ 2011-03-18 4:10 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, David S. Miller, netdev,
linux-kernel
The rcu callback wq_free_rcu() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(wq_free_rcu).
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
net/socket.c | 11 +----------
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index ac2219f..3158271 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -261,21 +261,12 @@ static struct inode *sock_alloc_inode(struct super_block *sb)
return &ei->vfs_inode;
}
-
-
-static void wq_free_rcu(struct rcu_head *head)
-{
- struct socket_wq *wq = container_of(head, struct socket_wq, rcu);
-
- kfree(wq);
-}
-
static void sock_destroy_inode(struct inode *inode)
{
struct socket_alloc *ei;
ei = container_of(inode, struct socket_alloc, vfs_inode);
- call_rcu(&ei->socket.wq->rcu, wq_free_rcu);
+ kfree_rcu(ei->socket.wq, rcu);
kmem_cache_free(sock_inode_cachep, ei);
}
--
1.7.4
^ permalink raw reply related
* [PATCH 35/36] net/mac80211,rcu: convert call_rcu(work_free_rcu) to kfree_rcu()
From: Lai Jiangshan @ 2011-03-18 4:14 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, Johannes Berg, John W. Linville,
"David S. Miller
The rcu callback work_free_rcu() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(work_free_rcu).
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
net/mac80211/work.c | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index 36305e0..dcc433e 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -66,17 +66,9 @@ static void run_again(struct ieee80211_local *local,
mod_timer(&local->work_timer, timeout);
}
-static void work_free_rcu(struct rcu_head *head)
-{
- struct ieee80211_work *wk =
- container_of(head, struct ieee80211_work, rcu_head);
-
- kfree(wk);
-}
-
void free_work(struct ieee80211_work *wk)
{
- call_rcu(&wk->rcu_head, work_free_rcu);
+ kfree_rcu(wk, rcu_head);
}
static int ieee80211_compatible_rates(const u8 *supp_rates, int supp_rates_len,
--
1.7.4
^ permalink raw reply related
* [PATCH 36/36] net,rcu: convert call_rcu(xt_osf_finger_free_rcu) to kfree_rcu()
From: Lai Jiangshan @ 2011-03-18 4:15 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, Patrick McHardy, David S. Miller,
netfilter-devel
The rcu callback xt_osf_finger_free_rcu() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(xt_osf_finger_free_rcu).
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
net/netfilter/xt_osf.c | 11 ++---------
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/net/netfilter/xt_osf.c b/net/netfilter/xt_osf.c
index 4327e10..846f895 100644
--- a/net/netfilter/xt_osf.c
+++ b/net/netfilter/xt_osf.c
@@ -62,13 +62,6 @@ static const struct nla_policy xt_osf_policy[OSF_ATTR_MAX + 1] = {
[OSF_ATTR_FINGER] = { .len = sizeof(struct xt_osf_user_finger) },
};
-static void xt_osf_finger_free_rcu(struct rcu_head *rcu_head)
-{
- struct xt_osf_finger *f = container_of(rcu_head, struct xt_osf_finger, rcu_head);
-
- kfree(f);
-}
-
static int xt_osf_add_callback(struct sock *ctnl, struct sk_buff *skb,
const struct nlmsghdr *nlh,
const struct nlattr * const osf_attrs[])
@@ -133,7 +126,7 @@ static int xt_osf_remove_callback(struct sock *ctnl, struct sk_buff *skb,
* We are protected by nfnl mutex.
*/
list_del_rcu(&sf->finger_entry);
- call_rcu(&sf->rcu_head, xt_osf_finger_free_rcu);
+ kfree_rcu(sf, rcu_head);
err = 0;
break;
@@ -414,7 +407,7 @@ static void __exit xt_osf_fini(void)
list_for_each_entry_rcu(f, &xt_osf_fingers[i], finger_entry) {
list_del_rcu(&f->finger_entry);
- call_rcu(&f->rcu_head, xt_osf_finger_free_rcu);
+ kfree_rcu(f, rcu_head);
}
}
rcu_read_unlock();
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Jerry Chu @ 2011-03-18 4:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, netdev
In-Reply-To: <20110317142030.62af785a@nehalam>
On Thu, Mar 17, 2011 at 2:20 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Thu, 17 Mar 2011 13:16:15 -0700
> Jerry Chu <hkchu@google.com> wrote:
>
>> Eric, thanks for the prompt feedback.
>>
>> On Thu, Mar 17, 2011 at 1:42 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > Le jeudi 17 mars 2011 à 01:06 -0700, H.K. Jerry Chu a écrit :
>> >> From: Jerry Chu <hkchu@google.com>
>> >>
>> >> This patch add a number of very useful counters/stats (defined in
>> >> tcp_stats.h) to help diagnosing TCP related problems.
>> >>
>> >> create_time - when the connection was created (in jiffies)
>> >> total_inbytes - total inbytes as consumed by the receiving apps.
>> >> total_outbytes - total outbytes sent down from the transmitting apps.
>> >>
>> >> total_outdatasegs - total data carrying segments sent so far, including
>> >> retransmitted ones.
>> >>
>> >> total_xmit - total accumulated time (usecs) when the connection
>> >> has something to send.
>> >>
>> >> total_retrans_time - total time (usecs, accumulated) the connection
>> >> spends trying to recover lost packets. For each
>> >> loss event the time is measured from the lost packet
>> >> was first sent till the retransmitted packet was
>> >> eventually ack'ed.
>> >>
>> >> total_cwnd_limit - total time (usecs, excluding time spent on loss
>> >> recovery) the xmit is stopped due to cwnd limited
>> >>
>> >> total_swnd_limit - total time (usecs) theconnection is swnd limited
>> >>
>> >> The following two counters are for listeners only:
>> >>
>> >> accepted_reqs - total # of accepted connection requests.
>> >> listen_drops - total # of dropped SYN reqs (SYN cookies excluded) due
>> >> to listener's queue overflow.
>> >>
>> >> total_retrans_time/total_retrans ratio gives a rough picture of how
>> >> quickly in average the connection can recover from a pkt loss. E.g.,
>> >> when the network is more congested, or the traffic contains mainly
>> >> smaller RPC where tail drop often requires RTO to recover,
>> >> the total_retrans_time/total_retrans ratio tends to be higher.
>> >>
>> >> Currently the new counters/stats are exported through /proc/net/tcp.
>> >
>> > Please dont. Use iproute2 instead.
>> >
>> >> Some simple, abbreviated field names have been added to the output of
>> >> /proc/net/tcp in order to allow backward/forward compatibility in the
>> >> future. Obviously the new counters/stats can also be easily exported
>> >> through other APIs.
>> >>
>> >
>> > /proc/net/tcp is legacy. You should touch it eventually, but after
>> > "other APIS" are done. It was the old way (quick but a bit ugly)
>>
>> Understood. /proc/net/tcp is a much more expedient way of exporting these
>> counters because it doesn't requires any additional, special tool to read it,
>> unless other APIs (e.g., netlink). Note that backward compatibility to
>> /proc/net/tcp has been ensured by adding field names in the heading.
>>
>> >
>> >
>> >
>> >> Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
>> >> ---
>> >> include/linux/ktime.h | 3 ++
>> >> include/linux/tcp.h | 1 +
>> >> include/net/tcp_stats.h | 65 ++++++++++++++++++++++++++++++++++++++++++++++
>> >> net/ipv4/tcp.c | 30 ++++++++++++++++++---
>> >> net/ipv4/tcp_input.c | 13 +++++++++
>> >> net/ipv4/tcp_ipv4.c | 41 ++++++++++++++++++++++++++---
>> >> net/ipv4/tcp_minisocks.c | 9 ++++++
>> >> net/ipv4/tcp_output.c | 47 +++++++++++++++++++++++++++++++--
>> >> net/ipv6/tcp_ipv6.c | 8 +++++
>> >> 9 files changed, 206 insertions(+), 11 deletions(-)
>> >> create mode 100644 include/net/tcp_stats.h
>> >>
>> >> diff --git a/include/linux/ktime.h b/include/linux/ktime.h
>> >> index e1ceaa9..e60e758 100644
>> >> --- a/include/linux/ktime.h
>> >> +++ b/include/linux/ktime.h
>> >> @@ -333,6 +333,9 @@ extern void ktime_get_ts(struct timespec *ts);
>> >> /* Get the real (wall-) time in timespec format: */
>> >> #define ktime_get_real_ts(ts) getnstimeofday(ts)
>> >
>> > Hmm, this kind of changes are out of netdev scope and should be avoided
>>
>> Ok. (It was moved out of tcp_stats.h only at the last minute.)
>>
>> >
>> >>
>> >> +#define ktime_since(a) ktime_to_us(ktime_sub(ktime_get(), (a)))
>> >
>> > us are implied in ktime_since() ? thats strange.
>>
>> Ok.
>>
>> >
>> >> +#define ktime_zero(a) ktime_equal((a), ktime_set(0, 0))
>> >
>> > ktime_zero() sounds like : "give me zero time" or "clear the ktime
>> > field".
>>
>> Yes I actually have been flip-flopping on the name...
>>
>> >
>> >> +
>> >> static inline ktime_t ns_to_ktime(u64 ns)
>> >> {
>> >> static const ktime_t ktime_zero = { .tv64 = 0 };
>> >> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
>> >> index e64f4c6..ea5cb5d 100644
>> >> --- a/include/linux/tcp.h
>> >> +++ b/include/linux/tcp.h
>> >> @@ -460,6 +460,7 @@ struct tcp_sock {
>> >> * contains related tcp_cookie_transactions fields.
>> >> */
>> >> struct tcp_cookie_values *cookie_values;
>> >> + struct tcp_stats *conn_stats;
>> >> };
>> >
>> > Really, using separate cache lines to store some stats is expensive.
>> > You should add counters in existing structure, to avoid additional cache
>> > line dirties. Carefully placing stats in already dirtied cache lines.
>>
>> This was how it was done initially but then we wanted to allow future
>> extension to include possibly a lot more counters, something like Web100
>> (RFC4898). For the latter the memory/performance hit will likely require
>> a config option, and a separate structure will make this easier. Does it
>> make sense?
>>
>> >
>> > You also should use native ktime_t infrastructure, to make the maths
>> > really fast in fast path.
>> >
>> > Only when stats are to be returned to user, you'll have to convert the
>> > native timestamps to user exportable ones.
>>
>> Good point! Will do. (I mistakenly thought ktime_t is a larger structure.)
>>
>> >
>> > Quite frankly, using u64 fields allow nanosec resolution.
>>
>> I wish to use less bits because the final report only needs ms or even
>> sec resolution but the intermediate computation needs to capture usec
>> resolution.
>>
>> >
>> > BTW, we probably could 'export' sk->sk_drops for TCP, like we do for
>> > UDP.
>>
>> There are many other potentially useful counters/stats (spurious_retrans,
>> min_rtt, total_rto,...) but there is a tradeoff against memory/performance hit
>> so for the first round I'm focusing on what i feel is the most useful set.
>>
>> Thanks,
>>
>> Jerry
>
> These stats are best added via netlink, the tool ss already prints lots
> of similar stats. Look at INET_DIAG_INFO and the output of:
> ss -i -t
Yes I'm familiar with ss and how inet_csk_diag_fill() calls into
tcp_diag_get_info(),..., etc. Like I mentioned previously the netlink
interface
requires a new version of reader app (e.g., ss) to ship every time a new
counter is added and exported by the kernel, whereas /proc/net/tcp does
not have such a problem.
Anyway I can add a INET_DIAG_INFO_EXT of some sort to netlink in
addition to /proc/net/tcp. That's easy to do.
Thanks,
Jerry
>
>
>
>
>
>
> --
>
^ permalink raw reply
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: David Miller @ 2011-03-18 4:51 UTC (permalink / raw)
To: hkchu; +Cc: shemminger, eric.dumazet, netdev
In-Reply-To: <AANLkTi=W-=8zhQpfJZ=DrDyUCwrT==5JkwRBiHaDkVXK@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
Date: Thu, 17 Mar 2011 21:33:50 -0700
> Yes I'm familiar with ss and how inet_csk_diag_fill() calls into
> tcp_diag_get_info(),..., etc. Like I mentioned previously the netlink
> interface
> requires a new version of reader app (e.g., ss) to ship every time a new
> counter is added and exported by the kernel, whereas /proc/net/tcp does
> not have such a problem.
You can add new netlink attributes to portably extend the existing
info, and also to add a mechanism by which to make 'ss' utility
upgrades unnecessary.
Please, just use modern mechanisms like netlink and leave legacy
bits like /proc/net/tcp alone, thank you.
^ permalink raw reply
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Eric Dumazet @ 2011-03-18 6:05 UTC (permalink / raw)
To: Jerry Chu; +Cc: Stephen Hemminger, netdev
In-Reply-To: <AANLkTi=W-=8zhQpfJZ=DrDyUCwrT==5JkwRBiHaDkVXK@mail.gmail.com>
Le jeudi 17 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
> Yes I'm familiar with ss and how inet_csk_diag_fill() calls into
> tcp_diag_get_info(),..., etc. Like I mentioned previously the netlink
> interface
> requires a new version of reader app (e.g., ss) to ship every time a new
> counter is added and exported by the kernel, whereas /proc/net/tcp does
> not have such a problem.
>
> Anyway I can add a INET_DIAG_INFO_EXT of some sort to netlink in
> addition to /proc/net/tcp. That's easy to do.
>
I suggest adding a getsockopt() or something to gather stats for one
socket. On a loaded machine, /proc/net/tcp is damn slow.
We have TCP_INFO, we could add TCP_INFO_EXT, but taking care of choosing
an interface allowing for extension of the structure.
^ permalink raw reply
* Re: sky2, vlan and nat/masquerading
From: Christian Hesse @ 2011-03-18 6:46 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev
In-Reply-To: <20110317224044.3ff4fbd8@leda.vpn.lugor.de>
On Thu, 17 Mar 2011 22:40:44 +0100 Christian Hesse <mail@eworm.de> wrote:
> On Thu, 17 Mar 2011 12:23:48 -0700 Jesse Gross <jesse@nicira.com> wrote:
> > Can you try using ethtool to turn off txvlan and see if that makes a
> > difference?
>
> Sure. I will give it a try tomorrow.
No, that does not make a difference.
--
Schoene Gruesse
Chris
^ permalink raw reply
* Re: Poll about irqsafe_cpu_add and others
From: Benjamin Herrenschmidt @ 2011-03-18 6:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, linux-arch, Christoph Lameter, netdev,
Netfilter Development Mailinglist
In-Reply-To: <1300371834.6315.93.camel@edumazet-laptop>
On Thu, 2011-03-17 at 15:23 +0100, Eric Dumazet wrote:
> Hi
>
> irqsafe_cpu_{dec|inc} are used in network stack since 2.6.37 (commit
> 29b4433d991c88), and I would like to use irqsafe_cpu_add() in netfilter
> fast path too, and SNMP counters eventually (to lower ram needs by 50%)
>
> Initial support of irqsafe_ was given by Christoph in 2.6.34
>
> It seems only x86 arch is using a native and efficient implementation.
>
> Others use irqsafe_cpu_generic_to_op() and its pair of
> local_irq_save() / local_irq_restore()
>
> Which other arches could use a native implementation ?
>
> What about defining a HAVE_FAST_IRQSAFE_ADD ?
On powerpc, we use the generic one and it's fast :-) Well, at least on
ppc64, bcs we do lazy irq disabling, disabling/enabling interrupt is
basically just poking a byte in a per-cpu data structure (there's a tad
more work on enable in case the interrupt actually occured and we ended
up really disabling but that's not the common case). Overall faster than
using the atomic ops which have to go all the way to the L2 cache.
So if you define the above, please set in on powerpc despite the fact
that we use the generic implementation.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 05/36] block,rcu: convert call_rcu(disk_free_ptbl_rcu_cb) to kfree_rcu()
From: Jens Axboe @ 2011-03-18 6:59 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Paul E. McKenney, Ingo Molnar, Robert Love, James E.J. Bottomley,
Neil Horman, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Eric Dumazet, Stephen Hemminger, Tejun Heo,
Jarek Poplawski, linux-kernel, devel, linux-scsi, netdev
In-Reply-To: <4D82D4C2.8020503@cn.fujitsu.com>
On 2011-03-18 04:42, Lai Jiangshan wrote:
>
>
> The rcu callback disk_free_ptbl_rcu_cb() just calls a kfree(),
> so we use kfree_rcu() instead of the call_rcu(disk_free_ptbl_rcu_cb).
Thanks, I'll add this.
--
Jens Axboe
^ permalink raw reply
* VLAN over GRE segfault
From: Diddi Oscarsson @ 2011-03-18 7:34 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
I was trying to get ethernet over GRE to work when I found an obvious
way NOT to do it.
Basically I created a VLAN interface from the GRE interface (even
though I had my fair doubts it would work) which gave me a nice segfault.
The problem with this is that after the segfault, new network
connections cannot be made (ping, ssh, http, whatever) and a reboot of
the computer is necessary.
I think an error message needs to be added when trying an operation
like this.
My system:
Linux colalapp 2.6.37-2-amd64 #1 SMP Sun Feb 27 10:12:22 UTC 2011
x86_64 GNU/Linux
ip utility, iproute2-ss110107
Debian unstable
Steps to reproduce:
ip tunnel add gre0 mode gre
ip link add link gre0 name vlan1 type vlan id 1
ip link set vlan1 address 00:15:14:13:12:11
ip link set gre0 up
ip link set vlan1 up
<CRASH>
Attached in the mail is an output from dmesg right after the segfault.
Regarding ethernet over gre, I've just found out about gretap which
I'm testing right now.
BR
Diddi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNgwr5AAoJEA4EcRXoFHyYL+4H/iENafoHp780qO2Kjfz1UWkj
XDAijBm+CI7cq+0Bs3VgvtP86ym/Qe5ueJok+dm4nfrboLpg93Z3UssbvF9RbngI
CJllJ+jIMDPJveioSEif8VIiaPT3LVkp2DO2nDOgRMdAFfYANzWQCX44FJTtX11v
R5gtYPLxv0v6iODhBMcYorTeC/x+Z607K7QaoSQhmKqt/ehw1bG2c30zHCUBNKMS
mU216M811ZDr87JQ86hm8ADkQUrCzoi50yAMjX0M0iiOX/yjyLD2VnqWNco0bPJE
CgH+5Bc8+6jNRsofYoi8d5g+g7Q2RpA7Xx1kiJrD2sR6SKr+vjTt/DIsSY+SXNA=
=mWZT
-----END PGP SIGNATURE-----
[-- Attachment #2: crash.log --]
[-- Type: text/plain, Size: 5904 bytes --]
[396626.662104] device gre0 entered promiscuous mode
[396626.662561] skb_under_panic: text:ffffffffa0935af7 len:80 put:24 head:ffff880078b8d000 data:ffff880078b8cff8 tail:0x48 end:0x100 dev:veth0
[396626.662742] ------------[ cut here ]------------
[396626.662790] kernel BUG at /build/buildd-linux-2.6_2.6.37-2-amd64-bITS0h/linux-2.6-2.6.37/debian/build/source_amd64_none/net/core/skbuff.c:146!
[396626.662891] invalid opcode: 0000 [#1] SMP
[396626.662932] last sysfs file: /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlan0/statistics/tx_bytes
[396626.663010] CPU 0
[396626.663029] Modules linked in: tun macvlan dummy 8021q garp stp ip_gre gre veth binfmt_misc fuse loop firewire_sbp2 btusb bluetooth snd_hda_codec_analog snd_hda_intel arc4 ecb snd_hda_codec iwl3945 thinkpad_acpi iwlcore snd_hwdep snd_pcm i915 snd_seq drm_kms_helper snd_timer drm mac80211 snd_seq_device pcmcia snd snd_page_alloc i2c_i801 soundcore cfg80211 yenta_socket i2c_algo_bit tpm_tis pcmcia_rsrc pcmcia_core i2c_core battery tpm ac tpm_bios nvram power_supply serio_raw psmouse video pcspkr output rfkill evdev processor button ext3 jbd mbcache sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10dif mmc_block ahci libahci ata_piix uhci_hcd ata_generic libata ehci_hcd scsi_mod firewire_ohci sdhci_pci sdhci usbcore mmc_core e1000e firewire_core thermal crc_it
u_t thermal_sys nls_base [last unloaded: scsi_wait_scan]
[396626.663977]
[396626.663995] Pid: 1440, comm: ip Not tainted 2.6.37-2-amd64 #1 LENOVO 766929G/766929G
[396626.664105] RIP: 0010:[<ffffffff81261ef7>] [<ffffffff81261ef7>] skb_push+0x6f/0x7b
[396626.664177] RSP: 0018:ffff88005cd63498 EFLAGS: 00010296
[396626.664221] RAX: 0000000000000095 RBX: ffff880019387000 RCX: 0000000000060d52
[396626.664279] RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246
[396626.664337] RBP: ffff8800780bbbf8 R08: 0000000000000002 R09: 0000000000000005
[396626.664395] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8800193876c0
[396626.664453] R13: 000000000000dd86 R14: ffff8800469bfec0 R15: ffff88005cd635a8
[396626.664512] FS: 00007f18c2b21700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000
[396626.664576] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[396626.664624] CR2: 00007f18c22cc728 CR3: 000000001955c000 CR4: 00000000000006f0
[396626.664682] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[396626.664740] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[396626.664800] Process ip (pid: 1440, threadinfo ffff88005cd62000, task ffff880078132880)
[396626.664862] Stack:
[396626.664881] 0000000000000048 0000000000000100 ffff8800469bf800 ffff88005cd63518
[396626.664956] 0000000000000286 ffffffffa0935af7 ffff88005cd635a8 ffff88005ce4b7f0
[396626.665031] ffffffff817f4a38 ffff880046862b00 ffff8800469bf800 0000000000000000
[396626.665106] Call Trace:
[396626.665137] [<ffffffffa0935af7>] ? ipgre_header+0x2e/0x86 [ip_gre]
[396626.665193] [<ffffffffa094d7e8>] ? vlan_dev_hard_header+0x121/0x139 [8021q]
[396626.665252] [<ffffffff81053bcd>] ? mod_timer+0x87/0x8e
[396626.665300] [<ffffffff812721b6>] ? neigh_connected_output+0x94/0xd3
[396626.665355] [<ffffffff812e829c>] ? ndisc_send_skb+0x144/0x22d
[396626.665405] [<ffffffff812e97ab>] ? ndisc_send_rs+0x8f/0x9a
[396626.665455] [<ffffffff812dc422>] ? addrconf_dad_completed+0x71/0xb5
[396626.665508] [<ffffffff812deaff>] ? addrconf_add_linklocal+0x6e/0x7d
[396626.665561] [<ffffffff812e00c3>] ? addrconf_notify+0x59e/0x78e
[396626.665612] [<ffffffff8128e16d>] ? rt_cache_flush+0x1a/0x51
[396626.665662] [<ffffffff81321f16>] ? notifier_call_chain+0x2e/0x5b
[396626.665714] [<ffffffff8126b157>] ? __dev_notify_flags+0x34/0x59
[396626.665764] [<ffffffff8126b1b6>] ? dev_change_flags+0x3a/0x42
[396626.665815] [<ffffffffa094c625>] ? vlan_device_event+0x42a/0x4ba [8021q]
[396626.665872] [<ffffffff8128e16d>] ? rt_cache_flush+0x1a/0x51
[396626.668139] [<ffffffff81321f16>] ? notifier_call_chain+0x2e/0x5b
[396626.670352] [<ffffffff8126b157>] ? __dev_notify_flags+0x34/0x59
[396626.672524] [<ffffffff8126b1b6>] ? dev_change_flags+0x3a/0x42
[396626.674682] [<ffffffff81276ef9>] ? do_setlink+0x26f/0x5ce
[396626.676834] [<ffffffff81276053>] ? rtnl_fill_ifinfo+0x88e/0x957
[396626.678911] [<ffffffff8127761c>] ? rtnl_newlink+0x2b3/0x4cb
[396626.680934] [<ffffffff812773fb>] ? rtnl_newlink+0x92/0x4cb
[396626.682897] [<ffffffff812651e3>] ? __skb_recv_datagram+0x100/0x23d
[396626.684808] [<ffffffff8128a3a6>] ? netlink_sendmsg+0x17e/0x294
[396626.686653] [<ffffffff81276799>] ? rtnetlink_rcv_msg+0x0/0x1ea
[396626.688456] [<ffffffff812899e1>] ? netlink_rcv_skb+0x34/0x7d
[396626.690221] [<ffffffff81276790>] ? rtnetlink_rcv+0x1f/0x28
[396626.691893] [<ffffffff812897cc>] ? netlink_unicast+0xe7/0x14f
[396626.693558] [<ffffffff8128a49c>] ? netlink_sendmsg+0x274/0x294
[396626.695196] [<ffffffff8125a876>] ? sock_sendmsg+0x83/0x9b
[396626.696792] [<ffffffff810d0eef>] ? __do_fault+0x3bc/0x3f3
[396626.698382] [<ffffffff812640cc>] ? copy_from_user+0x18/0x30
[396626.699924] [<ffffffff81264410>] ? verify_iovec+0x46/0x98
[396626.701579] [<ffffffff8125b009>] ? sys_sendmsg+0x22c/0x2b4
[396626.703154] [<ffffffff8128a13b>] ? netlink_insert+0xfd/0x123
[396626.704721] [<ffffffff81321eb0>] ? do_page_fault+0x324/0x35c
[396626.706236] [<ffffffff810d591c>] ? do_brk+0x2ca/0x326
[396626.707710] [<ffffffff8125ab56>] ? sys_recvmsg+0x4a/0x58
[396626.709198] [<ffffffff81009a12>] ? system_call_fastpath+0x16/0x1b
[396626.710652] Code: 8b 57 68 48 89 44 24 10 8b 87 d0 00 00 00 48 89 44 24 08 8b bf cc 00 00 00 31 c0 48 89 3c 24 48 c7 c7 4a 32 4f 81 e8 9f af 0b 00 <0f> 0b eb fe 4c 89 c8 48 83 c4 28 c3 48 83 ec 28 83 7f 6c 00 89
[396626.714396] RIP [<ffffffff81261ef7>] skb_push+0x6f/0x7b
[396626.715992] RSP <ffff88005cd63498>
[396626.724990] ---[ end trace 36ec1d4936ba3c26 ]---
[-- Attachment #3: crash.log.sig --]
[-- Type: application/octet-stream, Size: 287 bytes --]
^ permalink raw reply
* Re: VLAN over GRE segfault
From: Eric Dumazet @ 2011-03-18 8:26 UTC (permalink / raw)
To: Diddi Oscarsson; +Cc: netdev
In-Reply-To: <4D830AF9.8040007@diddi.se>
Le vendredi 18 mars 2011 à 08:34 +0100, Diddi Oscarsson a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello!
>
> I was trying to get ethernet over GRE to work when I found an obvious
> way NOT to do it.
> Basically I created a VLAN interface from the GRE interface (even
> though I had my fair doubts it would work) which gave me a nice segfault.
> The problem with this is that after the segfault, new network
> connections cannot be made (ping, ssh, http, whatever) and a reboot of
> the computer is necessary.
> I think an error message needs to be added when trying an operation
> like this.
Hmm, thanks for the report, I'll submit a patch to fix this
(NETIF_F_VLAN_CHALLENGED needed on some devices)
^ permalink raw reply
* Re: [PATCH 28/36] net,rcu: convert call_rcu(phonet_device_rcu_free) to kfree_rcu()
From: Rémi Denis-Courmont @ 2011-03-18 8:27 UTC (permalink / raw)
To: ext Lai Jiangshan
Cc: Paul E. McKenney, Ingo Molnar, David S. Miller, netdev,
linux-kernel
In-Reply-To: <4D82DADF.4010802@cn.fujitsu.com>
On Friday 18 March 2011 06:09:03 ext Lai Jiangshan, you wrote:
> The rcu callback phonet_device_rcu_free() just calls a kfree(),
> so we use kfree_rcu() instead of the call_rcu(phonet_device_rcu_free).
>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
In principles, that's fine with me. But I think David is not taking that kind
of not-a-fix patch at the moment...
--
Rémi Denis-Courmont
http://www.remlab.net/
^ permalink raw reply
* Re: sctp panic
From: walter schloegl @ 2011-03-18 8:30 UTC (permalink / raw)
To: Wei Yongjun, richard.weinberger; +Cc: netdev, linux-kernel
In-Reply-To: <4D82DA2D.1020503@cn.fujitsu.com>
-------- Original-Nachricht --------
> Datum: Fri, 18 Mar 2011 12:06:05 +0800
> Von: Wei Yongjun <yjwei@cn.fujitsu.com>
> An: richard -rw- weinberger <richard.weinberger@gmail.com>
> CC: walter schloegl <sctp@muskelshirt.de>, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
> Betreff: Re: sctp panic
>
>
> > On Thu, Mar 17, 2011 at 11:49 AM, walter schloegl <sctp@muskelshirt.de>
> wrote:
> >> -------- Original-Nachricht --------
> >>> Datum: Thu, 17 Mar 2011 08:56:47 +0100
> >>> Von: richard -rw- weinberger <richard.weinberger@gmail.com>
> >>> An: sctp@muskelshirt.de
> >>> CC: linux-kernel@vger.kernel.org
> >>> Betreff: Re: sctp panic
> >>> On Thu, Mar 17, 2011 at 8:43 AM, <sctp@muskelshirt.de> wrote:
> >>>> Hi
> >>>>
> >>>> when doing the actions below I get a panic.
> >>>>
> >>>> - echo 1 > /proc/sys/net/sctp/addip_enable
> >>>> - In a C-Programm
> >>>> - socket(AF_INET,SOCK_STREAM,IPPROTO_SCTP);
> >>>> - connect(....) (with correct filled parameters)
> >>>>
> >>>> Its no process (waiting in accept) neccessary
> >>> Can you show us the panic message and your C prorgam?
> >>> This would help reproducing the panic...
> >> ...snip...
> >>
> >> The crash says:
> >>
> >> crash> bt
> >> PID: 14646 TASK: ffff8801f40c7560 CPU: 9 COMMAND: "x"
> >> #0 [ffff8801f6f5f6f0] machine_kexec at ffffffff8103697b
> >> #1 [ffff8801f6f5f750] crash_kexec at ffffffff810b9078
> >> #2 [ffff8801f6f5f820] oops_end at ffffffff814cc900
> >> #3 [ffff8801f6f5f850] die at ffffffff8101733b
> >> #4 [ffff8801f6f5f880] do_trap at ffffffff814cc1d4
> >> #5 [ffff8801f6f5f8e0] do_invalid_op at ffffffff81014ee5
> >> #6 [ffff8801f6f5f980] invalid_op at ffffffff81013f5b
> >> [exception RIP: skb_over_panic+93]
> >> RIP: ffffffff81404bdd RSP: ffff8801f6f5fa38 RFLAGS: 00010296
> >> RAX: 0000000000000083 RBX: 0000000000000040 RCX: 00000000000013f6
> >> RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246
> >> RBP: ffff8801f6f5fa58 R8: ffffffff818a3da0 R9: 0000000000000000
> >> R10: 0000000000000001 R11: 0000000000000000 R12: ffff8801f4e11000
> >> R13: 0000000000000004 R14: 000000000000003e R15: 0000000000000001
> >> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> >> #7 [ffff8801f6f5fa60] skb_put at ffffffff81405c1c
> >> #8 [ffff8801f6f5fa80] sctp_addto_chunk at ffffffffa0503c23
> >> #9 [ffff8801f6f5fad0] sctp_make_init at ffffffffa0506705
> >> #10 [ffff8801f6f5fba0] sctp_sf_do_prm_asoc at ffffffffa04f81d4
> >> #11 [ffff8801f6f5fbd0] sctp_do_sm at ffffffffa04fd381
> >> #12 [ffff8801f6f5fd60] sctp_primitive_ASSOCIATE at ffffffffa0513daf
> >> #13 [ffff8801f6f5fd80] __sctp_connect at ffffffffa0510f09
> >> #14 [ffff8801f6f5fe50] sctp_connect at ffffffffa0511248
> >> #15 [ffff8801f6f5fe80] inet_dgram_connect at ffffffff81471b6c
> >> #16 [ffff8801f6f5feb0] sys_connect at ffffffff813ff747
> >> #17 [ffff8801f6f5ff80] system_call_fastpath at ffffffff81013172
> >> RIP: 0000003015ee2150 RSP: 00007fffea7bdce8 RFLAGS: 00010206
> >> RAX: 000000000000002a RBX: ffffffff81013172 RCX: 0000000000000000
> >> RDX: 0000000000000010 RSI: 00007fffea7bdd00 RDI: 0000000000000003
> >> RBP: 00007fffea7bdd40 R8: 0000000000759020 R9: ff00000000000000
> >> R10: 00007fffea7bda70 R11: 0000000000000246 R12: 0000000000000000
> >> R13: 00007fffea7bde20 R14: 00000000004006e0 R15: 0000000000000000
> >> ORIG_RAX: 000000000000002a CS: 0033 SS: 002b
> >>
> >>
> >>
>
> Are you using old kernel? If it is, the following patch may fixed this
> issue.
>
> http://git.kernel.org/?p=linux/kernel/git/vxy/lksctp-dev.git;a=commitdiff;h=a8170c35e738d62e9919ce5b109cf4ed66e95bde;hp=81419d862db743fe4450a021893f24bab4698c1d
>
I am using:
Red Hat Enterprise Linux Server release 6.0 (Santiago)
2.6.32-71.18.1.el6.x86_64 #1 SMP Wed Feb 2 17:49:59 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
> >>>> br
> >>>> walter
> >>>> --
> >>>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> >>>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
> >>>> --
> >>>> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel"
> >>> in
> >>>> the body of a message to majordomo@vger.kernel.org
> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>> Please read the FAQ at http://www.tux.org/lkml/
> >>>>
> >>> --
> >>> Thanks,
> >>> //richard
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>> Please read the FAQ at http://www.tux.org/lkml/
> >> --
> >> NEU: FreePhone - kostenlos mobil telefonieren und surfen!
> >> Jetzt informieren: http://www.gmx.net/de/go/freephone
> >>
> > CC'ing netdev
> >
>
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
^ permalink raw reply
* Re: SO_BINDTODEVICE inconsistency between IPv4 and IPv6
From: David Woodhouse @ 2011-03-18 8:54 UTC (permalink / raw)
To: Brian Haley; +Cc: netdev, Yuniverg, Michael, Yedvab, Nadav
In-Reply-To: <4D82B4DB.2060006@hp.com>
On Thu, 2011-03-17 at 21:26 -0400, Brian Haley wrote:
> Hmm, "connection refused", do you have any iptables rules installed? Connecting
> to a local global address worked fine for me on 2.6.32-30 using a home-grown
> test app.
Thanks for looking at this.
Just to confirm... after your server does SO_BINDTODEVICE to 'lo', your
clients on the same host can make a successful connection to global IPv6
addresses which are assigned to the *other* interfaces?
Can you show your version of the test app, and your results? What kernel
is this on?
--
dwmw2
^ permalink raw reply
* Re: VLAN over GRE segfault
From: Eric Dumazet @ 2011-03-18 10:27 UTC (permalink / raw)
To: Diddi Oscarsson, David Miller; +Cc: netdev, Herbert Xu, Patrick McHardy
In-Reply-To: <4D830AF9.8040007@diddi.se>
Le vendredi 18 mars 2011 à 08:34 +0100, Diddi Oscarsson a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello!
>
> I was trying to get ethernet over GRE to work when I found an obvious
> way NOT to do it.
> Basically I created a VLAN interface from the GRE interface (even
> though I had my fair doubts it would work) which gave me a nice segfault.
> The problem with this is that after the segfault, new network
> connections cannot be made (ping, ssh, http, whatever) and a reboot of
> the computer is necessary.
> I think an error message needs to be added when trying an operation
> like this.
>
> My system:
> Linux colalapp 2.6.37-2-amd64 #1 SMP Sun Feb 27 10:12:22 UTC 2011
> x86_64 GNU/Linux
> ip utility, iproute2-ss110107
> Debian unstable
>
> Steps to reproduce:
> ip tunnel add gre0 mode gre
> ip link add link gre0 name vlan1 type vlan id 1
> ip link set vlan1 address 00:15:14:13:12:11
> ip link set gre0 up
> ip link set vlan1 up
> <CRASH>
> Attached in the mail is an output from dmesg right after the segfault.
>
> Regarding ethernet over gre, I've just found out about gretap which
> I'm testing right now.
Hi Diddi
It might be a 2.6.28 regression, after commit c95b819ad7
(gre: Use needed_headroom)
Thanks
[PATCH] vlan: should take into account needed_headroom
Commit c95b819ad7 (gre: Use needed_headroom)
made gre use needed_headroom instead of hard_header_len
This uncover a bug in vlan code.
We should make sure vlan devices take into account their
real_dev->needed_headroom or we risk a crash in ipgre_header(), because
we dont have enough room to push IP header in skb.
Reported-by: Diddi Oscarsson <diddi@diddi.se>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
net/8021q/vlan_dev.c | 1 +
1 files changed, 1 insertion(+)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index ae610f0..e34ea9e 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -720,6 +720,7 @@ static int vlan_dev_init(struct net_device *dev)
dev->fcoe_ddp_xid = real_dev->fcoe_ddp_xid;
#endif
+ dev->needed_headroom = real_dev->needed_headroom;
if (real_dev->features & NETIF_F_HW_VLAN_TX) {
dev->header_ops = real_dev->header_ops;
dev->hard_header_len = real_dev->hard_header_len;
^ permalink raw reply related
* Re: [PATCH] netfilter: xtables: fix reentrancy
From: Jesper Dangaard Brouer @ 2011-03-18 10:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Patrick McHardy, Netfilter Developers, netdev
In-Reply-To: <1300367841.6315.9.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1883 bytes --]
On Thu, 17 Mar 2011, Eric Dumazet wrote:
> Le jeudi 17 mars 2011 à 12:45 +0100, Eric Dumazet a écrit :
>> Le jeudi 17 mars 2011 à 12:36 +0100, Jesper Dangaard Brouer a écrit :
>>> Hi Eric,
>>>
>>> How critial is this bug fix?
>>>
>>> Should I apply this on my stable production kernels?
>>> (I'm preparing a 2.6.38 kernel for prod usage, eventhougt its just been
>>> released, because I want your SFQ fixes...)
>>
>> I would say the race is there, but probability must be very small, and
>> might need malicious iptables rules (with RETURN targets)
Actually do have a large number of return targets.
In the filter forward chain.
>> Especially in routers, where OUTPUT path is taken from softirq handler
>> anyway ;)
>>
>> So dont worry at all, consider this as a cleanup :)
>>
>
> Almost forgot to mention your kernels probably have :
>
> CONFIG_PREEMPT_NONE=y
> # CONFIG_PREEMPT is not set
>
> So you can take it easy ;)
I have actually enabled PREEMPTion, am I in trouble then?
I have modified the .config I got from you, quite a lot, during my
attempts to find the CCISS/HPSA problem.
Which reminds me that I needed to enable, the follwing config options,
(which your config didn't have):
CONFIG_PCIEASPM=y
CONFIG_X86_X2APIC=y
In order to get rid of a PCI warning:
NMI: PCI system error (SERR) for reason b1 on CPU 0.
Dazed and confused, but trying to continue
The system worked fine, and you might not see this issue on your G6
servers, as its most likely BIOS related (my server is a HP DL370 G6).
FYI: Operations have deployed the kernel on prod server this morning.
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] netfilter: xtables: fix reentrancy
From: Eric Dumazet @ 2011-03-18 10:50 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, Patrick McHardy, Netfilter Developers, netdev
In-Reply-To: <Pine.LNX.4.64.1103181113040.21558@ask.diku.dk>
Le vendredi 18 mars 2011 à 11:27 +0100, Jesper Dangaard Brouer a écrit :
> I have actually enabled PREEMPTion, am I in trouble then?
>
Well, to get problem on localy generated trafic (as all forwarding is
done from softirq handler), you'll need a malicious -j RETURN in OUTPUT
hook (in the OUTPUT chain, not a called one)
Also, even for localy generated trafic, I guess most callers block BH
before calling ipt_do_table() anyway...
> I have modified the .config I got from you, quite a lot, during my
> attempts to find the CCISS/HPSA problem.
>
> Which reminds me that I needed to enable, the follwing config options,
> (which your config didn't have):
> CONFIG_PCIEASPM=y
> CONFIG_X86_X2APIC=y
>
> In order to get rid of a PCI warning:
> NMI: PCI system error (SERR) for reason b1 on CPU 0.
> Dazed and confused, but trying to continue
>
> The system worked fine, and you might not see this issue on your G6
> servers, as its most likely BIOS related (my server is a HP DL370 G6).
>
Mine is ProLiant BL460c G6
> FYI: Operations have deployed the kernel on prod server this morning.
Okay, lets pray ;)
^ permalink raw reply
* [PATCH RFC] net: unify features for drivers which use skb_copy_and_csum_dev
From: Cesar Eduardo Barros @ 2011-03-18 10:57 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Jeff Garzik, Lennert Buytenhek, Tristram Ha,
Roger Luethi, Michał Mirosław, Cesar Eduardo Barros
A few network drivers use skb_copy_and_csum_dev as the core of their
.ndo_start_xmit function. Which NETIF_F_* features these drivers can use
should depend only on the implementation of skb_copy_and_csum_dev, and
so should be the same for all of them. However, I could find three
different sets of feature flags on these drivers.
To prevent these drivers from getting out of sync again, move this set
of feature flags to a central location. With the advantage that if the
set of flags is later found to be wrong or skb_copy_and_csum_dev is
modified, it can be changed in a single place.
This also enables NETIF_F_FRAGLIST for these drivers. Unless I misread
the code behind skb_copy_and_csum_dev, it can also deal with frag lists.
There were other drivers using skb_copy_and_csum_dev (ksz884x and
via-rhine), but I did not touch them, since they are doing things on
their .ndo_start_xmit which are more complex than a simple call of
skb_copy_and_csum_dev.
Cc: Jeff Garzik <jgarzik@pobox.com> (8139too)
Cc: Lennert Buytenhek <kernel@wantstofly.org> (ep93xx_eth, ixp2000)
Cc: Tristram Ha <Tristram.Ha@micrel.com> (ksz884x)
Cc: Roger Luethi <rl@hellgate.ch> (via-rhine)
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
drivers/net/8139too.c | 2 +-
drivers/net/arm/ep93xx_eth.c | 2 +-
drivers/net/ixp2000/ixpdev.c | 2 +-
drivers/net/sc92031.c | 3 +--
include/linux/netdevice.h | 4 ++++
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 98517a3..0fc2127 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -991,7 +991,7 @@ static int __devinit rtl8139_init_one (struct pci_dev *pdev,
* through the use of skb_copy_and_csum_dev we enable these
* features
*/
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA;
+ dev->features |= NETIF_F_XMIT_COPY_AND_CSUM;
dev->irq = pdev->irq;
diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 5a77001..50ebd33 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -769,7 +769,7 @@ static struct net_device *ep93xx_dev_alloc(struct ep93xx_eth_data *data)
dev->ethtool_ops = &ep93xx_ethtool_ops;
dev->netdev_ops = &ep93xx_netdev_ops;
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ dev->features |= NETIF_F_XMIT_COPY_AND_CSUM;
return dev;
}
diff --git a/drivers/net/ixp2000/ixpdev.c b/drivers/net/ixp2000/ixpdev.c
index 78ddd8b..0df0734 100644
--- a/drivers/net/ixp2000/ixpdev.c
+++ b/drivers/net/ixp2000/ixpdev.c
@@ -303,7 +303,7 @@ struct net_device *ixpdev_alloc(int channel, int sizeof_priv)
dev->netdev_ops = &ixpdev_netdev_ops;
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ dev->features |= NETIF_F_XMIT_COPY_AND_CSUM;
ip = netdev_priv(dev);
ip->dev = dev;
diff --git a/drivers/net/sc92031.c b/drivers/net/sc92031.c
index 76290a8..63db429 100644
--- a/drivers/net/sc92031.c
+++ b/drivers/net/sc92031.c
@@ -1449,8 +1449,7 @@ static int __devinit sc92031_probe(struct pci_dev *pdev,
dev->irq = pdev->irq;
/* faked with skb_copy_and_csum_dev */
- dev->features = NETIF_F_SG | NETIF_F_HIGHDMA |
- NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+ dev->features = NETIF_F_XMIT_COPY_AND_CSUM;
dev->netdev_ops = &sc92031_netdev_ops;
dev->watchdog_timeo = TX_TIMEOUT;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 5eeb2cd..680ed33 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1110,6 +1110,10 @@ struct net_device {
/* changeable features with no special hardware requirements */
#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO)
+ /* skb_copy_and_csum_dev is able to fake a few features */
+#define NETIF_F_XMIT_COPY_AND_CSUM (NETIF_F_SG | NETIF_F_HW_CSUM | \
+ NETIF_F_HIGHDMA | NETIF_F_FRAGLIST)
+
/* Interface index. Unique device identifier */
int ifindex;
int iflink;
--
1.7.4
^ permalink raw reply related
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