* Re: [Bloat] shaper team forming up
From: Eric Dumazet @ 2011-03-15 23:00 UTC (permalink / raw)
To: David Miller; +Cc: chromatix99, d, netdev
In-Reply-To: <20110315.155305.71104836.davem@davemloft.net>
Le mardi 15 mars 2011 à 15:53 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 15 Mar 2011 05:42:46 +0100
>
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index 6ed6603..fabfe81 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -171,7 +171,7 @@ static struct dst_ops ipv4_dst_ops = {
> >
> > const __u8 ip_tos2prio[16] = {
> > TC_PRIO_BESTEFFORT,
> > - ECN_OR_COST(FILLER),
> > + ECN_OR_COST(BESTEFFORT),
> > TC_PRIO_BESTEFFORT,
> > ECN_OR_COST(BESTEFFORT),
> > TC_PRIO_BULK,
> >
> >
>
> Eric can you please formally submit this fix? I'd like to apply it soon.
>
> Thanks.
Sure, I can do this right now, but I want to fully credit Dan Siemon on
this one, as the author of the patch.
^ permalink raw reply
* Re: [PATCH] ipv4: Cache source address in nexthop entries.
From: David Miller @ 2011-03-15 23:02 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1103151135110.1729@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Tue, 15 Mar 2011 12:00:33 +0200 (EET)
> I see another problem with nh_saddr. fib_info
> is reused when NHs and some parameters are equal but the
> scope is not part of the fib_info and it is wrong to cache
> route scope in NH or even in fib_info. The problem is
> that we can expose in nh_saddr addresses with wrong
> scope for the route. It happens when two routes with
> different route scope reuse same fib_info.
>
> First thought is that the field fa_scope can be
> moved into fib_scope in struct fib_info, not to use
> nh_cfg_scope. Then fib_find_info can differentiate the
> entries by fib_scope. It means, fib_info will not be reused
> if fib_scope is different. For FIB_RES_PREFSRC I assume we
> can access fib_info from nh->nh_parent safely when
> refreshing nh_saddr.
>
> Here is a script that demonstrates the wrong
> exposing:
Thanks for all of your feedback Julian, I will look into
this very soon.
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: Michael Smith @ 2011-03-15 23:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110314.152704.98879085.davem@davemloft.net>
On Mon, 14 Mar 2011, David Miller wrote:
> > David Miller wrote:
> >
> >> Existing arguments might be large enough to carry more than one piece
> >> of information :-)
> >
> > If it's encoded into another argument, would there be more overhead
> > from bit-shifting it out than you'd save by losing an argument?
>
> It sure will if it's the different between the argument being passed
> in a register vs. on the stack.
I have a patch to replace u32 mark with an sk_buff. The mark is in the
sk_buff already, and so is the secpath field I need. Would that be
acceptable? I can hold off until the merge window is over.
-extern int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
- struct net_device *dev, __be32 *spec_dst,
- u32 *itag, u32 mark);
+extern int fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
+ u8 tos, int oif, struct net_device *dev,
+ __be32 *spec_dst, u32 *itag);
(dev is also usually the same as skb->dev, but not always...)
Mike
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: David Miller @ 2011-03-15 23:35 UTC (permalink / raw)
To: msmith; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.1103151913340.28997@juice.ott.cti.com>
From: Michael Smith <msmith@cbnco.com>
Date: Tue, 15 Mar 2011 19:21:29 -0400 (EDT)
> On Mon, 14 Mar 2011, David Miller wrote:
>
>> > David Miller wrote:
>> >
>> >> Existing arguments might be large enough to carry more than one piece
>> >> of information :-)
>> >
>> > If it's encoded into another argument, would there be more overhead
>> > from bit-shifting it out than you'd save by losing an argument?
>>
>> It sure will if it's the different between the argument being passed
>> in a register vs. on the stack.
>
> I have a patch to replace u32 mark with an sk_buff. The mark is in the
> sk_buff already, and so is the secpath field I need. Would that be
> acceptable? I can hold off until the merge window is over.
Sounds good, and yes please wait until after the merge window.
^ permalink raw reply
* [PATCH] net_sched: fix ip_tos2prio
From: Eric Dumazet @ 2011-03-15 23:56 UTC (permalink / raw)
To: David Miller; +Cc: chromatix99, d, netdev, Dan Siemon
In-Reply-To: <20110315.155305.71104836.davem@davemloft.net>
From: Dan Siemon <dan@coverfire.com>
ECN support incorrectly maps ECN BESTEFFORT packets to TC_PRIO_FILLER
(1) instead of TC_PRIO_BESTEFFORT (0)
This means ECN enabled flows are placed in pfifo_fast/prio low priority
band, giving ECN enabled flows [ECT(0) and CE codepoints] higher drop
probabilities.
This is rather unfortunate, given we would like ECN being more widely
used.
Ref : http://www.coverfire.com/archives/2011/03/13/pfifo_fast-and-ecn/
Signed-off-by: Dan Siemon <dan@coverfire.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Dave Täht <d@taht.net>
Cc: Jonathan Morton <chromatix99@gmail.com>
---
Note: I left TC_PRIO_FILLER definition, this can be removed later.
net/ipv4/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 209989c..870b518 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -204,7 +204,7 @@ static struct dst_ops ipv4_dst_ops = {
const __u8 ip_tos2prio[16] = {
TC_PRIO_BESTEFFORT,
- ECN_OR_COST(FILLER),
+ ECN_OR_COST(BESTEFFORT),
TC_PRIO_BESTEFFORT,
ECN_OR_COST(BESTEFFORT),
TC_PRIO_BULK,
^ permalink raw reply related
* pull request: wireless-2.6 2011-03-15
From: John W. Linville @ 2011-03-16 0:12 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
I nearly forgot this one! It is a really simple patch to enable the use
of some (so far still unreleased) firmware for the iwl1000 hardware.
Please pull for 2.6.39-rc1, so that users will be able to use the
new firmware when it is generally available!
John
---
The following changes since commit 84c0c6933cb0303fa006992a6659c2b46de4eb17:
smsc911x: Fix build error when SMSC_TRACE() used (2011-03-15 14:52:48 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Fry, Donald H (1):
iwlagn: Support new 1000 microcode.
drivers/net/wireless/iwlwifi/iwl-1000.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c b/drivers/net/wireless/iwlwifi/iwl-1000.c
index ba78bc8..507cab4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -49,7 +49,7 @@
#include "iwl-agn-debugfs.h"
/* Highest firmware API version supported */
-#define IWL1000_UCODE_API_MAX 3
+#define IWL1000_UCODE_API_MAX 5
#define IWL100_UCODE_API_MAX 5
/* Lowest firmware API version supported */
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: net-next-2.6 status...
From: John W. Linville @ 2011-03-16 0:13 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
eric.dumazet-u79uwXL29TY76Z2rM5mHXA,
jpirko-H+wXaHxf7aLQT0dZR+AlfA, kaber-dcUjhNyLwpNeoWH0uzbU5w
In-Reply-To: <20110315.160124.104058374.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, Mar 15, 2011 at 04:01:24PM -0700, David Miller wrote:
> John and Patrick, I assume that after today's pulls I am completely
> up to date with everything, feature wise, that will go into the merge
> window for wireless and netfilter.
Just sent a pull request for wireless-2.6 to cover a one-liner to
enable some new firmware for iwlagn -- I nearly forgot!
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] tcp: avoid cwnd moderation in undo
From: Yuchung Cheng @ 2011-03-16 0:34 UTC (permalink / raw)
To: Carsten Wolff; +Cc: David Miller, Ilpo Jarvinen, Nandita Dukkipati, netdev
In-Reply-To: <201103151107.35379.carsten@wolffcarsten.de>
On Tue, Mar 15, 2011 at 3:07 AM, Carsten Wolff <carsten@wolffcarsten.de> wrote:
>
> Hi,
>
> On Monday 14 March 2011, Yuchung Cheng wrote:
> > On Mon, Mar 14, 2011 at 3:06 AM, Carsten Wolff <carsten@wolffcarsten.de>
> wrote:
> > In the presence of reordering, cwnd is already moderated in Disorder
> > state before
> > entering the (false) recovery.
>
> Sure, cwnd moderation to in_flight + 1 segment is applied in disorder state,
it's in_flight + 3 usually. the moderation first happens
tcp_try_to_open() instead of tcp_cwnd_down()
>
> because this is implementing a form of extended limited transmit.
> Nevertheless, after a reordering event that caused a spurious fast retransmit,
> there can be an undo of congestion state changes (either after recovery or
> interrupting recovery, depending on the options enabled in the connection). I
> just wanted to point out, that the moderation step happening upon an undo may
> allow a larger burst, if a previous reordering event was detected and caused
> tp->reordering to be increased.
Your point is that cwnd should be moderated on reordering (in undo or
other events). Point taken.
My point is that cwnd does not need to be moderated on false
recoveries. Do you agree?
To implement your design, tcp_update_reordering should do
tcp_cwnd_moderation().
To implement my point, the moderations should be avoided in undo operations.
The two aren't in conflict. But there are cases that have both undo
and reordering.
Are we on the same page?
>
> > > More importantly, the prior ssthresh is restored and not affected by
> > > moderation. This means, if moderation reduces cwnd to a small value, then
> > > cwnd < ssthresh and TCP will quickly slow-start back to the previous
> > > state, without sending a big burst of segments.
>
> This is actually the more important point, because it means that the
> moderation does not negate the effects of the undo operation, as suggested by
> your patch-description.
It's a double-edge sword. Why slow-start if there is no real loss? It
hurts short
request-response type traffic performance badly b/c each undo makes cwnd = 3.
>
> False fast retransmits are mostly caused by reordering, spurious RTOs can also
> be caused by delay variations that do not exhibit reordering. Your patch
> touches all cases of spurious events. Anyway, I just mentioned reordering,
> because it is the event in which Linux already allows larger bursts of size
> tp->reordering in the moderation function (i.e. tp->reordering might be
> increased). It's also not important to me if the undo is happening duringor
> after recovery, the important question is, if burst protection in general is
> an important goal, or not (and I think it's there for a reason).
I am hoping my previous explanation make sense to you (these two points are
not in conflict).
^ permalink raw reply
* Re: net-next-2.6 status...
From: Jeff Kirsher @ 2011-03-16 0:36 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-wireless, netfilter-devel, eric.dumazet, jpirko,
linville, kaber
In-Reply-To: <20110315.160124.104058374.davem@davemloft.net>
On Tue, Mar 15, 2011 at 16:01, David Miller <davem@davemloft.net> wrote:
>
> Please do not submit feature patches until the merge window is over and
> Linus releases 2.6.39-rc1, thank you.
>
> Bug fixes are, of course, still ok.
>
Understood, thanks Dave.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH] net_sched: fix ip_tos2prio
From: David Miller @ 2011-03-16 1:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: chromatix99, d, netdev, dan
In-Reply-To: <1300233367.2565.133.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Mar 2011 00:56:07 +0100
> From: Dan Siemon <dan@coverfire.com>
>
> ECN support incorrectly maps ECN BESTEFFORT packets to TC_PRIO_FILLER
> (1) instead of TC_PRIO_BESTEFFORT (0)
>
> This means ECN enabled flows are placed in pfifo_fast/prio low priority
> band, giving ECN enabled flows [ECT(0) and CE codepoints] higher drop
> probabilities.
>
> This is rather unfortunate, given we would like ECN being more widely
> used.
>
> Ref : http://www.coverfire.com/archives/2011/03/13/pfifo_fast-and-ecn/
>
> Signed-off-by: Dan Siemon <dan@coverfire.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Dave Täht <d@taht.net>
> Cc: Jonathan Morton <chromatix99@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: pull request: wireless-2.6 2011-03-15
From: David Miller @ 2011-03-16 1:55 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110316001234.GA28663-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 15 Mar 2011 20:12:34 -0400
> I nearly forgot this one! It is a really simple patch to enable the use
> of some (so far still unreleased) firmware for the iwl1000 hardware.
>
> Please pull for 2.6.39-rc1, so that users will be able to use the
> new firmware when it is generally available!
Ok, pulled, thanks!
--
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 0/3] bonding: various fixes
From: David Miller @ 2011-03-16 2:29 UTC (permalink / raw)
To: andy; +Cc: kernel, netdev, fubar
In-Reply-To: <20110314210435.GZ11864@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Mon, 14 Mar 2011 17:04:35 -0400
> On Mon, Mar 14, 2011 at 09:22:03AM -0700, Phil Oester wrote:
>> A few collected fixes to bonding. Patches are against net-next,
>> but should apply fine to 38-rc.
>>
>> Phil
>>
>>
>> bond_main.c | 15 +++++++++++----
>> bond_sysfs.c | 5 ++++-
>> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> All in the series look good. Thanks for posting the queue cleanup,
> Phil.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
All applied, thanks.
^ permalink raw reply
* Re: [PATCH v6] xen network backend driver
From: David Miller @ 2011-03-16 2:38 UTC (permalink / raw)
To: Ian.Campbell
Cc: netdev, xen-devel, jeremy, herbert, konrad.wilk, romieu,
bhutchings, shemminger, mirqus, eric.dumazet
In-Reply-To: <1300183578.17339.2239.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 15 Mar 2011 10:06:18 +0000
> netback is the host side counterpart to the frontend driver in
> drivers/net/xen-netfront.c. The PV protocol is also implemented by
> frontend drivers in other OSes too, such as the BSDs and even Windows.
>
> The patch is based on the driver from the xen.git pvops kernel tree but
> has been put through the checkpatch.pl wringer plus several manual
> cleanup passes and review iterations. The driver has been moved from
> drivers/xen/netback to drivers/net/xen-netback.
>
> One major change from xen.git is that the guest transmit path (i.e. what
> looks like receive to netback) has been significantly reworked to remove
> the dependency on the out of tree PageForeign page flag (a core kernel
> patch which enables a per page destructor callback on the final
> put_page). This page flag was used in order to implement a grant map
> based transmit path (where guest pages are mapped directly into SKB
> frags). Instead this version of netback uses grant copy operations into
> regular memory belonging to the backend domain. Reinstating the grant
> map functionality is something which I would like to revisit in the
> future.
>
> Note that this driver depends on 2e820f58f7ad "xen/irq: implement
> bind_interdomain_evtchn_to_irqhandler for backend drivers" which is in
> linux next via the "xen-two" tree and is intended for the 2.6.39 merge
> window:
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/backends
> this branch has only that single commit since 2.6.38-rc2 and is safe for
> cross merging into the net branch.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Ok, I merged that xen commit into my tree and then added this
driver.
Thanks.
^ permalink raw reply
* No iproute2 for 2.6.38
From: Stephen Hemminger @ 2011-03-16 2:55 UTC (permalink / raw)
To: linux-kernel, netdev
I am not going to bother releasing for 2.6.38 the only changes
were later reverted.
---
Roopa Prabhu (1):
iproute2: add VF_PORT support
Stephen Hemminger (3):
Update to lasest kernel headers
Revert "iproute2: add VF_PORT support"
v2.6.38
^ permalink raw reply
* Re: [PATCH 17/17] net,act_police,rcu: remove rcu_barrier()
From: Lai Jiangshan @ 2011-03-16 3:13 UTC (permalink / raw)
To: Eric Dumazet
Cc: Randy Dunlap, linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Trond Myklebust, linux-sctp-u79uwXL29TY76Z2rM5mHXA,
Pavel Emelyanov, Pekka Savola (ipv6), Uwe Kleine-König,
Alexey Kuznetsov, Ingo Molnar, Paul E. McKenney,
Sridhar Samudrala, Vlad Yasevich, Hagen Paul Pfeifer,
John W. Linville, Al Viro, Johannes Berg, Jens Axboe,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, Jiri Pirko
In-Reply-To: <1300187052.10062.12.camel@edumazet-laptop>
On 03/15/2011 07:04 PM, Eric Dumazet wrote:
> Le mardi 15 mars 2011 à 18:11 +0800, Lai Jiangshan a écrit :
>>
>> There is no callback of this module maybe queued
>> since we use kfree_rcu(), we can safely remove the rcu_barrier().
>>
>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>> ---
>> net/sched/act_police.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/sched/act_police.c b/net/sched/act_police.c
>> index 083b091..22e3f9b 100644
>> --- a/net/sched/act_police.c
>> +++ b/net/sched/act_police.c
>> @@ -397,7 +397,6 @@ static void __exit
>> police_cleanup_module(void)
>> {
>> tcf_unregister_action(&act_police_ops);
>> - rcu_barrier(); /* Wait for completion of call_rcu()'s (tcf_police_free_rcu) */
>> }
>>
>> module_init(police_init_module);
>
>
> Why is it a separate patch, and not included in patch 5/17 ?
>
A simple_kfree_callback() a patch, if a module has multiple simple_kfree_callback()s,
"rcu_barrier()" in module_exit function should only be removed after all
callback()s are converted to kfree_rcu(). Separate patches makes things
clearer.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: No iproute2 for 2.6.38
From: Sridhar Samudrala @ 2011-03-16 5:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel, netdev
In-Reply-To: <20110315195534.0cc43032@nehalam>
On 3/15/2011 7:55 PM, Stephen Hemminger wrote:
> I am not going to bother releasing for 2.6.38 the only changes
> were later reverted.
2.6.38 includes support for macvlan/macvtap 'passthru' mode that allows
assigning
SR-IOV VFs to a KVM guest via macvtap/virtio.
It is not possible to support live migration using direct assignment of
VF's to a guest,
but 'passthu' assignment makes this possible.
Enabling this feature requires the following patch to iproute2 that
allows creating macvlan
device in 'passthru' mode.
http://patchwork.ozlabs.org/patch/69515/
Looks like this patch is still marked as 'Awaiting upstream'.
Could you apply this patch and it would be great if a version of
iproute2 is released for 2.6.38.
Thanks
Sridhar
> ---
> Roopa Prabhu (1):
> iproute2: add VF_PORT support
>
> Stephen Hemminger (3):
> Update to lasest kernel headers
> Revert "iproute2: add VF_PORT support"
> v2.6.38
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Multicast Fails Over Multipoint GRE Tunnel
From: Timo Teräs @ 2011-03-16 6:01 UTC (permalink / raw)
To: Doug Kehn; +Cc: Eric Dumazet, netdev
In-Reply-To: <553973.46912.qm@web39301.mail.mud.yahoo.com>
On 03/15/2011 11:35 PM, Doug Kehn wrote:
>> From: Timo Teräs <timo.teras@iki.fi>
>> Subject: Re: Multicast Fails Over Multipoint GRE Tunnel
>> To: "Eric Dumazet" <eric.dumazet@gmail.com>
>> Cc: "Doug Kehn" <rdkehn@yahoo.com>, netdev@vger.kernel.org
>> Date: Tuesday, March 15, 2011, 12:36 PM
>> On 03/15/2011 05:34 PM, Eric Dumazet
>> wrote:
>>> Le lundi 14 mars 2011 à 16:34 -0700, Doug Kehn a
>> écrit :
>>>> I'm running kernel version 2.6.36 on ARM XSCALE
>> (big-endian) and multicast over a multipoint GRE tunnel
>> isn't working. For my architecture, this worked on
>> 2.6.26.8. For x86, multicast over a multipoint GRE
>> tunnel worked with kernel version 2.6.31 but failed with
>> version 2.6.35. Multicast over a multipoint GRE tunnel
>> fails because ipgre_header() fails the 'if (iph->daddr)'
>> check and reutrns -t->hlen. ipgre_header() is being
>> called, from neigh_connected_output(), with a non-null
>> daddr; the contents of daddr is zero.
>
> I wasn't sure if the above patch was in addition too or in lieu of the partial revert of ipgre_header() suggested by Eric; both cases were attempted.
It was intended without the ipgre_header revert. The partial revert does
not differ from full revert related to my problem.
> The multicast scenario described does not work if only the arp_mc_map() patch is applied.
Uh. Right, the if test had wrong condition. The intention was to show
the idea that we create the multicast-to-multicast GRE NOARP mappings in
arp code where it should've been done in the first place (IMHO).
Could you try the below patch? That should work better. And the
ipgre_header should not be touched.
- Timo
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 7927589..8c24845 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -215,6 +215,13 @@ int arp_mc_map(__be32 addr, u8 *haddr, struct
net_device *dev, int dir)
case ARPHRD_INFINIBAND:
ip_ib_mc_map(addr, dev->broadcast, haddr);
return 0;
+ case ARPHRD_IPGRE:
+ if (dev->addr_len == 4 &&
+ get_unaligned_be32(dev->broadcast) != INADDR_ANY)
+ memcpy(haddr, dev->broadcast, dev->addr_len);
+ else
+ memcpy(haddr, &addr, sizeof(addr));
+ return 0;
default:
if (dir) {
memcpy(haddr, dev->broadcast, dev->addr_len);
^ permalink raw reply related
* Re: net-next-2.6 status...
From: Jiri Pirko @ 2011-03-16 6:50 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-wireless, netfilter-devel, eric.dumazet, linville,
kaber
In-Reply-To: <20110315.160124.104058374.davem@davemloft.net>
>Jiri, I know there is your patch set there, but I think you and Changli
>still need to go back and forth one more time wrt. orig_dev semantics.
>Since you have been posting this patch set for some time I'm still
>willing to apply it for this merge window, but please make haste and
>work out the remaining discussion. Thank you.
Dave, you can apply the rest of the series and leave only the first
patch (af_packet) out. There's no dependency. We will figure out things
around origdev later.
Thanks.
Jirka
^ permalink raw reply
* Re: [PATCHv2 1/9] at91: provide macb clks with "pclk" and "hclk" name
From: avictor.za @ 2011-03-16 6:53 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel, plagnioj, nicolas.ferre
In-Reply-To: <1300184096-13937-2-git-send-email-jamie@jamieiles.com>
hi,
On Tue, Mar 15, 2011 at 12:14 PM, Jamie Iles <jamie@jamieiles.com> wrote:
> The macb driver expects clocks with the names "pclk" and "hclk". We
> currently provide "macb_clk" but to fit in line with other
> architectures (namely AVR32), provide "pclk" and a fake "hclk".
There is no reference to a "pclk" or "hclk" in the AT91 architecture.
So to avoid possible confusion, maybe create two "fake" clocks both
parented to "macb_clk", and add a comment they're only for
compatibility with the AVR32.
Regards,
Andrew Victor
^ permalink raw reply
* Re: net-next-2.6 status...
From: David Miller @ 2011-03-16 7:02 UTC (permalink / raw)
To: jpirko
Cc: netdev, linux-wireless, netfilter-devel, eric.dumazet, linville,
kaber
In-Reply-To: <20110316065008.GA2780@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Wed, 16 Mar 2011 07:50:09 +0100
>>Jiri, I know there is your patch set there, but I think you and Changli
>>still need to go back and forth one more time wrt. orig_dev semantics.
>>Since you have been posting this patch set for some time I'm still
>>willing to apply it for this merge window, but please make haste and
>>work out the remaining discussion. Thank you.
>
> Dave, you can apply the rest of the series and leave only the first
> patch (af_packet) out. There's no dependency. We will figure out things
> around origdev later.
I was about to do that but I've found other problems.
You cannot make the modifications you make to linux/if.h, those
interface flags are visible to userspace.
^ permalink raw reply
* [PATCH 1/2] xfrm: Force a dst refcount before entering the xfrm type handlers
From: Steffen Klassert @ 2011-03-16 7:08 UTC (permalink / raw)
To: David Miller, Eric Dumazet; +Cc: netdev
Crypto requests might return asynchronous. In this case we leave
the rcu protected region, so force a refcount on the skb's
destination entry before we enter the xfrm type input/output
handlers.
This fixes a crash when a route is deleted whilst sending IPsec
data that is transformed by an asynchronous algorithm.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_input.c | 2 ++
net/xfrm/xfrm_output.c | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 872065c..341cd11 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -190,6 +190,8 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
XFRM_SKB_CB(skb)->seq.input.low = seq;
XFRM_SKB_CB(skb)->seq.input.hi = seq_hi;
+ skb_dst_force(skb);
+
nexthdr = x->type->input(x, skb);
if (nexthdr == -EINPROGRESS)
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 1aba03f..8f3f0ee 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -78,6 +78,8 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
spin_unlock_bh(&x->lock);
+ skb_dst_force(skb);
+
err = x->type->output(x, skb);
if (err == -EINPROGRESS)
goto out_exit;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] dst: Clone child entry in skb_dst_pop
From: Steffen Klassert @ 2011-03-16 7:09 UTC (permalink / raw)
To: David Miller, Eric Dumazet; +Cc: netdev
In-Reply-To: <20110316070828.GQ31402@secunet.com>
We clone the child entry in skb_dst_pop before we call
skb_dst_drop(). Otherwise we might kill the child right
before we return it to the caller.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/net/dst.h | 2 +-
net/xfrm/xfrm_output.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 2a46cba..75b95df 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -345,7 +345,7 @@ static inline void skb_tunnel_rx(struct sk_buff *skb, struct net_device *dev)
static inline struct dst_entry *skb_dst_pop(struct sk_buff *skb)
{
- struct dst_entry *child = skb_dst(skb)->child;
+ struct dst_entry *child = dst_clone(skb_dst(skb)->child);
skb_dst_drop(skb);
return child;
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 8f3f0ee..47bacd8 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -96,7 +96,7 @@ resume:
err = -EHOSTUNREACH;
goto error_nolock;
}
- skb_dst_set(skb, dst_clone(dst));
+ skb_dst_set(skb, dst);
x = dst->xfrm;
} while (x && !(x->outer_mode->flags & XFRM_MODE_FLAG_TUNNEL));
--
1.7.0.4
^ permalink raw reply related
* [PATCH] xfrm: Refcount destination entry on xfrm_lookup
From: Steffen Klassert @ 2011-03-16 7:12 UTC (permalink / raw)
To: David Miller, Timo Teräs; +Cc: netdev
We return a destination entry without refcount if a socket
policy is found in xfrm_lookup. This triggers a warning on
a negative refcount when freeeing this dst entry. So take
a refcount in this case to fix it.
This refcount was forgotten when xfrm changed to cache bundles
instead of policies for outgoing flows.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_policy.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 027e3c6..15792d8 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1804,6 +1804,8 @@ restart:
goto no_transform;
}
+ dst_hold(&xdst->u.dst);
+
spin_lock_bh(&xfrm_policy_sk_bundle_lock);
xdst->u.dst.next = xfrm_policy_sk_bundles;
xfrm_policy_sk_bundles = &xdst->u.dst;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] xfrm: Force a dst refcount before entering the xfrm type handlers
From: David Miller @ 2011-03-16 7:17 UTC (permalink / raw)
To: steffen.klassert; +Cc: eric.dumazet, netdev
In-Reply-To: <20110316070828.GQ31402@secunet.com>
Steffen we really need to find another way to fix these problems.
We already make way too many expensive atomic operations in these code
paths modified by your 3 patches, we should strive to not add new
ones.
Thanks.
^ permalink raw reply
* Winner
From: United Nations Trust Funds @ 2011-03-16 6:18 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: United Nation Form.docx --]
[-- Type: application/octet-stream, Size: 2763 bytes --]
^ 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