* Re: [PATCH v2 2/2] ipv6 addrconf: don't cleanup route prefix for IFA_F_NOPREFIXROUTE
From: Hannes Frederic Sowa @ 2014-01-07 23:09 UTC (permalink / raw)
To: Thomas Haller; +Cc: Jiri Pirko, netdev, stephen, dcbw
In-Reply-To: <1389135262.2248.42.camel@weing>
On Tue, Jan 07, 2014 at 11:54:22PM +0100, Thomas Haller wrote:
> Hi,
>
>
> I think, the modify case is not that hairy and the patch does IMO the
> sensible thing:
>
> case 1) "change NOPREFIXROUTE -> !NOPREFIXROUTE":
> update or add prefix route (as before);;
> case 2) "change !NOPREFIXROUTE -> !NOPREFIXROUTE":
> update or add prefix route (as before);;
> case 3) "change NOPREFIXROUTE -> NOPREFIXROUTE":
> ;;
> case 4) "change !NOPREFIXROUTE -> NOPREFIXROUTE":
> cleanup prefix route;;
>
> where "cleanup" means the same as done in ipv6_del_addr(), as determined
> by check_cleanup_prefix_routes().
>
>
> Allowing modify with case 2) and 3) is important. But for case 4) (and
> possibly 1)), we could also fail with error. I tend to the scheme above
> though because it makes it easier for userspace and is likely what it
> wants.
>
>
>
> The problem of deleting a route created by somebody else is already
> present without this patch in ipv6_del_addr. This is indeed a bit shaky,
> but I guess it's good enough in practice. Do I understand correctly,
> that you think about to use the information from ifp->rt to ensure, that
> what we really cleanup the correct route? If that's what you intend, can
> you elaborate a bit on how to do that?
The ifp->rt thing, I thought of, does not work. It only holds the RTF_LOCAL
route (over loopback) which has nothing to do with the prefix route. We don't
have a link from ifp to the prefix route.
Currently I am fine with the semantics you described above but won't
have time to review them today. I'll do that tomorrow.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next V2 1/3] net: Add GRO support for UDP encapsulating protocols
From: Tom Herbert @ 2014-01-07 23:04 UTC (permalink / raw)
To: Or Gerlitz
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
Linux Netdev List, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CAJZOPZKecwB9S_+goH2SvcXS+03rYk=73eVNBUoEMz=M5484RA@mail.gmail.com>
On Tue, Jan 7, 2014 at 12:21 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
> On Tue, Jan 7, 2014 at 8:44 PM, Tom Herbert <therbert@google.com> wrote:
>> Or, thanks for posting the patches!
>>
>> We should also support the case where direct encapsulation is being
>> done, that is there is no encapsulation header after UDP and the
>> protocol of the encapsulated packet is inferred by the port number
>> (e.g. GRE/UDP, TCP/UDP, SCTP/UDP, etc.). This is probably an
>> additional field in net_offload struct for next protocol, a little
>> more API, and pretty trivial handlers in UDP code.
>
> The way I have set that follows your guideline under which the
> encapsulating method is derived from the udp destination port in the
> sense that the encapsulating protocol can do what they want in the
> gro_receive/complete handlers entry they plant per that udp port,
> isn't that generic enough?
Direct encapsulation of different protocols could be done using the
same callback functions. Somehow, we just need to pass the protocol
number (or more generally pass private data to the callbacks). In lieu
adding this to net_offload, we could just make the net_offload an
argument to the callbacks and use container_of to access a private
structure.
>
>
>>
>>
>> On Tue, Jan 7, 2014 at 7:29 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>>> Add GRO handlers for protocols that do UDP encapsulation, with the intent of
>>> being able to coalesce packets which encapsulate packets belonging to
>>> the same TCP session.
>>>
>>> For GRO purposes, the destination UDP port takes the role of the ether type
>>> field in the ethernet header or the next protocol in the IP header.
>>>
>>> The UDP GRO handler will only attempt to coalesce packets whose destination
>>> port is registered to have gro handler.
>>>
>>> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
>>> ---
>>> include/net/protocol.h | 6 ++++
>>> net/ipv4/protocol.c | 21 ++++++++++++++
>>> net/ipv4/udp_offload.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 96 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/net/protocol.h b/include/net/protocol.h
>>> index fbf7676..d776c08 100644
>>> --- a/include/net/protocol.h
>>> +++ b/include/net/protocol.h
>>> @@ -92,6 +92,10 @@ extern const struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS];
>>> extern const struct net_offload __rcu *inet_offloads[MAX_INET_PROTOS];
>>> extern const struct net_offload __rcu *inet6_offloads[MAX_INET_PROTOS];
>>>
>>> +
>>> +#define MAX_UDP_PORT (1 << 16)
>>> +extern const struct net_offload __rcu *udp_offloads[MAX_UDP_PORT];
>>> +
>>> #if IS_ENABLED(CONFIG_IPV6)
>>> extern const struct inet6_protocol __rcu *inet6_protos[MAX_INET_PROTOS];
>>> #endif
>>> @@ -102,6 +106,8 @@ int inet_add_offload(const struct net_offload *prot, unsigned char num);
>>> int inet_del_offload(const struct net_offload *prot, unsigned char num);
>>> void inet_register_protosw(struct inet_protosw *p);
>>> void inet_unregister_protosw(struct inet_protosw *p);
>>> +int udp_add_offload(const struct net_offload *prot, __be16 port);
>>> +int udp_del_offload(const struct net_offload *prot, __be16 port);
>>>
>>> #if IS_ENABLED(CONFIG_IPV6)
>>> int inet6_add_protocol(const struct inet6_protocol *prot, unsigned char num);
>>> diff --git a/net/ipv4/protocol.c b/net/ipv4/protocol.c
>>> index 46d6a1c..426eae5 100644
>>> --- a/net/ipv4/protocol.c
>>> +++ b/net/ipv4/protocol.c
>>> @@ -30,6 +30,7 @@
>>>
>>> const struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS] __read_mostly;
>>> const struct net_offload __rcu *inet_offloads[MAX_INET_PROTOS] __read_mostly;
>>> +const struct net_offload __rcu *udp_offloads[MAX_UDP_PORT] __read_mostly;
>>>
>>> int inet_add_protocol(const struct net_protocol *prot, unsigned char protocol)
>>> {
>>> @@ -51,6 +52,13 @@ int inet_add_offload(const struct net_offload *prot, unsigned char protocol)
>>> }
>>> EXPORT_SYMBOL(inet_add_offload);
>>>
>>> +int udp_add_offload(const struct net_offload *prot, __be16 port)
>>> +{
>>> + return !cmpxchg((const struct net_offload **)&udp_offloads[port],
>>> + NULL, prot) ? 0 : -1;
>>> +}
>>> +EXPORT_SYMBOL(udp_add_offload);
>>> +
>>> int inet_del_protocol(const struct net_protocol *prot, unsigned char protocol)
>>> {
>>> int ret;
>>> @@ -76,3 +84,16 @@ int inet_del_offload(const struct net_offload *prot, unsigned char protocol)
>>> return ret;
>>> }
>>> EXPORT_SYMBOL(inet_del_offload);
>>> +
>>> +int udp_del_offload(const struct net_offload *prot, __be16 port)
>>> +{
>>> + int ret;
>>> +
>>> + ret = (cmpxchg((const struct net_offload **)&udp_offloads[port],
>>> + prot, NULL) == prot) ? 0 : -1;
>>> +
>>> + synchronize_net();
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL(udp_del_offload);
>>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>>> index 79c62bd..0a8fdd6 100644
>>> --- a/net/ipv4/udp_offload.c
>>> +++ b/net/ipv4/udp_offload.c
>>> @@ -89,10 +89,79 @@ out:
>>> return segs;
>>> }
>>>
>>> +
>>> +static struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb)
>>> +{
>>> + const struct net_offload *ops;
>>> + struct sk_buff *p, **pp = NULL;
>>> + struct udphdr *uh, *uh2;
>>> + unsigned int hlen, off;
>>> + int flush = 1;
>>> +
>>> + off = skb_gro_offset(skb);
>>> + hlen = off + sizeof(*uh);
>>> + uh = skb_gro_header_fast(skb, off);
>>> + if (skb_gro_header_hard(skb, hlen)) {
>>> + uh = skb_gro_header_slow(skb, hlen, off);
>>> + if (unlikely(!uh))
>>> + goto out;
>>> + }
>>> +
>>> + rcu_read_lock();
>>> + ops = rcu_dereference(udp_offloads[uh->dest]);
>>> + if (!ops || !ops->callbacks.gro_receive)
>>> + goto out_unlock;
>>> +
>>> + flush = 0;
>>> +
>>> + for (p = *head; p; p = p->next) {
>>> + if (!NAPI_GRO_CB(p)->same_flow)
>>> + continue;
>>> +
>>> + uh2 = (struct udphdr *)(p->data + off);
>>> + if ((*(u32 *)&uh->source ^ *(u32 *)&uh2->source)) {
>>> + NAPI_GRO_CB(p)->same_flow = 0;
>>> + continue;
>>> + }
>>> + goto found;
>>> + }
>>> +
>>> +found:
>>> + skb_gro_pull(skb, sizeof(struct udphdr)); /* pull encapsulating udp header */
>>> + pp = ops->callbacks.gro_receive(head, skb);
>>> +
>>> +out_unlock:
>>> + rcu_read_unlock();
>>> +out:
>>> + NAPI_GRO_CB(skb)->flush |= flush;
>>> +
>>> + return pp;
>>> +}
>>> +
>>> +static int udp_gro_complete(struct sk_buff *skb, int nhoff)
>>> +{
>>> + const struct net_offload *ops;
>>> + __be16 newlen = htons(skb->len - nhoff);
>>> + struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
>>> + int err = -ENOSYS;
>>> +
>>> + uh->len = newlen;
>>> +
>>> + rcu_read_lock();
>>> + ops = rcu_dereference(udp_offloads[uh->dest]);
>>> + if (ops && ops->callbacks.gro_complete)
>>> + err = ops->callbacks.gro_complete(skb, nhoff + sizeof(struct udphdr));
>>> +
>>> + rcu_read_unlock();
>>> + return err;
>>> +}
>>> +
>>> static const struct net_offload udpv4_offload = {
>>> .callbacks = {
>>> .gso_send_check = udp4_ufo_send_check,
>>> .gso_segment = udp4_ufo_fragment,
>>> + .gro_receive = udp_gro_receive,
>>> + .gro_complete = udp_gro_complete,
>>> },
>>> };
>>>
>>> --
>>> 1.7.1
>>>
>>> --
>>> 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
>> --
>> 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 net-next v5] IPv6: add the option to use anycast addresses as source addresses in echo reply
From: Hannes Frederic Sowa @ 2014-01-07 23:01 UTC (permalink / raw)
To: Bill Fink
Cc: Francois-Xavier Le Bail, netdev, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki Yoshifuji,
Patrick McHardy
In-Reply-To: <20140107175507.fb543c70.billfink@mindspring.com>
On Tue, Jan 07, 2014 at 05:55:07PM -0500, Bill Fink wrote:
> On Tue, 7 Jan 2014, Francois-Xavier Le Bail wrote:
>
> > This change allows to follow a recommandation of RFC4942.
> >
> > - Add "anycast_src_echo_reply" sysctl to control the use of anycast addresses
> > as source addresses for ICMPv6 echo reply. This sysctl is false by default
> > to preserve existing behavior.
> > - Add inline check ipv6_anycast_destination().
> > - Use them in icmpv6_echo_reply().
> >
> > Reference:
> > RFC4942 - IPv6 Transition/Coexistence Security Considerations
> > (http://tools.ietf.org/html/rfc4942#section-2.1.6)
> >
> > 2.1.6. Anycast Traffic Identification and Security
> >
> > [...]
> > To avoid exposing knowledge about the internal structure of the
> > network, it is recommended that anycast servers now take advantage of
> > the ability to return responses with the anycast address as the
> > source address if possible.
> >
> > Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
> > ---
> > v4: update Subject and Documentation, this work also with anycast addresses
> > created via API, not just with Subnet-Router anycast addresses.
> >
> > v5: alternative way, replace ipv6_chk_acast_addr() test by
> > ipv6_anycast_destination() test.
>
> Why is ICMPV6 Echo Reply special? Can't the internal structure
> of the network be divined from other ICMPv6 responses such as
> Destination Unreachable, Time Exceeded (Hop Limit), and Parameter
> Problem.
No, here destination must match the source address so that the other side
handles accordingly when the icmp error is pushed up to the socket layer.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v5] IPv6: add the option to use anycast addresses as source addresses in echo reply
From: Bill Fink @ 2014-01-07 22:55 UTC (permalink / raw)
To: Francois-Xavier Le Bail
Cc: netdev, Hannes Frederic Sowa, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki Yoshifuji, Patrick McHardy
In-Reply-To: <1389103047-3380-1-git-send-email-fx.lebail@yahoo.com>
On Tue, 7 Jan 2014, Francois-Xavier Le Bail wrote:
> This change allows to follow a recommandation of RFC4942.
>
> - Add "anycast_src_echo_reply" sysctl to control the use of anycast addresses
> as source addresses for ICMPv6 echo reply. This sysctl is false by default
> to preserve existing behavior.
> - Add inline check ipv6_anycast_destination().
> - Use them in icmpv6_echo_reply().
>
> Reference:
> RFC4942 - IPv6 Transition/Coexistence Security Considerations
> (http://tools.ietf.org/html/rfc4942#section-2.1.6)
>
> 2.1.6. Anycast Traffic Identification and Security
>
> [...]
> To avoid exposing knowledge about the internal structure of the
> network, it is recommended that anycast servers now take advantage of
> the ability to return responses with the anycast address as the
> source address if possible.
>
> Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
> ---
> v4: update Subject and Documentation, this work also with anycast addresses
> created via API, not just with Subnet-Router anycast addresses.
>
> v5: alternative way, replace ipv6_chk_acast_addr() test by
> ipv6_anycast_destination() test.
Why is ICMPV6 Echo Reply special? Can't the internal structure
of the network be divined from other ICMPv6 responses such as
Destination Unreachable, Time Exceeded (Hop Limit), and Parameter
Problem.
-Bill
^ permalink raw reply
* Re: [PATCH net-next] net-gre-gro: Add GRE support to the GRO stack
From: Jerry Chu @ 2014-01-07 22:55 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Herbert Xu, Or Gerlitz, netdev@vger.kernel.org
In-Reply-To: <20140107.162251.778631453084913688.davem@davemloft.net>
On Tue, Jan 7, 2014 at 1:22 PM, David Miller <davem@davemloft.net> wrote:
> From: "H.K. Jerry Chu" <hkchu@google.com>
> Date: Tue, 7 Jan 2014 10:23:19 -0800
>
>> From: Jerry Chu <hkchu@google.com>
>>
>> This patch built on top of Commit 299603e8370a93dd5d8e8d800f0dff1ce2c53d36
>> ("net-gro: Prepare GRO stack for the upcoming tunneling support") to add
>> the support of the standard GRE (RFC1701/RFC2784/RFC2890) to the GRO
>> stack. It also serves as an example for supporting other encapsulation
>> protocols in the GRO stack in the future.
> ...
>> Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
>> Reviewed-by: Eric Dumazet <edumazet@google.com>
>
> Applied, thanks.
>
> We really need to talk about what we want to happen with these GRO
> offloads when GRE is not configured into the kernel.
>
> Right now, the GRO offloads simply won't happen.
>
I hope I've understood this correctly but with Eric's recent patch
"gre_offload: statically build GRE offloading support", gre_offload.o
is always present in the kernel regardless of the GRE configuration
option. And gre_offload.o is all that's needed for GRE-GRO to happen.
Jerry
^ permalink raw reply
* Re: [PATCH v2 2/2] ipv6 addrconf: don't cleanup route prefix for IFA_F_NOPREFIXROUTE
From: Thomas Haller @ 2014-01-07 22:54 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Jiri Pirko, netdev, stephen, dcbw
In-Reply-To: <20140107190148.GD30393@order.stressinduktion.org>
[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]
On Tue, 2014-01-07 at 20:01 +0100, Hannes Frederic Sowa wrote:
> On Tue, Jan 07, 2014 at 07:32:57PM +0100, Thomas Haller wrote:
> > On Tue, 2014-01-07 at 17:28 +0100, Hannes Frederic Sowa wrote:
> > > On Tue, Jan 07, 2014 at 03:39:13PM +0100, Thomas Haller wrote:
> > > > Also, when adding the NOPREFIXROUTE flag to an already existing address,
> > > > check if there there is a prefix that was likly added by the kernel
> > > > and delete it.
> > >
> > > Hmm, could you give a bit more details why you have done this? I find
> > > that a bit counterintuitive. Maybe it has a reason?
> > >
> >
> > You find the behavior or the commit message counterintuitive? Didn't you
> > suggest this behavior in your email from "7 Jan 2014 13:01:11 +0100"?
>
> I guess I was a bit confused, sorry. I think I confused the deleted and modify
> case. However:
>
> So we have the following changes on addresses:
>
> add is simple: just as in the first patch
>
> modify: is a bit hairy. To be extremly exact, we would have to recreate the
> route with proper metrics etc. so delete in any case and reinsert.
> I really dislike removing a route someone else might have inserted
> manually, and this is a likely scenario.
>
> Somehow I tend to just don't allow NOPREFIXROUTE on modify at all and
> just return a proper error value. What do you think? What would be the
> best behavior for NM?
>
> delete: if IFA_F_NOPREFIXROUTE is set, we don't care about removing a prefix
> route, it must be set by user space and should get cleaned up by user
> space
>
> >
> >
> > For v3 I will reword the commit message. How about the following:
> > ...
>
> If we want go with the current modify behavior this sounds good.
Hi,
I think, the modify case is not that hairy and the patch does IMO the
sensible thing:
case 1) "change NOPREFIXROUTE -> !NOPREFIXROUTE":
update or add prefix route (as before);;
case 2) "change !NOPREFIXROUTE -> !NOPREFIXROUTE":
update or add prefix route (as before);;
case 3) "change NOPREFIXROUTE -> NOPREFIXROUTE":
;;
case 4) "change !NOPREFIXROUTE -> NOPREFIXROUTE":
cleanup prefix route;;
where "cleanup" means the same as done in ipv6_del_addr(), as determined
by check_cleanup_prefix_routes().
Allowing modify with case 2) and 3) is important. But for case 4) (and
possibly 1)), we could also fail with error. I tend to the scheme above
though because it makes it easier for userspace and is likely what it
wants.
The problem of deleting a route created by somebody else is already
present without this patch in ipv6_del_addr. This is indeed a bit shaky,
but I guess it's good enough in practice. Do I understand correctly,
that you think about to use the information from ifp->rt to ensure, that
what we really cleanup the correct route? If that's what you intend, can
you elaborate a bit on how to do that?
ciao,
Thomas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/2] include/uapi/linux/xfrm.h: Pack struct xfrm_userpolicy_info
From: Sergei Shtylyov @ 2014-01-07 22:52 UTC (permalink / raw)
To: Fan Du, steffen.klassert; +Cc: davem, stephen, dev, netdev
In-Reply-To: <1389077339-12814-2-git-send-email-fan.du@windriver.com>
Hello.
On 07-01-2014 10:48, Fan Du wrote:
> Otherwise 64bits kernel has sizeof(struct xfrm_userpolicy_info) 168 bytes,
> while 32bits compiled iproute2 see the same structure as 164 bytes, which
> leading deficit xfrm policy, in turn broken IPsec connectivity.
> Fix this by packing the structure.
This will force byte-by-byte access to all members on some arches like ARM...
> Signed-off-by: Fan Du <fan.du@windriver.com>
> ---
> include/uapi/linux/xfrm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
> index a8cd6a4..470bfae 100644
> --- a/include/uapi/linux/xfrm.h
> +++ b/include/uapi/linux/xfrm.h
> @@ -405,7 +405,7 @@ struct xfrm_userpolicy_info {
> /* Automatically expand selector to include matching ICMP payloads. */
> #define XFRM_POLICY_ICMP 2
> __u8 share;
> -};
> +} __attribute__((packed));
Please use the __packed macro instead. I guess you haven't run checkpatch.pl?
WBR, Sergei
^ permalink raw reply
* [PATCH net-next] net: skbuff: const-ify casts in skb_queue_* functions
From: Daniel Borkmann @ 2014-01-07 22:23 UTC (permalink / raw)
To: davem; +Cc: netdev
We should const-ify comparisons on skb_queue_* inline helper
functions as their parameters are const as well, so lets not
drop that.
Suggested-by: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
include/linux/skbuff.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 956e11a..d97f2d0 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -827,7 +827,7 @@ static inline struct skb_shared_hwtstamps *skb_hwtstamps(struct sk_buff *skb)
*/
static inline int skb_queue_empty(const struct sk_buff_head *list)
{
- return list->next == (struct sk_buff *)list;
+ return list->next == (const struct sk_buff *) list;
}
/**
@@ -840,7 +840,7 @@ static inline int skb_queue_empty(const struct sk_buff_head *list)
static inline bool skb_queue_is_last(const struct sk_buff_head *list,
const struct sk_buff *skb)
{
- return skb->next == (struct sk_buff *)list;
+ return skb->next == (const struct sk_buff *) list;
}
/**
@@ -853,7 +853,7 @@ static inline bool skb_queue_is_last(const struct sk_buff_head *list,
static inline bool skb_queue_is_first(const struct sk_buff_head *list,
const struct sk_buff *skb)
{
- return skb->prev == (struct sk_buff *)list;
+ return skb->prev == (const struct sk_buff *) list;
}
/**
--
1.7.11.7
^ permalink raw reply related
* Re: Use of 'SIOCDEVPRIVATE' in ethernet drivers.
From: Giri Reddy @ 2014-01-07 22:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20140107.140520.1985936966889106257.davem@davemloft.net>
On 1/7/14 11:05 AM, David Miller wrote:
> From: Giri Reddy <giri.reddy@qlogic.com>
> Date: Tue, 7 Jan 2014 18:21:17 +0000
>
>> Are we still allowed to use 'SIOCDEVPRIVATE' in drivers if there the
>> deprecation efforts are on hold.
> To say that use of SIOCDEVPRIVATE is discouraged would be an
> understatement.
>
> Please create a generic ethtool based facility that other drivers in
> similar situations can use as well.
Thanks for the input. I will explore the 'ethtool' option. We will have
multiple control frames exchanged between user space and kernel for
every flash update operation, most of this will be proprietary stuff
that will get exchanged - I will explore how to provide a generic
interface for that.
Giri
>
________________________________
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* [PATCH net-next] net: xfrm: xfrm_policy: fix inline not at beginning of declaration
From: Daniel Borkmann @ 2014-01-07 22:20 UTC (permalink / raw)
To: davem; +Cc: netdev
Fix three warnings related to:
net/xfrm/xfrm_policy.c:1644:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
net/xfrm/xfrm_policy.c:1656:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
net/xfrm/xfrm_policy.c:1668:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
Just removing the inline keyword is sufficient as the compiler will
decide on its own about inlining or not.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/xfrm/xfrm_policy.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index a7487f3..b390446 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1641,20 +1641,20 @@ free_dst:
goto out;
}
-static int inline
-xfrm_dst_alloc_copy(void **target, const void *src, int size)
+static int xfrm_dst_alloc_copy(void **target, const void *src, int size)
{
if (!*target) {
*target = kmalloc(size, GFP_ATOMIC);
if (!*target)
return -ENOMEM;
}
+
memcpy(*target, src, size);
return 0;
}
-static int inline
-xfrm_dst_update_parent(struct dst_entry *dst, const struct xfrm_selector *sel)
+static int xfrm_dst_update_parent(struct dst_entry *dst,
+ const struct xfrm_selector *sel)
{
#ifdef CONFIG_XFRM_SUB_POLICY
struct xfrm_dst *xdst = (struct xfrm_dst *)dst;
@@ -1665,8 +1665,8 @@ xfrm_dst_update_parent(struct dst_entry *dst, const struct xfrm_selector *sel)
#endif
}
-static int inline
-xfrm_dst_update_origin(struct dst_entry *dst, const struct flowi *fl)
+static int xfrm_dst_update_origin(struct dst_entry *dst,
+ const struct flowi *fl)
{
#ifdef CONFIG_XFRM_SUB_POLICY
struct xfrm_dst *xdst = (struct xfrm_dst *)dst;
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH v3 3/3] ARM: shmobile: genmai: Enable r7s72100-ether
From: Sergei Shtylyov @ 2014-01-07 22:13 UTC (permalink / raw)
To: Simon Horman, netdev, linux-sh; +Cc: linux-arm-kernel, Magnus Damm
In-Reply-To: <1389061635-4083-4-git-send-email-horms+renesas@verge.net.au>
Hello.
On 07-01-2014 6:27, Simon Horman wrote:
You've removed RFC but still haven't signed off. :-)
> ---
> v2
> * As suggested by Magnus Damm and Sergei Shtylyov
> - r7s72100 ethernet is not gigabit so do not refer to it as such
> * As suggested by Sergei Shtylyov
> - set no_ether_link as there is no LINK signal documented
> in the manual
I'm OK with the patch, you can add my Acked-by.
WBR, Sergei
^ permalink raw reply
* [PATCH 2/2] netfilter: only warn once on wrong seqadj usage
From: Pablo Neira Ayuso @ 2014-01-07 22:13 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1389132819-9697-1-git-send-email-pablo@netfilter.org>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Avoid potentially spamming the kernel log with WARN splash messages
when catching wrong usage of seqadj, by simply using WARN_ONCE.
This is a followup to commit db12cf274353 (netfilter: WARN about
wrong usage of sequence number adjustments)
Suggested-by: Flavio Leitner <fbl@redhat.com>
Suggested-by: Daniel Borkmann <dborkman@redhat.com>
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_seqadj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_seqadj.c b/net/netfilter/nf_conntrack_seqadj.c
index b2d38da..f6e2ae9 100644
--- a/net/netfilter/nf_conntrack_seqadj.c
+++ b/net/netfilter/nf_conntrack_seqadj.c
@@ -37,7 +37,7 @@ int nf_ct_seqadj_set(struct nf_conn *ct, enum ip_conntrack_info ctinfo,
return 0;
if (unlikely(!seqadj)) {
- WARN(1, "Wrong seqadj usage, missing nfct_seqadj_ext_add()\n");
+ WARN_ONCE(1, "Missing nfct_seqadj_ext_add() setup call\n");
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] netfilter: nf_nat: fix access to uninitialized buffer in IRC NAT helper
From: Pablo Neira Ayuso @ 2014-01-07 22:13 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1389132819-9697-1-git-send-email-pablo@netfilter.org>
From: Daniel Borkmann <dborkman@redhat.com>
Commit 5901b6be885e attempted to introduce IPv6 support into
IRC NAT helper. By doing so, the following code seemed to be removed
by accident:
ip = ntohl(exp->master->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip);
sprintf(buffer, "%u %u", ip, port);
pr_debug("nf_nat_irc: inserting '%s' == %pI4, port %u\n", buffer, &ip, port);
This leads to the fact that buffer[] was left uninitialized and
contained some stack value. When we call nf_nat_mangle_tcp_packet(),
we call strlen(buffer) on excatly this uninitialized buffer. If we
are unlucky and the skb has enough tailroom, we overwrite resp. leak
contents with values that sit on our stack into the packet and send
that out to the receiver.
Since the rather informal DCC spec [1] does not seem to specify
IPv6 support right now, we log such occurences so that admins can
act accordingly, and drop the packet. I've looked into XChat source,
and IPv6 is not supported there: addresses are in u32 and print
via %u format string.
Therefore, restore old behaviour as in IPv4, use snprintf(). The
IRC helper does not support IPv6 by now. By this, we can safely use
strlen(buffer) in nf_nat_mangle_tcp_packet() and prevent a buffer
overflow. Also simplify some code as we now have ct variable anyway.
[1] http://www.irchelp.org/irchelp/rfc/ctcpspec.html
Fixes: 5901b6be885e ("netfilter: nf_nat: support IPv6 in IRC NAT helper")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Harald Welte <laforge@gnumonks.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_nat_irc.c | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/nf_nat_irc.c b/net/netfilter/nf_nat_irc.c
index f02b360..1fb2258 100644
--- a/net/netfilter/nf_nat_irc.c
+++ b/net/netfilter/nf_nat_irc.c
@@ -34,10 +34,14 @@ static unsigned int help(struct sk_buff *skb,
struct nf_conntrack_expect *exp)
{
char buffer[sizeof("4294967296 65635")];
+ struct nf_conn *ct = exp->master;
+ union nf_inet_addr newaddr;
u_int16_t port;
unsigned int ret;
/* Reply comes from server. */
+ newaddr = ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3;
+
exp->saved_proto.tcp.port = exp->tuple.dst.u.tcp.port;
exp->dir = IP_CT_DIR_REPLY;
exp->expectfn = nf_nat_follow_master;
@@ -57,17 +61,35 @@ static unsigned int help(struct sk_buff *skb,
}
if (port == 0) {
- nf_ct_helper_log(skb, exp->master, "all ports in use");
+ nf_ct_helper_log(skb, ct, "all ports in use");
return NF_DROP;
}
- ret = nf_nat_mangle_tcp_packet(skb, exp->master, ctinfo,
- protoff, matchoff, matchlen, buffer,
- strlen(buffer));
+ /* strlen("\1DCC CHAT chat AAAAAAAA P\1\n")=27
+ * strlen("\1DCC SCHAT chat AAAAAAAA P\1\n")=28
+ * strlen("\1DCC SEND F AAAAAAAA P S\1\n")=26
+ * strlen("\1DCC MOVE F AAAAAAAA P S\1\n")=26
+ * strlen("\1DCC TSEND F AAAAAAAA P S\1\n")=27
+ *
+ * AAAAAAAAA: bound addr (1.0.0.0==16777216, min 8 digits,
+ * 255.255.255.255==4294967296, 10 digits)
+ * P: bound port (min 1 d, max 5d (65635))
+ * F: filename (min 1 d )
+ * S: size (min 1 d )
+ * 0x01, \n: terminators
+ */
+ /* AAA = "us", ie. where server normally talks to. */
+ snprintf(buffer, sizeof(buffer), "%u %u", ntohl(newaddr.ip), port);
+ pr_debug("nf_nat_irc: inserting '%s' == %pI4, port %u\n",
+ buffer, &newaddr.ip, port);
+
+ ret = nf_nat_mangle_tcp_packet(skb, ct, ctinfo, protoff, matchoff,
+ matchlen, buffer, strlen(buffer));
if (ret != NF_ACCEPT) {
- nf_ct_helper_log(skb, exp->master, "cannot mangle packet");
+ nf_ct_helper_log(skb, ct, "cannot mangle packet");
nf_ct_unexpect_related(exp);
}
+
return ret;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] netfilter fixes for net
From: Pablo Neira Ayuso @ 2014-01-07 22:13 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains two patches:
* fix the IRC NAT helper which was broken when adding (incomplete) IPv6
support, from Daniel Borkmann.
* Refine the previous bugtrap that Jesper added to catch problems for the
usage of the sequence adjustment extension in IPVs in Dec 16th, it may
spam messages in case of finding a real bug.
I know it's fairly late, so please let me know if you prefer that I pass
you these via net-next.
Thanks!
----------------------------------------------------------------
The following changes since commit f35f76ee76df008131bbe01a2297de0c55ee2297:
xen-netback: Include header for vmalloc (2014-01-05 20:34:36 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git master
for you to fetch changes up to f2661adc0c134d890d84c32d7cb54a2b4d1f0a5f:
netfilter: only warn once on wrong seqadj usage (2014-01-06 14:23:17 +0100)
----------------------------------------------------------------
Daniel Borkmann (1):
netfilter: nf_nat: fix access to uninitialized buffer in IRC NAT helper
Jesper Dangaard Brouer (1):
netfilter: only warn once on wrong seqadj usage
net/netfilter/nf_conntrack_seqadj.c | 2 +-
net/netfilter/nf_nat_irc.c | 32 +++++++++++++++++++++++++++-----
2 files changed, 28 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next V2 1/3] net: Add GRO support for UDP encapsulating protocols
From: Jerry Chu @ 2014-01-07 22:11 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric Dumazet, Or Gerlitz, Eric Dumazet, Herbert Xu,
netdev@vger.kernel.org, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CAJZOPZ+b87xF8m7cgTfwH1OqA3k012YFVy0ySJasMuR6x38Czw@mail.gmail.com>
On Tue, Jan 7, 2014 at 12:37 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
> On Tue, Jan 7, 2014 at 10:32 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Tue, 2014-01-07 at 22:19 +0200, Or Gerlitz wrote:
>>> On Tue, Jan 7, 2014 at 6:33 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> > On Tue, 2014-01-07 at 17:29 +0200, Or Gerlitz wrote:
>>> >>
>>> >> +
>>> >> +#define MAX_UDP_PORT (1 << 16)
>>> >> +extern const struct net_offload __rcu *udp_offloads[MAX_UDP_PORT];
>>> >
>>> > Thats 512 KB of memory.
>>> > This will greatly impact forwarding performance of UDP packets with
>>> > random ports, and will increase kernel memory size for embedded devices.
>>>
>>> Re forwarding, are you referring to the case where the forwarded
>>> packets are encapsulated? packets which are not encapusalted will be
>>> flushed in the gro receive handler (this went out by mistake in V2 but
>>> exists in V1) if skb->encapsulation isn't set.
>>>
>>
>> How do you know encapsulation must be tried for a given incoming
>> packet ? NIC do not magically sets skb->encapsulation I think...
>
> So here's the thing, per my understanding we want to GRO only received
> **encapsulated** packets whose checksum status is != CHECKSUM_NONE
What's wrong with GRO'ing pkts whose csum == CHECKSUM_NONE?
Also "udp_offload" is a little misleading - you are not trying to GRO UDP
pkts where UDP is the real transport. You are only trying to GRO UDP
encapped TCP pkts.
Jerry
> which means the NIC has some support for doing RX checksum of
> encapsulated packets. Per the current convension, in that case the NIC
> RX code has to set skb->encapsulation see 6a674e9c75b17 "net: Add
> support for hardware-offloaded encapsulation" this convension is
> implemented in the current drivers that have HW offloads for
> encapsulated packets (bnx2x, i40e and mlx4)
>
>
>>
>> You access udp_offloads[XXX], with XXX being in 0..65535 range, right ?
>>
>>
>>> As for encapsulated packets, when you say random ports, are you
>>> referring to a router which has multiple udp encapsulating protocols
>>> where each uses different udp port? for this case and also to reduce
>>> the memory footprint, we can use lookup in a list as done for the L2
>>> protocols gro handlers in the list_for_each loop of dev_gro_receive(),
>>> makes sense?
>>
>> I am speaking of a normal router, running linux kernel, and having
>> GRO/TSO enabled.
>>
>> If each incoming UDP packet has to access one extra cache line in a
>> 512KB array, its likely to be an extra cache line miss, if UDP dest
>> port is mostly random (compared to ports used by very recent UDP
>> packets)
>>
>>
>>
> --
> 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
* [PATCH net-next 4/4] tipc: make link start event synchronous
From: Jon Maloy @ 2014-01-07 22:02 UTC (permalink / raw)
To: davem; +Cc: Jon Maloy, netdev, tipc-discussion
In-Reply-To: <1389132164-32451-1-git-send-email-jon.maloy@ericsson.com>
When a link is created we delay the start event by launching it
to be executed later in a tasklet. As we hold all the
necessary locks at the moment of creation, and there is no risk
of deadlock or contention, this delay serves no purpose in the
current code.
We remove this obsolete indirection step, and the associated function
link_start(). At the same time, we rename the function tipc_link_stop()
to the more appropriate tipc_link_purge_queues().
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/bcast.c | 2 +-
net/tipc/link.c | 16 +++++-----------
net/tipc/link.h | 2 +-
3 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 4c2a80b..bf860d9 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -794,7 +794,7 @@ void tipc_bclink_init(void)
void tipc_bclink_stop(void)
{
spin_lock_bh(&bc_lock);
- tipc_link_stop(bcl);
+ tipc_link_purge_queues(bcl);
spin_unlock_bh(&bc_lock);
memset(bclink, 0, sizeof(*bclink));
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 9fb0f6b..471973f 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -87,7 +87,6 @@ static int link_send_sections_long(struct tipc_port *sender,
static void link_state_event(struct tipc_link *l_ptr, u32 event);
static void link_reset_statistics(struct tipc_link *l_ptr);
static void link_print(struct tipc_link *l_ptr, const char *str);
-static void link_start(struct tipc_link *l_ptr);
static int link_send_long_buf(struct tipc_link *l_ptr, struct sk_buff *buf);
static void tipc_link_send_sync(struct tipc_link *l);
static void tipc_link_recv_sync(struct tipc_node *n, struct sk_buff *buf);
@@ -281,7 +280,8 @@ struct tipc_link *tipc_link_create(struct tipc_node *n_ptr,
k_init_timer(&l_ptr->timer, (Handler)link_timeout,
(unsigned long)l_ptr);
list_add_tail(&l_ptr->link_list, &b_ptr->links);
- tipc_k_signal((Handler)link_start, (unsigned long)l_ptr);
+
+ link_state_event(l_ptr, STARTING_EVT);
return l_ptr;
}
@@ -306,19 +306,13 @@ void tipc_link_delete(struct tipc_link *l_ptr)
tipc_node_lock(l_ptr->owner);
tipc_link_reset(l_ptr);
tipc_node_detach_link(l_ptr->owner, l_ptr);
- tipc_link_stop(l_ptr);
+ tipc_link_purge_queues(l_ptr);
list_del_init(&l_ptr->link_list);
tipc_node_unlock(l_ptr->owner);
k_term_timer(&l_ptr->timer);
kfree(l_ptr);
}
-static void link_start(struct tipc_link *l_ptr)
-{
- tipc_node_lock(l_ptr->owner);
- link_state_event(l_ptr, STARTING_EVT);
- tipc_node_unlock(l_ptr->owner);
-}
/**
* link_schedule_port - schedule port for deferred sending
@@ -404,10 +398,10 @@ void tipc_link_reset_fragments(struct tipc_link *l_ptr)
}
/**
- * tipc_link_stop - purge all inbound and outbound messages associated with link
+ * tipc_link_purge_queues - purge all pkt queues associated with link
* @l_ptr: pointer to link
*/
-void tipc_link_stop(struct tipc_link *l_ptr)
+void tipc_link_purge_queues(struct tipc_link *l_ptr)
{
kfree_skb_list(l_ptr->oldest_deferred_in);
kfree_skb_list(l_ptr->first_out);
diff --git a/net/tipc/link.h b/net/tipc/link.h
index 89ab89b..3b6aa65 100644
--- a/net/tipc/link.h
+++ b/net/tipc/link.h
@@ -222,7 +222,7 @@ void tipc_link_dup_send_queue(struct tipc_link *l_ptr,
void tipc_link_reset_fragments(struct tipc_link *l_ptr);
int tipc_link_is_up(struct tipc_link *l_ptr);
int tipc_link_is_active(struct tipc_link *l_ptr);
-void tipc_link_stop(struct tipc_link *l_ptr);
+void tipc_link_purge_queues(struct tipc_link *l_ptr);
struct sk_buff *tipc_link_cmd_config(const void *req_tlv_area,
int req_tlv_space,
u16 cmd);
--
1.7.9.5
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 3/4] tipc: introduce new spinlock to protect struct link_req
From: Jon Maloy @ 2014-01-07 22:02 UTC (permalink / raw)
To: davem; +Cc: Jon Maloy, netdev, tipc-discussion
In-Reply-To: <1389132164-32451-1-git-send-email-jon.maloy@ericsson.com>
From: Ying Xue <ying.xue@windriver.com>
Currently, only 'bearer_lock' is used to protect struct link_req in
the function disc_timeout(). This is unsafe, since the member fields
'num_nodes' and 'timer_intv' might be accessed by below three different
threads simultaneously, none of them grabbing bearer_lock in the
critical region:
link_activate()
tipc_bearer_add_dest()
tipc_disc_add_dest()
req->num_nodes++;
tipc_link_reset()
tipc_bearer_remove_dest()
tipc_disc_remove_dest()
req->num_nodes--
disc_update()
read req->num_nodes
write req->timer_intv
disc_timeout()
read req->num_nodes
read/write req->timer_intv
Without lock protection, the only symptom of a race is that discovery
messages occasionally may not be sent out. This is not fatal, since such
messages are best-effort anyway. On the other hand, since discovery
messages are not time critical, adding a protecting lock brings no
serious overhead either. So we add a new, dedicated spinlock in
order to guarantee absolute data consistency in link_req objects.
This also helps reduce the overall role of the bearer_lock, which
we want to remove completely in a later commit series.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/discover.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index bc849f1..412ff41 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
@@ -50,6 +50,7 @@
* @dest: destination address for request messages
* @domain: network domain to which links can be established
* @num_nodes: number of nodes currently discovered (i.e. with an active link)
+ * @lock: spinlock for controlling access to requests
* @buf: request message to be (repeatedly) sent
* @timer: timer governing period between requests
* @timer_intv: current interval between requests (in ms)
@@ -59,6 +60,7 @@ struct tipc_link_req {
struct tipc_media_addr dest;
u32 domain;
int num_nodes;
+ spinlock_t lock;
struct sk_buff *buf;
struct timer_list timer;
unsigned int timer_intv;
@@ -274,7 +276,9 @@ static void disc_update(struct tipc_link_req *req)
*/
void tipc_disc_add_dest(struct tipc_link_req *req)
{
+ spin_lock_bh(&req->lock);
req->num_nodes++;
+ spin_unlock_bh(&req->lock);
}
/**
@@ -283,8 +287,10 @@ void tipc_disc_add_dest(struct tipc_link_req *req)
*/
void tipc_disc_remove_dest(struct tipc_link_req *req)
{
+ spin_lock_bh(&req->lock);
req->num_nodes--;
disc_update(req);
+ spin_unlock_bh(&req->lock);
}
/**
@@ -297,7 +303,7 @@ static void disc_timeout(struct tipc_link_req *req)
{
int max_delay;
- spin_lock_bh(&req->bearer->lock);
+ spin_lock_bh(&req->lock);
/* Stop searching if only desired node has been found */
if (tipc_node(req->domain) && req->num_nodes) {
@@ -325,7 +331,7 @@ static void disc_timeout(struct tipc_link_req *req)
k_start_timer(&req->timer, req->timer_intv);
exit:
- spin_unlock_bh(&req->bearer->lock);
+ spin_unlock_bh(&req->lock);
}
/**
@@ -356,6 +362,7 @@ int tipc_disc_create(struct tipc_bearer *b_ptr, struct tipc_media_addr *dest,
req->domain = dest_domain;
req->num_nodes = 0;
req->timer_intv = TIPC_LINK_REQ_INIT;
+ spin_lock_init(&req->lock);
k_init_timer(&req->timer, (Handler)disc_timeout, (unsigned long)req);
k_start_timer(&req->timer, req->timer_intv);
b_ptr->link_req = req;
--
1.7.9.5
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 2/4] tipc: remove 'has_redundant_link' flag from STATE link protocol messages
From: Jon Maloy @ 2014-01-07 22:02 UTC (permalink / raw)
To: davem; +Cc: Jon Maloy, netdev, tipc-discussion
In-Reply-To: <1389132164-32451-1-git-send-email-jon.maloy@ericsson.com>
The flag 'has_redundant_link' is defined only in RESET and ACTIVATE
protocol messages. Due to an ambiguity in the protocol specification it
is currently also transferred in STATE messages. Its value is used to
initialize a link state variable, 'permit_changeover', which is used
to inhibit futile link failover attempts when it is known that the
peer node has no working links at the moment, although the local node
may still think it has one.
The fact that 'has_redundant_link' incorrectly is read from STATE
messages has the effect that 'permit_changeover' sometimes gets a wrong
value, and permanently blocks any links from being re-established. Such
failures can only occur in in dual-link systems, and are extremely rare.
This bug seems to have always been present in the code.
Furthermore, since commit b4b5610223f17790419b03eaa962b0e3ecf930d7
("tipc: Ensure both nodes recognize loss of contact between them"),
the 'permit_changeover' field serves no purpose any more. The task of
enforcing 'lost contact' cycles at both peer endpoints is now taken
by a new mechanism, using the flags WAIT_NODE_DOWN and WAIT_PEER_DOWN
in struct tipc_node to abort unnecessary failover attempts.
We therefore remove the 'has_redundant_link' flag from STATE messages,
as well as the now redundant 'permit_changeover' variable.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/link.c | 10 +---------
net/tipc/node.h | 2 --
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index bb48b96..9fb0f6b 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -438,8 +438,7 @@ void tipc_link_reset(struct tipc_link *l_ptr)
tipc_node_link_down(l_ptr->owner, l_ptr);
tipc_bearer_remove_dest(l_ptr->b_ptr, l_ptr->addr);
- if (was_active_link && tipc_node_active_links(l_ptr->owner) &&
- l_ptr->owner->permit_changeover) {
+ if (was_active_link && tipc_node_active_links(l_ptr->owner)) {
l_ptr->reset_checkpoint = checkpoint;
l_ptr->exp_msg_count = START_CHANGEOVER;
}
@@ -1838,8 +1837,6 @@ static void link_recv_proto_msg(struct tipc_link *l_ptr, struct sk_buff *buf)
if (tipc_own_addr > msg_prevnode(msg))
l_ptr->b_ptr->net_plane = msg_net_plane(msg);
- l_ptr->owner->permit_changeover = msg_redundant_link(msg);
-
switch (msg_type(msg)) {
case RESET_MSG:
@@ -2001,11 +1998,6 @@ void tipc_link_failover_send_queue(struct tipc_link *l_ptr)
if (!tunnel)
return;
- if (!l_ptr->owner->permit_changeover) {
- pr_warn("%speer did not permit changeover\n", link_co_err);
- return;
- }
-
tipc_msg_init(&tunnel_hdr, CHANGEOVER_PROTOCOL,
ORIGINAL_MSG, INT_H_SIZE, l_ptr->addr);
msg_set_bearer_id(&tunnel_hdr, l_ptr->peer_bearer_id);
diff --git a/net/tipc/node.h b/net/tipc/node.h
index d4bb654..63e2e8e 100644
--- a/net/tipc/node.h
+++ b/net/tipc/node.h
@@ -64,7 +64,6 @@
* @working_links: number of working links to node (both active and standby)
* @block_setup: bit mask of conditions preventing link establishment to node
* @link_cnt: number of links to node
- * @permit_changeover: non-zero if node has redundant links to this system
* @signature: node instance identifier
* @bclink: broadcast-related info
* @acked: sequence # of last outbound b'cast message acknowledged by node
@@ -89,7 +88,6 @@ struct tipc_node {
int link_cnt;
int working_links;
int block_setup;
- int permit_changeover;
u32 signature;
struct {
u32 acked;
--
1.7.9.5
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 1/4] tipc: rename functions related to link failover and improve comments
From: Jon Maloy @ 2014-01-07 22:02 UTC (permalink / raw)
To: davem; +Cc: Jon Maloy, netdev, tipc-discussion
In-Reply-To: <1389132164-32451-1-git-send-email-jon.maloy@ericsson.com>
The functionality related to link addition and failover is unnecessarily
hard to understand and maintain. We try to improve this by renaming
some of the functions, at the same time adding or improving the
explanatory comments around them. Names such as "tipc_rcv()" etc. also
align better with what is used in other networking components.
The changes in this commit are purely cosmetic, no functional changes
are made.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/bearer.c | 2 +-
net/tipc/bearer.h | 3 +--
net/tipc/link.c | 70 ++++++++++++++++++++++++++++++++---------------------
net/tipc/link.h | 15 ++++++++----
net/tipc/node.c | 4 +--
5 files changed, 56 insertions(+), 38 deletions(-)
diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 07ed5cc..2d456ab 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -541,7 +541,7 @@ static int tipc_l2_rcv_msg(struct sk_buff *buf, struct net_device *dev,
if (likely(b_ptr)) {
if (likely(buf->pkt_type <= PACKET_BROADCAST)) {
buf->next = NULL;
- tipc_recv_msg(buf, b_ptr);
+ tipc_rcv(buf, b_ptr);
rcu_read_unlock();
return NET_RX_SUCCESS;
}
diff --git a/net/tipc/bearer.h b/net/tipc/bearer.h
index 410efb1..4f5db9a 100644
--- a/net/tipc/bearer.h
+++ b/net/tipc/bearer.h
@@ -161,8 +161,7 @@ extern struct tipc_bearer tipc_bearers[];
* TIPC routines available to supported media types
*/
-void tipc_recv_msg(struct sk_buff *buf, struct tipc_bearer *tb_ptr);
-
+void tipc_rcv(struct sk_buff *buf, struct tipc_bearer *tb_ptr);
int tipc_enable_bearer(const char *bearer_name, u32 disc_domain, u32 priority);
int tipc_disable_bearer(const char *name);
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 131a32a..bb48b96 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1,7 +1,7 @@
/*
* net/tipc/link.c: TIPC link code
*
- * Copyright (c) 1996-2007, 2012, Ericsson AB
+ * Copyright (c) 1996-2007, 2012-2014, Ericsson AB
* Copyright (c) 2004-2007, 2010-2013, Wind River Systems
* All rights reserved.
*
@@ -78,8 +78,8 @@ static const char *link_unk_evt = "Unknown link event ";
static void link_handle_out_of_seq_msg(struct tipc_link *l_ptr,
struct sk_buff *buf);
static void link_recv_proto_msg(struct tipc_link *l_ptr, struct sk_buff *buf);
-static int link_recv_changeover_msg(struct tipc_link **l_ptr,
- struct sk_buff **buf);
+static int tipc_link_tunnel_rcv(struct tipc_link **l_ptr,
+ struct sk_buff **buf);
static void link_set_supervision_props(struct tipc_link *l_ptr, u32 tolerance);
static int link_send_sections_long(struct tipc_port *sender,
struct iovec const *msg_sect,
@@ -278,7 +278,8 @@ struct tipc_link *tipc_link_create(struct tipc_node *n_ptr,
tipc_node_attach_link(n_ptr, l_ptr);
- k_init_timer(&l_ptr->timer, (Handler)link_timeout, (unsigned long)l_ptr);
+ k_init_timer(&l_ptr->timer, (Handler)link_timeout,
+ (unsigned long)l_ptr);
list_add_tail(&l_ptr->link_list, &b_ptr->links);
tipc_k_signal((Handler)link_start, (unsigned long)l_ptr);
@@ -1422,14 +1423,14 @@ static int link_recv_buf_validate(struct sk_buff *buf)
}
/**
- * tipc_recv_msg - process TIPC messages arriving from off-node
+ * tipc_rcv - process TIPC packets/messages arriving from off-node
* @head: pointer to message buffer chain
* @tb_ptr: pointer to bearer message arrived on
*
* Invoked with no locks held. Bearer pointer must point to a valid bearer
* structure (i.e. cannot be NULL), but bearer can be inactive.
*/
-void tipc_recv_msg(struct sk_buff *head, struct tipc_bearer *b_ptr)
+void tipc_rcv(struct sk_buff *head, struct tipc_bearer *b_ptr)
{
read_lock_bh(&tipc_net_lock);
while (head) {
@@ -1603,7 +1604,7 @@ deliver:
continue;
case CHANGEOVER_PROTOCOL:
type = msg_type(msg);
- if (link_recv_changeover_msg(&l_ptr, &buf)) {
+ if (tipc_link_tunnel_rcv(&l_ptr, &buf)) {
msg = buf_msg(buf);
seq_no = msg_seqno(msg);
if (type == ORIGINAL_MSG)
@@ -1954,13 +1955,13 @@ exit:
}
-/*
- * tipc_link_tunnel(): Send one message via a link belonging to
- * another bearer. Owner node is locked.
+/* tipc_link_tunnel_xmit(): Tunnel one packet via a link belonging to
+ * a different bearer. Owner node is locked.
*/
-static void tipc_link_tunnel(struct tipc_link *l_ptr,
- struct tipc_msg *tunnel_hdr, struct tipc_msg *msg,
- u32 selector)
+static void tipc_link_tunnel_xmit(struct tipc_link *l_ptr,
+ struct tipc_msg *tunnel_hdr,
+ struct tipc_msg *msg,
+ u32 selector)
{
struct tipc_link *tunnel;
struct sk_buff *buf;
@@ -1983,12 +1984,13 @@ static void tipc_link_tunnel(struct tipc_link *l_ptr,
}
-
-/*
- * changeover(): Send whole message queue via the remaining link
- * Owner node is locked.
+/* tipc_link_failover_send_queue(): A link has gone down, but a second
+ * link is still active. We can do failover. Tunnel the failing link's
+ * whole send queue via the remaining link. This way, we don't lose
+ * any packets, and sequence order is preserved for subsequent traffic
+ * sent over the remaining link. Owner node is locked.
*/
-void tipc_link_changeover(struct tipc_link *l_ptr)
+void tipc_link_failover_send_queue(struct tipc_link *l_ptr)
{
u32 msgcount = l_ptr->out_queue_size;
struct sk_buff *crs = l_ptr->first_out;
@@ -2037,20 +2039,30 @@ void tipc_link_changeover(struct tipc_link *l_ptr)
msgcount = msg_msgcnt(msg);
while (msgcount--) {
msg_set_seqno(m, msg_seqno(msg));
- tipc_link_tunnel(l_ptr, &tunnel_hdr, m,
- msg_link_selector(m));
+ tipc_link_tunnel_xmit(l_ptr, &tunnel_hdr, m,
+ msg_link_selector(m));
pos += align(msg_size(m));
m = (struct tipc_msg *)pos;
}
} else {
- tipc_link_tunnel(l_ptr, &tunnel_hdr, msg,
- msg_link_selector(msg));
+ tipc_link_tunnel_xmit(l_ptr, &tunnel_hdr, msg,
+ msg_link_selector(msg));
}
crs = crs->next;
}
}
-void tipc_link_send_duplicate(struct tipc_link *l_ptr, struct tipc_link *tunnel)
+/* tipc_link_dup_send_queue(): A second link has become active. Tunnel a
+ * duplicate of the first link's send queue via the new link. This way, we
+ * are guaranteed that currently queued packets from a socket are delivered
+ * before future traffic from the same socket, even if this is using the
+ * new link. The last arriving copy of each duplicate packet is dropped at
+ * the receiving end by the regular protocol check, so packet cardinality
+ * and sequence order is preserved per sender/receiver socket pair.
+ * Owner node is locked.
+ */
+void tipc_link_dup_send_queue(struct tipc_link *l_ptr,
+ struct tipc_link *tunnel)
{
struct sk_buff *iter;
struct tipc_msg tunnel_hdr;
@@ -2106,12 +2118,14 @@ static struct sk_buff *buf_extract(struct sk_buff *skb, u32 from_pos)
return eb;
}
-/*
- * link_recv_changeover_msg(): Receive tunneled packet sent
- * via other link. Node is locked. Return extracted buffer.
+/* tipc_link_tunnel_rcv(): Receive a tunneled packet, sent
+ * via other link as result of a failover (ORIGINAL_MSG) or
+ * a new active link (DUPLICATE_MSG). Failover packets are
+ * returned to the active link for delivery upwards.
+ * Owner node is locked.
*/
-static int link_recv_changeover_msg(struct tipc_link **l_ptr,
- struct sk_buff **buf)
+static int tipc_link_tunnel_rcv(struct tipc_link **l_ptr,
+ struct sk_buff **buf)
{
struct sk_buff *tunnel_buf = *buf;
struct tipc_link *dest_link;
diff --git a/net/tipc/link.h b/net/tipc/link.h
index 0636ca9..89ab89b 100644
--- a/net/tipc/link.h
+++ b/net/tipc/link.h
@@ -216,15 +216,20 @@ struct tipc_link *tipc_link_create(struct tipc_node *n_ptr,
struct tipc_bearer *b_ptr,
const struct tipc_media_addr *media_addr);
void tipc_link_delete(struct tipc_link *l_ptr);
-void tipc_link_changeover(struct tipc_link *l_ptr);
-void tipc_link_send_duplicate(struct tipc_link *l_ptr, struct tipc_link *dest);
+void tipc_link_failover_send_queue(struct tipc_link *l_ptr);
+void tipc_link_dup_send_queue(struct tipc_link *l_ptr,
+ struct tipc_link *dest);
void tipc_link_reset_fragments(struct tipc_link *l_ptr);
int tipc_link_is_up(struct tipc_link *l_ptr);
int tipc_link_is_active(struct tipc_link *l_ptr);
void tipc_link_stop(struct tipc_link *l_ptr);
-struct sk_buff *tipc_link_cmd_config(const void *req_tlv_area, int req_tlv_space, u16 cmd);
-struct sk_buff *tipc_link_cmd_show_stats(const void *req_tlv_area, int req_tlv_space);
-struct sk_buff *tipc_link_cmd_reset_stats(const void *req_tlv_area, int req_tlv_space);
+struct sk_buff *tipc_link_cmd_config(const void *req_tlv_area,
+ int req_tlv_space,
+ u16 cmd);
+struct sk_buff *tipc_link_cmd_show_stats(const void *req_tlv_area,
+ int req_tlv_space);
+struct sk_buff *tipc_link_cmd_reset_stats(const void *req_tlv_area,
+ int req_tlv_space);
void tipc_link_reset(struct tipc_link *l_ptr);
int tipc_link_send(struct sk_buff *buf, u32 dest, u32 selector);
void tipc_link_send_names(struct list_head *message_list, u32 dest);
diff --git a/net/tipc/node.c b/net/tipc/node.c
index e167d26..efe4d41 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -162,7 +162,7 @@ void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
pr_info("New link <%s> becomes standby\n", l_ptr->name);
return;
}
- tipc_link_send_duplicate(active[0], l_ptr);
+ tipc_link_dup_send_queue(active[0], l_ptr);
if (l_ptr->priority == active[0]->priority) {
active[0] = l_ptr;
return;
@@ -225,7 +225,7 @@ void tipc_node_link_down(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
if (active[0] == l_ptr)
node_select_active_links(n_ptr);
if (tipc_node_is_up(n_ptr))
- tipc_link_changeover(l_ptr);
+ tipc_link_failover_send_queue(l_ptr);
else
node_lost_contact(n_ptr);
}
--
1.7.9.5
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 0/4] tipc: link setup and failover improvements
From: Jon Maloy @ 2014-01-07 22:02 UTC (permalink / raw)
To: davem; +Cc: Jon Maloy, netdev, tipc-discussion
This series consists of four unrelated commits with different purposes.
- Commit #1 is purely cosmetic and pedagogic, hopefully making the
failover/tunneling logics slightly easier to understand.
- Commit #2 fixes a bug that has always been in the code, but was not
discovered until very recently.
- Commit #3 fixes a non-fatal race issue in the neighbour discovery
code.
- Commit #4 removes an unnecessary indirection step during link
startup.
Jon Maloy (3):
tipc: rename functions related to link failover and improve comments
tipc: remove 'has_redundant_link' flag from STATE link protocol
messages
tipc: make link start event synchronous
Ying Xue (1):
tipc: introduce new spinlock to protect struct link_req
net/tipc/bcast.c | 2 +-
net/tipc/bearer.c | 2 +-
net/tipc/bearer.h | 3 +-
net/tipc/discover.c | 11 ++++--
net/tipc/link.c | 96 +++++++++++++++++++++++++--------------------------
net/tipc/link.h | 17 +++++----
net/tipc/node.c | 4 +--
net/tipc/node.h | 2 --
8 files changed, 73 insertions(+), 64 deletions(-)
--
1.7.9.5
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [net-next 08/15] i40e: acknowledge VFLR when disabling SR-IOV
From: Sergei Shtylyov @ 2014-01-07 21:55 UTC (permalink / raw)
To: Williams, Mitch A, Kirsher, Jeffrey T, Rose, Gregory V
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com, Brandeburg, Jesse
In-Reply-To: <AAEA33E297BCAC4B9BB20A7C2DF0AB8D654EA3EF@FMSMSX113.amr.corp.intel.com>
Hello.
On 06-01-2014 22:10, Williams, Mitch A wrote:
>>> From: Mitch Williams <mitch.a.williams@intel.com>
>>> When SR-IOV is disabled, the (now nonexistent) virtual function
>>> devices undergo a VFLR event. We don't need to handle this event
>>> because the VFs are gone, but we do need to tell the HW that they are
>>> complete. This fixes an issue with a phantom VFLR and broken VFs when
>>> SR-IOV is re-enabled.
>>> Change-Id: I7580b49ded0158172a85b14661ec212af77000c8
>>> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
>>> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>>> Tested-by: Sibai Li <sibai.li@intel.com>
>>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>> ---
>>> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 +++++++++++++--
>>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>> b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>>> index f92404c..e91f9d7 100644
>>> --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>> [...]
>>> @@ -748,8 +750,17 @@ void i40e_free_vfs(struct i40e_pf *pf)
>>> kfree(pf->vf);
>>> pf->vf = NULL;
>>>
>>> - if (!i40e_vfs_are_assigned(pf))
>>> + if (!i40e_vfs_are_assigned(pf)) {
>>> pci_disable_sriov(pf->pdev);
>>> + /* Acknowledge VFLR for all VFS. Without this, VFs will fail to
>>> + * work correctly when SR-IOV gets re-enabled.
>>> + */
>>> + for (vf_id = 0; vf_id < tmp; vf_id++) {
>>> + reg_idx = (hw->func_caps.vf_base_id + vf_id) / 32;
>>> + bit_idx = (hw->func_caps.vf_base_id + vf_id) % 32;
>>> + wr32(hw, I40E_GLGEN_VFLRSTAT(reg_idx), (1 << bit_idx));
>>> + }
>>> + }
>>> else
>> } and *else* should be on the same line. And the *else* arm should also
>> have {} now.
>>> dev_warn(&pf->pdev->dev,
>>> "unable to disable SR-IOV because VFs are assigned.\n");
>> WBR, Sergei
> You are absolutely correct, Sergei, and I apologize for not seeing this before I submitted the patch.
I guess you haven't run scripts/checkpatch.pl, have you?
> There will be a patch coming from Greg Rose in the next few weeks that will fix this problem in the process of adding a bug fix. Since this is just cosmetic, would it be all right with you if we just wait for Greg's patch to come through?
Looks like DaveM has decided for everybody and the patch with the fix has
been already posted too.
> -Mitch
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 0/2] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes
From: Thomas Haller @ 2014-01-07 21:42 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Jiri Pirko, netdev, stephen, dcbw
In-Reply-To: <20140107160328.GF24730@order.stressinduktion.org>
[-- Attachment #1: Type: text/plain, Size: 843 bytes --]
On Tue, 2014-01-07 at 17:03 +0100, Hannes Frederic Sowa wrote:
> On Tue, Jan 07, 2014 at 03:39:11PM +0100, Thomas Haller wrote:
> > Now, the IFA_F_NOPREFIXROUTE flag is saved in ifp->flags.
> > The second patch reworks the deletion of addresses/cleanup of prefix
> > routes and considers IFA_F_NOPREFIXROUTE.
> >
> > Thomas Haller (2):
> > ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of
> > IP6 routes
> > ipv6 addrconf: don't cleanup route prefix for IFA_F_NOPREFIXROUTE
>
> Maybe you could look into if a small patch implementing noprefixroute would be
> doable. That would help testing these changes a lot. ;)
>
> Greetings,
>
> Hannes
>
Just for reference:
I sent an email "[patch iproute2 v3 3/3] add support for IFA_F_NOPREFIXROUTE"
with a patch for iproute2.
Thomas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next V2 1/3] net: Add GRO support for UDP encapsulating protocols
From: Tom Herbert @ 2014-01-07 21:40 UTC (permalink / raw)
To: David Miller
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
Linux Netdev List, Yan Burman, Shlomo Pongratz
In-Reply-To: <20140107.161958.2246599406178837029.davem@davemloft.net>
On Tue, Jan 7, 2014 at 1:19 PM, David Miller <davem@davemloft.net> wrote:
> From: Or Gerlitz <ogerlitz@mellanox.com>
> Date: Tue, 7 Jan 2014 17:29:52 +0200
>
>> +#define MAX_UDP_PORT (1 << 16)
>> +extern const struct net_offload __rcu *udp_offloads[MAX_UDP_PORT];
>
> Bloating the kernel up by half a megabyte just for this feature is
> beyond unacceptable.
For now we should have at most handful of encapsulation ports (maybe
5?) so a linear lookup in a simple array should suffice. If we get
into more complex scenarios, like using connected UDP sockets to get
encapsulation through NAT boxes, then we would need something more
complex (maybe socket lookup).
> --
> 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 net-next V2 1/3] net: Add GRO support for UDP encapsulating protocols
From: Eric Dumazet @ 2014-01-07 21:38 UTC (permalink / raw)
To: Or Gerlitz
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
netdev@vger.kernel.org, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CAJZOPZ+b87xF8m7cgTfwH1OqA3k012YFVy0ySJasMuR6x38Czw@mail.gmail.com>
On Tue, 2014-01-07 at 22:37 +0200, Or Gerlitz wrote:
> So here's the thing, per my understanding we want to GRO only received
> **encapsulated** packets whose checksum status is != CHECKSUM_NONE
> which means the NIC has some support for doing RX checksum of
> encapsulated packets. Per the current convension, in that case the NIC
> RX code has to set skb->encapsulation see 6a674e9c75b17 "net: Add
> support for hardware-offloaded encapsulation" this convension is
> implemented in the current drivers that have HW offloads for
> encapsulated packets (bnx2x, i40e and mlx4)
I do not think its true.
Some drivers set CHECKSUM_COMPLETE even for regular UDP frames...
git grep -n CHECKSUM_COMPLETE -- drivers/net
^ permalink raw reply
* Re: [PATCH net-next 02/17] openvswitch: Shrink sw_flow_mask by 8 bytes (64-bit) or 4 bytes (32-bit).
From: Sergei Shtylyov @ 2014-01-07 21:36 UTC (permalink / raw)
To: Jesse Gross, David Miller, Ben Pfaff; +Cc: netdev, dev, Andy Zhou
In-Reply-To: <1389053776-62865-3-git-send-email-jesse@nicira.com>
On 07.01.2014 4:16, Jesse Gross wrote:
> From: Ben Pfaff <blp@nicira.com>
> We won't normally have a ton of flow masks but using a size_t to store
> values no bigger than sizeof(struct sw_flow_key) seems excessive.
> This reduces sw_flow_key_range and sw_flow_mask by 4 bytes on 32-bit
> systems. On 64-bit systems it shrinks sw_flow_key_range by 12 bytes but
> sw_flow_mask only by 8 bytes due to padding.
> Compile tested only.
> Signed-off-by: Ben Pfaff <blp@nicira.com>
> Acked-by: Andy Zhou <azhou@nicira.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
> ---
> net/openvswitch/flow.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
> index 1510f51..176406d 100644
> --- a/net/openvswitch/flow.h
> +++ b/net/openvswitch/flow.h
> @@ -122,8 +122,8 @@ struct sw_flow_key {
> } __aligned(BITS_PER_LONG/8); /* Ensure that we can do comparisons as longs. */
>
> struct sw_flow_key_range {
> - size_t start;
> - size_t end;
> + unsigned short int start;
> + unsigned short int end;
*short int* seems somewhat ambiguous, no?
WBR, Sergei
^ 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