* Re: build breakage due to br_multicast.c referencing ipv6_dev_get_saddr()
From: Stephen Hemminger @ 2011-03-16 15:24 UTC (permalink / raw)
To: Jan Beulich; +Cc: linus.luessing, davem, bridge, netdev
In-Reply-To: <4D80BC5B0200007800036D85@vpn.id2.novell.com>
On Wed, 16 Mar 2011 12:34:19 +0000
"Jan Beulich" <JBeulich@novell.com> wrote:
> With BRIDGE=y and IPV6=m commit
> fe29ec41aaa51902aebd63658dfb04fe6fea8be5 ("bridge: Use IPv6
> link-local address for multicast listener queries") causes the build to
> break.
Rather than continue with the config games, lets just make the necessary
ipv6 pieces accessible.
--
^ permalink raw reply
* [PATCH] net: 2.6.38 Compile Failure e1000e Module
From: Randy Dunlap @ 2011-03-16 15:21 UTC (permalink / raw)
To: Frank Peters; +Cc: linux-kernel, netdev, davem
In-Reply-To: <20110316103318.19bd03e4.frank.peters@comcast.net>
Hi,
Please test this patch:
From: Randy Dunlap <randy.dunlap@oracle.com>
e1000e needs to select CRC32 for CRC support.
This patch fixes the build error:
ERROR: "crc32_le" [drivers/net/e1000e/e1000e.ko] undefined!
Reported-by: Frank Peters <frank.peters@comcast.net>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- lnx-2638.orig/drivers/net/Kconfig
+++ lnx-2638/drivers/net/Kconfig
@@ -2099,6 +2099,7 @@ config E1000
config E1000E
tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
depends on PCI && (!SPARC32 || BROKEN)
+ select CRC32
---help---
This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
ethernet family of adapters. For PCI or PCI-X e1000 adapters,
^ permalink raw reply
* Re: 2.6.38 Compile Failure e1000e Module
From: Eric Dumazet @ 2011-03-16 15:16 UTC (permalink / raw)
To: Frank Peters
Cc: linux-kernel, Bruce Allan, Jeff Kirsher, David Miller, netdev
In-Reply-To: <20110316103318.19bd03e4.frank.peters@comcast.net>
Le mercredi 16 mars 2011 à 10:33 -0400, Frank Peters a écrit :
> Hello,
>
> I cannot compile kernel 2.6.38. Apparently, there is a build failure
> with the e1000e module (ethernet driver). The brief error message is this:
>
> ERROR: "crc32_le" [drivers/net/e1000e/e1000e.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> My compiler is gcc-4.5.2 on a Gentoo x64 system. The kernel source
> is the stock source from kernel.org.
>
> Please CC to frank.peters (at) comcast.net.
Hi Franck
Probably coming from commit fe46f58fa61f02
(e1000e: use either_crc_le() rather than re-write it)
Could you try following patch ?
Thanks
[PATCH] e1000e: fix kconfig for crc32 dependency
ERROR: "crc32_le" [drivers/net/e1000e/e1000e.ko] undefined!
Reported-by: Frank Peters <frank.peters@comcast.net>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Bruce Allan <bruce.w.allan@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0382332..90d1d3c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2098,6 +2098,7 @@ config E1000
config E1000E
tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
+ select CRC32
depends on PCI && (!SPARC32 || BROKEN)
---help---
This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
^ permalink raw reply related
* Re: [PATCH V12 0/4] ptp: IEEE 1588 hardware clock support
From: Richard Cochran @ 2011-03-16 14:26 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Alan Cox, Arnd Bergmann,
Christoph Lameter, David Miller, John Stultz, Krzysztof Halasa,
Peter Zijlstra, Rodolfo Giometti, Thomas Gleixner,
Benjamin Herrenschmidt, Mike Frysinger, Paul Mackerras,
Russell King
In-Reply-To: <cover.1298878618.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
On Mon, Feb 28, 2011 at 08:57:03AM +0100, Richard Cochran wrote:
> * PHC Patch ChangeLog
> ** v12
> *** gianfar_ptp
> - fixed up device tree
> - inlined the header file
> - use platform_ calls instead of deprecated of_ calls
> - removed static global single instance
> - removed John Stultz's ack from this patch
@Thomas and John:
Can I get your acks on the remaining patches?
Can this be merged for 2.6.39?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH][v3] dev : fix mtu check when TSO is enabled
From: Daniel Lezcano @ 2011-03-16 13:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, eric.dumazet, kaber, nightnord, netdev
In-Reply-To: <20110315111756.64b5f4b1@nehalam>
On 03/15/2011 07:17 PM, Stephen Hemminger wrote:
> On Tue, 15 Mar 2011 14:57:40 +0100
> Daniel Lezcano<daniel.lezcano@free.fr> wrote:
>
>> On 03/15/2011 12:59 AM, David Miller wrote:
>>> From: Daniel Lezcano<daniel.lezcano@free.fr>
>>> Date: Mon, 14 Mar 2011 21:39:50 +0100
>>>
>>>> + len = dev->mtu + dev->hard_header_len + VLAN_HLEN;
>>>> + if (skb->len< len)
>>>> + return true;
>>> This is not a correct translation of the original test:
>>>
>>>> - (skb->len> (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
>>> You need to use "<=" in your version, which currently rejects all
>>> full sized frames. :-)
>> Right, thanks.
>>
>>>> +
>>>> + /* if TSO is enabled, we don't care about the length as the packet
>>>> + * could be forwarded without being segmented before
>>>> + */
>>>> + if (skb->dev&& skb->dev->features& NETIF_F_TSO)
>>>> + return true;
>>> I am trying to understand why you aren't simply checking also if this
>>> is a segmented frame? Perhaps skb_is_gso()&& device has NETIF_F_TSO
>>> set?
>> Maybe I am misunderstanding but the packet was forwarded by another device.
>> In our case from macvlan:
>>
>> macvlan_start_xmit
>> macvlan_queue_xmit
>> dest->forward
>> dev_skb_forward
>>
>> When we reached dev_skb_forward, that means we passed through
>> dev_hard_start_xmit where the packet was already segmented so we should
>> exit at the first test (skb->len< len). I don't see the point of adding
>> the skb_is_gso.
>> But maybe I am missing something, can you explain ?
> The macvlan device only has one downstream device (slave).
> If kernel is working properly, macvlan device should have a subset
> of the features of the underlying device
Right, dev->features = lowerdev->features & MACVLAN_FEATURES
> and macvlan device should
> have same MTU as underlying device.
Right,
...
if (!tb[IFLA_MTU])
dev->mtu = lowerdev->mtu;
...
> If the feature/MTU flags
> were correct, then the path calling macvlan should be respecting
> the MTU.
But if the TSO is enabled on the macvlan (inherited from eg e1000), the
packet won't be fragmented to the mtu size no ?
^ permalink raw reply
* build breakage due to br_multicast.c referencing ipv6_dev_get_saddr()
From: Jan Beulich @ 2011-03-16 12:34 UTC (permalink / raw)
To: linus.luessing; +Cc: davem, shemminger, bridge, netdev
With BRIDGE=y and IPV6=m commit
fe29ec41aaa51902aebd63658dfb04fe6fea8be5 ("bridge: Use IPv6
link-local address for multicast listener queries") causes the build to
break.
Similary, even if both are =m, but ipv6.ko got blacklisted (as is
happening in various SuSE distros when disabling IPv6), there's
a runtime problem since bridge.ko then won't load anymore due
to the missing symbol.
I note that infiniband appears to have had a similar problem
(didn't verify whether they have other dependencies on ipv6.ko),
resolved by an odd looking dependency of INFINIBAND_ADDR_TRANS
on !(INFINIBAND = y && IPV6 = m).
IP_VS also seems to have a similar issue.
Resolving this the infiniband way seems rather undesirable to me.
Instead I would think that this and any similar dependency should
get resolved via placing a stub pointer in net/ipv6/addrconf_core.c
(for this particular case), and having ipv6.ko set the pointer to the
actual implementation.
Otherwise, namely in distro kernels, pure IPv4 environments
pointlessly load the (huge) ipv6.ko just to satisfy symbol
references that would never get called.
One unrelated other observation with this change of yours:
daddr is an input argument to ipv6_dev_get_saddr(), yet
it gets initialized only after the function was called. Is that
really correct?
Thanks, Jan
^ permalink raw reply
* Re: [PATCH v6] xen network backend driver
From: Ian Campbell @ 2011-03-16 9:17 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
jeremy@goop.org, herbert@gondor.apana.org.au,
konrad.wilk@oracle.com, romieu@fr.zoreil.com,
bhutchings@solarflare.com, shemminger@vyatta.com,
mirqus@gmail.com, eric.dumazet@gmail.com
In-Reply-To: <20110315.193855.104049587.davem@davemloft.net>
On Wed, 2011-03-16 at 02:38 +0000, David Miller wrote:
> 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.
Awesome, thanks!
For the ML archives: the history which led to this patch was
2e820f58f7ad..db3afbafeffd which I have pushed to:
git://xenbits.xen.org/people/ianc/linux-2.6.git upstream/dom0/backend/netback-history
The base of the cleanup/upstreaming work (i.e. the commit which
corresponds to xen.git 072407c789a0) is
git://xenbits.xen.org/people/ianc/linux-2.6.git upstream/dom0/backend/netback-history-base
Ian.
^ 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
* 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: [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: [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: [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: 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
* 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: [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
* [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
* [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 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
* 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
* 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: 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: 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: 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: [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
* 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
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