* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-10-20 0:28 UTC (permalink / raw)
To: Joyce.Yu; +Cc: netdev
In-Reply-To: <4AD4F0BF.1040606@Sun.COM>
If you send this patch improperly any more times, I'm simply just
going to start ignoring your patch postings completely.
First of all, you did not add a proper commit message with your patch
explaining your change, in detail. I've asked you for this not ONCE,
but TWICE.
You also did not provide a proper Signed-off-by: tag for your change,
please read linux/Documentation/SubmittingPatches for details.
Every time you submit a patch improperly, you waste a lot of my time.
I have to handle receiving patches from hundreds of people every day,
I don't have time to teach each and every one of them how to submit
things properly. I especially don't have time to do it MULTIPLE
TIMES, like I have been doing for you.
^ permalink raw reply
* Re: Subject: [PATCH 1/6] bna: Brocade 10Gb Ethernet device driver
From: Herbert Xu @ 2009-10-20 0:54 UTC (permalink / raw)
To: Rasesh Mody; +Cc: netdev, amathur
In-Reply-To: <200910161824.n9GIOuoX010135@blc-10-10.brocade.com>
Rasesh Mody <rmody@brocade.com> wrote:
.
> +static int bnad_lro_get_skb_header(struct sk_buff *skb, void **iphdr,
> + void **tcphdr, u64 *hdr_flags, void *priv)
Please stop using LRO in new code. The GRO replacement should
be used instead.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Kernel oops when clearing bgp neighbor info with TCP MD5SUM enabled
From: Anirban Sinha @ 2009-10-20 0:56 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Anirban Sinha, linux-kernel, David Miller, netdev
In-Reply-To: <20091019121327.GA11423@redhat.com>
> I'd suppose that this unbalance comes from inet_twdr_hangman() pathes.
>
> Could you verify this?
Yes, I have now verified this. There is indeed an issue with one of the
functions called by inet_twdr_hangman(). The call sequence is:
inet_twdr_hangman() -> inet_twdr_do_twkill_work() -> inet_twsk_put() ->
twsk_destructor().
In this case, the destructor callback is tcp_twsk_destructor() (installed
from line 1208 in net/ipv4/tcp_ipv4.c and line 906 in net/ipv6/tcp_ipv6.c) .
Without the TCP_MD5SUM compiled in, the function is a no-op. However, with the MD5SUM
compiled in, it calls tcp_put_md5_sig_pool() (when keylen is non zero) which
does an unbalanced put_cpu(). I did a grep across the entire tree.
tcp_put_md5_sig_pool() is a matching function for tcp_get_md5_sig_pool() and
in all other TCP IPV4 cases, it is called from net/ipv4/tcp_ipv4.c from
functions tcp_v4_md5_hash_hdr() and
^ permalink raw reply
* [PATCH] Re: Kernel oops when clearing bgp neighbor info with TCP MD5SUM enabled
From: Anirban Sinha @ 2009-10-20 1:08 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Anirban Sinha, linux-kernel, David Miller, netdev
In-Reply-To: <Pine.LNX.4.64.0910191745050.20086@sleet.zeugmasystems.local>
> I'd suppose that this unbalance comes from inet_twdr_hangman() pathes.
>
> Could you verify this?
Yes, I have now verified this. There is indeed an issue with one of the
functions called by inet_twdr_hangman(). The call sequence is:
inet_twdr_hangman() -> inet_twdr_do_twkill_work() -> inet_twsk_put() ->
twsk_destructor().
In this case, the destructor callback is tcp_twsk_destructor() (installed
from line 1208 in net/ipv4/tcp_ipv4.c and line 906 in net/ipv6/tcp_ipv6.c) .
Without the TCP_MD5SUM compiled in, the function is a no-op. However, with the MD5SUM
compiled in, it calls tcp_put_md5_sig_pool() (when keylen is non zero) which
does an unbalanced put_cpu(). I did a grep across the entire tree.
tcp_put_md5_sig_pool() is a matching function for tcp_get_md5_sig_pool() and
in all other TCP IPV4 cases, it is called from net/ipv4/tcp_ipv4.c from
functions tcp_v4_md5_hash_hdr() and tcp_v4_hash_skb() along with the matching
get()
function. So I would think that in tcp_twsk_destructor(), the call should be
replaced by tcp_free_md5_sig_pool() instead.
Signed-of-by: Anirban Sinha <asinha@zeugmasystems.com>
---
net/ipv4/tcp_minisocks.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index e48c37d..dccc01e 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -363,7 +363,7 @@ void tcp_twsk_destructor(struct sock *sk)
#ifdef CONFIG_TCP_MD5SIG
struct tcp_timewait_sock *twsk = tcp_twsk(sk);
if (twsk->tw_md5_keylen)
- tcp_put_md5sig_pool();
+ tcp_free_md5sig_pool();
#endif
}
^ permalink raw reply related
* Re: [PATCH] Re: Kernel oops when clearing bgp neighbor info with TCP MD5SUM enabled
From: David Miller @ 2009-10-20 1:13 UTC (permalink / raw)
To: asinha; +Cc: oleg, ani, linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.64.0910191756420.20086@sleet.zeugmasystems.local>
From: Anirban Sinha <asinha@zeugmasystems.com>
Date: Mon, 19 Oct 2009 18:08:21 -0700 (PDT)
> @@ -363,7 +363,7 @@ void tcp_twsk_destructor(struct sock *sk)
> #ifdef CONFIG_TCP_MD5SIG
> struct tcp_timewait_sock *twsk = tcp_twsk(sk);
> if (twsk->tw_md5_keylen)
> - tcp_put_md5sig_pool();
> + tcp_free_md5sig_pool();
> #endif
> }
This has been fixed in the tree for a month of so:
commit 657e9649e745b06675aa5063c84430986cdc3afa
Author: Robert Varga <nite@hq.alert.sk>
Date: Tue Sep 15 23:49:21 2009 -0700
tcp: fix CONFIG_TCP_MD5SIG + CONFIG_PREEMPT timer BUG()
I have recently came across a preemption imbalance detected by:
<4>huh, entered ffffffff80644630 with preempt_count 00000102, exited with 00000101?
<0>------------[ cut here ]------------
<2>kernel BUG at /usr/src/linux/kernel/timer.c:664!
<0>invalid opcode: 0000 [1] PREEMPT SMP
with ffffffff80644630 being inet_twdr_hangman().
This appeared after I enabled CONFIG_TCP_MD5SIG and played with it a
bit, so I looked at what might have caused it.
One thing that struck me as strange is tcp_twsk_destructor(), as it
calls tcp_put_md5sig_pool() -- which entails a put_cpu(), causing the
detected imbalance. Found on 2.6.23.9, but 2.6.31 is affected as well,
as far as I can tell.
Signed-off-by: Robert Varga <nite@hq.alert.sk>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 045bcfd..624c3c9 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -363,7 +363,7 @@ void tcp_twsk_destructor(struct sock *sk)
#ifdef CONFIG_TCP_MD5SIG
struct tcp_timewait_sock *twsk = tcp_twsk(sk);
if (twsk->tw_md5_keylen)
- tcp_put_md5sig_pool();
+ tcp_free_md5sig_pool();
#endif
}
^ permalink raw reply related
* Re: [PATCH] Re: Kernel oops when clearing bgp neighbor info with TCP MD5SUM enabled
From: Anirban Sinha @ 2009-10-20 1:17 UTC (permalink / raw)
To: David Miller; +Cc: oleg, ani, linux-kernel, netdev
In-Reply-To: <20091019.181341.104579802.davem@davemloft.net>
> This has been fixed in the tree for a month of so:
Grrrr! Time for me to do a git pull again. The kernel source tree in my work
machine must be out of date by about the same time.
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: David Miller @ 2009-10-20 2:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: ja, w, netdev
In-Reply-To: <4ADCC58B.2060408@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 19 Oct 2009 22:01:15 +0200
> David, I think we should revert 6d01a026b7d3009a418326bdcf313503a314f1ea
> (tcp: fix tcp_defer_accept to consider the timeout)
> since we know its broken.
I've reverted that patch and applied Julian's three tcp
patches, thanks!
^ permalink raw reply
* Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces
From: David Miller @ 2009-10-20 2:28 UTC (permalink / raw)
To: mostrows; +Cc: gorcunov, eric.dumazet, denys, netdev, linux-ppp, paulus,
mostrows
In-Reply-To: <e6d1cecd0910191422t2905d9bbl3355fc50cf36ff90@mail.gmail.com>
Please stop top posting!
I want to follow this discussions efficiently and that's impossible
if you reply BEFORE instead of AFTER the context of what you're
replying to.
Note that a day will come very soon that postings to these lists
that do top posting will be flat out bounced back to you and
never make it to the list at all.
^ permalink raw reply
* Re: [PATCH 1/2] bluetooth: scheduling while atomic bug fix
From: David Miller @ 2009-10-20 2:37 UTC (permalink / raw)
To: hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w
Cc: marcel-kz+m5ild9QBg9hUCZPvPmw,
alan-qBU/x9rampVanCEyBjwyrvXRex20P6io,
oliver-fJ+pQTUTwRTk1uMJSBkQmQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091019062441.GA4102-4/PLUo9XfK+SVgrV+fD4Uw@public.gmane.org>
From: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 19 Oct 2009 14:24:41 +0800
> Due to driver core changes dev_set_drvdata will call kzalloc which should be
> in might_sleep context, but hci_conn_add will be called in atomic context
>
> Like dev_set_name move dev_set_drvdata to work queue function.
>
> oops as following:
...
> Signed-off-by: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] bluetooth: static lock key fix
From: David Miller @ 2009-10-20 2:37 UTC (permalink / raw)
To: hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w
Cc: marcel-kz+m5ild9QBg9hUCZPvPmw, oliver-fJ+pQTUTwRTk1uMJSBkQmQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091019062830.GB4102-4/PLUo9XfK+SVgrV+fD4Uw@public.gmane.org>
From: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 19 Oct 2009 14:28:30 +0800
> When shutdown ppp connection, lockdep waring about non-static key
> will happen, it is caused by the lock is not initialized properly
> at that time.
>
> Fix with tuning the lock/skb_queue_head init order
...
> Reported-by: Oliver Hartkopp <oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
> Signed-off-by: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Oliver Hartkopp <oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Applied, thanks Dave.
^ permalink raw reply
* Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces
From: Cyrill Gorcunov @ 2009-10-20 3:04 UTC (permalink / raw)
To: Denys Fedoryschenko
Cc: Michal Ostrowski, Eric Dumazet, netdev, linux-ppp, paulus,
mostrows
In-Reply-To: <200910200308.57381.denys@visp.net.lb>
On 10/20/09, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> On Tuesday 20 October 2009 00:22:39 Michal Ostrowski wrote:
>> I'm assuming that there was a race in us sending patches at nearly the
>> same
>> time I'm convinced now that the flush_lock can die, and the patch I sent
>> out kills it.
> o_O
>
> I am drowning in patches. Just let me know which one to test :-)
>
Oh ;) Try out latest Michal's patch (and then mine). I'll continue
digg this issue at next spare time slot. Thanks!
^ permalink raw reply
* pktgen and spin_lock_bh in xmit path
From: Ben Greear @ 2009-10-20 3:38 UTC (permalink / raw)
To: NetDev
I'm having strange issues when running pktgen on 10G interfaces while
also running
pktgen on mac-vlans on that interface, when the mac-vlan pktgen threads
are on a different
CPU.
First, lockdep gives up and says that things are not properly
annotated. I believe this is because
the macvlan tx path will lock it's txq and will also lock the
lower-dev's txq. To fix this, perhaps
we need some new lockdep aware primitives for netdev txq locking?
Second, is using _bh() locking really sufficient if we have pktgen
writing to a physical device
and also have other pktgen threads writing to that same device though
mac-vlans? I'm seeing
deadlocks spinning on the _bh() lock in pktgen as well as strange
corruptions, so I think there
must be *some* problem somewhere, I just don't know quite what it is yet.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces
From: Eric Dumazet @ 2009-10-20 3:42 UTC (permalink / raw)
To: Michal Ostrowski
Cc: Cyrill Gorcunov, Denys Fedoryschenko, netdev, linux-ppp, paulus,
mostrows
In-Reply-To: <e6d1cecd0910191354o16d023d2lbe2761a97e88acea@mail.gmail.com>
Michal Ostrowski a écrit :
> Access of po->pppoe_dev is guarded by sk->sk_state & PPPOX_CONNECTED,
> and all use cases now rely on the socket lock. Because of this, the
> ref-count on the namespace held by the socket object suffices to hold
> the namespace in existence and so we don't need to ref-count the
> namespace in PPPoE. The flush_lock is gone.
>
Seems good !
But can we use lock_sock() in __pppoe_xmit() context ?
^ permalink raw reply
* Re: pktgen and spin_lock_bh in xmit path
From: Eric Dumazet @ 2009-10-20 3:48 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4ADD309B.1040505@candelatech.com>
Ben Greear a écrit :
> I'm having strange issues when running pktgen on 10G interfaces while
> also running
> pktgen on mac-vlans on that interface, when the mac-vlan pktgen threads
> are on a different
> CPU.
>
> First, lockdep gives up and says that things are not properly
> annotated. I believe this is because
> the macvlan tx path will lock it's txq and will also lock the
> lower-dev's txq. To fix this, perhaps
> we need some new lockdep aware primitives for netdev txq locking?
>
> Second, is using _bh() locking really sufficient if we have pktgen
> writing to a physical device
> and also have other pktgen threads writing to that same device though
> mac-vlans? I'm seeing
> deadlocks spinning on the _bh() lock in pktgen as well as strange
> corruptions, so I think there
> must be *some* problem somewhere, I just don't know quite what it is yet.
>
Could you please give us a copy if your pktgen scripts ?
^ permalink raw reply
* Re: [PATCH] net: Fix IP_MULTICAST_IF
From: David Miller @ 2009-10-20 3:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ADC96D6.4000909@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 19 Oct 2009 18:41:58 +0200
> ipv4/ipv6 setsockopt(IP_MULTICAST_IF) have dubious __dev_get_by_index() calls.
Dubious, how so?
Yes, I know RTNL/dev_base_lock, but it's not using what it gets
back at all.
It's testing existence, a boolean, it doesn't dereference the
'dev' it gets back at all.
This code is intentional and perfectly fine.
^ permalink raw reply
* Re: [PATCH] net: Fix IP_MULTICAST_IF
From: Eric Dumazet @ 2009-10-20 4:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091019.205948.193706797.davem@davemloft.net>
David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 19 Oct 2009 18:41:58 +0200
>
>> ipv4/ipv6 setsockopt(IP_MULTICAST_IF) have dubious __dev_get_by_index() calls.
>
> Dubious, how so?
>
> Yes, I know RTNL/dev_base_lock, but it's not using what it gets
> back at all.
>
> It's testing existence, a boolean, it doesn't dereference the
> 'dev' it gets back at all.
>
> This code is intentional and perfectly fine.
If this was intentional, something changed and made the prereq false.
Final target might be fine, but an element in the chain, before target
could be deleted while reader scans hash chain.
/* Device list removal */
static void unlist_netdevice(struct net_device *dev)
{
ASSERT_RTNL();
/* Unlink dev from the device chain */
write_lock_bh(&dev_base_lock);
list_del(&dev->dev_list);
hlist_del(&dev->name_hlist);
hlist_del(&dev->index_hlist); <<< HERE >>>
write_unlock_bh(&dev_base_lock);
}
static inline void hlist_del(struct hlist_node *n)
{
__hlist_del(n);
n->next = LIST_POISON1; <<< HERE >>>
n->pprev = LIST_POISON2;
}
include/linux/poison.h:#define LIST_POISON1 ((void *) 0x00100100)
reader tries to pass over this delete net_device, doing a dev->index_hlist->next
#define hlist_for_each(pos, head) \
for (pos = (head)->first; pos && ({ prefetch(pos->next); 1; }); \
pos = pos->next)
So it should visit a nice memory location ?
^ permalink raw reply
* Re: [PATCH] net: Fix IP_MULTICAST_IF
From: Eric Dumazet @ 2009-10-20 4:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <4ADD3794.8030906@gmail.com>
Eric Dumazet a écrit :
> David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Mon, 19 Oct 2009 18:41:58 +0200
>>
>>> ipv4/ipv6 setsockopt(IP_MULTICAST_IF) have dubious __dev_get_by_index() calls.
>> Dubious, how so?
>>
>> Yes, I know RTNL/dev_base_lock, but it's not using what it gets
>> back at all.
>>
>> It's testing existence, a boolean, it doesn't dereference the
>> 'dev' it gets back at all.
>>
>> This code is intentional and perfectly fine.
>
> If this was intentional, something changed and made the prereq false.
>
> Final target might be fine, but an element in the chain, before target
> could be deleted while reader scans hash chain.
>
BTW, even an insertion can crash a lockless reader, since reader could see a corrupt
n->next (hlist_add_head() has no barrier between n->next = first and h->first = n;)
static inline void hlist_add_head(struct hlist_node *n, struct hlist_head *h)
{
struct hlist_node *first = h->first;
n->next = first;
if (first)
first->pprev = &n->next;
h->first = n;
n->pprev = &h->first;
}
^ permalink raw reply
* Re: [PATCH 4/4 v3] net: Fix for dst_negative_advice
From: David Miller @ 2009-10-20 4:17 UTC (permalink / raw)
To: krkumar2; +Cc: shemminger, dada1, herbert, netdev
In-Reply-To: <OF47BDCCCB.33D1775A-ON65257654.00178901-65257654.00192AA2@in.ibm.com>
From: Krishna Kumar2 <krkumar2@in.ibm.com>
Date: Mon, 19 Oct 2009 10:04:53 +0530
> Should I resubmit with the changed order?
I took care of this.
I put the patch that actually makes dev.c use sk_tx_queue_mapping
last in the set.
All applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net: Fix IP_MULTICAST_IF
From: David Miller @ 2009-10-20 4:20 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ADD3794.8030906@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Oct 2009 06:07:48 +0200
> Final target might be fine, but an element in the chain, before target
> could be deleted while reader scans hash chain.
...
> So it should visit a nice memory location ?
It should hit a NULL eventually and deterministically even if an
unlink happens at the same time..... unless the object gets free'd
meanwhile, hmmm...
This code is definitely intentional, I remember when I added it to
the tree, Alexey wrote it :-)
^ permalink raw reply
* Re: [PATCH] net: Fix IP_MULTICAST_IF
From: David Miller @ 2009-10-20 4:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ADD3982.2040100@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Oct 2009 06:16:02 +0200
> BTW, even an insertion can crash a lockless reader, since reader
> could see a corrupt n->next (hlist_add_head() has no barrier
> between n->next = first and h->first = n;)
Ok, now that convinces it for me, I'll apply your patch, thanks!
^ permalink raw reply
* Re: [PATCH] net: Fix IP_MULTICAST_IF
From: Eric Dumazet @ 2009-10-20 4:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091019.212018.79580287.davem@davemloft.net>
David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 20 Oct 2009 06:07:48 +0200
>
>> Final target might be fine, but an element in the chain, before target
>> could be deleted while reader scans hash chain.
> ...
>> So it should visit a nice memory location ?
>
> It should hit a NULL eventually and deterministically even if an
> unlink happens at the same time..... unless the object gets free'd
> meanwhile, hmmm...
>
> This code is definitely intentional, I remember when I added it to
> the tree, Alexey wrote it :-)
I wonder if the whole thing could use RCU somehow, since some workloads hit
this dev_base_lock rwlock pretty hard...
^ permalink raw reply
* Re: [PATCH] net: Fix IP_MULTICAST_IF
From: David Miller @ 2009-10-20 4:28 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ADD3B5A.1080905@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Oct 2009 06:23:54 +0200
> I wonder if the whole thing could use RCU somehow, since some
> workloads hit this dev_base_lock rwlock pretty hard...
True, but for now we'll put your fix in :-)
^ permalink raw reply
* Re: pktgen and spin_lock_bh in xmit path
From: Ben Greear @ 2009-10-20 4:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev
In-Reply-To: <4ADD32FA.6030409@gmail.com>
Eric Dumazet wrote:
> Ben Greear a écrit :
>
>> I'm having strange issues when running pktgen on 10G interfaces while
>> also running
>> pktgen on mac-vlans on that interface, when the mac-vlan pktgen threads
>> are on a different
>> CPU.
>>
>> First, lockdep gives up and says that things are not properly
>> annotated. I believe this is because
>> the macvlan tx path will lock it's txq and will also lock the
>> lower-dev's txq. To fix this, perhaps
>> we need some new lockdep aware primitives for netdev txq locking?
>>
>> Second, is using _bh() locking really sufficient if we have pktgen
>> writing to a physical device
>> and also have other pktgen threads writing to that same device though
>> mac-vlans? I'm seeing
>> deadlocks spinning on the _bh() lock in pktgen as well as strange
>> corruptions, so I think there
>> must be *some* problem somewhere, I just don't know quite what it is yet.
>>
>>
>
> Could you please give us a copy if your pktgen scripts ?
>
I'm driving it with another program, and my pktgen is a bit hacked, but
the basic idea is:
1 pktgen connection on cpu 0 running as fast as it can (trying for
10Gbps, but getting maybe 3-4),
running between two 10G ports (intel 82599).
Multi-pkt is set to 10,000 on each side.
3 pairs of mac-vlans on each of the two physical 10G ports.
3 pktgen 'connections' between these..each are running at about 1Gbps.
These 3 pktgen connections are on CPU 4.
Multi-pkt is set to 1 since multi-pkt is a very bad idea on virtual
devices.
1514 byte pkts. No IPs on the interfaces, using ToS in pktgen, but
nothing else is configured to
care.
The two physical ports are cabled together directly with a fibre cable.
All pktgen connections are full duplex (both sides transmitting to each
other..and I have
rx logic to gather stats on received pkts as well). With no kernel
debugging, this can run right at 10Gbps bi-directional,
with lockdep it gets around 5-6Gbps in each direction.
The lockup often occurs near starting/stopping pktgen, but also happens
while just normally
running under load, usually within 10 minutes.
I tried and failed to reproduce this on a 1G network, but maybe I'm just
not getting (un)lucky,
didn't try for too long.
Among other things, it appears as if the mac-vlan interfaces sometimes
become locked to transmit
by pktgen, but a raw socket in user-space can send on them fine. I'm
going to add some debugging
for this particular issue tomorrow to try to figure out why that happens.
Please note I have the rest of my network patches applied (but not using
any proprietary modules),
so it could easily be something I've caused. I think fixing lockdep to
work with the txq _bh locks
would be a good first step to fixing this..
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] can: provide library functions for skb allocation
From: David Miller @ 2009-10-20 4:54 UTC (permalink / raw)
To: wg; +Cc: netdev, socketcan-core, haas, anantgole, mkl
In-Reply-To: <4ADB6243.2040109@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Sun, 18 Oct 2009 20:45:23 +0200
> This patch makes the private functions alloc_can_skb() and
> alloc_can_err_skb() of the at91_can driver public and adapts all
> drivers to use these. While making the patch I realized, that
> the skb's are *not* setup consistently. It's now done as shown
> below:
>
> skb->protocol = htons(ETH_P_CAN);
> skb->pkt_type = PACKET_BROADCAST;
> skb->ip_summed = CHECKSUM_UNNECESSARY;
> *cf = (struct can_frame *)skb_put(skb, sizeof(struct can_frame));
> memset(*cf, 0, sizeof(struct can_frame));
>
> The frame is zeroed out to avoid uninitialized data to be passed to
> user space. Some drivers or library code did not set "pkt_type" or
> "ip_summed". Also, "__constant_htons()" should not be used for
> runtime invocations, as pointed out by David Miller.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next V2 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: David Miller @ 2009-10-20 4:54 UTC (permalink / raw)
To: tomas.winkler
Cc: linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1255806576-26869-1-git-send-email-tomas.winkler@intel.com>
From: Tomas Winkler <tomas.winkler@intel.com>
Date: Sat, 17 Oct 2009 21:09:34 +0200
> This patch adds Intel Wireless MultiCom 3200 top driver.
> IWMC3200 is 4Wireless Com CHIP (GPS/BT/WiFi/WiMAX).
> Top driver is responsible for device initialization and firmware download.
> Firmware handled by top is responsible for top itself and
> as well as bluetooth and GPS coms. (Wifi and WiMax provide their own firmware)
> In addition top driver is used to retrieve firmware logs
> and supports other debugging features
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Applied to net-next-2.6
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox