* Re: [PATCH 2/2] fec: don't enable irqs in hard irq context
From: Greg Ungerer @ 2009-09-03 1:14 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-rt-users, Ben Hutchings, Patrick McHardy, Sascha Hauer,
Matt Waddel, netdev, Tim Sander
In-Reply-To: <1251882856-23549-2-git-send-email-u.kleine-koenig@pengutronix.de>
Hi Uwe,
Uwe Kleine-König wrote:
> fec_enet_mii, fec_enet_rx and fec_enet_tx are both only called by
> fec_enet_interrupt in interrupt context. So they must not use
> spin_lock_irq/spin_unlock_irq.
>
> This fixes:
> WARNING: at kernel/lockdep.c:2140 trace_hardirqs_on_caller+0x130/0x194()
> ...
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Cc: Greg Ungerer <gerg@uclinux.org>
Looks good.
Acked-by: Greg Ungerer <gerg@uclinux.org>
> Cc: Ben Hutchings <ben@decadent.org.uk>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Matt Waddel <Matt.Waddel@freescale.com>
> Cc: netdev@vger.kernel.org
> Cc: Tim Sander <tim01@vlsi.informatik.tu-darmstadt.de>
> ---
> drivers/net/fec.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index ef82606..9c49d56 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -427,7 +427,7 @@ fec_enet_tx(struct net_device *dev)
> struct sk_buff *skb;
>
> fep = netdev_priv(dev);
> - spin_lock_irq(&fep->hw_lock);
> + spin_lock(&fep->hw_lock);
> bdp = fep->dirty_tx;
>
> while (((status = bdp->cbd_sc) & BD_ENET_TX_READY) == 0) {
> @@ -486,7 +486,7 @@ fec_enet_tx(struct net_device *dev)
> }
> }
> fep->dirty_tx = bdp;
> - spin_unlock_irq(&fep->hw_lock);
> + spin_unlock(&fep->hw_lock);
> }
>
>
> @@ -509,7 +509,7 @@ fec_enet_rx(struct net_device *dev)
> flush_cache_all();
> #endif
>
> - spin_lock_irq(&fep->hw_lock);
> + spin_lock(&fep->hw_lock);
>
> /* First, grab all of the stats for the incoming packet.
> * These get messed up if we get called due to a busy condition.
> @@ -604,7 +604,7 @@ rx_processing_done:
> }
> fep->cur_rx = bdp;
>
> - spin_unlock_irq(&fep->hw_lock);
> + spin_unlock(&fep->hw_lock);
> }
>
> /* called from interrupt context */
> @@ -615,7 +615,7 @@ fec_enet_mii(struct net_device *dev)
> mii_list_t *mip;
>
> fep = netdev_priv(dev);
> - spin_lock_irq(&fep->mii_lock);
> + spin_lock(&fep->mii_lock);
>
> if ((mip = mii_head) == NULL) {
> printk("MII and no head!\n");
> @@ -633,7 +633,7 @@ fec_enet_mii(struct net_device *dev)
> writel(mip->mii_regval, fep->hwp + FEC_MII_DATA);
>
> unlock:
> - spin_unlock_irq(&fep->mii_lock);
> + spin_unlock(&fep->mii_lock);
> }
>
> static int
--
-----------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip: Report qdisc packet drops
From: David Miller @ 2009-09-03 1:09 UTC (permalink / raw)
To: cl; +Cc: eric.dumazet, sri, dlstevens, netdev, niv, mtk.manpages
In-Reply-To: <alpine.DEB.1.10.0909021318490.21832@V090114053VZO-1>
From: Christoph Lameter <cl@linux-foundation.org>
Date: Wed, 2 Sep 2009 13:22:25 -0500 (CDT)
> There may be a minor issue here in that IP_RECVERR sometimes sends error
> packets that have to be intercepted using special code. Or can those be
> simply ignored? If so then I will ask UDP app vendors to use IP_RECVERR.
If you don't set MSG_ERRQUEUE, no special error reports will be
given to the application.
And this only matters for recvmsg() handling.
On send, the only behavior difference is this error code reporting
(and before Eric's patch, SNMP statistics handling).
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: multiqueue vlan devices
From: Eric Dumazet @ 2009-09-03 1:05 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, brian.haley, kaber, jarkao2, netdev
In-Reply-To: <20090902.180401.155663057.davem@davemloft.net>
David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 02 Sep 2009 21:12:03 +0200
>
>> [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>
>
> Applied, but now I need you to do an audit :-)
>
> I believe that drivers will change the number of TX queues
> in use at times where we'll need to trigger an event or
> something so that vlan's can learn about the value changing.
Yes, I know :)
This is why I kept both num_tx_queues and real_num_tx_queues values,
and not the later :)
Thanks
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip: Report qdisc packet drops
From: David Miller @ 2009-09-03 1:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: cl, sri, dlstevens, netdev, niv, mtk.manpages
In-Reply-To: <4A9EF113.9030102@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Sep 2009 00:26:27 +0200
> Here is an updated version of the patch, after Christoph comments.
>
>
>
> [PATCH net-next-2.6] ip: Report qdisc packet drops
Looks great, applied!
^ permalink raw reply
* [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
From: Eric Dumazet @ 2009-09-03 1:04 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: <c4e36d110909021531v324a9ce2x3ff2c93b7c5a57de@mail.gmail.com>
Zdenek Kabelac a écrit :
>
> 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...
>
Reading again your traces, I do believe there are two bugs in slub
Maybe not explaining your problem, but worth to fix !
Thank you
[PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
When SLAB_POISON is used and slab_pad_check() finds an overwrite of the
slab padding, we call restore_bytes() on the whole slab, not only
on the padding.
kmem_cache_destroy() should call rcu_barrier() *after* kmem_cache_close()
and *before* sysfs_slab_remove() or risk rcu_free_slab()
being called after kmem_cache is deleted (kfreed).
rmmod nf_conntrack can crash the machine because it has to
kmem_cache_destroy() a SLAB_DESTROY_BY_RCU enabled cache.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/mm/slub.c b/mm/slub.c
index b9f1491..0ac839f 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -646,7 +646,7 @@ static int slab_pad_check(struct kmem_cache *s, struct page *page)
slab_err(s, page, "Padding overwritten. 0x%p-0x%p", fault, end - 1);
print_section("Padding", end - remainder, remainder);
- restore_bytes(s, "slab padding", POISON_INUSE, start, end);
+ restore_bytes(s, "slab padding", POISON_INUSE, end - remainder, end);
return 0;
}
@@ -2594,8 +2594,6 @@ static inline int kmem_cache_close(struct kmem_cache *s)
*/
void kmem_cache_destroy(struct kmem_cache *s)
{
- if (s->flags & SLAB_DESTROY_BY_RCU)
- rcu_barrier();
down_write(&slub_lock);
s->refcount--;
if (!s->refcount) {
@@ -2606,6 +2604,8 @@ void kmem_cache_destroy(struct kmem_cache *s)
"still has objects.\n", s->name, __func__);
dump_stack();
}
+ if (s->flags & SLAB_DESTROY_BY_RCU)
+ rcu_barrier();
sysfs_slab_remove(s);
} else
up_write(&slub_lock);
^ permalink raw reply related
* Re: [PATCH net-next-2.6] vlan: multiqueue vlan devices
From: David Miller @ 2009-09-03 1:04 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, brian.haley, kaber, jarkao2, netdev
In-Reply-To: <4A9EC383.4070304@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 02 Sep 2009 21:12:03 +0200
> [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>
Applied, but now I need you to do an audit :-)
I believe that drivers will change the number of TX queues
in use at times where we'll need to trigger an event or
something so that vlan's can learn about the value changing.
^ permalink raw reply
* Re: Crypto oops in async_chainiv_do_postponed
From: Brad Bosch @ 2009-09-02 23:47 UTC (permalink / raw)
To: Herbert Xu; +Cc: Brad Bosch, linux-crypto, netdev, offbase0
In-Reply-To: <20090902215712.GA16941@gondor.apana.org.au>
Herbert Xu writes:
> 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.
In the example I cited (one entry in the queue when the worker
function starts), async_chainiv_schedule_work is indeed executed.
(indirectly) by async_chainiv_givencrypt_tail from the worker thread.
I'm sorry I didn't make it more clear that it is that code path I was
talking about.
>
> Perhaps you were misled by the clear_bit call in schedule_work.
> That is only used if we end up not scheduling the work.
No, I was not misled. But apparently, I was not clear. I do
understand how you use the INUSE bit. I did not say above that
INUSE is not set when the worker thread is running (at least not for
the first part of my example). If you had read further, you might
have noticed that the following paragraphs showed that indeed I do
understand that INUSE is set in the worker thread as evidenced by
"thread one calls test_and_set_bit which returns 1" I have added one
sentence (marked by **) to my event description below to make my
understanding more clear. Please read on.
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
the last item on the queue so durring this time, ctx->queue.qlen =
0. **INUSE is still set at this point.
Meanwhile, three threads enter async_chainiv_givencrypt for the same
ctx at about the same time.
Thread one calls test_and_set_bit which returns 1 and calls
async_cahiniv_postpone_request but suppose it has not yet enqueued.
Now INUSE is set and qlen=0.
Next, the worker thread calls clear_bit in async_chainiv_schedule_work
but it is interrupted before it can call test_and_set_bit. Now INUSE
is clear and qlen=0
The test_and_set_bit in thread two is called at this moment and
returns 0 and then calls async_chainiv_givencrypt_tail. Now INUSE is
set and qlen=0.
Thread one now locks the ctx and calls skcipher_enqueue_givcrypt and
unlocks. Now INUSE is set and qlen=1.
Thread three calls test_and_set_bit which returns 1 and then it clears
INUSE since qlen=1 and it calls postpone with INUSE clear and qlen=1
Now thread three will use ctx->err to hold the return value of
skcipher_enqueue_givcrypt at the same time as thread two uses ctx->err
to hold the return value of crypto_ablkcipher_encrypt!
Did I make a mistake above? I suspect more bad things can happen as
well in this scenario, but I'm just focusing on the use of ctx->err here.
Thanks
--Brad
^ permalink raw reply
* 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
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