* Re: System freeze on reboot - general protection fault
From: Zdenek Kabelac @ 2009-09-02 22:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Patrick McHardy, Christoph Lameter, Robin Holt,
Linux Kernel Mailing List, Pekka Enberg, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <4A9EEF07.5070800@gmail.com>
2009/9/3 Eric Dumazet <eric.dumazet@gmail.com>:
> Zdenek Kabelac a écrit :
>> 2009/8/17 Patrick McHardy <kaber@trash.net>:
>>> Eric Dumazet wrote:
>>>> Zdenek Kabelac a écrit :
>>>>> [<ffffffffa02c502f>] nf_conntrack_ftp_fini+0x2f/0x70 [nf_conntrack_ftp]
>>>>> [<ffffffff8027bcc5>] sys_delete_module+0x1a5/0x270
>>>>> [<ffffffff8020d329>] ? retint_swapgs+0xe/0x13
>>>>> [<ffffffff80271bf2>] ? trace_hardirqs_on_caller+0x162/0x1b0
>>>>> [<ffffffff80292121>] ? audit_syscall_entry+0x191/0x1c0
>>>>> [<ffffffff80526dae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>>>>> [<ffffffff8020c84b>] system_call_fastpath+0x16/0x1b
>>>>> Code: c6 00 00 0f 82 66 ff ff ff 49 8b 9e d8 05 00 00 48 85 db 75 16
>>>>> e9 8e 00 00 00 0f 1f 44 00 00 48 85 c0 0f 84 80 00 00 00 48 89 c3 <0f>
>>>>> b6 4b 37 48 8b 03 48 8d 14 cd 00 00 00 00 0f 18 08 48 29 ca
>>>>> RIP [<ffffffffa02b2c2c>] nf_conntrack_helper_unregister+0x16c/0x320
>>>>> [nf_conntrack]
>>>>> RSP <ffff88013982fe68>
>>>>> CR2: 0000000000000038
>>>>> ---[ end trace bc3a0ede3d0084db ]---
>>>>>
>>>> I am currently traveling and wont be able to help you before next week.
>>>>
>>>> I added netdev, Patrick, and netfilter-devel in CC so that more eyes can take a look.
>>> Thanks for the report, I'll have a look at this. Zdenek, please
>>> send me the nf_conntrack.ko file used in the above oops. Thanks.
>>>
>>
>> Ok
>>
>> I've found the solution for my problem.
>>
>> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/30483
>>
>> I've made this small fix from this thread:
>>
>> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core
>> index b5869b9..68488f8 100644
>> --- a/net/netfilter/nf_conntrack_core.c
>> +++ b/net/netfilter/nf_conntrack_core.c
>> @@ -1108,6 +1108,7 @@ static void nf_conntrack_cleanup_init_net(void)
>> {
>> nf_conntrack_helper_fini();
>> nf_conntrack_proto_fini();
>> + rcu_barrier();
>> kmem_cache_destroy(nf_conntrack_cachep);
>> }
>>
>> @@ -1266,7 +1267,7 @@ static int nf_conntrack_init_init_net(void)
>>
>> nf_conntrack_cachep = kmem_cache_create("nf_conntrack",
>> sizeof(struct nf_conn),
>> - 0, SLAB_DESTROY_BY_RCU, NULL);
>> + 0, 0, NULL);
>> if (!nf_conntrack_cachep) {
>> printk(KERN_ERR "Unable to create nf_conn slab cache\n");
>> ret = -ENOMEM;
>>
>>
>> As the thread nf_conntrack: Use rcu_barrier() and fix kmem_cache_create flags
>> seems to be samewhat 'unfinished' and already a bit old and I've no
>> idea whether it actually fixes problem completely or just hides it in
>> my case - I'm leaving it to some RCU gurus to fix this issue.
>>
>> All I could say is - this this extra rcu_barrier() and removal of
>> SLAB_DESTROY removes my GPF on reboot.
>>
>> Zdenek
>
> Ouch..
>
> Dont think such a patch makes your kernel better, it'll crash too.
>
> You cannot remove SLAB_DESTROY_BY_RCU like this, it's there for very good reasons.
>
Well I'm not noticing any ill behavior - also note - rcu_barrier() is
there before the cache is destroyed.
But as I said - it's just my shot into the dark - which seems to work for me...
Zdenek
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip: Report qdisc packet drops
From: Eric Dumazet @ 2009-09-02 22:26 UTC (permalink / raw)
To: David Miller; +Cc: cl, sri, dlstevens, netdev, niv, mtk.manpages
In-Reply-To: <4A9E849A.30105@gmail.com>
Eric Dumazet a écrit :
> David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Mon, 31 Aug 2009 14:09:50 +0200
>>
>>> Re-reading again this stuff, I realized ip6_push_pending_frames()
>>> was not updating IPSTATS_MIB_OUTDISCARDS, even if IP_RECVERR was set.
>>>
>>> May I suggest following path :
>>>
>>> 1) Correct ip6_push_pending_frames() to properly
>>> account for dropped-by-qdisc frames when IP_RECVERR is set
>> Your patch is applied to net-next-2.6, thanks!
>>
>>> 2) Submit a patch to account for qdisc-dropped frames in SNMP counters
>>> but still return a OK to user application, to not break them ?
>> Sounds good.
>>
>> I think if you sample random UDP applications, you will find that such
>> errors will upset them terribly, make them log tons of crap to
>> /var/log/messages et al., and consume tons of CPU.
>>
>> And in such cases silent ignoring of drops is entirely appropriate and
>> optimal, which supports our current behavior.
>>
>> If we are to make such applications "more sophisticated" such
>> converted apps can be indicated simply their use of IP_RECVERR.
>>
>> If you want to be notified of all asynchronous errors we can detect,
>> you use this, end of story. It is the only way to handle this
>> situation without breaking the world.
>>
>> As usual, Alexey Kuznetsov's analysis of this situation is timeless,
>> accurate, and wise. And he understood all of this 10+ years ago.
>
> Thanks David, here is the 2nd patch then :
Here is an updated version of the patch, after Christoph comments.
[PATCH net-next-2.6] ip: Report qdisc packet drops
Christoph Lameter pointed out that packet drops at qdisc level where not
accounted in SNMP counters. Only if application sets IP_RECVERR, drops
are reported to user (-ENOBUFS errors) and SNMP counters updated.
IP_RECVERR is used to enable extended reliable error message passing,
but these are not needed to update system wide SNMP stats.
This patch changes things a bit to allow SNMP counters to be updated,
regardless of IP_RECVERR being set or not on the socket.
Example after an UDP tx flood
# netstat -s
...
IP:
1487048 outgoing packets dropped
...
Udp:
...
SndbufErrors: 1487048
send() syscalls, do however still return an OK status, to not
break applications.
Note : send() manual page explicitly says for -ENOBUFS error :
"The output queue for a network interface was full.
This generally indicates that the interface has stopped sending,
but may be caused by transient congestion.
(Normally, this does not occur in Linux. Packets are just silently
dropped when a device queue overflows.) "
This is not true for IP_RECVERR enabled sockets : a send() syscall
that hit a qdisc drop returns an ENOBUFS error.
Many thanks to Christoph, David, and last but not least, Alexey !
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/ip_output.c | 2 +-
net/ipv4/raw.c | 9 +++++++--
net/ipv4/udp.c | 12 +++++++++---
net/ipv6/ip6_output.c | 2 +-
net/ipv6/raw.c | 4 +++-
net/ipv6/udp.c | 12 +++++++++---
6 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 7d08210..afae0cb 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1302,7 +1302,7 @@ int ip_push_pending_frames(struct sock *sk)
err = ip_local_out(skb);
if (err) {
if (err > 0)
- err = inet->recverr ? net_xmit_errno(err) : 0;
+ err = net_xmit_errno(err);
if (err)
goto error;
}
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 2979f14..ebb1e58 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -375,7 +375,7 @@ static int raw_send_hdrinc(struct sock *sk, void *from, size_t length,
err = NF_HOOK(PF_INET, NF_INET_LOCAL_OUT, skb, NULL, rt->u.dst.dev,
dst_output);
if (err > 0)
- err = inet->recverr ? net_xmit_errno(err) : 0;
+ err = net_xmit_errno(err);
if (err)
goto error;
out:
@@ -386,6 +386,8 @@ error_fault:
kfree_skb(skb);
error:
IP_INC_STATS(net, IPSTATS_MIB_OUTDISCARDS);
+ if (err == -ENOBUFS && !inet->recverr)
+ err = 0;
return err;
}
@@ -576,8 +578,11 @@ back_from_confirm:
&ipc, &rt, msg->msg_flags);
if (err)
ip_flush_pending_frames(sk);
- else if (!(msg->msg_flags & MSG_MORE))
+ else if (!(msg->msg_flags & MSG_MORE)) {
err = ip_push_pending_frames(sk);
+ if (err == -ENOBUFS && !inet->recverr)
+ err = 0;
+ }
release_sock(sk);
}
done:
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 29ebb0d..ebaaa7f 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -561,12 +561,18 @@ static int udp_push_pending_frames(struct sock *sk)
send:
err = ip_push_pending_frames(sk);
+ if (err) {
+ if (err == -ENOBUFS && !inet->recverr) {
+ UDP_INC_STATS_USER(sock_net(sk),
+ UDP_MIB_SNDBUFERRORS, is_udplite);
+ err = 0;
+ }
+ } else
+ UDP_INC_STATS_USER(sock_net(sk),
+ UDP_MIB_OUTDATAGRAMS, is_udplite);
out:
up->len = 0;
up->pending = 0;
- if (!err)
- UDP_INC_STATS_USER(sock_net(sk),
- UDP_MIB_OUTDATAGRAMS, is_udplite);
return err;
}
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index a931229..cd48801 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1511,7 +1511,7 @@ int ip6_push_pending_frames(struct sock *sk)
err = ip6_local_out(skb);
if (err) {
if (err > 0)
- err = np->recverr ? net_xmit_errno(err) : 0;
+ err = net_xmit_errno(err);
if (err)
goto error;
}
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 5068410..7d675b8 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -642,7 +642,7 @@ static int rawv6_send_hdrinc(struct sock *sk, void *from, int length,
err = NF_HOOK(PF_INET6, NF_INET_LOCAL_OUT, skb, NULL, rt->u.dst.dev,
dst_output);
if (err > 0)
- err = np->recverr ? net_xmit_errno(err) : 0;
+ err = net_xmit_errno(err);
if (err)
goto error;
out:
@@ -653,6 +653,8 @@ error_fault:
kfree_skb(skb);
error:
IP6_INC_STATS(sock_net(sk), rt->rt6i_idev, IPSTATS_MIB_OUTDISCARDS);
+ if (err == -ENOBUFS && !np->recverr)
+ err = 0;
return err;
}
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 20d2ffc..1640406 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -724,12 +724,18 @@ static int udp_v6_push_pending_frames(struct sock *sk)
send:
err = ip6_push_pending_frames(sk);
+ if (err) {
+ if (err == -ENOBUFS && !inet6_sk(sk)->recverr) {
+ UDP6_INC_STATS_USER(sock_net(sk),
+ UDP_MIB_SNDBUFERRORS, is_udplite);
+ err = 0;
+ }
+ } else
+ UDP6_INC_STATS_USER(sock_net(sk),
+ UDP_MIB_OUTDATAGRAMS, is_udplite);
out:
up->len = 0;
up->pending = 0;
- if (!err)
- UDP6_INC_STATS_USER(sock_net(sk),
- UDP_MIB_OUTDATAGRAMS, is_udplite);
return err;
}
^ permalink raw reply related
* Re: System freeze on reboot - general protection fault
From: Eric Dumazet @ 2009-09-02 22:17 UTC (permalink / raw)
To: Zdenek Kabelac
Cc: Patrick McHardy, Christoph Lameter, Robin Holt,
Linux Kernel Mailing List, Pekka Enberg, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <c4e36d110909021445l5f44183es9e338437dfbbd195@mail.gmail.com>
Zdenek Kabelac a écrit :
> 2009/8/17 Patrick McHardy <kaber@trash.net>:
>> Eric Dumazet wrote:
>>> Zdenek Kabelac a écrit :
>>>> [<ffffffffa02c502f>] nf_conntrack_ftp_fini+0x2f/0x70 [nf_conntrack_ftp]
>>>> [<ffffffff8027bcc5>] sys_delete_module+0x1a5/0x270
>>>> [<ffffffff8020d329>] ? retint_swapgs+0xe/0x13
>>>> [<ffffffff80271bf2>] ? trace_hardirqs_on_caller+0x162/0x1b0
>>>> [<ffffffff80292121>] ? audit_syscall_entry+0x191/0x1c0
>>>> [<ffffffff80526dae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>>>> [<ffffffff8020c84b>] system_call_fastpath+0x16/0x1b
>>>> Code: c6 00 00 0f 82 66 ff ff ff 49 8b 9e d8 05 00 00 48 85 db 75 16
>>>> e9 8e 00 00 00 0f 1f 44 00 00 48 85 c0 0f 84 80 00 00 00 48 89 c3 <0f>
>>>> b6 4b 37 48 8b 03 48 8d 14 cd 00 00 00 00 0f 18 08 48 29 ca
>>>> RIP [<ffffffffa02b2c2c>] nf_conntrack_helper_unregister+0x16c/0x320
>>>> [nf_conntrack]
>>>> RSP <ffff88013982fe68>
>>>> CR2: 0000000000000038
>>>> ---[ end trace bc3a0ede3d0084db ]---
>>>>
>>> I am currently traveling and wont be able to help you before next week.
>>>
>>> I added netdev, Patrick, and netfilter-devel in CC so that more eyes can take a look.
>> Thanks for the report, I'll have a look at this. Zdenek, please
>> send me the nf_conntrack.ko file used in the above oops. Thanks.
>>
>
> Ok
>
> I've found the solution for my problem.
>
> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/30483
>
> I've made this small fix from this thread:
>
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core
> index b5869b9..68488f8 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -1108,6 +1108,7 @@ static void nf_conntrack_cleanup_init_net(void)
> {
> nf_conntrack_helper_fini();
> nf_conntrack_proto_fini();
> + rcu_barrier();
> kmem_cache_destroy(nf_conntrack_cachep);
> }
>
> @@ -1266,7 +1267,7 @@ static int nf_conntrack_init_init_net(void)
>
> nf_conntrack_cachep = kmem_cache_create("nf_conntrack",
> sizeof(struct nf_conn),
> - 0, SLAB_DESTROY_BY_RCU, NULL);
> + 0, 0, NULL);
> if (!nf_conntrack_cachep) {
> printk(KERN_ERR "Unable to create nf_conn slab cache\n");
> ret = -ENOMEM;
>
>
> As the thread nf_conntrack: Use rcu_barrier() and fix kmem_cache_create flags
> seems to be samewhat 'unfinished' and already a bit old and I've no
> idea whether it actually fixes problem completely or just hides it in
> my case - I'm leaving it to some RCU gurus to fix this issue.
>
> All I could say is - this this extra rcu_barrier() and removal of
> SLAB_DESTROY removes my GPF on reboot.
>
> Zdenek
Ouch..
Dont think such a patch makes your kernel better, it'll crash too.
You cannot remove SLAB_DESTROY_BY_RCU like this, it's there for very good reasons.
^ permalink raw reply
* Re: [PATCH net-next-2.6] tc: report informations for multiqueue devices
From: Jarek Poplawski @ 2009-09-02 22:17 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, David Miller, cl, netdev
In-Reply-To: <4A9E7C07.9000109@trash.net>
On Wed, Sep 02, 2009 at 04:07:03PM +0200, Patrick McHardy wrote:
> Eric Dumazet wrote:
> > Patrick McHardy a écrit :
> >> Eric Dumazet wrote:
> >>> [PATCH net-next-2.6] tc: report informations for multiqueue devices
> >>>
> >>> qdisc and classes are not yet displayed by "tc -s -d {qdisc|class} show"
> >>> for multiqueue devices.
> >>>
> >>> We use a new TCA_QINDEX attribute, to report queue index to user space.
> >>> iproute2 tc should be changed to eventually display this queue index as in :
> >>>
> >>> $ tc -s -d qdisc
> >>> qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> >>> Sent 52498 bytes 465 pkt (dropped 0, overlimits 0 requeues 0)
> >>> rate 0bit 0pps backlog 0b 0p requeues 0
> >>> qdisc pfifo_fast 0: dev eth0 qindex 1 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >>> rate 0bit 0pps backlog 0b 0p requeues 0
> >> This might confuse existing userspace since the handle is not unique
> >> anymore. libnl f.i. will treat all but the first root qdisc as an
> >> update and use it to update the state of the first one. There's also
> >> no combined view for applications unaware of multiqueue.
> >>
> >> Please have a look at the mail I just wrote for some possible ways
> >> around this.
> >
> > Hum, how can we combine infos on qdisc/class if in the future we allow each queue index
> > to have its own qdisc/classes ?
> >
> > htb on queue index 0
> > cbq on queue index 1
>
> My suggestion was to only dump the statistics in the combined
> view and use a virtual qdisc, something like:
>
> qdisc multiqueue 0: dev eth0 root queues 8
> Sent ...
> rate ...
>
> and show each real qdisc as child of this qdisc:
>
> qdisc pfifo_fast <unique handle> dev eth0 parent 0: bands 3 ...
> qdisc pfifo_fast <unique handle> dev eth0 parent 0: bands 3 ...
>
> Configuration would be symetrical to this:
>
> tc qdisc add dev eth0 handle 0: root multiqueue
> tc qdisc add dev eth0 handle x: parent 0: pfifo_fast
> ...
Actually, I wonder why it can't be a real "virtual" qdisc with
classes, similar to... multiq, doing such mappings inside, according
to the current api:
tc qdisc add dev eth0 handle 1: root multiqueue
tc qdisc add dev eth0 handle x: parent 1:1 pfifo_fast
Jarek P.
PS: but I'd prefer (more) different name, even mq, mtq or something.
^ permalink raw reply
* Re: Crypto oops in async_chainiv_do_postponed
From: Herbert Xu @ 2009-09-02 21:57 UTC (permalink / raw)
To: Brad Bosch; +Cc: linux-crypto, netdev, offbase0
In-Reply-To: <19102.31846.180030.843571@waldo.imnotcreative.homeip.net>
On Wed, Sep 02, 2009 at 09:08:38AM -0500, Brad Bosch wrote:
>
> Assume the worker thread is executing between the dequeue in
> async_chainiv_do_postponed and the clear_bit call in
> async_chainiv_schedule_work. Further assume that we are processing
It cannot. The worker thread can only execute when it owns
the INUSE bit. In that case do_postponed will never call the
schedule_work function.
Perhaps you were misled by the clear_bit call in schedule_work.
That is only used if we end up not scheduling the work.
> Unfortunately, the offset problem is not easily reproduced with our
> application, so testing long enough to be sure the problem is fixed
> (assuming that it was indeed the cause of the oops) may not be
> practical. All I can say at the moment is that I have not seen the
> crash since I introduced the two patches I sent you.
OK I'll forward this upstream then.
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: System freeze on reboot - general protection fault
From: Zdenek Kabelac @ 2009-09-02 21:45 UTC (permalink / raw)
To: Patrick McHardy
Cc: Eric Dumazet, Christoph Lameter, Robin Holt,
Linux Kernel Mailing List, Pekka Enberg, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <4A896324.3040104@trash.net>
2009/8/17 Patrick McHardy <kaber@trash.net>:
> Eric Dumazet wrote:
>> Zdenek Kabelac a écrit :
>>> [<ffffffffa02c502f>] nf_conntrack_ftp_fini+0x2f/0x70 [nf_conntrack_ftp]
>>> [<ffffffff8027bcc5>] sys_delete_module+0x1a5/0x270
>>> [<ffffffff8020d329>] ? retint_swapgs+0xe/0x13
>>> [<ffffffff80271bf2>] ? trace_hardirqs_on_caller+0x162/0x1b0
>>> [<ffffffff80292121>] ? audit_syscall_entry+0x191/0x1c0
>>> [<ffffffff80526dae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>>> [<ffffffff8020c84b>] system_call_fastpath+0x16/0x1b
>>> Code: c6 00 00 0f 82 66 ff ff ff 49 8b 9e d8 05 00 00 48 85 db 75 16
>>> e9 8e 00 00 00 0f 1f 44 00 00 48 85 c0 0f 84 80 00 00 00 48 89 c3 <0f>
>>> b6 4b 37 48 8b 03 48 8d 14 cd 00 00 00 00 0f 18 08 48 29 ca
>>> RIP [<ffffffffa02b2c2c>] nf_conntrack_helper_unregister+0x16c/0x320
>>> [nf_conntrack]
>>> RSP <ffff88013982fe68>
>>> CR2: 0000000000000038
>>> ---[ end trace bc3a0ede3d0084db ]---
>>>
>> I am currently traveling and wont be able to help you before next week.
>>
>> I added netdev, Patrick, and netfilter-devel in CC so that more eyes can take a look.
>
> Thanks for the report, I'll have a look at this. Zdenek, please
> send me the nf_conntrack.ko file used in the above oops. Thanks.
>
Ok
I've found the solution for my problem.
http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/30483
I've made this small fix from this thread:
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core
index b5869b9..68488f8 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1108,6 +1108,7 @@ static void nf_conntrack_cleanup_init_net(void)
{
nf_conntrack_helper_fini();
nf_conntrack_proto_fini();
+ rcu_barrier();
kmem_cache_destroy(nf_conntrack_cachep);
}
@@ -1266,7 +1267,7 @@ static int nf_conntrack_init_init_net(void)
nf_conntrack_cachep = kmem_cache_create("nf_conntrack",
sizeof(struct nf_conn),
- 0, SLAB_DESTROY_BY_RCU, NULL);
+ 0, 0, NULL);
if (!nf_conntrack_cachep) {
printk(KERN_ERR "Unable to create nf_conn slab cache\n");
ret = -ENOMEM;
As the thread nf_conntrack: Use rcu_barrier() and fix kmem_cache_create flags
seems to be samewhat 'unfinished' and already a bit old and I've no
idea whether it actually fixes problem completely or just hides it in
my case - I'm leaving it to some RCU gurus to fix this issue.
All I could say is - this this extra rcu_barrier() and removal of
SLAB_DESTROY removes my GPF on reboot.
Zdenek
^ permalink raw reply related
* Re: [RFC][PATCH][v5] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: David Miller @ 2009-09-02 21:40 UTC (permalink / raw)
To: ajitk; +Cc: jgarzik, netdev
In-Reply-To: <20090902155006.GA22314@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Wed, 2 Sep 2009 21:20:09 +0530
> Is this patch good enough for being accepted? Please let me know if
> any more work has to be done on this. Also, I want to send the
> changes to the be2net driver which would use this ethtool feature.
My impression was that the patch was still under review and
people were still making change requests.
I guess not :-)
Please resubmit the kernel side patch, it'll get into patchwork
and I'll apply it.
Thanks.
^ permalink raw reply
* Re: [PATCH] drop_monitor: make last_rx timestamp private
From: David Miller @ 2009-09-02 21:37 UTC (permalink / raw)
To: nhorman; +Cc: netdev, eric.dumazet
In-Reply-To: <20090902133620.GC402@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed, 2 Sep 2009 09:36:20 -0400
> Ok, heres a repost, unchanged saved for being massaged to fit in with the recent
> changes that my origional patch raced against. Thanks!
> Neil
>
>
> It was recently pointed out to me that the last_rx field of the net_device
> structure wasn't updated regularly. In fact only the bonding driver really uses
> it currently. Since the drop_monitor code relies on the last_rx field to detect
> drops on recevie in hardware, We need to find a more reliable way to rate limit
> our drop checks (so that we don't check for drops on every frame recevied, which
> would be inefficient. This patch makes a last_rx timestamp that is private to
> the drop monitor code and is updated for every device that we track.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks Neil.
^ permalink raw reply
* Re: [NET] Add proc file to display the state of all qdiscs.
From: Jarek Poplawski @ 2009-09-02 21:27 UTC (permalink / raw)
To: Christoph Lameter; +Cc: eric.dumazet, netdev, David Miller, Patrick McHardy
In-Reply-To: <alpine.DEB.1.10.0909011943430.12066@V090114053VZO-1>
Christoph Lameter wrote, On 09/02/2009 01:52 AM:
> [NET] Add proc file to display the state of all qdiscs
>
> TC is a complicated tool and it currently does not allow the display of all
> qdisc states. It does not support multiple tx queues and also not
> localhost, nor does it display the current operating state of the queues.
>
> This functionality could be added to tc / netlink but the tool is already
> complex to handle. The simple proc file here allows easy scanning by
> scripts and other tools. However, tc still needs to be updated to allow
> the modifications of multiqueue TX settings. tc's main focus is the
> configuration of qdiscs. The qdisc_stats file just shows the current
> state.
>
> This patch adds
>
> /proc/net/qdisc_stats
>
> which displays the current state of all qdiscs on the system.
>
> F.e.
>
> $ cat /proc/net/qdisc_stats
> Queue Device State Bytes Packets Qlen Blog Drops Requeue Overlimit
> TX0/root lo - 0 0 0 0 0 0 0
> RX/root lo - 0 0 0 0 0 0 0
> TX0/root eth0 - 5518 60 0 0 0 0 0
> TX1/root eth0 - 2549 37 0 0 0 0 0
> TX2/root eth0 - 63625 272 0 0 0 0 0
> TX3/root eth0 - 1580 21 0 0 0 0 0
> TX4/root eth0 R 88979440 260183 0 3532 43176 2111 0
> TX5/root eth0 - 4698 56 0 0 0 0 0
> TX6/root eth0 - 3598883129 10523140 0 0 0 0 0
> TX7/root eth0 - 1750 21 0 0 0 0 0
>
>
> Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
>
> ---
> net/sched/sch_api.c | 130 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 130 insertions(+)
>
> Index: linux-2.6/net/sched/sch_api.c
> ===================================================================
> --- linux-2.6.orig/net/sched/sch_api.c 2009-09-01 12:27:24.000000000 -0500
> +++ linux-2.6/net/sched/sch_api.c 2009-09-01 14:39:27.000000000 -0500
...
> +static void qdisc_seq_out(struct seq_file *seq, struct net_device *dev)
> +{
> + struct netdev_queue *dev_queue;
> + int i;
> +
> + for (i = 0; i < dev->real_num_tx_queues; i++) {
> + char buffer[10];
> +
> + dev_queue = netdev_get_tx_queue(dev, i);
> + sprintf(buffer, "TX%d", i);
> + dump_qdisc_root(seq, dev, dev_queue->qdisc_sleeping, buffer);
> + }
...
Btw, Patrick's comments reminded me this is probably not what you want
in case of non-default qdiscs: the root qdisc like prio will be
repeated for each tx queue with the same stats. I guess you need to do
here an additional query e.g. by comparing dev_queue->qdisc_sleeping
with that of i = 0.
Jarek P.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-09-02
From: David Miller @ 2009-09-02 21:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090902195651.GF2662@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 2 Sep 2009 15:56:51 -0400
> Once again, the usual batch of wireless updates for -next... This time
> its mostly a random collection of driver updates...
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* pull request: wireless-next-2.6 2009-09-02
From: John W. Linville @ 2009-09-02 19:56 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
Once again, the usual batch of wireless updates for -next... This time
its mostly a random collection of driver updates...
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 9e39f7c5b311a306977c5471f9e2ce4c456aa038:
Joe Perches (1):
s2io: Generate complete messages using single line DBG_PRINTs
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Bob Copeland (1):
cfg80211: fix looping soft lockup in find_ie()
Daniel C Halperin (3):
iwlwifi: remove 60 Mbps from sband bitrates table
iwlwifi: remove incorrect uses of ieee80211_get_tx_rate to prevent TX stall
iwlwifi: use iwl_hwrate_get_mac80211_idx where appropriate
Gábor Stefanik (4):
b43: Refactor and update antenna diversity for A/G-PHY
b43: Add myself to module authors & to LP-PHY file copyright notices
b43: Fix typo in modparam_btcoex description
b43: LP-PHY: Fix TX gain tables
Ivo van Doorn (2):
rt2x00: Fix TX status reporting
rt2x00: Reorganize padding & L2 padding
Johannes Berg (2):
iwlwifi: use sleep interval succession
rfkill: relicense header file
Jussi Kivilinna (4):
rndis_wlan: use bool for on/off switches
rndis_wlan: cleanup
rndis_wlan: fix sparse endianess warnings
rndis_wlan: remove 'select WIRELESS_EXT' in Kconfig
Luis R. Rodriguez (3):
wireless: update top level wireless driver entry
wireless: update reg debug kconfig entry
wireless: remove mac80211 rate selection extra menu
Randy Dunlap (1):
ipw2200: fix kconfig dependencies
Reinette Chatre (2):
iwlwifi: fix situation in which debug message is printed
iwl3945: reduce debug noise when default debug flags used
Samuel Ortiz (5):
iwmc3200wifi: Set WEP key from connect
iwmc3200wifi: Fix sparse warning
iwmc3200wifi: New initial LMAC calibration
iwmc3200wifi: Handle UMAC stalls and UMAC assert properly
iwmc3200wifi: Add a last_fw_err debugfs entry
Vasanthakumar Thiagarajan (3):
ath9k: Do an AHB reset before doing RTC reset
ath9k: Move generic hw timer intr handler to bottom-half
ath9k: Call spin_lock_bh() on btcoex_lock
Vivek Natarajan (1):
ath9k: Reconfigure beacon timers after the scan is completed.
Zhu Yi (4):
iwmc3200wifi: invalidate profile when necessary before connect
iwmc3200wifi: use cfg80211_roamed to send roam event
iwmc3200wifi: add disconnect work
iwmc3200wifi: fix misuse of le16_to_cpu
drivers/net/wireless/Kconfig | 14 +-
drivers/net/wireless/ath/ath9k/btcoex.c | 10 +-
drivers/net/wireless/ath/ath9k/hw.c | 7 +
drivers/net/wireless/ath/ath9k/main.c | 12 +-
drivers/net/wireless/b43/main.c | 3 +-
drivers/net/wireless/b43/phy_a.c | 48 ++---
drivers/net/wireless/b43/phy_g.c | 53 ++---
drivers/net/wireless/b43/phy_lp.c | 3 +-
drivers/net/wireless/b43/tables_lpphy.c | 309 +++++++++++++-------------
drivers/net/wireless/ipw2x00/Kconfig | 6 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 56 +++---
drivers/net/wireless/iwlwifi/iwl-agn-rs.h | 1 +
drivers/net/wireless/iwlwifi/iwl-core.c | 39 +++-
drivers/net/wireless/iwlwifi/iwl-core.h | 1 +
drivers/net/wireless/iwlwifi/iwl-power.c | 24 ++-
drivers/net/wireless/iwlwifi/iwl-rx.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 111 +++++----
drivers/net/wireless/iwlwifi/iwl3945-base.c | 8 +-
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 66 +++++-
drivers/net/wireless/iwmc3200wifi/commands.c | 1 +
drivers/net/wireless/iwmc3200wifi/debug.h | 2 +
drivers/net/wireless/iwmc3200wifi/debugfs.c | 105 +++++++++-
drivers/net/wireless/iwmc3200wifi/fw.c | 56 ++++--
drivers/net/wireless/iwmc3200wifi/iwm.h | 8 +-
drivers/net/wireless/iwmc3200wifi/lmac.h | 15 ++
drivers/net/wireless/iwmc3200wifi/main.c | 60 +++++-
drivers/net/wireless/iwmc3200wifi/rx.c | 87 ++++++--
drivers/net/wireless/rndis_wlan.c | 98 ++------
drivers/net/wireless/rt2x00/rt2x00crypto.c | 6 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 38 ++--
drivers/net/wireless/rt2x00/rt2x00lib.h | 45 +++-
drivers/net/wireless/rt2x00/rt2x00queue.c | 99 +++++++--
include/linux/rfkill.h | 23 +-
net/mac80211/Kconfig | 5 +-
net/wireless/Kconfig | 4 +
net/wireless/scan.c | 2 +-
36 files changed, 894 insertions(+), 540 deletions(-)
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-09-02.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [NET] Add proc file to display the state of all qdiscs.
From: Jarek Poplawski @ 2009-09-02 19:49 UTC (permalink / raw)
To: Christoph Lameter; +Cc: eric.dumazet, David Miller, Patrick McHardy, netdev
In-Reply-To: <alpine.DEB.1.10.0909021311560.27987@V090114053VZO-1>
On Wed, Sep 02, 2009 at 01:12:55PM -0500, Christoph Lameter wrote:
>
> On Wed, 2 Sep 2009, Jarek Poplawski wrote:
>
> > I think, tc should've no problem with displaying summary stats of
> > multiqueue qdiscs or even all of them separately, as mentioned by
> > Patrick. And, maybe I still miss something, but there should be
> > nothing special with tc vs. localhost either.
>
> Ok. Can you come up with a patch? net/sched/sch_api.c can likely be
> patches with the loop logic that Eric suggested earlier.
Yes, it's nice Eric and Patrick found time to fix it most properly.
Jarek P.
^ permalink raw reply
* Re: 100Mbit ethernet performance on embedded devices
From: David Acker @ 2009-09-02 19:35 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: linux-embedded, netdev
In-Reply-To: <20090819145057.GA25400@sig21.net>
Johannes Stezenbach wrote:
> What I'm interested in are some numbers for similar hardware,
> to find out if my hardware and/or ethernet driver can be improved,
> or if the CPU will always be the limiting factor.
> I'd also be interested to know if hardware checksumming
> support would improve throughput noticably in such a system,
> or if it is only useful for 1Gbit and above.
>
> Did anyone actually manage to get close to 100Mbit/sec
> with similar CPU resources?
I have a pico station, http://ubnt.com/products/picostation.php with
Atheros MIPS 4KC @ 180MHz. Iperf on this device gives 46.0 Mbits/sec
sending TCP from a PC to the device and 36.2 Mbits/sec sending TCP from
the device to a PC. The NIC is part of the Atheros chipset so PCI is
not involved.
-ack
^ permalink raw reply
* Re: [NET] Add proc file to display the state of all qdiscs.
From: Jarek Poplawski @ 2009-09-02 19:33 UTC (permalink / raw)
To: Christoph Lameter; +Cc: eric.dumazet, netdev, David Miller, Patrick McHardy
In-Reply-To: <alpine.DEB.1.10.0909021310370.27987@V090114053VZO-1>
On Wed, Sep 02, 2009 at 01:11:43PM -0500, Christoph Lameter wrote:
> On Wed, 2 Sep 2009, Jarek Poplawski wrote:
>
> > Then my humble suggestions would be to reserve more space for most of
> > the columns to make it readable not only for scripts when more TX#,
> > bytes, packets etc. Users of non-default qdiscs would also miss things
> > like: q->ops->id, q->handle, and q->parent at least. Plus, as I
> > mentioned earlier, q->qstats.qlen update with q->q.qlen (or using it
> > directly) is needed.
>
> Which of those are needed if we just want to focus on statistics? Next rev
> will have q->q.len.
IMHO in the future there will be included most of the current tc qdisc
stats items. It would be nice to avoid those backward compatibility
arguments in the meantime as much as we can. But of course I might be
wrong, so feel free to do it your way.
Jarek P.
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: multiqueue vlan devices
From: Eric Dumazet @ 2009-09-02 19:12 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Brian Haley, David Miller, Patrick McHardy, jarkao2, netdev
In-Reply-To: <20090902120107.15146e4e@nehalam>
Stephen Hemminger a écrit :
> On Wed, 02 Sep 2009 20:55:24 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> +static int vlan_get_tx_queues(struct net *net,
>> + struct nlattr *tb[],
>> + int *num_tx_queues,
>> + int *real_num_tx_queues)
>
>
> Nitpick again. use unsigned unless you have some reason
> to allow -1.
No problem :)
Thanks Stephen
[PATCH net-next-2.6] vlan: multiqueue vlan device
vlan devices are currently not multi-queue capable.
We can do that with a new rtnl_link_ops method,
get_tx_queues(), called from rtnl_create_link()
This new method gets num_tx_queues/real_num_tx_queues
from real device.
register_vlan_device() is also handled.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/rtnetlink.h | 3 +++
net/8021q/vlan.c | 5 +++--
net/8021q/vlan_netlink.c | 20 ++++++++++++++++++++
net/core/rtnetlink.c | 10 +++++++++-
4 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
index 3c1895e..b630196 100644
--- a/include/net/rtnetlink.h
+++ b/include/net/rtnetlink.h
@@ -70,6 +70,9 @@ struct rtnl_link_ops {
size_t (*get_xstats_size)(const struct net_device *dev);
int (*fill_xstats)(struct sk_buff *skb,
const struct net_device *dev);
+ int (*get_tx_queues)(struct net *net, struct nlattr *tb[],
+ unsigned int *tx_queues,
+ unsigned int *real_tx_queues);
};
extern int __rtnl_link_register(struct rtnl_link_ops *ops);
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index e814794..8836575 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -330,12 +330,13 @@ static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
snprintf(name, IFNAMSIZ, "vlan%.4i", vlan_id);
}
- new_dev = alloc_netdev(sizeof(struct vlan_dev_info), name,
- vlan_setup);
+ new_dev = alloc_netdev_mq(sizeof(struct vlan_dev_info), name,
+ vlan_setup, real_dev->num_tx_queues);
if (new_dev == NULL)
return -ENOBUFS;
+ new_dev->real_num_tx_queues = real_dev->real_num_tx_queues;
dev_net_set(new_dev, net);
/* need 4 bytes for extra VLAN header info,
* hope the underlying device can handle it.
diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
index e9c91dc..cd5c2ae 100644
--- a/net/8021q/vlan_netlink.c
+++ b/net/8021q/vlan_netlink.c
@@ -100,6 +100,25 @@ static int vlan_changelink(struct net_device *dev,
return 0;
}
+static int vlan_get_tx_queues(struct net *net,
+ struct nlattr *tb[],
+ unsigned int *num_tx_queues,
+ unsigned int *real_num_tx_queues)
+{
+ struct net_device *real_dev;
+
+ if (!tb[IFLA_LINK])
+ return -EINVAL;
+
+ real_dev = __dev_get_by_index(net, nla_get_u32(tb[IFLA_LINK]));
+ if (!real_dev)
+ return -ENODEV;
+
+ *num_tx_queues = real_dev->num_tx_queues;
+ *real_num_tx_queues = real_dev->real_num_tx_queues;
+ return 0;
+}
+
static int vlan_newlink(struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
{
@@ -216,6 +235,7 @@ struct rtnl_link_ops vlan_link_ops __read_mostly = {
.maxtype = IFLA_VLAN_MAX,
.policy = vlan_policy,
.priv_size = sizeof(struct vlan_dev_info),
+ .get_tx_queues = vlan_get_tx_queues,
.setup = vlan_setup,
.validate = vlan_validate,
.newlink = vlan_newlink,
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index b44775f..bbcba2a 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -974,12 +974,20 @@ struct net_device *rtnl_create_link(struct net *net, char *ifname,
{
int err;
struct net_device *dev;
+ unsigned int num_queues = 1;
+ unsigned int real_num_queues = 1;
+ if (ops->get_tx_queues) {
+ err = ops->get_tx_queues(net, tb, &num_queues, &real_num_queues);
+ if (err)
+ goto err;
+ }
err = -ENOMEM;
- dev = alloc_netdev(ops->priv_size, ifname, ops->setup);
+ dev = alloc_netdev_mq(ops->priv_size, ifname, ops->setup, num_queues);
if (!dev)
goto err;
+ dev->real_num_tx_queues = real_num_queues;
if (strchr(dev->name, '%')) {
err = dev_alloc_name(dev, dev->name);
if (err < 0)
^ permalink raw reply related
* Re: [PATCH] tc: Fix unitialized kernel memory leak
From: Stephen Hemminger @ 2009-09-02 19:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4A9E67A9.7090205@gmail.com>
On Wed, 02 Sep 2009 14:40:09 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Three bytes of uninitialized kernel memory are currently leaked to user
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
> index 24d17ce..fdb694e 100644
> --- a/net/sched/sch_api.c
> +++ b/net/sched/sch_api.c
> @@ -1456,6 +1456,8 @@ static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q,
> nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
> tcm = NLMSG_DATA(nlh);
> tcm->tcm_family = AF_UNSPEC;
> + tcm->tcm__pad1 = 0;
> + tcm->tcm__pad2 = 0;
> tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
> tcm->tcm_parent = q->handle;
> tcm->tcm_handle = q->handle;
Perhaps __nlmsg_put should just always call memset() for the whole
added chunk. It is not like it is critical path in any way, and
avoid any of this possible class of errors.
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: multiqueue vlan devices
From: Stephen Hemminger @ 2009-09-02 19:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Brian Haley, David Miller, Patrick McHardy, jarkao2, netdev
In-Reply-To: <4A9EBF9C.2030904@gmail.com>
On Wed, 02 Sep 2009 20:55:24 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Brian Haley a écrit :
> > Eric Dumazet wrote:
> >> diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
> >> index 3c1895e..0525a1d 100644
> >> --- a/include/net/rtnetlink.h
> >> +++ b/include/net/rtnetlink.h
> >> @@ -70,6 +70,8 @@ struct rtnl_link_ops {
> >> size_t (*get_xstats_size)(const struct net_device *dev);
> >> int (*fill_xstats)(struct sk_buff *skb,
> >> const struct net_device *dev);
> >> + int (*get_tx_queues)(struct net*, struct nlattr *tb[],
> >> + int *tx_queues, int *real_tx_queues);
> >
> > int (*get_tx_queues)(struct net *net, struct nlattr *tb[],
> >
> > Total nitpick, but tbird highlighted it because of the missing "net".
> >
>
> Thats right, and I believe some gcc versions could complain
>
> Thanks Brian
>
> [PATCH net-next-2.6] vlan: multiqueue vlan device
>
> vlan devices are currently not multi-queue capable.
>
> We can do that with a new rtnl_link_ops method,
> get_tx_queues(), called from rtnl_create_link()
>
> This new method gets num_tx_queues/real_num_tx_queues
> from real device.
>
> register_vlan_device() is also handled.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> include/net/rtnetlink.h | 2 ++
> net/8021q/vlan.c | 5 +++--
> net/8021q/vlan_netlink.c | 20 ++++++++++++++++++++
> net/core/rtnetlink.c | 10 +++++++++-
> 4 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
> index 3c1895e..3f4ab54 100644
> --- a/include/net/rtnetlink.h
> +++ b/include/net/rtnetlink.h
> @@ -70,6 +70,8 @@ struct rtnl_link_ops {
> size_t (*get_xstats_size)(const struct net_device *dev);
> int (*fill_xstats)(struct sk_buff *skb,
> const struct net_device *dev);
> + int (*get_tx_queues)(struct net *net, struct nlattr *tb[],
> + int *tx_queues, int *real_tx_queues);
> };
>
> extern int __rtnl_link_register(struct rtnl_link_ops *ops);
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index e814794..8836575 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -330,12 +330,13 @@ static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
> snprintf(name, IFNAMSIZ, "vlan%.4i", vlan_id);
> }
>
> - new_dev = alloc_netdev(sizeof(struct vlan_dev_info), name,
> - vlan_setup);
> + new_dev = alloc_netdev_mq(sizeof(struct vlan_dev_info), name,
> + vlan_setup, real_dev->num_tx_queues);
>
> if (new_dev == NULL)
> return -ENOBUFS;
>
> + new_dev->real_num_tx_queues = real_dev->real_num_tx_queues;
> dev_net_set(new_dev, net);
> /* need 4 bytes for extra VLAN header info,
> * hope the underlying device can handle it.
> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
> index e9c91dc..8ce4122 100644
> --- a/net/8021q/vlan_netlink.c
> +++ b/net/8021q/vlan_netlink.c
> @@ -100,6 +100,25 @@ static int vlan_changelink(struct net_device *dev,
> return 0;
> }
>
> +static int vlan_get_tx_queues(struct net *net,
> + struct nlattr *tb[],
> + int *num_tx_queues,
> + int *real_num_tx_queues)
Nitpick again. use unsigned unless you have some reason
to allow -1.
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: multiqueue vlan devices
From: Eric Dumazet @ 2009-09-02 18:55 UTC (permalink / raw)
To: Brian Haley
Cc: David Miller, Patrick McHardy, Stephen Hemminger, jarkao2, netdev
In-Reply-To: <4A9EBB68.2080903@hp.com>
Brian Haley a écrit :
> Eric Dumazet wrote:
>> diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
>> index 3c1895e..0525a1d 100644
>> --- a/include/net/rtnetlink.h
>> +++ b/include/net/rtnetlink.h
>> @@ -70,6 +70,8 @@ struct rtnl_link_ops {
>> size_t (*get_xstats_size)(const struct net_device *dev);
>> int (*fill_xstats)(struct sk_buff *skb,
>> const struct net_device *dev);
>> + int (*get_tx_queues)(struct net*, struct nlattr *tb[],
>> + int *tx_queues, int *real_tx_queues);
>
> int (*get_tx_queues)(struct net *net, struct nlattr *tb[],
>
> Total nitpick, but tbird highlighted it because of the missing "net".
>
Thats right, and I believe some gcc versions could complain
Thanks Brian
[PATCH net-next-2.6] vlan: multiqueue vlan device
vlan devices are currently not multi-queue capable.
We can do that with a new rtnl_link_ops method,
get_tx_queues(), called from rtnl_create_link()
This new method gets num_tx_queues/real_num_tx_queues
from real device.
register_vlan_device() is also handled.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/rtnetlink.h | 2 ++
net/8021q/vlan.c | 5 +++--
net/8021q/vlan_netlink.c | 20 ++++++++++++++++++++
net/core/rtnetlink.c | 10 +++++++++-
4 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
index 3c1895e..3f4ab54 100644
--- a/include/net/rtnetlink.h
+++ b/include/net/rtnetlink.h
@@ -70,6 +70,8 @@ struct rtnl_link_ops {
size_t (*get_xstats_size)(const struct net_device *dev);
int (*fill_xstats)(struct sk_buff *skb,
const struct net_device *dev);
+ int (*get_tx_queues)(struct net *net, struct nlattr *tb[],
+ int *tx_queues, int *real_tx_queues);
};
extern int __rtnl_link_register(struct rtnl_link_ops *ops);
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index e814794..8836575 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -330,12 +330,13 @@ static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
snprintf(name, IFNAMSIZ, "vlan%.4i", vlan_id);
}
- new_dev = alloc_netdev(sizeof(struct vlan_dev_info), name,
- vlan_setup);
+ new_dev = alloc_netdev_mq(sizeof(struct vlan_dev_info), name,
+ vlan_setup, real_dev->num_tx_queues);
if (new_dev == NULL)
return -ENOBUFS;
+ new_dev->real_num_tx_queues = real_dev->real_num_tx_queues;
dev_net_set(new_dev, net);
/* need 4 bytes for extra VLAN header info,
* hope the underlying device can handle it.
diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
index e9c91dc..8ce4122 100644
--- a/net/8021q/vlan_netlink.c
+++ b/net/8021q/vlan_netlink.c
@@ -100,6 +100,25 @@ static int vlan_changelink(struct net_device *dev,
return 0;
}
+static int vlan_get_tx_queues(struct net *net,
+ struct nlattr *tb[],
+ int *num_tx_queues,
+ int *real_num_tx_queues)
+{
+ struct net_device *real_dev;
+
+ if (!tb[IFLA_LINK])
+ return -EINVAL;
+
+ real_dev = __dev_get_by_index(net, nla_get_u32(tb[IFLA_LINK]));
+ if (!real_dev)
+ return -ENODEV;
+
+ *num_tx_queues = real_dev->num_tx_queues;
+ *real_num_tx_queues = real_dev->real_num_tx_queues;
+ return 0;
+}
+
static int vlan_newlink(struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
{
@@ -216,6 +235,7 @@ struct rtnl_link_ops vlan_link_ops __read_mostly = {
.maxtype = IFLA_VLAN_MAX,
.policy = vlan_policy,
.priv_size = sizeof(struct vlan_dev_info),
+ .get_tx_queues = vlan_get_tx_queues,
.setup = vlan_setup,
.validate = vlan_validate,
.newlink = vlan_newlink,
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index b44775f..5c1fe53 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -974,12 +974,20 @@ struct net_device *rtnl_create_link(struct net *net, char *ifname,
{
int err;
struct net_device *dev;
+ int num_queues = 1;
+ int real_num_queues = 1;
+ if (ops->get_tx_queues) {
+ err = ops->get_tx_queues(net, tb, &num_queues, &real_num_queues);
+ if (err)
+ goto err;
+ }
err = -ENOMEM;
- dev = alloc_netdev(ops->priv_size, ifname, ops->setup);
+ dev = alloc_netdev_mq(ops->priv_size, ifname, ops->setup, num_queues);
if (!dev)
goto err;
+ dev->real_num_tx_queues = real_num_queues;
if (strchr(dev->name, '%')) {
err = dev_alloc_name(dev, dev->name);
if (err < 0)
^ permalink raw reply related
* Re: [PATCH net-next-2.6] vlan: multiqueue vlan devices
From: Brian Haley @ 2009-09-02 18:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Patrick McHardy, Stephen Hemminger, jarkao2, netdev
In-Reply-To: <4A9EA8C6.2000501@gmail.com>
Eric Dumazet wrote:
> diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
> index 3c1895e..0525a1d 100644
> --- a/include/net/rtnetlink.h
> +++ b/include/net/rtnetlink.h
> @@ -70,6 +70,8 @@ struct rtnl_link_ops {
> size_t (*get_xstats_size)(const struct net_device *dev);
> int (*fill_xstats)(struct sk_buff *skb,
> const struct net_device *dev);
> + int (*get_tx_queues)(struct net*, struct nlattr *tb[],
> + int *tx_queues, int *real_tx_queues);
int (*get_tx_queues)(struct net *net, struct nlattr *tb[],
Total nitpick, but tbird highlighted it because of the missing "net".
-Brian
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Bartlomiej Zolnierkiewicz @ 2009-09-02 18:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Tso Ted, Aneesh Kumar K.V, Zhu Yi, Andrew Morton, Mel Gorman,
Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, James Ketrenos,
Chatre, Reinette,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ipw2100-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
In-Reply-To: <43e72e890909021102g7f844c79xefccf305f5f5c5b6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wednesday 02 September 2009 20:02:14 Luis R. Rodriguez wrote:
> On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
> Zolnierkiewicz<bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> >>
> >> s/2.6.30/2.6.31-rc6/
> >>
> >> The issue has always been there but it was some recent change that
> >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> >
> > ipw2200 fix works fine but yesterday I got the following error while mounting
> > ext4 filesystem (mb_history is optional so the mount succeeded):
>
> OK so the mount succeeded.
>
> > EXT4-fs (dm-2): barriers enabled
> > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > EXT4-fs (dm-2): internal journal on dm-2:8
> > EXT4-fs (dm-2): delayed allocation enabled
> > EXT4-fs: file extents enabled
> > mount: page allocation failure. order:5, mode:0xc0d0
> > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > Call Trace:
> > [<c0394de3>] ? printk+0xf/0x14
> > [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> > [<c016a71b>] __get_free_pages+0xf/0x32
> > [<c01865cf>] __kmalloc+0x28/0xfa
> > [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> > [<c01f529d>] ext4_mb_init+0x392/0x460
> > [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> > [<c0239bc8>] ? snprintf+0x15/0x17
> > [<c01c0b26>] ? disk_name+0x24/0x69
> > [<c018ba63>] get_sb_bdev+0xda/0x117
> > [<c01e6711>] ext4_get_sb+0x13/0x15
> > [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> > [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> > [<c018adad>] do_kern_mount+0x33/0xbd
> > [<c019d0af>] do_mount+0x660/0x6b8
> > [<c016a71b>] ? __get_free_pages+0xf/0x32
> > [<c019d168>] sys_mount+0x61/0x99
> > [<c0102908>] sysenter_do_call+0x12/0x36
> > Mem-Info:
> > DMA per-cpu:
> > CPU 0: hi: 0, btch: 1 usd: 0
> > Normal per-cpu:
> > CPU 0: hi: 186, btch: 31 usd: 0
> > Active_anon:25471 active_file:22802 inactive_anon:25812
> > inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> > free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> > DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 489 489
> > Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 0 0
> > DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> > Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> > 57947 total pagecache pages
> > 878 pages in swap cache
> > Swap cache stats: add 920, delete 42, find 11/11
> > Free swap = 1016436kB
> > Total swap = 1020116kB
> > 131056 pages RAM
> > 4233 pages reserved
> > 90573 pages shared
> > 77286 pages non-shared
> > EXT4-fs: mballoc enabled
> > EXT4-fs (dm-2): mounted filesystem with ordered data mode
> >
> > Thus it seems like the original bug is still there and any ideas how to
> > debug the problem further are appreciated..
> >
> > The complete dmesg and kernel config are here:
> >
> > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
>
> This looks very similar to the kmemleak ext4 reports upon a mount. If
> it is the same issue, which from the trace it seems it is, then this
> is due to an extra kmalloc() allocation and this apparently will not
> get fixed on 2.6.31 due to the closeness of the merge window and the
> non-criticalness this issue has been deemed.
>
> A patch fix is part of the ext4-patchqueue
> http://repo.or.cz/w/ext4-patch-queue.git
Thanks for the pointer but the page allocation failures that I hit seem
to be caused by the memory management itself and the ext4 issue fixed by:
http://repo.or.cz/w/ext4-patch-queue.git?a=blob;f=memory-leak-fix-ext4_group_info-allocation;h=c919fff34e70ec85f96d1833f9ce460c451000de;hb=HEAD
is a different problem (unrelated to this one).
^ permalink raw reply
* Re: [PATCH] tc: Fix unitialized kernel memory leak
From: Jiri Pirko @ 2009-09-02 18:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4A9E67A9.7090205@gmail.com>
Wed, Sep 02, 2009 at 02:40:09PM CEST, eric.dumazet@gmail.com wrote:
>Three bytes of uninitialized kernel memory are currently leaked to user
>
>Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Reviewed-by: Jiri Pirko <jpirko@redhat.com>
>---
>diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>index 24d17ce..fdb694e 100644
>--- a/net/sched/sch_api.c
>+++ b/net/sched/sch_api.c
>@@ -1456,6 +1456,8 @@ static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q,
> nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
> tcm = NLMSG_DATA(nlh);
> tcm->tcm_family = AF_UNSPEC;
>+ tcm->tcm__pad1 = 0;
>+ tcm->tcm__pad2 = 0;
> tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
> tcm->tcm_parent = q->handle;
> tcm->tcm_handle = q->handle;
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Luis R. Rodriguez @ 2009-09-02 18:02 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz, Tso Ted, Aneesh Kumar K.V
Cc: Zhu Yi, Andrew Morton, Mel Gorman, Johannes Weiner, Pekka Enberg,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Mel Gorman, netdev@vger.kernel.org, linux-mm@kvack.org,
James Ketrenos, Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <200909021948.13262.bzolnier@gmail.com>
On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
Zolnierkiewicz<bzolnier@gmail.com> wrote:
> On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
>> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
>> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
>> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
>>
>> s/2.6.30/2.6.31-rc6/
>>
>> The issue has always been there but it was some recent change that
>> explicitly triggered the allocation failures (after 2.6.31-rc1).
>
> ipw2200 fix works fine but yesterday I got the following error while mounting
> ext4 filesystem (mb_history is optional so the mount succeeded):
OK so the mount succeeded.
> EXT4-fs (dm-2): barriers enabled
> kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> EXT4-fs (dm-2): internal journal on dm-2:8
> EXT4-fs (dm-2): delayed allocation enabled
> EXT4-fs: file extents enabled
> mount: page allocation failure. order:5, mode:0xc0d0
> Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> Call Trace:
> [<c0394de3>] ? printk+0xf/0x14
> [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> [<c016a71b>] __get_free_pages+0xf/0x32
> [<c01865cf>] __kmalloc+0x28/0xfa
> [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> [<c01f529d>] ext4_mb_init+0x392/0x460
> [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> [<c0239bc8>] ? snprintf+0x15/0x17
> [<c01c0b26>] ? disk_name+0x24/0x69
> [<c018ba63>] get_sb_bdev+0xda/0x117
> [<c01e6711>] ext4_get_sb+0x13/0x15
> [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> [<c018adad>] do_kern_mount+0x33/0xbd
> [<c019d0af>] do_mount+0x660/0x6b8
> [<c016a71b>] ? __get_free_pages+0xf/0x32
> [<c019d168>] sys_mount+0x61/0x99
> [<c0102908>] sysenter_do_call+0x12/0x36
> Mem-Info:
> DMA per-cpu:
> CPU 0: hi: 0, btch: 1 usd: 0
> Normal per-cpu:
> CPU 0: hi: 186, btch: 31 usd: 0
> Active_anon:25471 active_file:22802 inactive_anon:25812
> inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 489 489
> Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> 57947 total pagecache pages
> 878 pages in swap cache
> Swap cache stats: add 920, delete 42, find 11/11
> Free swap = 1016436kB
> Total swap = 1020116kB
> 131056 pages RAM
> 4233 pages reserved
> 90573 pages shared
> 77286 pages non-shared
> EXT4-fs: mballoc enabled
> EXT4-fs (dm-2): mounted filesystem with ordered data mode
>
> Thus it seems like the original bug is still there and any ideas how to
> debug the problem further are appreciated..
>
> The complete dmesg and kernel config are here:
>
> http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
This looks very similar to the kmemleak ext4 reports upon a mount. If
it is the same issue, which from the trace it seems it is, then this
is due to an extra kmalloc() allocation and this apparently will not
get fixed on 2.6.31 due to the closeness of the merge window and the
non-criticalness this issue has been deemed.
A patch fix is part of the ext4-patchqueue
http://repo.or.cz/w/ext4-patch-queue.git
Luis
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/3] netfilter: xt_ipvs (netfilter matcher for IPVS)
From: Patrick McHardy @ 2009-09-02 17:51 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Hannes Eder, lvs-devel, linux-kernel, netdev, netfilter-devel,
Fabien Duchêne, Jean-Luc Fortemaison, Julian Anastasov,
Julius Volz, Laurent Grawet, Simon Horman, Wensong Zhang
In-Reply-To: <alpine.LSU.2.00.0909021748310.25091@fbirervta.pbzchgretzou.qr>
Jan Engelhardt wrote:
> On Wednesday 2009-09-02 17:36, Patrick McHardy wrote:
>>> Nice, I'll use par->family.
>>>
>>> So in theory I do not even need a check like the following in the beginning?
>>>
>>> if (family != NFPROTO_IPV4
>>> #ifdef CONFIG_IP_VS_IPV6
>>> && family != NFPROTO_IPV6
>>> #endif
>>> ) {
>>> match = false;
>>> goto out;
>>> }
>> With the AF_UNSPEC registration of your match, it might be used
>
> par->family always contains the NFPROTO of the invoking implementation,
> which can never be UNSPEC (except, in future, xtables2 ;-)
I didn't say it will be UNSPEC, I said it might be something
different than IPV4/IPV6 unless that is checked *somewhere*.
^ permalink raw reply
* Re: [PATCH net-next-2.6] tc: report informations for multiqueue devices
From: Patrick McHardy @ 2009-09-02 17:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, David Miller, jarkao2, cl, netdev
In-Reply-To: <4A9EAC00.4030106@gmail.com>
Eric Dumazet wrote:
> Patrick McHardy a écrit :
>> Just to avoid duplicate work - I'm currently trying to put a patch
>> together that presents multiqueue qdiscs to userspace as regular
>> child qdiscs of a dummy qdisc, which also contains the aggregated
>> statistics. So far it actually looks pretty sane :)
>
> There is one thing that bothers me with "tc -s -d qdisc", maybe
> its the right time to speak
>
> qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 54823 bytes 490 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc pfifo_fast 0: dev eth1 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 468 bytes 6 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
>
>
> The rate estimation is given by kernel even if no rate estimation is performed.
>
> User space doesnt have an indication saying this 0 numbers are real or fake
> (rate 0bit 0pps).
>
> Could we set a bit at Qdisc level when a gen_new_estimator() is really
> done one a Qdisc, so that we do not call gnet_stats_copy_rate_est()
> from tc_fill_qdisc() if this bit is not set ?
That should be possible, I'll look into it once I've finished my patch.
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: multiqueue vlan devices
From: Patrick McHardy @ 2009-09-02 17:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Stephen Hemminger, jarkao2, netdev
In-Reply-To: <4A9EA8C6.2000501@gmail.com>
Eric Dumazet wrote:
> vlan devices are currently not multi-queue capable.
>
> We can do that with a new rtnl_link_ops method,
> get_tx_queues(), called from rtnl_create_link()
>
> This new method gets num_tx_queues/real_num_tx_queues
> from real device.
>
> register_vlan_device() is also handled.
Looks great. This will also make it easier to test multiqueue
scheduling without a multiqueue-capable device :)
^ 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