* Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Daniel Borkmann @ 2015-01-23 19:05 UTC (permalink / raw)
To: Michael Tuexen; +Cc: Vlad Yasevich, Sun Paul, linux-sctp, netdev, linux-kernel
In-Reply-To: <8BBFBEE6-FA34-4190-BFCB-AB6BEC093774@fh-muenster.de>
On 01/23/2015 07:36 PM, Michael Tuexen wrote:
...
> Yepp. It might not reach the peer or it might. If it does it helps
> to keep the states in sync. If it doesn't it sometimes helps in
> analysing tracefiles. In BSD, we also send it. It is not required,
> doesn't harm and is useful in some cases...
Ok, as the TCB is destroyed in any case, should be fine then.
Thanks,
Daniel
^ permalink raw reply
* Re: [patch net-next RFC] tc: introduce OpenFlow classifier
From: Cong Wang @ 2015-01-23 19:33 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, David Miller, Jamal Hadi Salim
In-Reply-To: <1421933824-17916-1-git-send-email-jiri@resnulli.us>
On Thu, Jan 22, 2015 at 5:37 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> This patch introduces OpenFlow-based filter. So far, the very essential
> packet fields are supported (according to OpenFlow v1.4 spec).
>
> Known issues: skb_flow_dissect hashes out ipv6 addresses. That needs
> to be changed to store them somewhere so they can be used later on.
>
This has large overlap with cls_flow, I suspect we really
need so many flow dissectors? Or, on the other hand, it might
make sense to move the key computing logic to user-space
so that we don't need to add each of them in kernel?
^ permalink raw reply
* Re: wireless: p54: add handling of the signal case
From: Kalle Valo @ 2015-01-23 19:34 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Christian Lamparter, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Nicholas Mc Guire
In-Reply-To: <1421731543-13290-1-git-send-email-der.herr-kA1LtwSENNE@public.gmane.org>
> if(!wait_for_completion_interruptible_timeout(...))
> only handles the timeout case - this patch adds handling the
> signal case the same as timeout.
>
> Signed-off-by: Nicholas Mc Guire <der.herr-kA1LtwSENNE@public.gmane.org>
> Acked-by: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Thanks, applied to wireless-drivers-next.git but I removed "wireless:" from the
title.
Kalle Valo
--
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: p54pci: add handling of signal case
From: Kalle Valo @ 2015-01-23 19:37 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Christian Lamparter, linux-wireless, netdev, linux-kernel,
Nicholas Mc Guire
In-Reply-To: <1421731577-13324-1-git-send-email-der.herr@hofr.at>
> if(!wait_for_completion_interruptible_timeout(...))
> only handles the timeout case - this patch adds handling the
> signal case the same as timeout.
>
> Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
> Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Thanks, applied to wireless-drivers-next.git. I remove the useless "wireless: "
from the title.
Kalle Valo
^ permalink raw reply
* Re: [v2] atmel: Remove open-coded and wrong strcasecmp
From: Kalle Valo @ 2015-01-23 19:40 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Simon Kelley, Sergei Shtylyov, Rasmus Villemoes, linux-wireless,
netdev, linux-kernel
In-Reply-To: <1421841127-8209-1-git-send-email-linux@rasmusvillemoes.dk>
> The kernel's string library does in fact have strcasecmp, at least
> since ded220bd8f08 ("[STRING]: Move strcasecmp/strncasecmp to
> lib/string.c"). Moreover, this open-coded version is in fact wrong: If
> the strings only differ in their last character, a and b have already
> been incremented to point to the terminating NUL bytes, so they would
> wrongly be treated as equal.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Thanks, applied to wireless-drivers-next.git. I just remove the useless "net:
wireless:" from the title. People, PLEASE stop using that.
Kalle Valo
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: John Fastabend @ 2015-01-23 19:59 UTC (permalink / raw)
To: Thomas Graf
Cc: Jiri Pirko, Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123174609.GA23242@casper.infradead.org>
On 01/23/2015 09:46 AM, Thomas Graf wrote:
> I'm pulling in both branches of the thread here:
>
> On 01/23/15 at 04:56pm, Jiri Pirko wrote:
>> Fri, Jan 23, 2015 at 04:43:48PM CET, john.fastabend@gmail.com wrote:
>>> But with the current API its clear that the rules managed by the
>>> Flow API are in front of 'tc' and 'ovs' on ingress. Just the same
>>> as it is clear 'tc' ingress rules are walked before 'ovs' ingress
>>> rules. On egress it is similarly clear that 'ovs' does a forward
>>> rule to a netdev, then 'tc' fiters+qdisc is run, and finally the
>>> hardware flow api is hit.
>>
>>
>> Seems like this would be resolved by the separe "offload" qdisc.
>
> I'm not sure I understand the offload qdisc yet. My interpretation
> so far is that it would contain childs which *must* be offloaded.
Correct that is my suggestion.
_If_ we want to pursue an embedding inside tc/qdisc for the Flow API
then we need some structure to attach filters and qdisc's that _must_
be offloaded. I have cases where qdisc's on the software dataplane
will be entirely different the qdisc/filter layout on the hardware
dataplane. If you don't do this you end up with a rather strange
array of filters that I don't see anyway to unravel especially
with filters like u32 that have many tables and hardware that has
many tables.
In these cases IMO its going to be easiest to reason about the state
and how to configure it if you have two qdisc/filter attach points. One
for software and one for hardware.
>
> How would one transparently offload tc in this model? e.g. let's
> assume we have a simple prio qdisc with u32 cls:
>
> eth0
> prio
> class
> class
> ...
> u32 ...
> u32 ...
>
> Would you need to attach the prio to an "offload qdisc" to offload
> it or would that happen automatically? How would this looks like to
> user space?
My take is it doesn't happen transparently in general. The user space
has to add the qdisc then subsequently attach flows and actions
explicitly to the hardware qdisc. But I'm confused about what 'tc' has
to say about global pipelines see below,
>
> eth0
> offload
> prio
> u32
> u32
> prio
> u32
> u32
>
> Like this?
>
So if I try to do a mock 'tc' session first creating some software
QOS and filters,
# tc qdisc dev eth0 handle 8001: root mq <- add my mq sw qdisc
# tc qdisc dev eth0 parent 8001:1 fq_codel <- add my fq_codel qdiscs
# tc qdisc dev eth0 parent 8001:2 prio <- one per queue
...
# tc filter add dev p3p2 parent 8001:2 \
protocol ip prio 20 \
u32 match ip protocol 1 0xff \
action skbedit priority <- arbitrary filter
[...]
everything above is part of my software dataplane next up add some
hw qdisc's and filters.
# tc qdisc dev eth0 handle hw_dpif: root mq <- add my mq hw qdisc
# tc qdisc show
[...] <- normal output
qdisc mq (hwdpif) 0: dev eth0 ...
So that seems OK to me I have a multiqueue QOS object on top of a
netdev that represents the switch _port_.
But it starts to break when I want to add a filter to the flow table
pipeline _not_ a qdisc on a port. The pipeline is shared between all
ports its a per port queueing discipline which is how the current
'tc' model works?
And here is where I stopped in my initial attempt and decided we needed
a new object the Flow API. But let me try to push it perhaps? So I need
something to represent the actual pipeline not the per port qdisc. A
new 'tc' object called 'tables' perhaps?
# tc tables dev eth0 show
[...]
table: vlan:2
src 1 apply 2 size -1
matches:
in_lport [in_lport (lpm)]
vlan [vid (lpm)]
actions:
set_vlan_id ( u16 vlan_id 0 )
[...]
So the above is just selected output from 'flow' tool command giving a
table description. Then I can use the same syntax as my 'flow' tool but
embedded in 'tc'
# tc tables dev eth0 set_rule prio 1 handle 4 table 2 \
match in_lport.in_lport 1 0xffffffff \
action set_vlan_id 10
This could work but its a very simple embedding of what I have now.
Also I can imagine another qdisc options to offload port filters/qos
automagically from inside 'tc'. This could/should be done regardless
of if the Flow API is embedded in 'tc' IMO. So we can have a bit,
# tc qdisc set dev p3p2 handle 8001: offload
Then we can do some tests and offload flows and rules from 'tc'. but
I hope(?) its clear its not the same operation as the above 'tables'
command that I made up to represent the pipeline. The tables cmd above
lets me work on the pipeline.
>>> The cases I've been experimenting with using Flow API it is clear
>>> on the priority and what rules are being used by looking at counters
>>> and "knowing" the above pipeline mode.
>>>
>>> Although as I type this I think a picture would help and some
>>> documentation.
>
> +1
>
> We need one of those awesome graphs as the netfilter guys had it with
> where the hooks are attached to ;-)
Yes, I'll try to draft something next week. I'm a bit worried my above
example is a bit convoluted without it.
>
> On 01/23/15 at 07:34am, John Fastabend wrote:
>> Now 'xflows' needs to implement the same get operations that exist in
>> this flow API otherwise writing meaningful policies as Thomas points out
>> is crude at best. So this tc classifier supports 'get headers',
>> 'get actions', and 'get tables' and then there associated graphs. All
>> good so far. This is just an embedding of the existing API in the 'tc'
>> netlink family. I've never had any issues with this. Finally you build
>> up the 'get_flow' and 'set_flow' operations I still so no issue with
>> this and its just an embedding of the existing API into a 'tc
>> classifier'. My flow tool becomes one of the classifier tools.
>
> .... if we can get rid of the rtnl lock in the flow mod path ;-)
Well isn't it the qdisc lock here? And its not needed anymore for
filters/actions only qdisc's use it because they are not lock-safe
yet. Its been on my backlog to start replacing the skb lists with
lock-free rings but I haven't got anywhere on this yet.
Although a hardware doesn't really need a queuing discipline its
done in hardware so you could drop the qdisc lock in this case.
>
>> Now what should I attach my filter to? Typically we attach it to qdiscs
>> today. But what does that mean for a switch device? I guess I need an
>> _offloaded qdisc_? I don't want to run the same qdisc in my dataplane
>> of the switch as I run on the ports going into/out of the sw dataplane.
>> Similarly I don't want to run the same set of filters. So at this point
>> I have a set of qdiscs per port to represent the switch dataplane and
>> a set of qdiscs attached to the software dataplane. If people think this
>> is worth doing lets do it. It may get you a nice way to manage QOS while
>> your @ it.
>
> If I interpret this correctly then this would imply that each switch
> port is represented with a net_device as this is what the tc API
> understands.
>
I think this would work for QOS but I'm also confused as I tried to
illustrate above how the global pipeline fits into the 'tc' model where
everything is a port with queues.
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH 3/6] rtlwifi: btcoexist: Add routines for RTL8812AE with single antenna
From: Kalle Valo @ 2015-01-23 20:06 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1422033044-7461-4-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
> From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>
> The RTL8812AE needs different BT coexistence routines than does the
> RTL8821AE. This patch adds the necessary routines for devices with a
> single antenna.
>
> Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
> .../wireless/rtlwifi/btcoexist/halbtc8812a1ant.c | 2073 ++++++++++++++++++++
> .../wireless/rtlwifi/btcoexist/halbtc8812a1ant.h | 152 ++
> 2 files changed, 2225 insertions(+)
> create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
> create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.h
>
> diff --git a/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
> new file mode 100644
> index 0000000..11ae66b
> --- /dev/null
> +++ b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
> @@ -0,0 +1,2073 @@
> +/* */
> +/* Description: */
> +/* */
> +/* This file is for 8812a1ant Co-exist mechanism */
> +/* */
> +/* History */
> +/* 2012/11/15 Cosa first check in. */
> +/* */
> +/* */
> +
> +/* */
> +/* include files */
> +/* */
One problem I see is that there's no license on either of the files. It
would be much better if the files had that.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net v3] ipv4: try to cache dst_entries which would cause a redirect
From: Julian Anastasov @ 2015-01-23 20:09 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, Marcelo Leitner, Florian Westphal
In-Reply-To: <996db187263dc0419ea3ab4d6e3fad4c0e0e5b44.1422010254.git.hannes@stressinduktion.org>
Hello,
On Fri, 23 Jan 2015, Hannes Frederic Sowa wrote:
> Not caching dst_entries which cause redirects could be exploited by hosts
> on the same subnet, causing a severe DoS attack. This effect aggravated
> since commit f88649721268999 ("ipv4: fix dst race in sk_dst_get()").
>
> Lookups causing redirects will be allocated with DST_NOCACHE set which
> will force dst_release to free them via RCU. Unfortunately waiting for
> RCU grace period just takes too long, we can end up with >1M dst_entries
> waiting to be released and the system will run OOM. rcuos threads cannot
> catch up under high softirq load.
>
> Attaching the flag to emit a redirect later on to the specific skb allows
> us to cache those dst_entries thus reducing the pressure on allocation
> and deallocation.
>
> This issue was discovered by Marcelo Leitner.
>
> Cc: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: Marcelo Leitner <mleitner@redhat.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks! Looks fine.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
> ---
> v2:
> Julian noticed that v1 did omit the redirect flag in rtnetlink
> queries, fixed. Thanks!
>
> v3:
> Julian noticed that we could accidentally write into NEIGHCB, fixed
> and thanks again!
>
> include/net/ip.h | 11 ++++++-----
> net/ipv4/ip_forward.c | 3 ++-
> net/ipv4/route.c | 9 +++++----
> 3 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/ip.h b/include/net/ip.h
> index 0e5a0ba..14211ea 100644
> --- a/include/net/ip.h
> +++ b/include/net/ip.h
> @@ -39,11 +39,12 @@ struct inet_skb_parm {
> struct ip_options opt; /* Compiled IP options */
> unsigned char flags;
>
> -#define IPSKB_FORWARDED 1
> -#define IPSKB_XFRM_TUNNEL_SIZE 2
> -#define IPSKB_XFRM_TRANSFORMED 4
> -#define IPSKB_FRAG_COMPLETE 8
> -#define IPSKB_REROUTED 16
> +#define IPSKB_FORWARDED BIT(0)
> +#define IPSKB_XFRM_TUNNEL_SIZE BIT(1)
> +#define IPSKB_XFRM_TRANSFORMED BIT(2)
> +#define IPSKB_FRAG_COMPLETE BIT(3)
> +#define IPSKB_REROUTED BIT(4)
> +#define IPSKB_DOREDIRECT BIT(5)
>
> u16 frag_max_size;
> };
> diff --git a/net/ipv4/ip_forward.c b/net/ipv4/ip_forward.c
> index 3a83ce5..787b3c2 100644
> --- a/net/ipv4/ip_forward.c
> +++ b/net/ipv4/ip_forward.c
> @@ -129,7 +129,8 @@ int ip_forward(struct sk_buff *skb)
> * We now generate an ICMP HOST REDIRECT giving the route
> * we calculated.
> */
> - if (rt->rt_flags&RTCF_DOREDIRECT && !opt->srr && !skb_sec_path(skb))
> + if (IPCB(skb)->flags & IPSKB_DOREDIRECT && !opt->srr &&
> + !skb_sec_path(skb))
> ip_rt_send_redirect(skb);
>
> skb->priority = rt_tos2priority(iph->tos);
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 2000110..0c63b2a 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1567,11 +1567,10 @@ static int __mkroute_input(struct sk_buff *skb,
>
> do_cache = res->fi && !itag;
> if (out_dev == in_dev && err && IN_DEV_TX_REDIRECTS(out_dev) &&
> + skb->protocol == htons(ETH_P_IP) &&
> (IN_DEV_SHARED_MEDIA(out_dev) ||
> - inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) {
> - flags |= RTCF_DOREDIRECT;
> - do_cache = false;
> - }
> + inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res))))
> + IPCB(skb)->flags |= IPSKB_DOREDIRECT;
>
> if (skb->protocol != htons(ETH_P_IP)) {
> /* Not IP (i.e. ARP). Do not create route, if it is
> @@ -2316,6 +2315,8 @@ static int rt_fill_info(struct net *net, __be32 dst, __be32 src,
> r->rtm_flags = (rt->rt_flags & ~0xFFFF) | RTM_F_CLONED;
> if (rt->rt_flags & RTCF_NOTIFY)
> r->rtm_flags |= RTM_F_NOTIFY;
> + if (IPCB(skb)->flags & IPSKB_DOREDIRECT)
> + r->rtm_flags |= RTCF_DOREDIRECT;
>
> if (nla_put_be32(skb, RTA_DST, dst))
> goto nla_put_failure;
> --
> 2.1.0
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH 5/6] rtlwifi: btcoexist: Add routines for RTL8812AE - all configs
From: Kalle Valo @ 2015-01-23 20:12 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1422033044-7461-6-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
> From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>
> This patch adds the routines used for all antenna configurations.
>
> Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
The commit log is REALLY vague...
> +static u8 rtl_btcoex_create_kernel_socket(struct rtl_priv *rtlpriv,
> + u8 is_invite)
> +{
> + struct bt_coex_info *pcoex_info = &rtlpriv->coex_info;
> + s8 kernel_socket_err;
> +
> + BTC_PRINT(BTC_MSG_SOCKET, SOCKET_CRITICAL,
> + "%s CONNECT_PORT %d\n", __func__, CONNECT_PORT);
> +
> + if (!pcoex_info) {
> + BTC_PRINT(BTC_MSG_SOCKET, SOCKET_CRITICAL, "coex_info: NULL\n");
> + return _FAIL;
> + }
> +
> + kernel_socket_err = sock_create(PF_INET, SOCK_DGRAM, 0,
> + &pcoex_info->udpsock);
> + BTC_PRINT(BTC_MSG_SOCKET, SOCKET_CRITICAL,
> + "binding socket, err = %d\n", kernel_socket_err);
> +
> + if (kernel_socket_err < 0) {
> + BTC_PRINT(BTC_MSG_SOCKET, SOCKET_CRITICAL,
> + "Error during creation of socket error:%d\n",
> + kernel_socket_err);
> + return _FAIL;
> + }
> + memset(&pcoex_info->sin, 0, sizeof(pcoex_info->sin));
> + pcoex_info->sin.sin_family = AF_INET;
> + pcoex_info->sin.sin_port = htons(CONNECT_PORT);
> + pcoex_info->sin.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
...and then I see stuff like this. What an earth does this do?
--
Kalle Valo
--
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
* [PATCH 1/1 net-next] dev: add per net_device packet type chains
From: Salam Noureddine @ 2015-01-23 20:07 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Tom Herbert, Jiri Pirko,
Vlad Yasevich, netdev
Cc: Salam Noureddine, Eric W. Biederman
When many pf_packet listeners are created on a lot of interfaces the
current implementation using global packet type lists scales poorly.
This patch adds per net_device packet type lists to fix thi problem.
The patch was originally written by Eric Biederman for linux-2.6.20.
Tested on linux-3.16.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Salam Noureddine <noureddine@arista.com>
---
include/linux/netdevice.h | 2 +
net/core/dev.c | 131 +++++++++++++++++++++++++++++-----------------
2 files changed, 85 insertions(+), 48 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 642d426..3d37c6e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1514,6 +1514,8 @@ struct net_device {
struct list_head napi_list;
struct list_head unreg_list;
struct list_head close_list;
+ struct list_head ptype_all;
+ struct list_head ptype_specific;
struct {
struct list_head upper;
diff --git a/net/core/dev.c b/net/core/dev.c
index 1e325ad..0891d31 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -371,9 +371,10 @@ static inline void netdev_set_addr_lockdep_class(struct net_device *dev)
static inline struct list_head *ptype_head(const struct packet_type *pt)
{
if (pt->type == htons(ETH_P_ALL))
- return &ptype_all;
+ return pt->dev ? &pt->dev->ptype_all : &ptype_all;
else
- return &ptype_base[ntohs(pt->type) & PTYPE_HASH_MASK];
+ return pt->dev ? &pt->dev->ptype_specific :
+ &ptype_base[ntohs(pt->type) & PTYPE_HASH_MASK];
}
/**
@@ -1734,6 +1735,23 @@ static inline int deliver_skb(struct sk_buff *skb,
return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
}
+static inline void deliver_ptype_list_skb(struct sk_buff *skb,
+ struct packet_type **pt,
+ struct net_device *dev, __be16 type,
+ struct list_head *ptype_list)
+{
+ struct packet_type *ptype, *pt_prev = *pt;
+
+ list_for_each_entry_rcu(ptype, ptype_list, list) {
+ if (ptype->type != type)
+ continue;
+ if (pt_prev)
+ deliver_skb(skb, pt_prev, dev);
+ pt_prev = ptype;
+ }
+ *pt = pt_prev;
+}
+
static inline bool skb_loop_sk(struct packet_type *ptype, struct sk_buff *skb)
{
if (!ptype->af_packet_priv || !skb->sk)
@@ -1757,45 +1775,54 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
struct packet_type *ptype;
struct sk_buff *skb2 = NULL;
struct packet_type *pt_prev = NULL;
+ struct list_head *ptype_list = &ptype_all;
rcu_read_lock();
- list_for_each_entry_rcu(ptype, &ptype_all, list) {
+again:
+ list_for_each_entry_rcu(ptype, ptype_list, list) {
/* Never send packets back to the socket
* they originated from - MvS (miquels@drinkel.ow.org)
*/
- if ((ptype->dev == dev || !ptype->dev) &&
- (!skb_loop_sk(ptype, skb))) {
- if (pt_prev) {
- deliver_skb(skb2, pt_prev, skb->dev);
- pt_prev = ptype;
- continue;
- }
+ if (skb_loop_sk(ptype, skb))
+ continue;
- skb2 = skb_clone(skb, GFP_ATOMIC);
- if (!skb2)
- break;
+ if (pt_prev) {
+ deliver_skb(skb2, pt_prev, skb->dev);
+ pt_prev = ptype;
+ continue;
+ }
- net_timestamp_set(skb2);
+ /* need to clone skb, done only once */
+ skb2 = skb_clone(skb, GFP_ATOMIC);
+ if (!skb2)
+ goto out_unlock;
- /* skb->nh should be correctly
- set by sender, so that the second statement is
- just protection against buggy protocols.
- */
- skb_reset_mac_header(skb2);
-
- if (skb_network_header(skb2) < skb2->data ||
- skb_network_header(skb2) > skb_tail_pointer(skb2)) {
- net_crit_ratelimited("protocol %04x is buggy, dev %s\n",
- ntohs(skb2->protocol),
- dev->name);
- skb_reset_network_header(skb2);
- }
+ net_timestamp_set(skb2);
- skb2->transport_header = skb2->network_header;
- skb2->pkt_type = PACKET_OUTGOING;
- pt_prev = ptype;
+ /* skb->nh should be correctly
+ set by sender, so that the second statement is
+ just protection against buggy protocols.
+ */
+ skb_reset_mac_header(skb2);
+
+ if (skb_network_header(skb2) < skb2->data ||
+ skb_network_header(skb2) > skb_tail_pointer(skb2)) {
+ net_crit_ratelimited("protocol %04x is buggy, dev %s\n",
+ ntohs(skb2->protocol),
+ dev->name);
+ skb_reset_network_header(skb2);
}
+
+ skb2->transport_header = skb2->network_header;
+ skb2->pkt_type = PACKET_OUTGOING;
+ pt_prev = ptype;
+ }
+
+ if (ptype_list == &ptype_all) {
+ ptype_list = &dev->ptype_all;
+ goto again;
}
+out_unlock:
if (pt_prev)
pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);
rcu_read_unlock();
@@ -2617,7 +2644,7 @@ static int xmit_one(struct sk_buff *skb, struct net_device *dev,
unsigned int len;
int rc;
- if (!list_empty(&ptype_all))
+ if (!list_empty(&ptype_all) || !list_empty(&dev->ptype_all))
dev_queue_xmit_nit(skb, dev);
len = skb->len;
@@ -3615,7 +3642,6 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
struct packet_type *ptype, *pt_prev;
rx_handler_func_t *rx_handler;
struct net_device *orig_dev;
- struct net_device *null_or_dev;
bool deliver_exact = false;
int ret = NET_RX_DROP;
__be16 type;
@@ -3658,11 +3684,15 @@ another_round:
goto skip_taps;
list_for_each_entry_rcu(ptype, &ptype_all, list) {
- if (!ptype->dev || ptype->dev == skb->dev) {
- if (pt_prev)
- ret = deliver_skb(skb, pt_prev, orig_dev);
- pt_prev = ptype;
- }
+ if (pt_prev)
+ ret = deliver_skb(skb, pt_prev, orig_dev);
+ pt_prev = ptype;
+ }
+
+ list_for_each_entry_rcu(ptype, &skb->dev->ptype_all, list) {
+ if (pt_prev)
+ ret = deliver_skb(skb, pt_prev, orig_dev);
+ pt_prev = ptype;
}
skip_taps:
@@ -3718,19 +3748,20 @@ ncls:
skb->vlan_tci = 0;
}
+ type = skb->protocol;
+
/* deliver only exact match when indicated */
- null_or_dev = deliver_exact ? skb->dev : NULL;
+ if (likely(!deliver_exact)) {
+ deliver_ptype_list_skb(skb, &pt_prev, orig_dev, type,
+ &ptype_base[ntohs(type) & PTYPE_HASH_MASK]);
+ }
- type = skb->protocol;
- list_for_each_entry_rcu(ptype,
- &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
- if (ptype->type == type &&
- (ptype->dev == null_or_dev || ptype->dev == skb->dev ||
- ptype->dev == orig_dev)) {
- if (pt_prev)
- ret = deliver_skb(skb, pt_prev, orig_dev);
- pt_prev = ptype;
- }
+ deliver_ptype_list_skb(skb, &pt_prev, orig_dev, type,
+ &orig_dev->ptype_specific);
+
+ if (unlikely(skb->dev != orig_dev)) {
+ deliver_ptype_list_skb(skb, &pt_prev, orig_dev, type,
+ &skb->dev->ptype_specific);
}
if (pt_prev) {
@@ -6579,6 +6610,8 @@ void netdev_run_todo(void)
/* paranoia */
BUG_ON(netdev_refcnt_read(dev));
+ BUG_ON(!list_empty(&dev->ptype_all));
+ BUG_ON(!list_empty(&dev->ptype_specific));
WARN_ON(rcu_access_pointer(dev->ip_ptr));
WARN_ON(rcu_access_pointer(dev->ip6_ptr));
WARN_ON(dev->dn_ptr);
@@ -6761,6 +6794,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
INIT_LIST_HEAD(&dev->adj_list.lower);
INIT_LIST_HEAD(&dev->all_adj_list.upper);
INIT_LIST_HEAD(&dev->all_adj_list.lower);
+ INIT_LIST_HEAD(&dev->ptype_all);
+ INIT_LIST_HEAD(&dev->ptype_specific);
dev->priv_flags = IFF_XMIT_DST_RELEASE | IFF_XMIT_DST_RELEASE_PERM;
setup(dev);
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Jesse Gross @ 2015-01-23 20:20 UTC (permalink / raw)
To: Tom Herbert; +Cc: Pravin B Shelar, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx87bZBnY_9cgQ7k=xsD0VGZUt0rc9DjhSqhpeH3LZiuFw@mail.gmail.com>
On Fri, Jan 23, 2015 at 10:25 AM, Tom Herbert <therbert@google.com> wrote:
> On Fri, Jan 23, 2015 at 9:38 AM, Jesse Gross <jesse@nicira.com> wrote:
>> On Fri, Jan 23, 2015 at 8:58 AM, Tom Herbert <therbert@google.com> wrote:
>>> On Tue, Jan 20, 2015 at 12:25 PM, Pravin B Shelar <pshelar@nicira.com> wrote:
>>>> Following patch series adds support for Stateless Transport
>>>> Tunneling protocol.
>>>> STT uses TCP segmentation offload available in most of NIC. On
>>>> packet xmit STT driver appends STT header along with TCP header
>>>> to the packet. For GSO packet GSO parameters are set according
>>>> to tunnel configuration and packet is handed over to networking
>>>> stack. This allows use of segmentation offload available in NICs
>>>>
>>>> Netperf unidirectional test gives ~9.4 Gbits/s performance on 10Gbit
>>>> NIC with 1500 byte MTU with two TCP streams.
>>>>
>>> The reason you're able to get 9.4 Gbit/s with an L2 encapsulation
>>> using STT is that it has less protocol overhead per packet when doing
>>> segmentation compared to VXLAN (without segmentation STT packets will
>>> have more overhead than VXLAN).
>>>
>>> A VXLAN packet with TCP/IP has headers
>>> IP|UDP|VXLAN|Ethernet|IP|TCP+options. Assuming TCP is stuffed with
>>> options, this is 20+8+8+16+20+40=112 bytes, or 7.4% MTU. Each STT
>>> segment created in GSO, other than the first, has just IP|TCP headers
>>> which is 20+20=40 bytes or 2.6% MTU. So this explains throughput
>>> differences between VXLAN and STT.
>>
>> Tom, what performance do you see with a single stream of VXLAN running
>> on net-next with default configuration? The difference in numbers
>> being posted here is greater than a few percent caused by protocol
>> overheard.
>
> Please look at the data I posted with the VXLAN RCO patches.
The data you posted uses 200 streams, so I assume that you are using
multiple CPUs. It's not surprising that you would be able to consume a
10G link in that case. STT can do this with a single stream and less
than 1 core (or alternately handle higher throughput). Claiming that
since both can hit 10G they are same is not accurate.
Discussing performance like this seems a little silly given that the
code is available. Pravin posted some numbers that he got, if you want
to dispute them then why don't you just try running it?
^ permalink raw reply
* Re: [PATCH V2 for 3.19 0/7] Fixes for rtl8192ee
From: Kalle Valo @ 2015-01-23 20:24 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless, netdev,
troy_tan@realsil.com.cn >> 谭杭波
In-Reply-To: <54C27975.50501@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> It is too bad that it took so long to get these ready. I think the
> reason that there are not a lot of bug reports is because the
> complaints are all in the GitHub issues for the rtlwifi_new repo, or
> with Ubuntu. If there are any that get filed against Bugzilla, I will
> refer them to that repo.
Ok.
> Driver rtl8192ee was new in 3.18. There had been a previous version in
> staging, but it did not get a lot of usage. I'm not sure if the
> additional usage after 3.18 was due to the driver being in the regular
> tree, or if vendors started using the chips, but the problem reports
> started arriving. All these bugs have been part of rtl8192ee since it
> has been in the kernel, thus they are hard to categorize as
> regressions.
Good. So we are not going backwards in quality, that's most important.
> Push all 7 into -next so that they will be in 3.20. If you think it to
> be prudent, please leave the Cc for stable. That way 3.18 and 3.19
> will eventually get the fixes.
I think that's the best plan, thanks for understanding. The patches are
in my queue and I should apply them within the next few days, unless
anything comes during the review.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 3/6] rtlwifi: btcoexist: Add routines for RTL8812AE with single antenna
From: Larry Finger @ 2015-01-23 20:24 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87r3uljm7o.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
On 01/23/2015 02:06 PM, Kalle Valo wrote:
> Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
>
>> From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>>
>> The RTL8812AE needs different BT coexistence routines than does the
>> RTL8821AE. This patch adds the necessary routines for devices with a
>> single antenna.
>>
>> Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>> ---
>> .../wireless/rtlwifi/btcoexist/halbtc8812a1ant.c | 2073 ++++++++++++++++++++
>> .../wireless/rtlwifi/btcoexist/halbtc8812a1ant.h | 152 ++
>> 2 files changed, 2225 insertions(+)
>> create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
>> create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.h
>>
>> diff --git a/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
>> new file mode 100644
>> index 0000000..11ae66b
>> --- /dev/null
>> +++ b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
>> @@ -0,0 +1,2073 @@
>> +/* */
>> +/* Description: */
>> +/* */
>> +/* This file is for 8812a1ant Co-exist mechanism */
>> +/* */
>> +/* History */
>> +/* 2012/11/15 Cosa first check in. */
>> +/* */
>> +/* */
>> +
>> +/* */
>> +/* include files */
>> +/* */
>
> One problem I see is that there's no license on either of the files. It
> would be much better if the files had that.
I will add that and send a V2 after I wait a while for any other comments.
Thanks,
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] atheros/atlx: Simplify bit manipulations
From: Francois Romieu @ 2015-01-23 20:26 UTC (permalink / raw)
To: Rasmus Villemoes; +Cc: Jay Cliburn, Chris Snook, netdev, linux-kernel
In-Reply-To: <1422011212-30095-1-git-send-email-linux@rasmusvillemoes.dk>
Rasmus Villemoes <linux@rasmusvillemoes.dk> :
[...]
> diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c b/drivers/net/ethernet/atheros/atlx/atl2.c
> index 84a09e8ddd9c..46d1b959daa8 100644
> --- a/drivers/net/ethernet/atheros/atlx/atl2.c
> +++ b/drivers/net/ethernet/atheros/atlx/atl2.c
> @@ -1278,14 +1278,10 @@ static void atl2_setup_pcicmd(struct pci_dev *pdev)
>
> pci_read_config_word(pdev, PCI_COMMAND, &cmd);
>
> - if (cmd & PCI_COMMAND_INTX_DISABLE)
> - cmd &= ~PCI_COMMAND_INTX_DISABLE;
> - if (cmd & PCI_COMMAND_IO)
> - cmd &= ~PCI_COMMAND_IO;
> - if (0 == (cmd & PCI_COMMAND_MEMORY))
> - cmd |= PCI_COMMAND_MEMORY;
> - if (0 == (cmd & PCI_COMMAND_MASTER))
> - cmd |= PCI_COMMAND_MASTER;
> + cmd &= ~PCI_COMMAND_INTX_DISABLE;
> + cmd &= ~PCI_COMMAND_IO;
> + cmd |= PCI_COMMAND_MEMORY;
> + cmd |= PCI_COMMAND_MASTER;
> pci_write_config_word(pdev, PCI_COMMAND, cmd);
Mostly open-coded pci_set_master, pci_enable_device_mem and pci_intx.
I'd suggest to ignore the PCI_COMMAND_IO bit at all then use the standard
pci helpers.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Tom Herbert @ 2015-01-23 20:57 UTC (permalink / raw)
To: Jesse Gross; +Cc: Pravin B Shelar, David Miller, Linux Netdev List
In-Reply-To: <CAEP_g=-Yn849TmrN5xFLJVxuux0fBuYGFSM7K-psg=pdxgPR9w@mail.gmail.com>
On Fri, Jan 23, 2015 at 12:20 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Fri, Jan 23, 2015 at 10:25 AM, Tom Herbert <therbert@google.com> wrote:
>> On Fri, Jan 23, 2015 at 9:38 AM, Jesse Gross <jesse@nicira.com> wrote:
>>> On Fri, Jan 23, 2015 at 8:58 AM, Tom Herbert <therbert@google.com> wrote:
>>>> On Tue, Jan 20, 2015 at 12:25 PM, Pravin B Shelar <pshelar@nicira.com> wrote:
>>>>> Following patch series adds support for Stateless Transport
>>>>> Tunneling protocol.
>>>>> STT uses TCP segmentation offload available in most of NIC. On
>>>>> packet xmit STT driver appends STT header along with TCP header
>>>>> to the packet. For GSO packet GSO parameters are set according
>>>>> to tunnel configuration and packet is handed over to networking
>>>>> stack. This allows use of segmentation offload available in NICs
>>>>>
>>>>> Netperf unidirectional test gives ~9.4 Gbits/s performance on 10Gbit
>>>>> NIC with 1500 byte MTU with two TCP streams.
>>>>>
>>>> The reason you're able to get 9.4 Gbit/s with an L2 encapsulation
>>>> using STT is that it has less protocol overhead per packet when doing
>>>> segmentation compared to VXLAN (without segmentation STT packets will
>>>> have more overhead than VXLAN).
>>>>
>>>> A VXLAN packet with TCP/IP has headers
>>>> IP|UDP|VXLAN|Ethernet|IP|TCP+options. Assuming TCP is stuffed with
>>>> options, this is 20+8+8+16+20+40=112 bytes, or 7.4% MTU. Each STT
>>>> segment created in GSO, other than the first, has just IP|TCP headers
>>>> which is 20+20=40 bytes or 2.6% MTU. So this explains throughput
>>>> differences between VXLAN and STT.
>>>
>>> Tom, what performance do you see with a single stream of VXLAN running
>>> on net-next with default configuration? The difference in numbers
>>> being posted here is greater than a few percent caused by protocol
>>> overheard.
>>
>> Please look at the data I posted with the VXLAN RCO patches.
>
> The data you posted uses 200 streams, so I assume that you are using
> multiple CPUs. It's not surprising that you would be able to consume a
> 10G link in that case. STT can do this with a single stream and less
> than 1 core (or alternately handle higher throughput). Claiming that
> since both can hit 10G they are same is not accurate.
>
> Discussing performance like this seems a little silly given that the
> code is available. Pravin posted some numbers that he got, if you want
> to dispute them then why don't you just try running it?
Because you haven't provided network interface like I already
requested twice, and I really don't have time or motivation to do
development on your patches or figure out how to do this with OVS. If
you want me to test your patches re-spin them with a network interface
included.
^ permalink raw reply
* udp_diag: Fix socket skipping within chain
From: Herbert Xu @ 2015-01-23 21:02 UTC (permalink / raw)
To: Pavel Emelyanov, netdev
While working on rhashtable walking I noticed that the UDP diag
dumping code is buggy. In particular, the socket skipping within
a chain never happens, even though we record the number of sockets
that should be skipped.
As this code was supposedly copied from TCP, this patch does what
TCP does and resets num before we walk a chain.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index 7927db0..4a000f1 100644
--- a/net/ipv4/udp_diag.c
+++ b/net/ipv4/udp_diag.c
@@ -99,11 +99,13 @@ static void udp_dump(struct udp_table *table, struct sk_buff *skb, struct netlin
s_slot = cb->args[0];
num = s_num = cb->args[1];
- for (slot = s_slot; slot <= table->mask; num = s_num = 0, slot++) {
+ for (slot = s_slot; slot <= table->mask; s_num = 0, slot++) {
struct sock *sk;
struct hlist_nulls_node *node;
struct udp_hslot *hslot = &table->hash[slot];
+ num = 0;
+
if (hlist_nulls_empty(&hslot->head))
continue;
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* [PATCH] net: dsa/mv88e6xxx: add reg read and write debug
From: Vivien Didelot @ 2015-01-23 21:10 UTC (permalink / raw)
To: netdev; +Cc: Vivien Didelot, David S . Miller, linux-kernel, kernel
This commit adds debug messages for the generic mv88e6xxx read and write
routines. The output is similar to this:
mdio-gpio mdio-gpio.0: <- addr: 0x1b reg: 0x05 val: 0x4000
mdio-gpio mdio-gpio.0: -> addr: 0x1b reg: 0x07 val: 0x3113
mdio-gpio mdio-gpio.0: -> addr: 0x1b reg: 0x08 val: 0x0330
mdio-gpio mdio-gpio.0: -> addr: 0x1b reg: 0x09 val: 0x0000
This is convenient to dynamically debug operations through debugfs with:
echo file mv88e6xxx.c +p > <debugfs>/dynamic_debug/control
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index cd6807c..3e7e31a 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -85,6 +85,12 @@ int mv88e6xxx_reg_read(struct dsa_switch *ds, int addr, int reg)
ret = __mv88e6xxx_reg_read(bus, ds->pd->sw_addr, addr, reg);
mutex_unlock(&ps->smi_mutex);
+ if (ret < 0)
+ return ret;
+
+ dev_dbg(ds->master_dev, "<- addr: 0x%.2x reg: 0x%.2x val: 0x%.4x\n",
+ addr, reg, ret);
+
return ret;
}
@@ -128,6 +134,9 @@ int mv88e6xxx_reg_write(struct dsa_switch *ds, int addr, int reg, u16 val)
if (bus == NULL)
return -EINVAL;
+ dev_dbg(ds->master_dev, "-> addr: 0x%.2x reg: 0x%.2x val: 0x%.4x\n",
+ addr, reg, val);
+
mutex_lock(&ps->smi_mutex);
ret = __mv88e6xxx_reg_write(bus, ds->pd->sw_addr, addr, reg, val);
mutex_unlock(&ps->smi_mutex);
--
2.2.2
^ permalink raw reply related
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Pravin Shelar @ 2015-01-23 21:11 UTC (permalink / raw)
To: Tom Herbert; +Cc: Jesse Gross, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx8bK16McNgBXKN8Vu6_ifEdyZL7FPzOmXvxLP5AqKx1Hw@mail.gmail.com>
On Fri, Jan 23, 2015 at 12:57 PM, Tom Herbert <therbert@google.com> wrote:
> On Fri, Jan 23, 2015 at 12:20 PM, Jesse Gross <jesse@nicira.com> wrote:
>> On Fri, Jan 23, 2015 at 10:25 AM, Tom Herbert <therbert@google.com> wrote:
>>> On Fri, Jan 23, 2015 at 9:38 AM, Jesse Gross <jesse@nicira.com> wrote:
>>>> On Fri, Jan 23, 2015 at 8:58 AM, Tom Herbert <therbert@google.com> wrote:
>>>>> On Tue, Jan 20, 2015 at 12:25 PM, Pravin B Shelar <pshelar@nicira.com> wrote:
>>>>>> Following patch series adds support for Stateless Transport
>>>>>> Tunneling protocol.
>>>>>> STT uses TCP segmentation offload available in most of NIC. On
>>>>>> packet xmit STT driver appends STT header along with TCP header
>>>>>> to the packet. For GSO packet GSO parameters are set according
>>>>>> to tunnel configuration and packet is handed over to networking
>>>>>> stack. This allows use of segmentation offload available in NICs
>>>>>>
>>>>>> Netperf unidirectional test gives ~9.4 Gbits/s performance on 10Gbit
>>>>>> NIC with 1500 byte MTU with two TCP streams.
>>>>>>
>>>>> The reason you're able to get 9.4 Gbit/s with an L2 encapsulation
>>>>> using STT is that it has less protocol overhead per packet when doing
>>>>> segmentation compared to VXLAN (without segmentation STT packets will
>>>>> have more overhead than VXLAN).
>>>>>
>>>>> A VXLAN packet with TCP/IP has headers
>>>>> IP|UDP|VXLAN|Ethernet|IP|TCP+options. Assuming TCP is stuffed with
>>>>> options, this is 20+8+8+16+20+40=112 bytes, or 7.4% MTU. Each STT
>>>>> segment created in GSO, other than the first, has just IP|TCP headers
>>>>> which is 20+20=40 bytes or 2.6% MTU. So this explains throughput
>>>>> differences between VXLAN and STT.
>>>>
>>>> Tom, what performance do you see with a single stream of VXLAN running
>>>> on net-next with default configuration? The difference in numbers
>>>> being posted here is greater than a few percent caused by protocol
>>>> overheard.
>>>
>>> Please look at the data I posted with the VXLAN RCO patches.
>>
>> The data you posted uses 200 streams, so I assume that you are using
>> multiple CPUs. It's not surprising that you would be able to consume a
>> 10G link in that case. STT can do this with a single stream and less
>> than 1 core (or alternately handle higher throughput). Claiming that
>> since both can hit 10G they are same is not accurate.
>>
>> Discussing performance like this seems a little silly given that the
>> code is available. Pravin posted some numbers that he got, if you want
>> to dispute them then why don't you just try running it?
>
> Because you haven't provided network interface like I already
> requested twice, and I really don't have time or motivation to do
> development on your patches or figure out how to do this with OVS. If
> you want me to test your patches re-spin them with a network interface
> included.
I am woking in it. I will have patches by next week.
^ permalink raw reply
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Brian Haley @ 2015-01-23 21:17 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: hannes
In-Reply-To: <54C2919A.2050707@gmail.com>
On 01/23/2015 01:23 PM, David Ahern wrote:
>>> Add a new sysctl to make this behavior optional. Setting defaults to flush
>>> addresses to maintain backwards compatibility. When reset flushing is bypassed:
>>>
>>> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
>>> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
>>> [root@f20 ~]# ip addr show dev eth1
>>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
>>> default qlen 1000
>>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>>> inet6 2000:11:1:1::1/64 scope global tentative
>>> valid_lft forever preferred_lft forever
>>> [root@f20 ~]# ip link set dev eth1 up
>>> [root@f20 ~]# ip link set dev eth1 down
>>> [root@f20 ~]# ip addr show dev eth1
>>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
>>> default qlen 1000
>>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>>> inet6 2000:11:1:1::1/64 scope global
>>> valid_lft forever preferred_lft forever
>>> inet6 fe80::4:11ff:fe22:3301/64 scope link
>>> valid_lft forever preferred_lft forever
>>
>> I think this was brought up in a previous thread on this, but don't you have to
>> do DAD on these addresses once the interface comes back up? Some other system
>> could have come along, done DAD, succeeded, and is now using it. Or does the
>> use of this flag assume the user is Ok without doing DAD, and will deal with the
>> fallout?
>
> You have the same problem today, don't you? Current code allows an IPv6 address
> to be configured on interface in the down state. The intent of this sysctl is to
> allow that address to stay on an up-down cycle.
Yes, looks like ndisc_send_skb() never returns any lower-level error back up to
the caller, so it's assumed the Neighbour Advertisement is always sent.
Although the address will be marked "tentative" until IFF_UP is set.
> I don't have a strong IPv6 background so the first email thread and this RFC
> patch are both asking first and foremost if there is any harm in this behavior.
> None has been raised - so far. To maintain backwards compatibility this is a new
> option which when reset allows the addresses to be retained (not flushed).
Seems as though you're in an RFC grey area then. Personally, I'd do DAD, even
though the possibility of a collision is always very small. But that's just my
opinion.
-Brian
^ permalink raw reply
* net: raw socket accessing invalid memory
From: Sasha Levin @ 2015-01-23 22:18 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: David S. Miller, James Morris, yoshfuji, Patrick McHardy, LKML,
Dave Jones, Andrey Ryabinin
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel and the KASan patchset, I've stumbled on the following spew:
[ 2560.693067] BUG: AddressSanitizer: out of bounds on stack in memcpy_fromiovec+0x24d/0x260 at addr ffff880200697dd0
[ 2560.693067] Read of size 8 by task trinity-c9/25362
[ 2560.693067] page:ffffea000801a5c0 count:0 mapcount:0 mapping: (null) index:0x0
[ 2560.693067] flags: 0x1afffff80000000()
[ 2560.693067] page dumped because: kasan: bad access detected
[ 2560.693067] CPU: 9 PID: 25362 Comm: trinity-c9 Not tainted 3.19.0-rc5-next-20150121-sasha-00064-g3c37e35-dirty #1810
[ 2560.693067] 0000000000000000 0000000000000000 ffff880200697790 ffff8802006976d8
[ 2560.693067] ffffffff92e9e8b7 1ffffd40010034bf ffffea000801a5c0 ffff880200697778
[ 2560.693067] ffffffff81b4a7b2 ffffed00629442ba dffffc0000000000 ffffed00629442b8
[ 2560.693067] Call Trace:
[ 2560.693067] dump_stack (lib/dump_stack.c:52)
[ 2560.693067] kasan_report_error (mm/kasan/report.c:136 mm/kasan/report.c:194)
[ 2560.693067] __asan_report_load8_noabort (mm/kasan/report.c:236)
[ 2560.693067] memcpy_fromiovec (lib/iovec.c:14)
[ 2560.693067] raw_sendmsg (net/ipv4/raw.c:444 net/ipv4/raw.c:606)
[ 2560.693067] inet_sendmsg (net/ipv4/af_inet.c:734)
[ 2560.693067] ? inet_sendmsg (include/net/sock.h:875 net/ipv4/af_inet.c:726)
[ 2560.693067] do_sock_sendmsg (net/socket.c:645 (discriminator 4))
[ 2560.771124] SYSC_sendto (net/socket.c:1782)
[ 2560.794593] SyS_sendto (net/socket.c:1748)
[ 2560.794593] tracesys_phase2 (arch/x86/kernel/entry_64.S:530)
[ 2560.794593] Memory state around the buggy address:
[ 2560.794593] ffff880200697c80: 00 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
[ 2560.794593] ffff880200697d00: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2 04
[ 2560.794593] >ffff880200697d80: f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f2 f2 f2 f2 00
[ 2560.794593] ^
[ 2560.794593] ffff880200697e00: 00 00 00 00 00 00 00 00 00 f4 f4 f2 f2 f2 f2 00
[ 2560.794593] ffff880200697e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3
Thanks,
Sasha
^ permalink raw reply
* [PATCH] ping: Fix race in free in receive path
From: subashab @ 2015-01-23 22:26 UTC (permalink / raw)
To: netdev; +Cc: edumazet
An exception is seen in ICMP ping receive path where the skb
destructor sock_rfree() tries to access a freed socket. This happens
because ping_rcv() releases socket reference with sock_put() and this
internally frees up the socket. Later icmp_rcv() will try to free the
skb and as part of this, skb destructor is called and which leads
to a kernel panic as the socket is freed already in ping_rcv().
-->|exception
-007|sk_mem_uncharge
-007|sock_rfree
-008|skb_release_head_state
-009|skb_release_all
-009|__kfree_skb
-010|kfree_skb
-011|icmp_rcv
-012|ip_local_deliver_finish
Fix this incorrect free by cloning this skb and processing this cloned
skb instead.
This patch was suggested by Eric Dumazet
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Cc: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ping.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index c0d82f7..2a3720f 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -966,8 +966,11 @@ bool ping_rcv(struct sk_buff *skb)
sk = ping_lookup(net, skb, ntohs(icmph->un.echo.id));
if (sk != NULL) {
+ struct sk_buff *skb2 = skb_clone(skb, GFP_ATOMIC);
+
pr_debug("rcv on socket %p\n", sk);
- ping_queue_rcv_skb(sk, skb_get(skb));
+ if (skb2)
+ ping_queue_rcv_skb(sk, skb2);
sock_put(sk);
return true;
}
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: ipvlan: Initial check-in of the IPVLAN driver.
From: Mahesh Bandewar @ 2015-01-23 22:40 UTC (permalink / raw)
To: David Miller; +Cc: dan.carpenter, linux-netdev
In-Reply-To: <20150119.162059.2087370902498436539.davem@davemloft.net>
On Mon, Jan 19, 2015 at 1:20 PM, David Miller <davem@davemloft.net> wrote:
> From: Dan Carpenter <dan.carpenter@oracle.com>
> Date: Mon, 19 Jan 2015 17:40:11 +0300
>
>> The patch 2ad7bf363841: "ipvlan: Initial check-in of the IPVLAN
>> driver." from Nov 23, 2014, leads to the following static checker
>> warning:
>>
>> drivers/net/ipvlan/ipvlan_core.c:380 ipvlan_process_v6_outbound()
>> warn: 'dst' isn't an ERR_PTR
>>
>> drivers/net/ipvlan/ipvlan_core.c
>> 378
>> 379 dst = ip6_route_output(dev_net(dev), NULL, &fl6);
>> 380 if (IS_ERR(dst))
>> 381 goto err;
>>
>> The ip6_route_output() function is not documented but it always returns
>> a valid pointer. I believe you are supposed to check something like:
>>
>> if (dst->error) {
>> ret = dst->error;
>> goto error;
>> }
>>
>> 382
>> 383 skb_dst_drop(skb);
>> 384 skb_dst_set(skb, dst);
>
> This is correct.
Thanks Dan for pointing it out. I'll send a patch correcting that code.
^ permalink raw reply
* Re: [PATCH net-next v3 2/5] swdevice: add new api to set and del bridge port attributes
From: roopa @ 2015-01-23 22:45 UTC (permalink / raw)
To: Jiri Pirko
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, vyasevic,
ronen.arad, netdev, davem, shm, gospo
In-Reply-To: <20150123160636.GM2065@nanopsycho.orion>
On 1/23/15, 8:06 AM, Jiri Pirko wrote:
> Fri, Jan 23, 2015 at 04:58:57PM CET, roopa@cumulusnetworks.com wrote:
>> On 1/23/15, 2:41 AM, Jiri Pirko wrote:
>>
>> <snip..>
>>> +
>>> +/**
>>> + * netdev_switch_port_bridge_dellink - Notify switch device port of bridge
>>> + * attribute delete
>>> + *
>>> + * @dev: port device
>>> + * @nlh: netlink msg with bridge port attributes
>>> + *
>>> + * Notify switch device port of bridge port attribute delete
>>> + */
>>> +int netdev_switch_port_bridge_dellink(struct net_device *dev,
>>> + struct nlmsghdr *nlh, u16 flags)
>>> +{
>>> + const struct net_device_ops *ops = dev->netdev_ops;
>>> + struct net_device *lower_dev;
>>> + struct list_head *iter;
>>> + int ret = 0, err = 0;
>>> +
>>> + if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD))
>>> + return err;
>>> +
>>> + if (ops->ndo_bridge_dellink) {
>>> + WARN_ON(!ops->ndo_switch_parent_id_get);
>>> + return ops->ndo_bridge_dellink(dev, nlh, flags);
>>> + }
>>> +
>>> + netdev_for_each_lower_dev(dev, lower_dev, iter) {
>>> + err = netdev_switch_port_bridge_dellink(lower_dev, nlh, flags);
>>> + if (err)
>>> + ret = err;
>>> + }
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL(netdev_switch_port_bridge_dellink);
>>> --
>>> 1.7.10.4
>>>
>>> Is there any other place, other than bridge code, this functions are
>>> suppored to be called from?
>> No other place today. Its usually the master that implements
>> ndo_bridge_setlink/dellink.
>>
>>> If not, which I consider likely, it would
>>> make more sense to me to:
>>>
>>> - move netdev_for_each_lower_dev iterations directly to bridge code
>>> - let the masters (bond, team, ..) implement ndo_bridge_*link and do
>>> the traversing there (can be in a form of pre-prepared default
>>> ndo callback (ndo_dflt_netdev_switch_port_bridge_*link)
>> But, i am still not understanding why i would modify bond, team and other
>> slaves
> Well, that is the usual way to propagate ndo calls. People are used to
> this. It is visible right away in bonding/other code that is propagated
> some ndo call to slaves. With your code, that is somehow hidden and only
> dependent on NETIF_F_HW_NETFUNC_OFFLOAD flag.
>
> Note that there are only couple of "master drivers" (for this, most likely
> only bond and team modifications are needed).
>
ndo_bridge_setlink today is only implemented by drivers that implement
bridging function.
So, having the bond and team driver implement it...seems odd.
But if you insist, i am going to do just that.
^ permalink raw reply
* Re: [PATCH net-next 1/5] bonding: keep bond interface carrier off until at least one active member
From: Jonathan Toppins @ 2015-01-23 23:04 UTC (permalink / raw)
To: Jay Vosburgh
Cc: netdev, Scott Feldman, Andy Gospodarek, Veaceslav Falico,
Nikolay Aleksandrov
In-Reply-To: <5368.1421824444@famine>
On 1/21/15 2:14 AM, Jay Vosburgh wrote:
> Jonathan Toppins <jtoppins@cumulusnetworks.com> wrote:
>
>> On 1/19/15 4:16 PM, Jay Vosburgh wrote:
>>> Jonathan Toppins <jtoppins@cumulusnetworks.com> wrote:
>>>
>>>> From: Scott Feldman <sfeldma@cumulusnetworks.com>
>>>>
>>>> Bonding driver parameter min_links is now used to signal upper-level
>>>> protocols of bond status. The way it works is if the total number of
>>>> active members in slaves drops below min_links, the bond link carrier
>>>> will go down, signaling upper levels that bond is inactive. When active
>>>> members returns to >= min_links, bond link carrier will go up (RUNNING),
>>>> and protocols can resume. When bond is carrier down, member ports are
>>>> in stp fwd state blocked (rather than normal disabled state), so
>>>> low-level ctrl protocols (LACP) can still get in and be processed by
>>>> bonding driver.
>>>
>>> Presuming that "stp" is Spanning Tree, is the last sentence
>>> above actually describing the behavior of a bridge port when a bond is
>>> the member of the bridge? I'm not sure I understand what "member ports"
>>> refers to (bridge ports or bonding slaves).
>>
>> Ack, maybe replacing the last sentence with something like:
>> When bond is carrier down, the slave ports are only forwarding
>> low-level control protocols (e.g. LACP PDU) and discarding all other
>> packets.
>
> Ah, are you actually referring to the fact that slaves that are
> up will still deliver packets to listeners that bind directly to the
> slave or hook in through a rx_handler? This is, in part, the
> "RX_HANDLER_EXACT" business in bond_handle_frame and
> __netif_receive_skb_core.
>
> The decision for that has nothing to do with the protocol; I
> seem to recall that FCoE (or maybe it's iSCSI) does its regular traffic
> reception this way (although via dev_add_pack, not an rx_handler) so it
> can run traffic regardless of the bonding master's state.
I see, it seems you are basically saying; the slaves are up but when the
logical bond interface is carrier down there was no code changed in
bond_handle_frame() to actually drop frames other than LACPDUs. So
basically having this statement makes no sense until there is code to
actually drop those additional frames.
>
>>>> @@ -2381,10 +2386,15 @@ int bond_3ad_set_carrier(struct bonding *bond)
>>>> ret = 0;
>>>> goto out;
>>>> }
>>>> +
>>>> + bond_for_each_slave_rcu(bond, slave, iter)
>>>> + if (SLAVE_AD_INFO(slave)->aggregator.is_active)
>>>> + active_slaves++;
>>>> +
>>>> active = __get_active_agg(&(SLAVE_AD_INFO(first_slave)->aggregator));
>>>> - if (active) {
>>>> + if (active && __agg_has_partner(active)) {
>>>
>>> Why "__agg_has_partner"? Since the "else" of this clause is:
>>>
>>> } else if (netif_carrier_ok(bond->dev)) {
>>> netif_carrier_off(bond->dev);
>>> }
>>>
>>> I'm wondering if this will do the right thing for the case that
>>> there are no LACP partners at all (e.g., the switch ports do not have
>>> LACP enabled), in which case the active aggregator should be a single
>>> "individual" port as a fallback, but will not have a partner.
>>>
>>> -J
>>>
>>
>> I see your point. The initial thinking was the logical bond carrier should
>> not be brought up until the bond has a partner and is ready to pass
>> traffic, otherwise we start blackholing frames. Looking over the code it
>> seems the aggregator.is_individual flag is only set to true when a slave
>> is in half-duplex, this seems odd?
>
> The agg.is_individual flag and an "individual" aggregator are
> subtly different things.
>
> The is_individual flag is part of the implementation of the
> standard requirement that half duplex ports are not allowed to enable
> LACP (and thus cannot aggregate, and end up as "Individual" in
> standard-ese). The standard capitalizes "Individual" when it describes
> the cannot-aggregate property of a port (note that half duplex is only
> one reason of many for a port being Individual).
>
> An "individual" aggregator (my usage of 802.1AX 5.3.6 (b)) is an
> aggregator containing exactly one port that is Individual. A port can
> end up as Individual (for purposes of this discussion) either through
> the is_individual business, or because the bonding port does run LACP,
> but the link partner does not, and thus no LACPDUs are ever received.
>
> For either of the above cases (is_individual or no-LACP-parter),
> then the active aggregator will be an "individual" aggregator, but will
> not have a parter (__agg_has_partner() will be false). The standard has
> a bunch of verbiage about this in 802.1AX 5.3.5 - 5.3.9.
>
>> My initial thinking to alleviate the concern is something like the
>> following:
>>
>> if (active && !SLAVE_AD_INFO(slave)->aggregator.is_individual &&
>> __agg_has_partner(active)) {
>> /* set carrier based on min_links */
>> } else if (active && SLAVE_AD_INFO(slave)->aggregator.is_individual) {
>> /* set bond carrier state according to carrier state of slave */
>> } else if (netif_carrier_ok(bond->dev)) {
>> netif_carrier_off(bond->dev);
>> }
>
> I'm not sure you need to care about is_individual or
> __agg_has_partner at all. If either of those conditions is true for the
> active aggregator, it will contain exactly one port, and so if min_links
> is 2, you'll have carrier off, and if min_links is 1 or less you'll have
> carrier on.
>
> If I'm reading the patch right, the real point (which isn't
> really described very well in the change log) is that you're changing
> the carrier decision to count only active ports in the active
> aggregator, not the total number of ports as is currently done.
>
> I'm not sure why this change is needed:
>
> @@ -2381,10 +2386,15 @@ int bond_3ad_set_carrier(struct bonding *bond)
> ret = 0;
> goto out;
> }
> +
> + bond_for_each_slave_rcu(bond, slave, iter)
> + if (SLAVE_AD_INFO(slave)->aggregator.is_active)
> + active_slaves++;
> +
> active = __get_active_agg(&(SLAVE_AD_INFO(first_slave)->aggregator));
> - if (active) {
> + if (active && __agg_has_partner(active)) {
> /* are enough slaves available to consider link up? */
> - if (active->num_of_ports < bond->params.min_links) {
> + if (active_slaves < bond->params.min_links) {
> if (netif_carrier_ok(bond->dev)) {
> netif_carrier_off(bond->dev);
> goto out;
>
> because a port (slave) that loses carrier or whose link partner
> becomes unresponsive to LACPDUs will be removed from the aggregator. As
> I recall, there are no "inactive" ports in an aggregator; all of them
> have to match in terms of capabilities.
>
> In other words, I'm unsure of when the count of is_active ports
> will not match active->num_of_ports.
>
> Also, the other parts of the patch add some extra updates to the
> carrier state when a port is enabled or disabled, e.g.,
>
> @@ -189,6 +189,7 @@ static inline int __agg_has_partner(struct aggregator *agg)
> static inline void __disable_port(struct port *port)
> {
> bond_set_slave_inactive_flags(port->slave, BOND_SLAVE_NOTIFY_LATER);
> + bond_3ad_set_carrier(port->slave->bond);
> }
>
> Again, I'm not sure why this is necessary, as the cases that
> disable or enable a port will eventually call bond_3ad_set_carrier. For
> example, ad_agg_selection_logic will, when changing active aggregator,
> individually disable all ports of the old active and then may
> individually enable ports of the new active if necessary, and then
> finally call bond_3ad_set_carrier.
>
> In what situations is the patch's behavior an improvement (i.e.,
> is there a situation I'm missing that doesn't do it right)?
I think the addition of bond_3ad_set_carrier() to both __enable_port()
and __disable_port() were optimizations so the bond carrier transition
would happen faster, though I am not certain.
>
> The last portion of the patch:
>
> --- a/drivers/net/bonding/bond_options.c
> +++ b/drivers/net/bonding/bond_options.c
> @@ -1181,6 +1181,7 @@ static int bond_option_min_links_set(struct bonding *bond,
> netdev_info(bond->dev, "Setting min links value to %llu\n",
> newval->value);
> bond->params.min_links = newval->value;
> + bond_set_carrier(bond);
>
> return 0;
> }
>
> does seem to fix a legitimate bug, in that when min_links is
> changed, it does not take effect in real time.
>
>> Maybe I am missing something and there is a simpler option.
>>
>> Thinking about how to validate this, it seems having a bond with two
>> slaves and both slaves in half-duplex will force an aggregator that is
>> individual to be selected.
>>
>> Thoughts?
>
> That's one way, yes. You'll also get an "individual" aggregator
> if none of the link partners enable LACP.
>
It seems it might be better to drop the changes to __enable/disable_port
and bond_3ad_set_carrier from this patch until more testing can be done
from me, especially if you agree the other changes in this series are of
benefit.
^ permalink raw reply
* Re: [PATCH] ping: Fix race in free in receive path
From: Eric Dumazet @ 2015-01-23 23:07 UTC (permalink / raw)
To: subashab; +Cc: netdev, edumazet
In-Reply-To: <45fab13fce077924f957cba84ba20ba4.squirrel@www.codeaurora.org>
On Fri, 2015-01-23 at 22:26 +0000, subashab@codeaurora.org wrote:
> An exception is seen in ICMP ping receive path where the skb
> destructor sock_rfree() tries to access a freed socket. This happens
> because ping_rcv() releases socket reference with sock_put() and this
> internally frees up the socket. Later icmp_rcv() will try to free the
> skb and as part of this, skb destructor is called and which leads
> to a kernel panic as the socket is freed already in ping_rcv().
...
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> Cc: Eric Dumazet <edumazet@google.com>
> ---
Thanks !
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ 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