Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net-next-2.6] net: speedup netdev_set_master()
From: David Miller @ 2010-03-19  6:11 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1268977513.2894.223.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Mar 2010 06:45:13 +0100

> Le jeudi 18 mars 2010 à 22:36 -0700, David Miller a écrit :
>> It was not an issue of related, but rather "B won't apply cleanly
>> without A". Even line offsets can make "git apply" reject.
>> --
> 
> I see, I can resubmit later if you prefer, once net-2.6 fix is pulled in
> net-next, there is no hurry :)

No need, just let me know about this stuff in the future, that's
all :-)

^ permalink raw reply

* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Herbert Xu @ 2010-03-19  6:03 UTC (permalink / raw)
  To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BA31049.7030005@iki.fi>

On Fri, Mar 19, 2010 at 07:48:57AM +0200, Timo Teräs wrote:
>
> But it always matches. The caching happens using the inner
> flow. Inner flow always matches with the same bundle unless
> the bundle expires or goes stale. What happens is that I get
> multiple cache entries per-inner flow each referencing to the
> same bundle.

Sorry for being slow, but if it always matches, doesn't that mean
you'll only have a single bundle in the policy bundle list? IOW
why do we need this at all?

Or have I misread your patch? You *are* proposing to cache the last
used bundle in the policy, right?

> True. But if we go and prune a bundle due to it being bad or
> needing garbage collection we need to invalidate all bundles
> pointers, and we cannot access the back-pointer. Alternatively

Why can't you access the back-pointer? You should always have
a reference held on the policy, either explicit or implicit.

> we need to keep xfrm_dst references again in the flow cache
> requiring an expensive iteration of all flow cache entries
> whenever a xfrm_dst needs to be deleted (which happens often).

So does the IPv4 routing cache.  I think what this reflects is
just that the IPsec garbage collection mechanism is broken.

There is no point in doing a GC on every dst_alloc if we know
that it isn't going to go below the threshold.  It should gain
a minimum GC interval like IPv4.  Or perhaps we can move the
minimum GC interval check into the dst core.

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

* [PATCH] ipv4: check rt_genid in dst_check
From: Timo Teras @ 2010-03-19  5:54 UTC (permalink / raw)
  To: netdev; +Cc: Timo Teras

Xfrm_dst keeps a reference to ipv4 rtable entries on each
cached bundle. The only way to renew xfrm_dst when the underlying
route has changed, is to implement dst_check for this. This is
what ipv6 side does too.

The problems started after 87c1e12b5eeb7b30b4b41291bef8e0b41fc3dde9
which fixed a bug causing xfrm_dst to not get reused, until that all
lookups always generated new xfrm_dst with new route reference
and path mtu worked. But after the fix, the old routes started
to get reused even after they were expired causing pmtu to break
(well it would occationally work if the rtable gc had run recently
and marked the route obsolete causing dst_check to get called).

Signed-off-by: Timo Teras <timo.teras@iki.fi>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
---
 net/ipv4/route.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index a770df2..8c9d06e 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1441,7 +1441,7 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
 					dev_hold(rt->u.dst.dev);
 				if (rt->idev)
 					in_dev_hold(rt->idev);
-				rt->u.dst.obsolete	= 0;
+				rt->u.dst.obsolete	= -1;
 				rt->u.dst.lastuse	= jiffies;
 				rt->u.dst.path		= &rt->u.dst;
 				rt->u.dst.neighbour	= NULL;
@@ -1506,7 +1506,7 @@ static struct dst_entry *ipv4_negative_advice(struct dst_entry *dst)
 	struct dst_entry *ret = dst;
 
 	if (rt) {
-		if (dst->obsolete) {
+		if (dst->obsolete > 0) {
 			ip_rt_put(rt);
 			ret = NULL;
 		} else if ((rt->rt_flags & RTCF_REDIRECTED) ||
@@ -1726,7 +1726,9 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu)
 
 static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
 {
-	return NULL;
+	if (dst && rt_is_expired((struct rtable *)dst))
+		return NULL;
+	return dst;
 }
 
 static void ipv4_dst_destroy(struct dst_entry *dst)
@@ -1888,7 +1890,8 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	if (!rth)
 		goto e_nobufs;
 
-	rth->u.dst.output= ip_rt_bug;
+	rth->u.dst.output = ip_rt_bug;
+	rth->u.dst.obsolete = -1;
 
 	atomic_set(&rth->u.dst.__refcnt, 1);
 	rth->u.dst.flags= DST_HOST;
@@ -2054,6 +2057,7 @@ static int __mkroute_input(struct sk_buff *skb,
 	rth->fl.oif 	= 0;
 	rth->rt_spec_dst= spec_dst;
 
+	rth->u.dst.obsolete = -1;
 	rth->u.dst.input = ip_forward;
 	rth->u.dst.output = ip_output;
 	rth->rt_genid = rt_genid(dev_net(rth->u.dst.dev));
@@ -2218,6 +2222,7 @@ local_input:
 		goto e_nobufs;
 
 	rth->u.dst.output= ip_rt_bug;
+	rth->u.dst.obsolete = -1;
 	rth->rt_genid = rt_genid(net);
 
 	atomic_set(&rth->u.dst.__refcnt, 1);
@@ -2444,6 +2449,7 @@ static int __mkroute_output(struct rtable **result,
 	rth->rt_spec_dst= fl->fl4_src;
 
 	rth->u.dst.output=ip_output;
+	rth->u.dst.obsolete = -1;
 	rth->rt_genid = rt_genid(dev_net(dev_out));
 
 	RT_CACHE_STAT_INC(out_slow_tot);
-- 
1.6.3.3


^ permalink raw reply related

* Re: [iproute2] iproute2 question
From: thomas yang @ 2010-03-19  5:53 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: hadi, netdev
In-Reply-To: <20100318085919.05328127@nehalam>

2010/3/18 Stephen Hemminger <shemminger@vyatta.com>:
> On Thu, 18 Mar 2010 17:02:16 +0800
> thomas yang <lampsu@gmail.com> wrote:
>
>> Hi,
>>
>> Linux router R (has some interfaces)  use the table "main" as default
>> routing table to route packets.  If  some link connected to R failed,
>> I want to use another table "backup_tbl" to route packets; if the
>> broken link repaired , go back to use table "main"  .  How to do this?
>
> That's now it works. Use a real routing daemon.
>

I want to reduce the packet loss that happens while routers converge
after a topology change due to a failure, use precalculated backup
table to do rapid failure repair  (repair faster than routing daemon,
fast reroute).
I do static routing on my linux routers.  When  some link  failed,
 I want to  use backup tables to route packets.  Can iproute2 do this?

^ permalink raw reply

* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Timo Teräs @ 2010-03-19  5:48 UTC (permalink / raw)
  To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100319003130.GA20227@gondor.apana.org.au>

Herbert Xu wrote:
> On Thu, Mar 18, 2010 at 09:30:58PM +0200, Timo Teräs wrote:
>> Now, these created xfrm_dst gets cached in policy->bundles
>> with ref count zero and not deleted until garbage collection
>> is required. That's how xfrm_find_bundle tries to reuse them
>> (but it does O(n) lookup).
> 
> Yes but the way you're caching it in the policy means that it
> only helps if two consecutive packets happen to match the same
> bundle.  If your traffic mix was such that each packet required
> a different bundle, then we're back to where we started.
> 
> That's why I was asking for you to directly cache the xfrm_dst
> objects in the flow cache.

But it always matches. The caching happens using the inner
flow. Inner flow always matches with the same bundle unless
the bundle expires or goes stale. What happens is that I get
multiple cache entries per-inner flow each referencing to the
same bundle.

And this is even more useful with the gre+esp. No matter what
I send inside gre (with private IPs), it ends up being routed
to more limited set of outer public IP parties. The bundle
lookup happens with the public-IP flow, so the speed up works
even better.

>> Actually no. As the pmtu case showed, it's more likely that
>> xfrm_dst needs to be regenerated, but the policy stays the
>> same since policy db isn't touched that often. If we keep
>> them separately we can almost most of the time avoid doing
>> policy lookup which is also O(n). Also the currently cache
>> entry validation is needs to check policy's bundles_genid
>> before allowing touching of xfrm_dst. Otherwise we would have
>> to keep global bundle_genid, and we'd lose the parent pointer
>> on cache miss.
> A back-pointer does not require an O(n) lookup.

True. But if we go and prune a bundle due to it being bad or
needing garbage collection we need to invalidate all bundles
pointers, and we cannot access the back-pointer. Alternatively
we need to keep xfrm_dst references again in the flow cache
requiring an expensive iteration of all flow cache entries
whenever a xfrm_dst needs to be deleted (which happens often).

- Timo

^ permalink raw reply

* Re: [PATCH net-next-2.6] net: speedup netdev_set_master()
From: Eric Dumazet @ 2010-03-19  5:45 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20100318.223658.241427584.davem@davemloft.net>

Le jeudi 18 mars 2010 à 22:36 -0700, David Miller a écrit :
> It was not an issue of related, but rather "B won't apply cleanly
> without A". Even line offsets can make "git apply" reject.
> --

I see, I can resubmit later if you prefer, once net-2.6 fix is pulled in
net-next, there is no hurry :)




^ permalink raw reply

* RE: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
From: Amit Salecha @ 2010-03-19  5:36 UTC (permalink / raw)
  To: David Miller, ebiederm@xmission.com; +Cc: netdev@vger.kernel.org, Ameen Rahman
In-Reply-To: <20100318.222126.27823381.davem@davemloft.net>

We are working on this problem, will let you know our decision by end of day.

-Thanks

-----Original Message-----
From: David Miller [mailto:davem@davemloft.net] 
Sent: Friday, March 19, 2010 10:51 AM
To: ebiederm@xmission.com
Cc: Amit Salecha; netdev@vger.kernel.org; Ameen Rahman
Subject: Re: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.

From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 18 Mar 2010 02:43:39 -0700

> Amit Salecha <amit.salecha@qlogic.com> writes:
> 
>> Sorry for all the problem you faced.
>>
>> But you shouldn't add support of device which is not supported.
>> Netxen is now owned by Qlogic. You should first contact Qlogic to solve your problem.
>> Qlogic will take needed action based on problem.
> 
> I'm not adding support.  I am sending a patch removing support for cards
> that do not work with the current driver and have not worked since 2.6.31.

You qlogic folks better resolve this _FAST_ or else I'll
make an executive decision about how to handle this and
I guarentee I'll make a decision that you will not like.

Thanks. :-)

^ permalink raw reply

* Re: [PATCH net-next-2.6] net: speedup netdev_set_master()
From: David Miller @ 2010-03-19  5:36 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1268976491.2894.221.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Mar 2010 06:28:11 +0100

> Le jeudi 18 mars 2010 à 22:22 -0700, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Fri, 19 Mar 2010 00:37:40 +0100
>> 
>> > We currently force a synchronize_net() in netdev_set_master()
>> > 
>> > This seems necessary only when a slave had a master and we dismantle it.
>> > 
>> > In the other case ("ifenslave bond0 ethO"), we dont need this long
>> > delay.
>> > 
>> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> 
>> Depends upon the net-2.6 race fix?
>> 
>> Thanks for telling me :-/
> 
> I believe it's not related. It's net-next-2.6 material, for sure :)

It was not an issue of related, but rather "B won't apply cleanly
without A". Even line offsets can make "git apply" reject.

^ permalink raw reply

* Re: [PATCH net-next-2.6] net: speedup netdev_set_master()
From: Eric Dumazet @ 2010-03-19  5:28 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20100318.222226.191403090.davem@davemloft.net>

Le jeudi 18 mars 2010 à 22:22 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 19 Mar 2010 00:37:40 +0100
> 
> > We currently force a synchronize_net() in netdev_set_master()
> > 
> > This seems necessary only when a slave had a master and we dismantle it.
> > 
> > In the other case ("ifenslave bond0 ethO"), we dont need this long
> > delay.
> > 
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> 
> Depends upon the net-2.6 race fix?
> 
> Thanks for telling me :-/

I believe it's not related. It's net-next-2.6 material, for sure :)

But yes, I discovered the race fix while studying netdev_set_master()

Thanks David



^ permalink raw reply

* Re: [PATCH net-next-2.6] net: speedup netdev_set_master()
From: David Miller @ 2010-03-19  5:22 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1268955460.2894.207.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Mar 2010 00:37:40 +0100

> We currently force a synchronize_net() in netdev_set_master()
> 
> This seems necessary only when a slave had a master and we dismantle it.
> 
> In the other case ("ifenslave bond0 ethO"), we dont need this long
> delay.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Depends upon the net-2.6 race fix?

Thanks for telling me :-/

^ permalink raw reply

* Re: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
From: David Miller @ 2010-03-19  5:21 UTC (permalink / raw)
  To: ebiederm; +Cc: amit.salecha, netdev, ameen.rahman
In-Reply-To: <m11vfic6d0.fsf@fess.ebiederm.org>

From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 18 Mar 2010 02:43:39 -0700

> Amit Salecha <amit.salecha@qlogic.com> writes:
> 
>> Sorry for all the problem you faced.
>>
>> But you shouldn't add support of device which is not supported.
>> Netxen is now owned by Qlogic. You should first contact Qlogic to solve your problem.
>> Qlogic will take needed action based on problem.
> 
> I'm not adding support.  I am sending a patch removing support for cards
> that do not work with the current driver and have not worked since 2.6.31.

You qlogic folks better resolve this _FAST_ or else I'll
make an executive decision about how to handle this and
I guarentee I'll make a decision that you will not like.

Thanks. :-)

^ permalink raw reply

* Re: [PATCH] smsc95xx: Fix tx checksum offload for small packets
From: David Miller @ 2010-03-19  5:19 UTC (permalink / raw)
  To: steve.glendinning; +Cc: netdev
In-Reply-To: <1268940010-19394-1-git-send-email-steve.glendinning@smsc.com>

From: Steve Glendinning <steve.glendinning@smsc.com>
Date: Thu, 18 Mar 2010 19:20:10 +0000

> TX checksum offload does not work properly when transmitting
> UDP packets with 0, 1 or 2 bytes of data.  This patch works
> around the problem by calculating checksums for these packets
> in the driver.
> 
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>

Applied, but I had to fix up trailing whitespace on one of the
patch's lines.  Please check for and fix up such trivial matters
before I ever have to see the patch in the future, thanks.

^ permalink raw reply

* Re: [PATCH] ipv4: check rt_genid in dst_check
From: Herbert Xu @ 2010-03-19  5:18 UTC (permalink / raw)
  To: David Miller; +Cc: timo.teras, netdev
In-Reply-To: <20100318.221649.02256374.davem@davemloft.net>

On Thu, Mar 18, 2010 at 10:16:49PM -0700, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Thu, 18 Mar 2010 20:11:46 +0800
> 
> > On Thu, Mar 18, 2010 at 01:48:22PM +0200, Timo Teras wrote:
> >> @@ -1726,7 +1726,9 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu)
> >>  
> >>  static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
> >>  {
> >> -	return NULL;
> >> +	if (dst && dst->dev && rt_is_expired((struct rtable *) dst))
                                                              ^

While you're at it, please delete this space to preemptively
stop anyone from sending a checkpatch patch :)

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: [PATCH] ipv4: check rt_genid in dst_check
From: David Miller @ 2010-03-19  5:16 UTC (permalink / raw)
  To: herbert; +Cc: timo.teras, netdev
In-Reply-To: <20100318121146.GA13307@gondor.apana.org.au>

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 18 Mar 2010 20:11:46 +0800

> On Thu, Mar 18, 2010 at 01:48:22PM +0200, Timo Teras wrote:
>> @@ -1726,7 +1726,9 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu)
>>  
>>  static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
>>  {
>> -	return NULL;
>> +	if (dst && dst->dev && rt_is_expired((struct rtable *) dst))
>> +		return NULL;
>> +	return dst;
>>  }
> 
> Can dst->dev ever be NULL? I'm pretty sure that we disallow that
> from ever happening through the use of the loopback device.  A
> quick grep also fails to find any other dst->dev NULL checks in
> this file.

Timo please respin with the NULL check removed, it just creates
confusion if one spot has the NULL check and not only is it
not needed, but also no other spots make this check.

Please remember to add in Herbert's ACK when reposting.

Thanks.

^ permalink raw reply

* Re: [net-2.6 PATCH] ixgbe: Fix 82599 KX4 Wake on LAN issue after an improper system shutdown
From: David Miller @ 2010-03-19  5:14 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, mallikarjuna.chilakala
In-Reply-To: <20100319011656.9385.44064.stgit@localhost.localdomain>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 18 Mar 2010 18:16:56 -0700

> From: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> 
> Advanced Power Management is disabled for 82599 KX4 connections by
> clearing GRC.APME bit, causing it to not wake the system from an
> improper system shutdown. By default GRC.APME is enabled and software
> is not supposed to clear these settings during adapter probe.
> 
> Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

^ permalink raw reply

* Re: [net-2.6 PATCH] ixgbe: Fix 82599 multispeed fiber link issues due to Tx laser flapping
From: David Miller @ 2010-03-19  5:14 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, mallikarjuna.chilakala
In-Reply-To: <20100319003422.8981.79416.stgit@localhost.localdomain>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 18 Mar 2010 17:34:52 -0700

> From: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> 
> Fix 82599 link issues during driver load and unload test using multi-speed
> 10G & 1G fiber modules. When connected back to back sometime 82599 multispeed
> fiber modules would link at 1G speed instead of 10G highest speed, due to a
> race condition in autotry process involving Tx laser flapping. Move autotry
> autoneg-37 tx laser flapping process from multispeed module init setup
> to driver unload. This will alert the link partner to restart its
> autotry process when it tries to establish the link with the link partner
> 
> Signed-off-by:  Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

^ permalink raw reply

* Re: [PATCH] net: dev_getfirstbyhwtype() optimization
From: Eric Dumazet @ 2010-03-19  5:14 UTC (permalink / raw)
  To: paulmck; +Cc: David Miller, netdev
In-Reply-To: <20100319023256.GD2894@linux.vnet.ibm.com>

Le jeudi 18 mars 2010 à 19:32 -0700, Paul E. McKenney a écrit :
> On Thu, Mar 18, 2010 at 10:27:25PM +0100, Eric Dumazet wrote:
> > Use RCU to avoid RTNL use in dev_getfirstbyhwtype()
> > 
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 17b1686..0f2e9fc 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -772,14 +772,17 @@ EXPORT_SYMBOL(__dev_getfirstbyhwtype);
> > 
> >  struct net_device *dev_getfirstbyhwtype(struct net *net, unsigned short type)
> >  {
> > -	struct net_device *dev;
> > +	struct net_device *dev, *ret = NULL;
> > 
> > -	rtnl_lock();
> > -	dev = __dev_getfirstbyhwtype(net, type);
> > -	if (dev)
> > -		dev_hold(dev);
> > -	rtnl_unlock();
> > -	return dev;
> > +	rcu_read_lock();
> > +	for_each_netdev_rcu(net, dev)
> > +		if (dev->type == type) {
> > +			dev_hold(dev);
> > +			ret = dev;
> > +			break;
> > +		}
> > +	rcu_read_unlock();
> > +	return ret;
> 
> Looks good, but I don't understand how it helps to introduce the
> local variable "ret".
> 

Thanks for reviewing Paul !

Not only it helps, its necessary :)

for_each_netdev_rcu(net, dev) {
	if (cond) {
	   dev_hold(dev);
	   break;
	}
}
makes no guarantee dev is NULL if we hit the list end :


/**
 * list_for_each_entry_rcu      -       iterate over rcu list of given type
 * @pos:        the type * to use as a loop cursor.
 * @head:       the head for your list.
 * @member:     the name of the list_struct within the struct.
 *
 * This list-traversal primitive may safely run concurrently with
 * the _rcu list-mutation primitives such as list_add_rcu()
 * as long as the traversal is guarded by rcu_read_lock().
 */
#define list_for_each_entry_rcu(pos, head, member) \
        for (pos = list_entry_rcu((head)->next, typeof(*pos), member); \
                prefetch(pos->member.next), &pos->member != (head); \
                pos = list_entry_rcu(pos->member.next, typeof(*pos), member))




^ permalink raw reply

* Re: [net-next PATCH 0/5] enic: updates to version 1.3.1.1
From: David Miller @ 2010-03-19  4:23 UTC (permalink / raw)
  To: vkolluri; +Cc: netdev
In-Reply-To: <20100319021901.10527.9869.stgit@savbu-pc100.cisco.com>

From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Thu, 18 Mar 2010 19:19:38 -0700

> The following series implements enic driver updates:
> 
> 1/5 - Bug Fix: Fix hardware descriptor reads
> 2/5 - Bug Fix: Fix timeout for hardware Tx and Rx queue disable operations
> 3/5 - Do not advertise NETIF_F_HW_VLAN_RX
> 4/5 - Clean up: Add wrapper functions
> 5/5 - Clean up: Change driver description; Fix tab space; Update MAINTAINERS
> 
> Signed-off-by: Scott Feldman <scofeldm@cisco.com>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>

All applied to net-next-2.6, thanks.

^ permalink raw reply

* Re: pull request: wireless-2.6 2010-03-18
From: David Miller @ 2010-03-19  4:19 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100318203532.GE17357@tuxdriver.com>

From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 18 Mar 2010 16:35:32 -0400

> Three more intended for 2.6.34...  The biggest one is for ath9k, which
> removes some unused code along with the one-liner that makes the code
> unused.  (Did you follow that?)  The others are a null-pointer fix and a
> "hush dawg" for a noisy warning message.
> 
> Please let me know if there are problems!

Pulled, thanks a lot John.

^ permalink raw reply

* Re: [PATCH net-2.6] net: Potential null skb->dev dereference
From: David Miller @ 2010-03-19  4:16 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1268954378.2894.201.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Mar 2010 00:19:38 +0100

> When doing "ifenslave -d bond0 eth0", there is chance to get NULL
> dereference in netif_receive_skb(), because dev->master suddenly becomes
> NULL after we tested it.
> 
> We should use ACCESS_ONCE() to avoid this (or rcu_dereference())
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied, thanks Eric.

^ permalink raw reply

* Re: [PATCH net-2.6 3/3] jme: Advance driver version number
From: David Miller @ 2010-03-19  4:14 UTC (permalink / raw)
  To: cooldavid; +Cc: netdev, ethanhsiao, devinchiu, hcchao
In-Reply-To: <1268820571-2092-3-git-send-email-cooldavid@cooldavid.org>

From: cooldavid@cooldavid.org
Date: Wed, 17 Mar 2010 18:09:31 +0800

> From: Guo-Fu Tseng <cooldavid@cooldavid.org>
> 
> Advance driver version number after some bug fix.
> 
> Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>

Applied.

^ permalink raw reply

* Re: [PATCH net-2.6 2/3] jme: Protect vlgrp structure by pause RX actions.
From: David Miller @ 2010-03-19  4:14 UTC (permalink / raw)
  To: cooldavid; +Cc: netdev, ethanhsiao, devinchiu, hcchao, stable
In-Reply-To: <1268820571-2092-2-git-send-email-cooldavid@cooldavid.org>

From: cooldavid@cooldavid.org
Date: Wed, 17 Mar 2010 18:09:30 +0800

> From: Guo-Fu Tseng <cooldavid@cooldavid.org>
> 
> Temporary stop the RX IRQ, and disable (sync) tasklet or napi.
> And restore it after finished the vlgrp pointer assignment.
> 
> Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>

Applied.

^ permalink raw reply

* Re: [PATCH net-2.6 1/3] jme: Fix VLAN memory leak
From: David Miller @ 2010-03-19  4:14 UTC (permalink / raw)
  To: cooldavid; +Cc: netdev, ethanhsiao, devinchiu, hcchao, stable
In-Reply-To: <1268820571-2092-1-git-send-email-cooldavid@cooldavid.org>

From: cooldavid@cooldavid.org
Date: Wed, 17 Mar 2010 18:09:29 +0800

> From: Guo-Fu Tseng <cooldavid@cooldavid.org>
> 
> Fix memory leak while receiving 8021q tagged packet which is not
> registered by user.
> 
> Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>

Applied.

^ permalink raw reply

* Re: [PATCH] KS8851: Avoid NULL pointer in set rx mode
From: David Miller @ 2010-03-19  4:08 UTC (permalink / raw)
  To: abraham.arce.moreno; +Cc: netdev, jpirko
In-Reply-To: <cb8016981003161524w6601d5e7i3885f77219582a0a@mail.gmail.com>

From: Abraham Arce <abraham.arce.moreno@gmail.com>
Date: Tue, 16 Mar 2010 16:24:54 -0600

> Kernel NULL pointer dereference when setting mode for IFF_MULTICAST.
> Tested on SDP OMAP4430 board.

I'll apply this, thanks.

Jiri, just FYI, this bug was added by your mclist conversion.

^ permalink raw reply

* Re: [PATCH] NET_DMA: free skbs periodically
From: David Miller @ 2010-03-19  3:36 UTC (permalink / raw)
  To: steve; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber, linux-kernel
In-Reply-To: <1268752964-4397-1-git-send-email-steve@digidescorp.com>

From: "Steven J. Magnani" <steve@digidescorp.com>
Date: Tue, 16 Mar 2010 10:22:44 -0500

> Under NET_DMA, data transfer can grind to a halt when userland issues a
> large read on a socket with a high RCVLOWAT (i.e., 512 KB for both).
> This appears to be because the NET_DMA design queues up lots of memcpy 
> operations, but doesn't issue or wait for them (and thus free the 
> associated skbs) until it is time for tcp_recvmesg() to return. 
> The socket hangs when its TCP window goes to zero before enough data is 
> available to satisfy the read.
> 
> Periodically issue asynchronous memcpy operations, and free skbs for ones 
> that have completed, to prevent sockets from going into zero-window mode.
> 
> Signed-off-by: Steven J. Magnani <steve@digidescorp.com>

Can one of the NET DMA folks review this.

It's a pretty fundamental problem with how this stuff works
it seems.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox