* Re: [RFC] dev->refcnt long term holder
From: David Miller @ 2009-11-17 8:30 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, herbert, netdev
In-Reply-To: <4B01ADF5.8090904@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 16 Nov 2009 20:54:29 +0100
> I was hoping a fast path, but anyway, a linkwatch_forget_dev(dev) is
> probably better, (in case "ip link del" closely follows an "ip link
> add / up")
>
> I'll post something when tested.
Let's face it, linkwatch has been a thorn in our sides for a long
time. A non-stop source of problems.
I suspect that here in this VLAN case you care about, the work can
even be done synchronously.
I'm trying to remember why we added this asynchronous link state event
processing monster. It probably has something to do with needing a
sleepable context. What's amusing is that linkwatch has repeatably
caused RTNL deadlock issues over the years. :-)
If it is purely an issue of doing link state processing outside of
HW irq context:
1) PHY events in most drivers are handled in softirq (NAPI ->poll())
or a workqueue of some sort these days. If we can make all of
the link state management softirq safe (it probably is, except
for perhaps RTNL), these case can be done synchronously always.
2) The remaining cases are device probe, open, and close. None of
which execute in HW irq context, they can sleep, and they hold
RTNL already.
I'm sure there are a few drivers which still can invoke
netif_carrier_*() in HW interrupt context, but we can create a tiny
workqueue helper or something like that for them. It won't be the
main way to invoke carrier state changes, just a compatability item.
Anyways, just some food for thought.
^ permalink raw reply
* Re: [PATCH 2/2 net-next-2.6] vlan: Precise RX stats accounting
From: David Miller @ 2009-11-17 8:20 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4B01558F.5000306@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 16 Nov 2009 14:37:19 +0100
> In case dynamic percpu allocation fails, we fallback to previous
> mode (sharing dev->stats counter)
Eric, please make allocation failure cause the vlan_setup()
to fail and propagate -EFAULT back to the caller.
Thanks.
^ permalink raw reply
* [PATCH net-next] Phonet: missing rcu_dereference()
From: Rémi Denis-Courmont @ 2009-11-17 8:17 UTC (permalink / raw)
To: netdev; +Cc: Rémi Denis-Courmont
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
---
net/phonet/af_phonet.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/phonet/af_phonet.c b/net/phonet/af_phonet.c
index ed65da2..526d027 100644
--- a/net/phonet/af_phonet.c
+++ b/net/phonet/af_phonet.c
@@ -44,7 +44,7 @@ static struct phonet_protocol *phonet_proto_get(int protocol)
return NULL;
rcu_read_lock();
- pp = proto_tab[protocol];
+ pp = rcu_dereference(proto_tab[protocol]);
if (pp && !try_module_get(pp->prot->owner))
pp = NULL;
rcu_read_unlock();
--
1.6.3.3
^ permalink raw reply related
* Re: linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2009-11-17 8:16 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David Miller, netdev, linux-next, linux-kernel, Wolfram Sang,
Christian Pellegrin, Wolfgang Grandegger, Anant Gole
In-Reply-To: <4B025812.6060807@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 523 bytes --]
Hi Oliver,
On Tue, 17 Nov 2009 09:00:18 +0100 Oliver Hartkopp <oliver@hartkopp.net> wrote:
>
> Yes. You only added the new Kconfig entries (for CAN_TI_HECC, CAN_MCP251X,
> CAN_MSCAN, ...) to the patch "can: Fix driver Kconfig structure", right?
Yes.
> These are the only added items in drivers/net/can/Kconfig from net-2.6 to
> net-next-2.6.
And it looks like Dave will fix this up for me tomorrow.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2009-11-17 8:10 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-next, linux-kernel, w.sang, chripell, wg, anantgole,
oliver
In-Reply-To: <20091117.000720.01506428.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
Hi Dave,
On Tue, 17 Nov 2009 00:07:20 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 17 Nov 2009 13:16:37 +1100
>
> > I fixed it up (see below) and can carry the fix for a while. (I am not
> > sure the fix is entirely correct.)
>
> I'll merge net-2.6 into net-next-2.6 so you won't see this tomorrow.
Great, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the net-current tree
From: David Miller @ 2009-11-17 8:07 UTC (permalink / raw)
To: sfr
Cc: netdev, linux-next, linux-kernel, w.sang, chripell, wg, anantgole,
oliver
In-Reply-To: <20091117131637.3a35f898.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 17 Nov 2009 13:16:37 +1100
> I fixed it up (see below) and can carry the fix for a while. (I am not
> sure the fix is entirely correct.)
I'll merge net-2.6 into net-next-2.6 so you won't see this tomorrow.
Thanks!
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the net-current tree
From: Oliver Hartkopp @ 2009-11-17 8:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Wolfram Sang,
Christian Pellegrin, Wolfgang Grandegger, Anant Gole
In-Reply-To: <20091117131637.3a35f898.sfr@canb.auug.org.au>
Hello Stephen,
Stephen Rothwell wrote:
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/can/Kconfig between commit
> b93cf3f0bb45560d2ce62bdcc2181c40660cfdbf ("can: Fix driver Kconfig
> structure") from the net-current tree
Indeed this cleanup was made in net-2.6 to fix the Kconfig structure before
2.6.32 is finalized.
The commits
> 3758bf25db8caeec667e4e56e030da0ec3060529 ("can: add TI CAN (HECC)
> driver"), e0000163e30eeb112b41486ea113fd54f64e1f17 ("can: Driver for the
> Microchip MCP251x SPI CAN controllers") and
> afa17a500a3667f66df450100538d06769529bba ("net/can: add driver for mscan
> family & mpc52xx_mscan") from the net tree.
added Kconfig entries right behind the CAN_AT91 driver - and that's because
the net-2.6 patch "can: Fix driver Kconfig structure" refuses to apply cleanly
on net-next-2.6 ...
>
> I fixed it up (see below) and can carry the fix for a while. (I am not
> sure the fix is entirely correct.)
>
Yes. You only added the new Kconfig entries (for CAN_TI_HECC, CAN_MCP251X,
CAN_MSCAN, ...) to the patch "can: Fix driver Kconfig structure", right?
These are the only added items in drivers/net/can/Kconfig from net-2.6 to
net-next-2.6.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH] ppp: fix BUG on non-linear SKB (multilink receive)
From: David Miller @ 2009-11-17 7:52 UTC (permalink / raw)
To: ben; +Cc: paulus, netdev, linux-ppp
In-Reply-To: <Pine.LNX.4.58.0911161334240.15274@benxen>
From: Ben McKeegan <ben@netservers.co.uk>
Date: Mon, 16 Nov 2009 13:44:25 +0000 (GMT)
> PPP does not correctly call pskb_may_pull() on all necessary receive paths
> before reading the PPP protocol, thus causing PPP to report seemingly
> random 'unsupported protocols' and eventually trigger BUG_ON(skb->len <
> skb->data_len) in skb_pull_rcsum() when receiving multilink protocol in
> non-linear skbs.
>
> ppp_receive_nonmp_frame() does not call pskb_may_pull() before reading the
> protocol number. For the non-mp receive path this is not a problem, as
> this check is done in ppp_receive_frame(). For the mp receive path,
> ppp_mp_reconstruct() usually copies the data into a new linear skb.
> However, in the case where the frame is made up of a single mp fragment,
> the mp header is pulled and the existing skb used. This skb was then
> passed to ppp_receive_nonmp_frame() without checking if the encapsulated
> protocol header could safely be read.
>
> Signed-off-by: Ben McKeegan <ben@netservers.co.uk>
Applied but:
> + while ((skb = ppp_mp_reconstruct(ppp))) {
> + if (pskb_may_pull(skb, 2))
There is a mix of space and tab characters leading up to
the "if (pskb_may_pull" there, I fixed it up but please
take care of such trivial issues before submitting your
patch next time.
Thanks.
^ permalink raw reply
* Re: [PATCH] ixgbe: Fixing EEH handler to handle more than one error
From: David Miller @ 2009-11-17 7:52 UTC (permalink / raw)
To: peter.p.waskiewicz.jr; +Cc: leitao, netdev, jeffrey.t.kirsher
In-Reply-To: <Pine.WNT.4.64.0911161100030.16132@ppwaskie-MOBL2.amr.corp.intel.com>
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Date: Mon, 16 Nov 2009 11:01:13 -0800 (Pacific Standard Time)
> On Sun, 15 Nov 2009, David Miller wrote:
>
>> From: leitao@linux.vnet.ibm.com
>> Date: Tue, 10 Nov 2009 13:37:47 -0500
>>
>> > After commmit 4b77b0a2ba27d64f58f16d8d4d48d8319dda36ff EEH breaks
>> > after the second error, since it calls pci_restore_state()
>> > but it returns 0, since pci->state_saved is false.
>> >
>> > So, this patch just call pci_save_state() after pci_restore_state().
>> >
>> > Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
>>
>> Intel folks, are you integrating or looking at this patch?
>
> This patch looks correct and makes sense to me. I'm going to ACK it now,
> but we'll still pull it in and test it. If we see any issues, we'll
> report them with possible fixes. But at this point, I think this patch is
> fine.
>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2 v2] KS8695: fix ks8695_rx() unreasonable action.
From: David Miller @ 2009-11-17 7:52 UTC (permalink / raw)
To: figo1802; +Cc: zealcook, netdev, ben
In-Reply-To: <1258046194.1931.18.camel@myhost>
From: "Figo.zhang" <figo1802@gmail.com>
Date: Fri, 13 Nov 2009 01:16:34 +0800
> On Mon, 2009-11-16 at 22:58 +0800, zeal wrote:
>> From: zeal <zealcook@gmail.com>
>>
>> ks8695_rx() will call refill_buffers() for every incoming packet.
>> Its not necessary. We just need do it after finishing receiving thing.
>> And the 'RX dma engine' is in the same situation.
>> This blocks our user space application. The following patch may fix it.
>>
>
> yes, it is right.
>
> Best,
> Figo.zhang
>
>> Signed-off-by: zeal <zealcook@gmail.com>
Patch applied.
^ permalink raw reply
* Re: [PATCH 1/2 v2] KS8695: fix ks8695_rx_irq() bug.
From: David Miller @ 2009-11-17 7:51 UTC (permalink / raw)
To: zealcook; +Cc: figo1802, netdev, ben
In-Reply-To: <efc9214f0911162028te62eca0h90f11b9b1e7a5d6e@mail.gmail.com>
From: zeal <zealcook@gmail.com>
Date: Tue, 17 Nov 2009 12:28:33 +0800
> 'the corresponding status bit has been clear(irq's ack)' is not enough?
I think it is sufficient, patch applied, thanks!
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-11-16
From: David Miller @ 2009-11-17 7:46 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091116162655.GD14410-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Mon, 16 Nov 2009 11:26:55 -0500
> The biggest is a revert of the patch that added cfg80211 support
> to ipw2200. It was ill conceived and inadvertantly caused problems
> for ipw2100. There are fixes available now, but they are just as
> big as the revert -- I'll restage them for 2.6.33. There is little
> activity in ipw2200, so it the revert should be set. Plus, I've
> tested the revert locally.
...
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Pulled, thanks a lot.
--
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: [PATCH 2/2] ipv4: factorize cache clearing for batched unregister operations
From: Octavian Purdila @ 2009-11-17 7:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Eric Dumazet
In-Reply-To: <20091116160646.39c0a1ac@nehalam>
On Tuesday 17 November 2009 02:06:46 you wrote:
> On Tue, 17 Nov 2009 01:49:49 +0200
>
> Octavian Purdila <opurdila@ixiacom.com> wrote:
> > Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
> > ---
> > net/ipv4/fib_frontend.c | 11 ++++++-----
> > 1 files changed, 6 insertions(+), 5 deletions(-)
>
> And what about IPV6?
>
IPv6 did not appear during profiling my simple dummy test and also a quick scan
through the code did not reveal anything obvious on the unregister path which
could be factorized.
BTW, it appears we don't have a route cache for IPv6. Right?
I known we will run into other scalability issues when we will set IPv4/IPv6
addresses, and that is one of the next items on my list to profile :)
^ permalink raw reply
* Re: 2.6.32-rc7-git1: Reported regressions from 2.6.31
From: Eric W. Biederman @ 2009-11-17 7:14 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Network Development
In-Reply-To: <GUZt44bIwCE.A.vLF.pSdALB@chimera>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> This message contains a list of some regressions from 2.6.31, for which there
> are no fixes in the mainline I know of. If any of them have been fixed already,
> please let me know.
>
> If you know of any other unresolved regressions from 2.6.31, please let me know
> either and I'll add them to the list. Also, please let me know if any of the
> entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply to
> this message with CCs to the people involved in reporting and handling the
> issue.
Not in 2.6.31 but in 2.6.32-rc5 I get a firmware hang from my netxen
nic when I try to bring the link up. I have reported and was working
with the developer for a while. I haven't heard anything in the last
week or so.
Eric
^ permalink raw reply
* Re: [PATCH] ifb: add multi-queue support
From: Stephen Hemminger @ 2009-11-17 6:02 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, kaber, eric.dumazet, therbert, netdev
In-Reply-To: <412e6f7f0911162138k6537afd1l5f8eeeaa6c636289@mail.gmail.com>
On Tue, 17 Nov 2009 13:38:29 +0800
Changli Gao <xiaosuo@gmail.com> wrote:
> On Tue, Nov 17, 2009 at 11:10 AM, David Miller <davem@davemloft.net> wrote:
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Mon, 16 Nov 2009 08:39:05 -0800
> >
> >> My $.02 is that receive packet steering RPS should be done generically at
> >> receive layer. Then all the CPU, mapping and configuration issues can be
> >> done once, not just for IFB, Bridge, VLAN, ... The number of users of IFB
> >> is small, and setup is complex. Steering packets in IFB is optimizing only
> >> a rarely used corner.
> >>
> >> Layered link services like IFB need to be multi-threaded lockless to maintain
> >> the advantages of multi-queue and RPS.
> >
> > You're probably right.
> >
>
> So I have to wait RPS, and after it gets merged, I'll back with
> multi-threaded lockless IFB.
Please don't wait... Help, test it make sure it works.
^ permalink raw reply
* Re: [PATCH 2/2] act_mirred: optimization
From: Changli Gao @ 2009-11-17 5:49 UTC (permalink / raw)
To: David Miller; +Cc: hadi, shemminger, netdev
In-Reply-To: <20091116.053329.215126585.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
On Mon, Nov 16, 2009 at 9:33 PM, David Miller <davem@davemloft.net> wrote:
> From: Changli Gao <xiaosuo@gmail.com>
> Date: Mon, 16 Nov 2009 21:22:46 +0800
>
>> I am working against linux-next. I'll check if there is any
>> difference. BTW: were these patches applied in order, 1 - 2?
>
> Yes, they were.
>
Patch is resubmitted as attachment.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
[-- Attachment #2: act_mirred_opt.diff --]
[-- Type: application/octet-stream, Size: 2485 bytes --]
--- a/net/sched/act_mirred.c 2009-11-16 16:21:21.000000000 +0800
+++ b/net/sched/act_mirred.c 2009-11-16 17:43:37.000000000 +0800
@@ -65,48 +65,53 @@
struct tc_mirred *parm;
struct tcf_mirred *m;
struct tcf_common *pc;
- struct net_device *dev = NULL;
- int ret = 0, err;
- int ok_push = 0;
+ struct net_device *dev;
+ int ret, ok_push = 0;
if (nla == NULL)
return -EINVAL;
-
- err = nla_parse_nested(tb, TCA_MIRRED_MAX, nla, mirred_policy);
- if (err < 0)
- return err;
-
+ ret = nla_parse_nested(tb, TCA_MIRRED_MAX, nla, mirred_policy);
+ if (ret < 0)
+ return ret;
if (tb[TCA_MIRRED_PARMS] == NULL)
return -EINVAL;
parm = nla_data(tb[TCA_MIRRED_PARMS]);
-
+ switch (parm->eaction) {
+ case TCA_EGRESS_MIRROR:
+ case TCA_EGRESS_REDIR:
+ break;
+ default:
+ return -EINVAL;
+ }
if (parm->ifindex) {
dev = __dev_get_by_index(&init_net, parm->ifindex);
if (dev == NULL)
return -ENODEV;
switch (dev->type) {
- case ARPHRD_TUNNEL:
- case ARPHRD_TUNNEL6:
- case ARPHRD_SIT:
- case ARPHRD_IPGRE:
- case ARPHRD_VOID:
- case ARPHRD_NONE:
- ok_push = 0;
- break;
- default:
- ok_push = 1;
- break;
+ case ARPHRD_TUNNEL:
+ case ARPHRD_TUNNEL6:
+ case ARPHRD_SIT:
+ case ARPHRD_IPGRE:
+ case ARPHRD_VOID:
+ case ARPHRD_NONE:
+ ok_push = 0;
+ break;
+ default:
+ ok_push = 1;
+ break;
}
+ } else {
+ dev = NULL;
}
pc = tcf_hash_check(parm->index, a, bind, &mirred_hash_info);
if (!pc) {
- if (!parm->ifindex)
+ if (dev == NULL)
return -EINVAL;
pc = tcf_hash_create(parm->index, est, a, sizeof(*m), bind,
&mirred_idx_gen, &mirred_hash_info);
if (IS_ERR(pc))
- return PTR_ERR(pc);
+ return PTR_ERR(pc);
ret = ACT_P_CREATED;
} else {
if (!ovr) {
@@ -119,12 +124,12 @@
spin_lock_bh(&m->tcf_lock);
m->tcf_action = parm->action;
m->tcfm_eaction = parm->eaction;
- if (parm->ifindex) {
+ if (dev != NULL) {
m->tcfm_ifindex = parm->ifindex;
if (ret != ACT_P_CREATED)
dev_put(m->tcfm_dev);
- m->tcfm_dev = dev;
dev_hold(dev);
+ m->tcfm_dev = dev;
m->tcfm_ok_push = ok_push;
}
spin_unlock_bh(&m->tcf_lock);
@@ -154,13 +159,6 @@
spin_lock(&m->tcf_lock);
m->tcf_tm.lastuse = jiffies;
- if (m->tcfm_eaction != TCA_EGRESS_MIRROR &&
- m->tcfm_eaction != TCA_EGRESS_REDIR) {
- if (net_ratelimit())
- printk("tcf_mirred unknown action %d\n",
- m->tcfm_eaction);
- goto out;
- }
dev = m->tcfm_dev;
if (!(dev->flags & IFF_UP)) {
^ permalink raw reply
* Re: [PATCH 1/2] act_mirred: cleanup
From: Changli Gao @ 2009-11-17 5:48 UTC (permalink / raw)
To: David Miller; +Cc: hadi, shemminger, netdev
In-Reply-To: <20091116.024824.267061616.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
On Mon, Nov 16, 2009 at 6:48 PM, David Miller <davem@davemloft.net> wrote:
> From: jamal <hadi@cyberus.ca>
> Date: Mon, 16 Nov 2009 04:24:39 -0500
>
>> On Mon, 2009-11-16 at 16:33 +0800, Changli Gao wrote:
>>> act_mirred: cleanup
>>>
>>> 1. don't let go back using goto.
>>> 2. don't call skb_act_clone() until it is necessary.
>>> 3. one exit of the critical context.
>>>
>>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>>
>> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
>
> Applied.
>
Patch is resubmitted as attachment.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
[-- Attachment #2: act_mirred_cleanup.diff --]
[-- Type: application/octet-stream, Size: 2433 bytes --]
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index b9aaab4..b812c20 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -148,47 +148,39 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
{
struct tcf_mirred *m = a->priv;
struct net_device *dev;
- struct sk_buff *skb2 = NULL;
- u32 at = G_TC_AT(skb->tc_verd);
+ struct sk_buff *skb2;
+ u32 at;
+ int retval, err = 1;
spin_lock(&m->tcf_lock);
-
- dev = m->tcfm_dev;
m->tcf_tm.lastuse = jiffies;
+ if (m->tcfm_eaction != TCA_EGRESS_MIRROR &&
+ m->tcfm_eaction != TCA_EGRESS_REDIR) {
+ if (net_ratelimit())
+ printk("tcf_mirred unknown action %d\n",
+ m->tcfm_eaction);
+ goto out;
+ }
- if (!(dev->flags&IFF_UP) ) {
+ dev = m->tcfm_dev;
+ if (!(dev->flags & IFF_UP)) {
if (net_ratelimit())
printk("mirred to Houston: device %s is gone!\n",
dev->name);
-bad_mirred:
- if (skb2 != NULL)
- kfree_skb(skb2);
- m->tcf_qstats.overlimits++;
- m->tcf_bstats.bytes += qdisc_pkt_len(skb);
- m->tcf_bstats.packets++;
- spin_unlock(&m->tcf_lock);
- /* should we be asking for packet to be dropped?
- * may make sense for redirect case only
- */
- return TC_ACT_SHOT;
+ goto out;
}
skb2 = skb_act_clone(skb, GFP_ATOMIC);
if (skb2 == NULL)
- goto bad_mirred;
- if (m->tcfm_eaction != TCA_EGRESS_MIRROR &&
- m->tcfm_eaction != TCA_EGRESS_REDIR) {
- if (net_ratelimit())
- printk("tcf_mirred unknown action %d\n",
- m->tcfm_eaction);
- goto bad_mirred;
- }
+ goto out;
m->tcf_bstats.bytes += qdisc_pkt_len(skb2);
m->tcf_bstats.packets++;
- if (!(at & AT_EGRESS))
+ at = G_TC_AT(skb->tc_verd);
+ if (!(at & AT_EGRESS)) {
if (m->tcfm_ok_push)
skb_push(skb2, skb2->dev->hard_header_len);
+ }
/* mirror is always swallowed */
if (m->tcfm_eaction != TCA_EGRESS_MIRROR)
@@ -197,8 +189,23 @@ bad_mirred:
skb2->dev = dev;
skb2->iif = skb->dev->ifindex;
dev_queue_xmit(skb2);
+ err = 0;
+
+out:
+ if (err) {
+ m->tcf_qstats.overlimits++;
+ m->tcf_bstats.bytes += qdisc_pkt_len(skb);
+ m->tcf_bstats.packets++;
+ /* should we be asking for packet to be dropped?
+ * may make sense for redirect case only
+ */
+ retval = TC_ACT_SHOT;
+ } else {
+ retval = m->tcf_action;
+ }
spin_unlock(&m->tcf_lock);
- return m->tcf_action;
+
+ return retval;
}
static int tcf_mirred_dump(struct sk_buff *skb, struct tc_action *a, int bind, int ref)
^ permalink raw reply related
* Re: [PATCH] ifb: add multi-queue support
From: Changli Gao @ 2009-11-17 5:38 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, kaber, eric.dumazet, therbert, netdev
In-Reply-To: <20091116.191054.131722163.davem@davemloft.net>
On Tue, Nov 17, 2009 at 11:10 AM, David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, 16 Nov 2009 08:39:05 -0800
>
>> My $.02 is that receive packet steering RPS should be done generically at
>> receive layer. Then all the CPU, mapping and configuration issues can be
>> done once, not just for IFB, Bridge, VLAN, ... The number of users of IFB
>> is small, and setup is complex. Steering packets in IFB is optimizing only
>> a rarely used corner.
>>
>> Layered link services like IFB need to be multi-threaded lockless to maintain
>> the advantages of multi-queue and RPS.
>
> You're probably right.
>
So I have to wait RPS, and after it gets merged, I'll back with
multi-threaded lockless IFB.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 1/2 v2] KS8695: fix ks8695_rx_irq() bug.
From: zeal @ 2009-11-17 4:28 UTC (permalink / raw)
To: Figo.zhang; +Cc: netdev, ben, davem
In-Reply-To: <1258045910.1931.16.camel@myhost>
On Fri, Nov 13, 2009 at 1:11 AM, Figo.zhang <figo1802@gmail.com> wrote:
> On Mon, 2009-11-16 at 23:18 +0800, zeal wrote:
>> On Fri, Nov 13, 2009 at 12:24 AM, Figo.zhang <figo1802@gmail.com> wrote:
>> > On Mon, 2009-11-16 at 22:58 +0800, zeal wrote:
>> >> From: zeal <zealcook@gmail.com>
>> >>
>> >> Sorry for the previously patches. THEY'RE NOT RIGHT. It's my mistake.
>> >> Please forgive my noise.
>> >> Please review the following patches and ignore the last (v1).
>> >>
>> >> ks8695 rx irq is edge-level. Before arriving at irq handler, the
>> >> corresponding status bit has been clear(irq's ack).
>> >> So we should not check it after that.
>> >
>> > see <KS8695X Integrated Multi-Port Gateway Solution Register
>> > Description> Version 1.00
>> >
>> > Interrupt Status Register(INTST Offset 0xE208)
>> >
>> > it has said: This edge-triggered interrupt status is cleared by writting
>> > 1 , so we should write 1 to clear status bit manually.
>> >
>> Yeah, but irq_chip's ack has done that.
>> Please check arch/arm/mach-ks8695/irq.c ks8695_irq_edge_chip->ack()
>
> yes, you are right, but you have better add this description at commit
> log.
'the corresponding status bit has been clear(irq's ack)' is not enough?
[snip]
--
Thanks & Regards
zeal
^ permalink raw reply
* Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: David Miller @ 2009-11-17 3:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: william.allen.simpson, netdev, joe
In-Reply-To: <4B01D17C.4010407@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 16 Nov 2009 23:26:04 +0100
> So adding DATA to SYN packets might be problematic for part of our tcp stack.
I can almost guarentee it won't work. For one thing getting a SACK
response to a SYN+DATA packet will explode quite nicely for one thing.
A lot of the other retransmit queue handling would need to be audited
as well. So much code assumes that if we see sent data in the
retransmit queue, there won't be SYN or SYN+ACK things in there to
contend with.
^ permalink raw reply
* Re: [PATCH] ifb: add multi-queue support
From: David Miller @ 2009-11-17 3:10 UTC (permalink / raw)
To: shemminger; +Cc: xiaosuo, kaber, eric.dumazet, therbert, netdev
In-Reply-To: <20091116083905.634b8f56@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 16 Nov 2009 08:39:05 -0800
> My $.02 is that receive packet steering RPS should be done generically at
> receive layer. Then all the CPU, mapping and configuration issues can be
> done once, not just for IFB, Bridge, VLAN, ... The number of users of IFB
> is small, and setup is complex. Steering packets in IFB is optimizing only
> a rarely used corner.
>
> Layered link services like IFB need to be multi-threaded lockless to maintain
> the advantages of multi-queue and RPS.
You're probably right.
^ permalink raw reply
* linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2009-11-17 2:16 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Wolfram Sang, Christian Pellegrin,
Wolfgang Grandegger, Anant Gole, Oliver Hartkopp
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/can/Kconfig between commit
b93cf3f0bb45560d2ce62bdcc2181c40660cfdbf ("can: Fix driver Kconfig
structure") from the net-current tree and commits
3758bf25db8caeec667e4e56e030da0ec3060529 ("can: add TI CAN (HECC)
driver"), e0000163e30eeb112b41486ea113fd54f64e1f17 ("can: Driver for the
Microchip MCP251x SPI CAN controllers") and
afa17a500a3667f66df450100538d06769529bba ("net/can: add driver for mscan
family & mpc52xx_mscan") from the net tree.
I fixed it up (see below) and can carry the fix for a while. (I am not
sure the fix is entirely correct.)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/can/Kconfig
index 772f6d2,c16e6ff..0000000
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@@ -41,10 -95,38 +41,42 @@@ config CAN_AT9
---help---
This is a driver for the SoC CAN controller in Atmel's AT91SAM9263.
+ config CAN_TI_HECC
+ depends on CAN_DEV && ARCH_OMAP3
+ tristate "TI High End CAN Controller"
+ ---help---
+ Driver for TI HECC (High End CAN Controller) module found on many
+ TI devices. The device specifications are available from www.ti.com
+
+ config CAN_MCP251X
+ tristate "Microchip MCP251x SPI CAN controllers"
+ depends on CAN_DEV && SPI
+ ---help---
+ Driver for the Microchip MCP251x SPI CAN controllers.
+
+ config CAN_MSCAN
+ depends on CAN_DEV && (PPC || M68K || M68KNOMMU)
+ tristate "Support for Freescale MSCAN based chips"
+ ---help---
+ The Motorola Scalable Controller Area Network (MSCAN) definition
+ is based on the MSCAN12 definition which is the specific
+ implementation of the Motorola Scalable CAN concept targeted for
+ the Motorola MC68HC12 Microcontroller Family.
+
+ config CAN_MPC52XX
+ tristate "Freescale MPC5xxx onboard CAN controller"
+ depends on CAN_MSCAN && PPC_MPC52xx
+ ---help---
+ If you say yes here you get support for Freescale's MPC52xx
+ onboard dualCAN controller.
+
+ This driver can also be built as a module. If so, the module
+ will be called mpc5xxx_can.
+
+source "drivers/net/can/sja1000/Kconfig"
+
+source "drivers/net/can/usb/Kconfig"
+
config CAN_DEBUG_DEVICES
bool "CAN devices debugging messages"
depends on CAN
^ permalink raw reply
* Re: [RFC PATCH] net: add dataref destructor to sk_buff
From: Herbert Xu @ 2009-11-17 1:02 UTC (permalink / raw)
To: Gregory Haskins
Cc: David Miller, ghaskins, mst, alacrityvm-devel, linux-kernel,
netdev
In-Reply-To: <4B016041.5030000@gmail.com>
On Mon, Nov 16, 2009 at 09:22:57AM -0500, Gregory Haskins wrote:
>
> But really, this is somewhat orthogonal to the original problem, so let
> me see if we can bring it back on topic. Michael stated that this patch
> in question may be problematic because there are places in the stack
> that can get_page() without also maintaining a reference to the shinfo
> object. Evgeniy seems to say the opposite. I am not sure who is right,
> or if I misunderstood one or both of them. Any thoughts?
There are loads of places where this can happen. Start with
pskb_expand_head.
Cheers,
--
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: [PATCH 2/2] ipv4: factorize cache clearing for batched unregister operations
From: Benjamin LaHaise @ 2009-11-17 0:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Octavian Purdila, netdev, Eric Dumazet
In-Reply-To: <20091116160646.39c0a1ac@nehalam>
On Mon, Nov 16, 2009 at 04:06:46PM -0800, Stephen Hemminger wrote:
> And what about IPV6?
It's not possible to create more than a few thousand IPv6 interfaces in
my tests with a 4GB vm. The culprit seems to be the per-cpu arrays for
statistics using vmalloc() and wasting gobs of memory as a result (memory
usage seems to be 10x per interface vs what IPv4 is using), but I haven't
dug too deeply yet.
-ben
^ permalink raw reply
* Re: Using netconsole and getting double prints
From: Luis R. Rodriguez @ 2009-11-17 0:18 UTC (permalink / raw)
To: Andre Naujoks; +Cc: Matt Mackall, linux-kernel, netdev
In-Reply-To: <43e72e890911060914i6233b71dgd68e228074869096@mail.gmail.com>
On Fri, Nov 6, 2009 at 9:14 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 8:45 AM, Andre Naujoks <nautsch2@googlemail.com> wrote:
>
>> I think the intention behind this is for you to check if they are double
>> prints on your end or double sends on the other end.
>
> Ah yeah, good point :)
Sniffed and saw the issue. My local router was echo'ing the message,
solution was to simply add the destination mac address on netconsole
module parameters passed.
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox