* 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
* Re: net-next-2.6 status...
From: Jiri Pirko @ 2011-03-16 7:38 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-wireless, netfilter-devel, eric.dumazet, linville,
kaber
In-Reply-To: <20110316.000251.189704695.davem@davemloft.net>
Wed, Mar 16, 2011 at 08:02:51AM CET, davem@davemloft.net wrote:
>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.
What do you suggest? To remove unused flags and leave gaps there or to
not to remove the flags at all?
Thanks.
Jirka
^ permalink raw reply
* Re: [PATCH 1/2] xfrm: Force a dst refcount before entering the xfrm type handlers
From: Steffen Klassert @ 2011-03-16 7:43 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20110316.001732.112599674.davem@davemloft.net>
On Wed, Mar 16, 2011 at 12:17:32AM -0700, David Miller wrote:
>
> 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.
>
I know that it is exspensive, but we have to take a refcount if
the crypto layer returns asyncronous. Unfortunately it is too
late to take the refcount when the crypto layer notifies us about
that as the skb might be already gone.
The second patch just moves the refcount from xfrm_output_one
to skb_dst_pop. As xfrm_output_one is the only user of
skb_dst_pop, we take the refcont just a bit realier.
The third one makes the socket policy case consistent to the
case where we get the destination entry from the flow cache
where we take a reference. We can either return the dst entry
with or without a refcont in both cases. But we can't return
sometimes with and somtimes without a refcount.
I'd be happy to see all these refcounts gone too of course,
but that's way beyond a simple bug fix.
Steffen
^ permalink raw reply
* Re: [PATCH] xfrm: Refcount destination entry on xfrm_lookup
From: Timo Teräs @ 2011-03-16 8:03 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20110316071249.GS31402@secunet.com>
On 03/16/2011 09:12 AM, Steffen Klassert wrote:
> 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>
Acked-by: Timo Teräs <timo.teras@iki.fi>
Ok. This is one of the corner cases I did not test: having socket policy
something else than no action. I just didn't have the application ready
for it. Sorry about the bug. And good catch Steffen.
> ---
> 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;
^ permalink raw reply
* Re: [PATCHv2 1/9] at91: provide macb clks with "pclk" and "hclk" name
From: Russell King - ARM Linux @ 2011-03-16 8:38 UTC (permalink / raw)
To: avictor.za@gmail.com
Cc: Jamie Iles, netdev, plagnioj, linux-arm-kernel, nicolas.ferre
In-Reply-To: <AANLkTimwwUQGhncE7Att_9rAXhpT0n61HC4SW8ShSfAm@mail.gmail.com>
On Wed, Mar 16, 2011 at 08:53:47AM +0200, avictor.za@gmail.com wrote:
> 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.
It doesn't matter what's in the documentation.
There's no apb_pclk mentioned in the ARM platform documentation yet we
have such a clock in the bus-level code for primecell support. I'm sure
many of the other early primecell using platforms are also the same.
On OMAP1 there's no iclk yet OMAP drivers have had iclk and iclk is a
dummy no-op clock for OMAP1 for compatibility with OMAP2.
What matters more than conforming to documentation is keeping the drivers
in a clean and maintainable state without throwing lots of ifdefs into
them.
^ permalink raw reply
* Re: net-next-2.6 status...
From: Jiri Pirko @ 2011-03-16 8:40 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
linville-2XuSBdqkA4R54TAoqtyWWQ, kaber-dcUjhNyLwpNeoWH0uzbU5w
In-Reply-To: <20110316073803.GB2780-YzwxZg+R7et1/kRsl7OVgNvLeJWuRmrY@public.gmane.org>
Wed, Mar 16, 2011 at 08:38:03AM CET, jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org wrote:
>Wed, Mar 16, 2011 at 08:02:51AM CET, davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org wrote:
>>From: Jiri Pirko <jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>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.
>
>What do you suggest? To remove unused flags and leave gaps there or to
>not to remove the flags at all?
Well, the following comment:
<quote>
/* Private (from user) interface flags (netdevice->priv_flags). */
</quote>
leads me to think that these flags should not be used by userspace.
So maybe it may not be problem to change those values.
>
>Thanks.
>
>Jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: net-next-2.6 status...
From: Thomas Graf @ 2011-03-16 8:47 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, netdev, linux-wireless, netfilter-devel,
eric.dumazet, linville, kaber
In-Reply-To: <20110316084022.GA2845@psychotron.brq.redhat.com>
On Wed, Mar 16, 2011 at 09:40:23AM +0100, Jiri Pirko wrote:
> >What do you suggest? To remove unused flags and leave gaps there or to
> >not to remove the flags at all?
>
> Well, the following comment:
> <quote>
> /* Private (from user) interface flags (netdevice->priv_flags). */
> </quote>
> leads me to think that these flags should not be used by userspace.
> So maybe it may not be problem to change those values.
These flags should be moved to linux/netdevice.h
^ 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