* Re: Reporting Bugs on This List
From: Atis Elsts @ 2010-03-23 19:22 UTC (permalink / raw)
To: Eduardo Panisset; +Cc: netdev
In-Reply-To: <b7b22e81003231205v38fa8774y81da6da5278c99a2@mail.gmail.com>
You need to submit patches in a proper format, and with [PATCH] in
subject line, so they get tracked automatically.
Reading this may be helpful: http://www.kernel.org/pub/linux/docs/lkml/#s1-10
Patches to netdev also need to apply clearly to net-2.6 (right?) Linux
kernel tree.
Also, be prepared that it may take much more time than one day until
someone reviews them.
On Tue, Mar 23, 2010 at 9:05 PM, Eduardo Panisset
<eduardo.panisset@gmail.com> wrote:
> Hi All,
>
> I have already reported two bugs on XFRM framework since yesterday.
> However my reports haven't been answered yet (I thought strange as
> this list is very active) and one of my questions simply disappeared
> even if its a simple plain text messages without offensive terms
> neither I think any other constraint.
> So I would like to know How would be the better way to report bugs on
> this list ?
>
> Thanks in advance,
> Eduardo Panisset.
> --
> 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
>
--
~Atis
^ permalink raw reply
* Re: Reporting Bugs on This List
From: David Miller @ 2010-03-23 19:27 UTC (permalink / raw)
To: eduardo.panisset; +Cc: netdev
In-Reply-To: <b7b22e81003231205v38fa8774y81da6da5278c99a2@mail.gmail.com>
From: Eduardo Panisset <eduardo.panisset@gmail.com>
Date: Tue, 23 Mar 2010 16:05:59 -0300
> I have already reported two bugs on XFRM framework since yesterday.
> However my reports haven't been answered yet (I thought strange as
> this list is very active) and one of my questions simply disappeared
> even if its a simple plain text messages without offensive terms
> neither I think any other constraint.
It's incredibly unreasonable to expect immediate responses from a
group of volunteers.
Personally, it takes me over 2 hours just to make a first pass over
the day's emails in the morning. This means not even replying to
anything or reading any content seriously. That's just deleting the
excess postings I have no direct interest in.
Then I go over patches, that can take 3 hours or more.
And then, and only then, can I look at bug reports and other things
which are not new patches. And your mail falls into that category
because you didn't post a proper patch, and if you did you'd need
to properly signoff on the patch and provide a properly formed
commit message.
You just need to be patient.
^ permalink raw reply
* Re: [Bug 15582] New: BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
From: David Miller @ 2010-03-23 19:40 UTC (permalink / raw)
To: alexander.h.duyck
Cc: akpm, kaber, jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
peter.p.waskiewicz.jr, bugzilla-daemon, netdev, stivi
In-Reply-To: <80769D7B14936844A23C0C43D9FBCF0F254E49A854@orsmsx501.amr.corp.intel.com>
From: "Duyck, Alexander H" <alexander.h.duyck@intel.com>
Date: Tue, 23 Mar 2010 11:32:19 -0700
> The patch below should address it. However I suspect it will get
> mangled by our email system here so I don't believe it will apply.
> I have also sent a copy of to Jeff to pull into his tree for testing
> and submission.
Good spotting, thanks Alex.
I'll wait for testing and a final version via Jeff.
^ permalink raw reply
* Re: Gianfar: RX Recycle skb->len error
From: David Miller @ 2010-03-23 20:00 UTC (permalink / raw)
To: ben; +Cc: avorontsov, netdev, Sandeep.Kumar, kumar.gala
In-Reply-To: <A6A1774AFD79E346AE6D49A33CB294530DC19F4A@EX-BE-017-SFO.shared.themessagecenter.com>
From: "Ben Menchaca (ben@bigfootnetworks.com)" <ben@bigfootnetworks.com>
Date: Tue, 23 Mar 2010 07:16:58 -0700
>> There's no need to make this so complicated. Just remember the
>> value and then refer to it later, when needed.
>
> Thanks for the sanity adjustment! As suggested, then...hope to hear
> from FS soon.
Let's get this tested and with a proper commit message and
signoff so it can get applied.
Thanks!
^ permalink raw reply
* Re: Reporting Bugs on This List
From: Eduardo Panisset @ 2010-03-23 20:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100323.122747.172618601.davem@davemloft.net>
Okay David,
Sorry, lack me experience on what to expect and what procedures I
should follow as is the first time I'm participating on this list.
However my intention is just to contribute for the kernel stability
and development.
I will be pacient.
Thanks.
Thank you also to Atis (I will check the link you have sent).
Eduardo Panisset.
On Tue, Mar 23, 2010 at 4:27 PM, David Miller <davem@davemloft.net> wrote:
> From: Eduardo Panisset <eduardo.panisset@gmail.com>
> Date: Tue, 23 Mar 2010 16:05:59 -0300
>
>> I have already reported two bugs on XFRM framework since yesterday.
>> However my reports haven't been answered yet (I thought strange as
>> this list is very active) and one of my questions simply disappeared
>> even if its a simple plain text messages without offensive terms
>> neither I think any other constraint.
>
> It's incredibly unreasonable to expect immediate responses from a
> group of volunteers.
>
> Personally, it takes me over 2 hours just to make a first pass over
> the day's emails in the morning. This means not even replying to
> anything or reading any content seriously. That's just deleting the
> excess postings I have no direct interest in.
>
> Then I go over patches, that can take 3 hours or more.
>
> And then, and only then, can I look at bug reports and other things
> which are not new patches. And your mail falls into that category
> because you didn't post a proper patch, and if you did you'd need
> to properly signoff on the patch and provide a properly formed
> commit message.
>
> You just need to be patient.
>
^ permalink raw reply
* Re: [PATCH 1/2] cgroups: net_cls as module
From: David Miller @ 2010-03-23 20:09 UTC (permalink / raw)
To: bblum; +Cc: akpm, netdev
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ksz884x: fix return value of netdev_set_eeprom
From: David Miller @ 2010-03-23 20:09 UTC (permalink / raw)
To: JRottmann; +Cc: Tristram.Ha, netdev, linux-kernel
In-Reply-To: <4BA8CEF6.2010707@LiPPERTEmbedded.de>
From: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Date: Tue, 23 Mar 2010 15:23:50 +0100
> ksz884x: fix return value of netdev_set_eeprom
>
> netdev_set_eeprom() confused ethtool by just returning 1 on error
> instead of a proper -EINVAL.
>
> Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Applied, thank you.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Jozsef Kadlecsik @ 2010-03-23 20:10 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Patrick McHardy, Shan Wei, YOSHIFUJI Hideaki, David Miller,
Alexey Dobriyan, Yasuyuki KOZAKAI, netdev@vger.kernel.org,
netfilter-devel
In-Reply-To: <4BA90F72.6010404@linux-ipv6.org>
Hi,
On Wed, 24 Mar 2010, YOSHIFUJI Hideaki wrote:
> > In this case without conntrack, IPv6 would send an ICMPv6 message,
> > so in my opinion the transparent thing to do would be to still send
> > them. Of course only if reassembly is done on an end host.
>
> Well, no. conntrack should just forward even uncompleted fragments
> to next process (e.g. core ipv6 code), and then the core would send
> ICMP error back. ICMP should be sent by the core ipv6 code according
> to decision of itself, not according to netfilter.
But what state could be associated by conntrack to the uncompleted
fragments but the INVALID state? In consequence, in any sane setup, the
uncompleted fragments will be dropped silently by a filter table rule
and no ICMP error message will be sent back.
Therefore I think iff the destination of the fragments is the host
itself, then conntrack should generate an ICMP error message. But that
error message must be processed by conntrack to set its state and then
the fate of the generated packet can be decided by a rule.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: handle dma mapping errors in Tx path
From: David Miller @ 2010-03-23 20:23 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100323064112.GA3706@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Tue, 23 Mar 2010 12:11:12 +0530
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] be2net: fix unmap_single/page() called incorrectly in Tx compl processing
From: David Miller @ 2010-03-23 20:23 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100323064134.GA3733@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Tue, 23 Mar 2010 12:11:34 +0530
> The first wrb seen by tx compl processing does not have a dma handle in it.
> Currently, pci_unmap_single() is attempted on this wrb and pci_unmap_page() on the
> rest. So, pci_unmap_page() gets incorrectly called on the dma hdl of skb->data (that
> was mapped using map_single()). This patch fixes this issue.
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Alexander Duyck @ 2010-03-23 20:25 UTC (permalink / raw)
To: netdev
The qdisc layer shows a significant issue when you start transmitting from
multiple CPUs. The issue is that the transmit rate drops significantly, and I
believe it is due to the fact that the spinlock is shared between the 1
dequeue, and n-1 enqueue cpu threads. In order to improve this situation I am
adding one additional lock which will need to be obtained during the enqueue
portion of the path. This essentially allows sch_direct_xmit to jump to
near the head of the line when attempting to obtain the lock after
completing a transmit.
Running the script below I saw an increase from 200K packets per second to
1.07M packets per second as a result of this patch.
for j in `seq 0 15`; do
for i in `seq 0 7`; do
netperf -H <ip> -t UDP_STREAM -l 600 -N -T $i -- -m 6 &
done
done
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
include/net/sch_generic.h | 3 ++-
net/core/dev.c | 7 ++++++-
net/sched/sch_generic.c | 1 +
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 67dc08e..f5088a9 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -51,7 +51,6 @@ struct Qdisc {
struct list_head list;
u32 handle;
u32 parent;
- atomic_t refcnt;
struct gnet_stats_rate_est rate_est;
int (*reshape_fail)(struct sk_buff *skb,
struct Qdisc *q);
@@ -65,6 +64,8 @@ struct Qdisc {
struct netdev_queue *dev_queue;
struct Qdisc *next_sched;
+ atomic_t refcnt;
+ spinlock_t enqueue_lock;
struct sk_buff *gso_skb;
/*
* For performance sake on SMP, we put highly modified fields at the end
diff --git a/net/core/dev.c b/net/core/dev.c
index a03aab4..8a2d508 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2006,8 +2006,10 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
spinlock_t *root_lock = qdisc_lock(q);
int rc;
+ spin_lock(&q->enqueue_lock);
spin_lock(root_lock);
if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
+ spin_unlock(&q->enqueue_lock);
kfree_skb(skb);
rc = NET_XMIT_DROP;
} else if ((q->flags & TCQ_F_CAN_BYPASS) && !qdisc_qlen(q) &&
@@ -2018,7 +2020,9 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
* xmit the skb directly.
*/
__qdisc_update_bstats(q, skb->len);
- if (sch_direct_xmit(skb, q, dev, txq, root_lock))
+ spin_unlock(&q->enqueue_lock);
+ rc = sch_direct_xmit(skb, q, dev, txq, root_lock);
+ if (rc)
__qdisc_run(q);
else
clear_bit(__QDISC_STATE_RUNNING, &q->state);
@@ -2026,6 +2030,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
rc = NET_XMIT_SUCCESS;
} else {
rc = qdisc_enqueue_root(skb, q);
+ spin_unlock(&q->enqueue_lock);
qdisc_run(q);
}
spin_unlock(root_lock);
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 5173c1e..4b5e125 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -538,6 +538,7 @@ struct Qdisc *qdisc_alloc(struct netdev_queue *dev_queue,
sch = (struct Qdisc *) QDISC_ALIGN((unsigned long) p);
sch->padded = (char *) sch - (char *) p;
+ spin_lock_init(&sch->enqueue_lock);
INIT_LIST_HEAD(&sch->list);
skb_queue_head_init(&sch->q);
sch->ops = ops;
^ permalink raw reply related
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: David Miller @ 2010-03-23 20:31 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20100323202553.21598.10754.stgit@gitlad.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue, 23 Mar 2010 13:25:53 -0700
> The qdisc layer shows a significant issue when you start transmitting from
> multiple CPUs.
Why are you hitting any central qdisc lock on a multiqueue
configuration?
^ permalink raw reply
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Rick Jones @ 2010-03-23 20:40 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev
In-Reply-To: <20100323202553.21598.10754.stgit@gitlad.jf.intel.com>
Alexander Duyck wrote:
> The qdisc layer shows a significant issue when you start transmitting from
> multiple CPUs. The issue is that the transmit rate drops significantly, and I
> believe it is due to the fact that the spinlock is shared between the 1
> dequeue, and n-1 enqueue cpu threads. In order to improve this situation I am
> adding one additional lock which will need to be obtained during the enqueue
> portion of the path. This essentially allows sch_direct_xmit to jump to
> near the head of the line when attempting to obtain the lock after
> completing a transmit.
>
> Running the script below I saw an increase from 200K packets per second to
> 1.07M packets per second as a result of this patch.
>
> for j in `seq 0 15`; do
> for i in `seq 0 7`; do
> netperf -H <ip> -t UDP_STREAM -l 600 -N -T $i -- -m 6 &
> done
> done
Wow - someone is using the no control connection mode in netperf :) Or were you
actually trying to get the test-specific -N option to control whether or not
netperf "connects" the UDP socket?
rick jones
^ permalink raw reply
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Eric Dumazet @ 2010-03-23 20:54 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev
In-Reply-To: <20100323202553.21598.10754.stgit@gitlad.jf.intel.com>
Le mardi 23 mars 2010 à 13:25 -0700, Alexander Duyck a écrit :
> The qdisc layer shows a significant issue when you start transmitting from
> multiple CPUs. The issue is that the transmit rate drops significantly, and I
> believe it is due to the fact that the spinlock is shared between the 1
> dequeue, and n-1 enqueue cpu threads. In order to improve this situation I am
> adding one additional lock which will need to be obtained during the enqueue
> portion of the path. This essentially allows sch_direct_xmit to jump to
> near the head of the line when attempting to obtain the lock after
> completing a transmit.
>
> Running the script below I saw an increase from 200K packets per second to
> 1.07M packets per second as a result of this patch.
>
> for j in `seq 0 15`; do
> for i in `seq 0 7`; do
> netperf -H <ip> -t UDP_STREAM -l 600 -N -T $i -- -m 6 &
> done
> done
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
>
Hi Alexander
Thats a pretty good topic :)
So to speedup a pathological case (dozen of cpus all sending to same
queue), you suggest adding a spin_lock to fast path, slowing down normal
cases ?
Quite frankly, the real problem in this case is not the reduced
throughput, but fact that one cpu can stay a long time doing the xmits
to device, of skb queued by other cpus. This can hurt latencies a lot,
for real time threads for example...
I wonder if ticket spinlocks are not the problem. Maybe we want a
variant of spinlocks, so that cpu doing transmits can get the lock
before other cpus...
^ permalink raw reply
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Eric Dumazet @ 2010-03-23 21:18 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev
In-Reply-To: <1269377667.2915.25.camel@edumazet-laptop>
Le mardi 23 mars 2010 à 21:54 +0100, Eric Dumazet a écrit :
> I wonder if ticket spinlocks are not the problem. Maybe we want a
> variant of spinlocks, so that cpu doing transmits can get the lock
> before other cpus...
Something like this portable implementation :
struct spinprio {
spinlock_t lock;
int highprio_cnt;
};
void spinprio_lock(struct spinprio *l)
{
while (1) {
spin_lock(&l->lock);
if (!l->highprio_cnt)
break;
spin_unlock(&l->lock);
cpu_relax();
}
}
void spinprio_unlock(struct spinprio *l)
{
spin_unlock(&l->lock);
}
void spinprio_relock(struct spinprio *l)
{
l->highprio_cnt = 1;
spin_lock(&l->lock);
l->highprio_cnt = 0;
}
We would have to use spinprio_unlock()/spinprio_relock() in
sch_direct_xmit()
^ permalink raw reply
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: David Miller @ 2010-03-23 21:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.h.duyck, netdev
In-Reply-To: <1269377667.2915.25.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 23 Mar 2010 21:54:27 +0100
> Quite frankly, the real problem in this case is not the reduced
> throughput, but fact that one cpu can stay a long time doing the xmits
> to device, of skb queued by other cpus. This can hurt latencies a lot,
> for real time threads for example...
>
> I wonder if ticket spinlocks are not the problem. Maybe we want a
> variant of spinlocks, so that cpu doing transmits can get the lock
> before other cpus...
I want to note that things operate the way they do now
intentionally.
Herbert Xu and Jamal Hadi Salim were active in this area
about 4 years ago.
^ permalink raw reply
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Eric Dumazet @ 2010-03-23 22:13 UTC (permalink / raw)
To: David Miller; +Cc: alexander.h.duyck, netdev
In-Reply-To: <20100323.144512.140757007.davem@davemloft.net>
Le mardi 23 mars 2010 à 14:45 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 23 Mar 2010 21:54:27 +0100
>
> > Quite frankly, the real problem in this case is not the reduced
> > throughput, but fact that one cpu can stay a long time doing the xmits
> > to device, of skb queued by other cpus. This can hurt latencies a lot,
> > for real time threads for example...
> >
> > I wonder if ticket spinlocks are not the problem. Maybe we want a
> > variant of spinlocks, so that cpu doing transmits can get the lock
> > before other cpus...
>
> I want to note that things operate the way they do now
> intentionally.
>
> Herbert Xu and Jamal Hadi Salim were active in this area
> about 4 years ago.
Yes, but ticket spinlocks were added after their work (in 2008 - 2.6.25
if I remember well) and change things.
We want cpu owning __QDISC_STATE_RUNNING being able to re-get the lock
as fast as possible. Alexander results can show the possible speedup.
^ permalink raw reply
* RE: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Duyck, Alexander H @ 2010-03-23 22:08 UTC (permalink / raw)
To: David Miller, eric.dumazet@gmail.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100323.144512.140757007.davem@davemloft.net>
David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 23 Mar 2010 21:54:27 +0100
>
>> Quite frankly, the real problem in this case is not the reduced
>> throughput, but fact that one cpu can stay a long time doing the
>> xmits to device, of skb queued by other cpus. This can hurt
>> latencies a lot, for real time threads for example...
>>
>> I wonder if ticket spinlocks are not the problem. Maybe we want a
>> variant of spinlocks, so that cpu doing transmits can get the lock
>> before other cpus...
>
> I want to note that things operate the way they do now
> intentionally.
>
> Herbert Xu and Jamal Hadi Salim were active in this area
> about 4 years ago.
I'll do some digging on this to see what I can find out. I'm not sure why we would want to do things this way since it seems like the CPU that has qdisc_running is sitting idle due to the fact that the ticket spinlocks have us waiting for all of the other CPU enqueues before we can get around to another dequeue. It seems like it would be in our best interest to keep qdisc_running going while we are still enqueuing on the other CPUs.
I'll also look into the idea of possibly coming up with a more portable solution such as a priority based spinlock solution.
Thanks,
Alex
^ permalink raw reply
* inet6_ifa_finish_destroy() blurt
From: Andrew Morton @ 2010-03-23 22:35 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Got this during boot using today's linux-next. The
WARN_ON(!hlist_unhashed(&ifp->addr_lst)) triggered.
c2e21293c054817c42eb5fa9c613d2ad51954136 ("ipv6: convert addrconf list
to hlist") added it.
[ 53.677562] calling init_autofs4_fs+0x0/0x23 [autofs4] @ 3535
[ 53.677931] initcall init_autofs4_fs+0x0/0x23 [autofs4] returned 0 after 57 usecs
[ 247.122112] ------------[ cut here ]------------
[ 247.122187] WARNING: at net/ipv6/addrconf.c:544 inet6_ifa_finish_destroy+0x24/0x9b [ipv6]()
[ 247.122244] Modules linked in: autofs4 sunrpc ipv6 dm_mirror dm_region_hash dm_log dm_multipath dm_mod video output sbs sbshc battery ac lp parport sg ide_cd_mod cdrom serio_raw floppy snd_hda_intel snd_hda_codec snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device button snd_pcm_oss snd_mixer_oss snd_pcm i2c_i801 i2c_core pcspkr snd_timer snd soundcore snd_page_alloc shpchp ehci_hcd ohci_hcd uhci_hcd
[ 247.124152] Pid: 0, comm: swapper Not tainted 2.6.34-rc2-mm1+ #1
[ 247.124208] Call Trace:
[ 247.124255] <IRQ> [<ffffffffa01941d3>] ? inet6_ifa_finish_destroy+0x24/0x9b [ipv6]
[ 247.124369] [<ffffffff81035489>] warn_slowpath_common+0x7e/0x97
[ 247.124425] [<ffffffff810354b7>] warn_slowpath_null+0x15/0x17
[ 247.124487] [<ffffffffa01941d3>] inet6_ifa_finish_destroy+0x24/0x9b [ipv6]
[ 247.124550] [<ffffffffa019666b>] addrconf_prefix_rcv+0x546/0x713 [ipv6]
[ 247.124609] [<ffffffff812d7625>] ? neigh_update+0x3cc/0x3ec
[ 247.124669] [<ffffffffa01a01ac>] ndisc_rcv+0xa45/0xf2c [ipv6]
[ 247.124723] [<ffffffff812d80d1>] ? rtnl_notify+0x2b/0x2d
[ 247.124785] [<ffffffffa0199962>] ? inet6_rt_notify+0x104/0x129 [ipv6]
[ 247.124851] [<ffffffffa01a5dd5>] icmpv6_rcv+0x5cb/0x66b [ipv6]
[ 247.124919] [<ffffffffa01986b4>] ? __ip6_ins_rt+0x3d/0x48 [ipv6]
[ 247.124976] [<ffffffff8135b0fd>] ? _raw_read_unlock_bh+0x12/0x14
[ 247.125041] [<ffffffffa01a83e7>] ? ipv6_chk_mcast_addr+0x129/0x14f [ipv6]
[ 247.125104] [<ffffffffa0192184>] ip6_input_finish+0x19f/0x28b [ipv6]
[ 247.125167] [<ffffffffa0191b62>] ip6_input+0x4a/0x4e [ipv6]
[ 247.125227] [<ffffffffa0191c4d>] ip6_mc_input+0xc3/0xd4 [ipv6]
[ 247.125288] [<ffffffffa0191b86>] ip6_rcv_finish+0x20/0x24 [ipv6]
[ 247.125351] [<ffffffffa0191fac>] ipv6_rcv+0x34e/0x387 [ipv6]
[ 247.125407] [<ffffffff812d03fd>] __netif_receive_skb+0x4bf/0x4e4
[ 247.125460] [<ffffffff812d0515>] netif_receive_skb+0x24/0x32
[ 247.125515] [<ffffffff812d0bbf>] napi_skb_finish+0x21/0x37
[ 247.125569] [<ffffffff812d0bff>] napi_gro_receive+0x2a/0x2f
[ 247.125625] [<ffffffff8125e7e2>] e1000_receive_skb+0x60/0x69
[ 247.125678] [<ffffffff812606f6>] e1000_clean_rx_irq+0x240/0x2da
[ 247.125734] [<ffffffff8126241c>] e1000_clean+0x79/0x224
[ 247.125788] [<ffffffff812d06e4>] net_rx_action+0xca/0x1da
[ 247.125841] [<ffffffff8103a502>] __do_softirq+0x9e/0x11f
[ 247.125895] [<ffffffff8100390c>] call_softirq+0x1c/0x28
[ 247.125950] [<ffffffff81004ff5>] do_softirq+0x33/0x6a
[ 247.126002] [<ffffffff8103a42e>] irq_exit+0x38/0x3a
[ 247.126055] [<ffffffff81004ebc>] do_IRQ+0xaa/0xc1
[ 247.126108] [<ffffffff8135b393>] ret_from_intr+0x0/0xa
[ 247.126159] <EOI> [<ffffffff81009d13>] ? mwait_idle+0x59/0x5e
[ 247.126260] [<ffffffff8100104a>] ? enter_idle+0x20/0x22
[ 247.126425] [<ffffffff810014c5>] cpu_idle+0x43/0x61
[ 247.126591] [<ffffffff81355389>] start_secondary+0x1aa/0x1ae
[ 247.126757] [<ffffffff813551df>] ? start_secondary+0x0/0x1ae
[ 247.126922] ---[ end trace ea6028b997f8cf89 ]---
[ 247.127085] Freeing alive inet6 address ffff88025d872a80
^ permalink raw reply
* [PATCH 1/2] bnx2: Fix netpoll crash.
From: Michael Chan @ 2010-03-23 23:13 UTC (permalink / raw)
To: davem; +Cc: netdev
From: Benjamin Li <benli@broadcom.com>
The bnx2 driver calls netif_napi_add() for all the NAPI structs during
->probe() time but not all of them will be used if we're not in MSI-X
mode. This creates a problem for netpoll since it will poll all the
NAPI structs in the dev_list whether or not they are scheduled, resulting
in a crash when we access structure fields not initialized for that vector.
We fix it by moving the netif_napi_add() call to ->open() after the number
of IRQ vectors has been determined.
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 381887b..417de1c 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -246,6 +246,8 @@ static const struct flash_spec flash_5709 = {
MODULE_DEVICE_TABLE(pci, bnx2_pci_tbl);
+static void bnx2_init_napi(struct bnx2 *bp);
+
static inline u32 bnx2_tx_avail(struct bnx2 *bp, struct bnx2_tx_ring_info *txr)
{
u32 diff;
@@ -6197,6 +6199,7 @@ bnx2_open(struct net_device *dev)
bnx2_disable_int(bp);
bnx2_setup_int_mode(bp, disable_msi);
+ bnx2_init_napi(bp);
bnx2_napi_enable(bp);
rc = bnx2_alloc_mem(bp);
if (rc)
@@ -8207,7 +8210,7 @@ bnx2_init_napi(struct bnx2 *bp)
{
int i;
- for (i = 0; i < BNX2_MAX_MSIX_VEC; i++) {
+ for (i = 0; i < bp->irq_nvecs; i++) {
struct bnx2_napi *bnapi = &bp->bnx2_napi[i];
int (*poll)(struct napi_struct *, int);
@@ -8276,7 +8279,6 @@ bnx2_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->ethtool_ops = &bnx2_ethtool_ops;
bp = netdev_priv(dev);
- bnx2_init_napi(bp);
pci_set_drvdata(pdev, dev);
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH 2/2] bnx2: Use proper handler during netpoll.
From: Michael Chan @ 2010-03-23 23:13 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1269385992-18525-1-git-send-email-mchan@broadcom.com>
Netpoll needs to call the proper handler depending on the IRQ mode
and the vector.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 417de1c..a257bab 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -7646,9 +7646,11 @@ poll_bnx2(struct net_device *dev)
int i;
for (i = 0; i < bp->irq_nvecs; i++) {
- disable_irq(bp->irq_tbl[i].vector);
- bnx2_interrupt(bp->irq_tbl[i].vector, &bp->bnx2_napi[i]);
- enable_irq(bp->irq_tbl[i].vector);
+ struct bnx2_irq *irq = &bp->irq_tbl[i];
+
+ disable_irq(irq->vector);
+ irq->handler(irq->vector, &bp->bnx2_napi[i]);
+ enable_irq(irq->vector);
}
}
#endif
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH v2] Fix locking in flush_backlog
From: Tom Herbert @ 2010-03-23 23:39 UTC (permalink / raw)
To: davem, netdev
Need to take spinlocks when dequeuing from input_pkt_queue in flush_backlog.
Also, flush_backlog can now be called directly from netdev_run_todo.
Signed-off-by: Tom Herbert <therbert@google.com>
---
diff --git a/net/core/dev.c b/net/core/dev.c
diff --git a/net/core/dev.c b/net/core/dev.c
index a03aab4..5e3dc28 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2766,17 +2766,19 @@ int netif_receive_skb(struct sk_buff *skb)
EXPORT_SYMBOL(netif_receive_skb);
/* Network device is going away, flush any packets still pending */
-static void flush_backlog(void *arg)
+static void flush_backlog(struct net_device *dev, int cpu)
{
- struct net_device *dev = arg;
- struct softnet_data *queue = &__get_cpu_var(softnet_data);
+ struct softnet_data *queue = &per_cpu(softnet_data, cpu);
struct sk_buff *skb, *tmp;
+ unsigned long flags;
+ spin_lock_irqsave(&queue->input_pkt_queue.lock, flags);
skb_queue_walk_safe(&queue->input_pkt_queue, skb, tmp)
if (skb->dev == dev) {
__skb_unlink(skb, &queue->input_pkt_queue);
kfree_skb(skb);
}
+ spin_unlock_irqrestore(&queue->input_pkt_queue.lock, flags);
}
static int napi_gro_complete(struct sk_buff *skb)
@@ -5545,6 +5547,7 @@ void netdev_run_todo(void)
while (!list_empty(&list)) {
struct net_device *dev
= list_first_entry(&list, struct net_device, todo_list);
+ int i;
list_del(&dev->todo_list);
if (unlikely(dev->reg_state != NETREG_UNREGISTERING)) {
@@ -5556,7 +5559,8 @@ void netdev_run_todo(void)
dev->reg_state = NETREG_UNREGISTERED;
- on_each_cpu(flush_backlog, dev, 1);
+ for_each_online_cpu(i)
+ flush_backlog(dev, i);
netdev_wait_allrefs(dev);
^ permalink raw reply related
* Re: ixgbe: Set IXGBE_RSC_CB(skb)->DMA field to zero after unmapping the address
From: Benjamin Herrenschmidt @ 2010-03-23 23:40 UTC (permalink / raw)
To: Malli
Cc: Mallikarjuna R Chilakala, Linux Kernel Mailing List, David Miller,
netdev
In-Reply-To: <7991c5481003231040u3479778dpcb27d9578383afc0@mail.gmail.com>
On Tue, 2010-03-23 at 10:40 -0700, Malli wrote:
>
> Yes. I just realized that i can't assign a zero magic "bad" value. It
> is only
> valid in x86/arm/m68k/alpha architecures and not in spark & PowerPC
> arch,
> (it should be ~0). In some other architecutres it throws a BUG() on
> with
> dma_mapping_error() checks. So the patch is not a total bogus in some
> architectures :(.
>
> May be it is best to create an internal FLAG in IXGBE_RSC_CB(skb)
> which can be used to avoid this double freeing.
I suppose if Linus reads that he'll just come back and say "you idiots,
just make 0 invalid everywhere" like he did for interrupts tho :-) It
wouldn't be too hard for us to make the IOMMU allocator always skip "0".
But for now, I'd suggest you add a flag.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2 1/2] vlan: adds vlan_dev_select_queue
From: Jeff Kirsher @ 2010-03-24 0:41 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Vasu Dev, Jeff Kirsher
From: Vasu Dev <vasu.dev@intel.com>
This is required to correctly select vlan tx queue for a driver
supporting multi tx queue with ndo_select_queue implemented since
currently selected vlan tx queue is unaligned to selected queue by
real net_devce ndo_select_queue.
Unaligned vlan tx queue selection causes thrash with higher vlan
tx lock contention for least fcoe traffic and wrong socket tx
queue_mapping for ixgbe having ndo_select_queue implemented.
-v2
As per Eric Dumazet<eric.dumazet@gmail.com> comments, mirrored
vlan net_device_ops to have them with and without vlan_dev_select_queue
and then select according to real dev ndo_select_queue present or not
for a vlan net_device. This is to completely skip vlan_dev_select_queue
calling for real net_device not supporting ndo_select_queue.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
net/8021q/vlan_dev.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 9e83272..2fd057c 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -361,6 +361,14 @@ static netdev_tx_t vlan_dev_hwaccel_hard_start_xmit(struct sk_buff *skb,
return ret;
}
+static u16 vlan_dev_select_queue(struct net_device *dev, struct sk_buff *skb)
+{
+ struct net_device *rdev = vlan_dev_info(dev)->real_dev;
+ const struct net_device_ops *ops = rdev->netdev_ops;
+
+ return ops->ndo_select_queue(rdev, skb);
+}
+
static int vlan_dev_change_mtu(struct net_device *dev, int new_mtu)
{
/* TODO: gotta make sure the underlying layer can handle it,
@@ -688,7 +696,8 @@ static const struct header_ops vlan_header_ops = {
.parse = eth_header_parse,
};
-static const struct net_device_ops vlan_netdev_ops, vlan_netdev_accel_ops;
+static const struct net_device_ops vlan_netdev_ops, vlan_netdev_accel_ops,
+ vlan_netdev_ops_sq, vlan_netdev_accel_ops_sq;
static int vlan_dev_init(struct net_device *dev)
{
@@ -722,11 +731,17 @@ static int vlan_dev_init(struct net_device *dev)
if (real_dev->features & NETIF_F_HW_VLAN_TX) {
dev->header_ops = real_dev->header_ops;
dev->hard_header_len = real_dev->hard_header_len;
- dev->netdev_ops = &vlan_netdev_accel_ops;
+ if (real_dev->netdev_ops->ndo_select_queue)
+ dev->netdev_ops = &vlan_netdev_accel_ops_sq;
+ else
+ dev->netdev_ops = &vlan_netdev_accel_ops;
} else {
dev->header_ops = &vlan_header_ops;
dev->hard_header_len = real_dev->hard_header_len + VLAN_HLEN;
- dev->netdev_ops = &vlan_netdev_ops;
+ if (real_dev->netdev_ops->ndo_select_queue)
+ dev->netdev_ops = &vlan_netdev_ops_sq;
+ else
+ dev->netdev_ops = &vlan_netdev_ops;
}
if (is_vlan_dev(real_dev))
@@ -865,6 +880,56 @@ static const struct net_device_ops vlan_netdev_accel_ops = {
#endif
};
+static const struct net_device_ops vlan_netdev_ops_sq = {
+ .ndo_select_queue = vlan_dev_select_queue,
+ .ndo_change_mtu = vlan_dev_change_mtu,
+ .ndo_init = vlan_dev_init,
+ .ndo_uninit = vlan_dev_uninit,
+ .ndo_open = vlan_dev_open,
+ .ndo_stop = vlan_dev_stop,
+ .ndo_start_xmit = vlan_dev_hard_start_xmit,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address = vlan_dev_set_mac_address,
+ .ndo_set_rx_mode = vlan_dev_set_rx_mode,
+ .ndo_set_multicast_list = vlan_dev_set_rx_mode,
+ .ndo_change_rx_flags = vlan_dev_change_rx_flags,
+ .ndo_do_ioctl = vlan_dev_ioctl,
+ .ndo_neigh_setup = vlan_dev_neigh_setup,
+ .ndo_get_stats = vlan_dev_get_stats,
+#if defined(CONFIG_FCOE) || defined(CONFIG_FCOE_MODULE)
+ .ndo_fcoe_ddp_setup = vlan_dev_fcoe_ddp_setup,
+ .ndo_fcoe_ddp_done = vlan_dev_fcoe_ddp_done,
+ .ndo_fcoe_enable = vlan_dev_fcoe_enable,
+ .ndo_fcoe_disable = vlan_dev_fcoe_disable,
+ .ndo_fcoe_get_wwn = vlan_dev_fcoe_get_wwn,
+#endif
+};
+
+static const struct net_device_ops vlan_netdev_accel_ops_sq = {
+ .ndo_select_queue = vlan_dev_select_queue,
+ .ndo_change_mtu = vlan_dev_change_mtu,
+ .ndo_init = vlan_dev_init,
+ .ndo_uninit = vlan_dev_uninit,
+ .ndo_open = vlan_dev_open,
+ .ndo_stop = vlan_dev_stop,
+ .ndo_start_xmit = vlan_dev_hwaccel_hard_start_xmit,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address = vlan_dev_set_mac_address,
+ .ndo_set_rx_mode = vlan_dev_set_rx_mode,
+ .ndo_set_multicast_list = vlan_dev_set_rx_mode,
+ .ndo_change_rx_flags = vlan_dev_change_rx_flags,
+ .ndo_do_ioctl = vlan_dev_ioctl,
+ .ndo_neigh_setup = vlan_dev_neigh_setup,
+ .ndo_get_stats = vlan_dev_get_stats,
+#if defined(CONFIG_FCOE) || defined(CONFIG_FCOE_MODULE)
+ .ndo_fcoe_ddp_setup = vlan_dev_fcoe_ddp_setup,
+ .ndo_fcoe_ddp_done = vlan_dev_fcoe_ddp_done,
+ .ndo_fcoe_enable = vlan_dev_fcoe_enable,
+ .ndo_fcoe_disable = vlan_dev_fcoe_disable,
+ .ndo_fcoe_get_wwn = vlan_dev_fcoe_get_wwn,
+#endif
+};
+
void vlan_setup(struct net_device *dev)
{
ether_setup(dev);
^ permalink raw reply related
* [PATCH v2 2/2] vlan: updates vlan real_num_tx_queues
From: Jeff Kirsher @ 2010-03-24 0:42 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Vasu Dev, Jeff Kirsher
In-Reply-To: <20100324004116.31609.73183.stgit@localhost.localdomain>
From: Vasu Dev <vasu.dev@intel.com>
Updates real_num_tx_queues in case underlying real device
has changed real_num_tx_queues.
-v2
As per Eric Dumazet<eric.dumazet@gmail.com> comment:-
-- adds BUG_ON to catch case of real_num_tx_queues exceeding num_tx_queues.
-- created this self contained patch to just update real_num_tx_queues.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
net/8021q/vlan.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 4535122..db783d7 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -378,6 +378,8 @@ static void vlan_transfer_features(struct net_device *dev,
#if defined(CONFIG_FCOE) || defined(CONFIG_FCOE_MODULE)
vlandev->fcoe_ddp_xid = dev->fcoe_ddp_xid;
#endif
+ vlandev->real_num_tx_queues = dev->real_num_tx_queues;
+ BUG_ON(vlandev->real_num_tx_queues > vlandev->num_tx_queues);
if (old_features != vlandev->features)
netdev_features_change(vlandev);
^ 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