* [PATCH net-next v2 2/5] net: Extend struct flowi6 with multipath hash
From: Jakub Sitnicki @ 2016-10-28 12:32 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Hannes Frederic Sowa, Hideaki YOSHIFUJI,
Tom Herbert
In-Reply-To: <1477657955-5157-1-git-send-email-jkbs@redhat.com>
Allow for functions that fill out the IPv6 flow info to also pass a hash
computed over the skb contents. The hash value will drive the multipath
routing decisions.
This is intended for special treatment of ICMPv6 errors, where we would
like to make a routing decision based on the flow identifying the
offending IPv6 datagram that triggered the error, rather than the flow
of the ICMP error itself.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/net/flow.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/flow.h b/include/net/flow.h
index 035aa77..73ee3aa 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -143,6 +143,7 @@ struct flowi6 {
#define fl6_ipsec_spi uli.spi
#define fl6_mh_type uli.mht.type
#define fl6_gre_key uli.gre_key
+ __u32 mp_hash;
} __attribute__((__aligned__(BITS_PER_LONG/8)));
struct flowidn {
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 0/5] Route ICMPv6 errors with the flow when ECMP in use
From: Jakub Sitnicki @ 2016-10-28 12:32 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Hannes Frederic Sowa, Hideaki YOSHIFUJI,
Tom Herbert
The motivation for this series is to route ICMPv6 error messages
together with the flow they belong to when multipath routing is in
use. It intends to bring the ECMP routing in IPv6 stack on par with
IPv4.
This enables the use of tools that rely on ICMP error messages such as
traceroute and makes PMTU discovery work both ways. However, for it to
work IPv6 flow labels have to be same in both directions
(i.e. reflected) or need to be chosen in a manner that ensures that
the flow going in the opposite direction would actually be routed to a
given path.
Even though we generally don't expect this, as receiving and sending
IPv6 are free to choose flow labels at will, we make an assumption
here that the enitity in charge of configuring ECMP routing will also
be in control of the server hosts, and can set up flow label
reflection. However, if this is not the case, the patchset doesn't
make the situation worse.
One potential user of the changes here would be an anycast service
hosted behind an ECMP router(s).
Changes have been tested in a virtual setup with a topology as below:
Re1 --- Hs1
/
Hc --- Ri --- Rc
\
Re1 --- Hs2
Hc - client host
HsX - server host
Rc - core router
ReX - edge router
Ri - intermediate router
To test the changes, traceroute in UDP mode to the client host, with
flow label set, has been run from one of the server hosts. Full test
is available at [1].
-Jakub
[1] https://github.com/jsitnicki/tools/blob/master/net/tests/ecmp/test-ecmp-icmpv6-error-routing.sh
v1 -> v2:
- don't use "extern" in external function declaration in header file,
pointed out by David Miller;
- style change, put as many arguments as possible on the first line of
a function call, and align consecutive lines to the first argument,
pointed out by David Miller;
- expand the cover letter based on the feedback from David Miller and
Hannes Sowa;
Jakub Sitnicki (5):
ipv6: Fold rt6_info_hash_nhsfn() into its only caller
net: Extend struct flowi6 with multipath hash
ipv6: Use multipath hash from flow info if available
ipv6: Compute multipath hash for sent ICMP errors from offending
packet
ipv6: Compute multipath hash for forwarded ICMP errors from offending
packet
include/linux/icmpv6.h | 2 ++
include/net/flow.h | 1 +
net/ipv6/icmp.c | 21 +++++++++++++++++++++
net/ipv6/route.c | 40 +++++++++++++++++++++++++++++-----------
4 files changed, 53 insertions(+), 11 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH] netfilter: ip_vs_sync: fix bogus maybe-uninitialized warning
From: Pablo Neira Ayuso @ 2016-10-28 12:16 UTC (permalink / raw)
To: Simon Horman
Cc: Julian Anastasov, Arnd Bergmann, Wensong Zhang, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller, Quentin Armitage, netdev,
lvs-devel, netfilter-devel, coreteam, linux-kernel
In-Reply-To: <20161028114020.GA4041@verge.net.au>
On Fri, Oct 28, 2016 at 01:40:23PM +0200, Simon Horman wrote:
> On Fri, Oct 28, 2016 at 11:34:22AM +0200, Pablo Neira Ayuso wrote:
> > On Mon, Oct 24, 2016 at 10:47:54PM +0300, Julian Anastasov wrote:
> > >
> > > Hello,
> > >
> > > On Mon, 24 Oct 2016, Arnd Bergmann wrote:
> > >
> > > > Building the ip_vs_sync code with CONFIG_OPTIMIZE_INLINING on x86
> > > > confuses the compiler to the point where it produces a rather
> > > > dubious warning message:
> > > >
> > > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘opt.init_seq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > > struct ip_vs_sync_conn_options opt;
> > > > ^~~
> > > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘opt.delta’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘opt.previous_delta’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘*((void *)&opt+12).init_seq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘*((void *)&opt+12).delta’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘*((void *)&opt+12).previous_delta’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > >
> > > > The problem appears to be a combination of a number of factors, including
> > > > the __builtin_bswap32 compiler builtin being slightly odd, having a large
> > > > amount of code inlined into a single function, and the way that some
> > > > functions only get partially inlined here.
> > > >
> > > > I've spent way too much time trying to work out a way to improve the
> > > > code, but the best I've come up with is to add an explicit memset
> > > > right before the ip_vs_seq structure is first initialized here. When
> > > > the compiler works correctly, this has absolutely no effect, but in the
> > > > case that produces the warning, the warning disappears.
> > > >
> > > > In the process of analysing this warning, I also noticed that
> > > > we use memcpy to copy the larger ip_vs_sync_conn_options structure
> > > > over two members of the ip_vs_conn structure. This works because
> > > > the layout is identical, but seems error-prone, so I'm changing
> > > > this in the process to directly copy the two members. This change
> > > > seemed to have no effect on the object code or the warning, but
> > > > it deals with the same data, so I kept the two changes together.
> > > >
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > OK,
> > >
> > > Acked-by: Julian Anastasov <ja@ssi.bg>
> > >
> > > I guess, Simon will take the patch for ipvs-next.
> >
> > @Simon: If you have no more pending updates, I can save you one pull
> > request for this small fix by placing this.
>
> Thanks Pablo, please do.
Thanks Simon, feel free to exercise this path anytime.
> Signed-off-by: Simon Horman <horms@verge.net.au>
Applied to nf, thanks!
^ permalink raw reply
* Re: [PATCH v7 0/6] Add eBPF hooks for cgroups
From: Daniel Mack @ 2016-10-28 12:07 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: htejun, daniel, ast, davem, kafai, fw, harald, netdev, sargun,
cgroups
In-Reply-To: <20161028115311.GB29798@salvia>
On 10/28/2016 01:53 PM, Pablo Neira Ayuso wrote:
> On Thu, Oct 27, 2016 at 10:40:14AM +0200, Daniel Mack wrote:
>> It's not anything new. These hooks live on the very same level as
>> SO_ATTACH_FILTER. The only differences are that the BPF programs are
>> stored in the cgroup, and not in the socket, and that they exist for
>> egress as well.
>
> Can we agree this is going further than SO_ATTACH_FILTER?
It's the same level. Only the way of setting the program(s) is different.
>> Adding it there would mean we need to early-demux *every* packet as soon
>> as there is *any* such rule installed, and that renders many
>> optimizations in the kernel to drop traffic that has no local receiver
>> useless.
>
> I think such concern applies to doing early demux inconditionally in
> all possible scenarios (such as UDP broadcast/multicast), that implies
> wasted cycles for people not requiring this.
If you have a rule that acts on a condition based on a local receiver
detail such as a cgroup membership, then the INPUT filter *must* know
the local receiver for *all* packets passing by, otherwise it cannot act
upon it. And that means that you have to early-demux in any case as long
as at least one such a rule exists.
> If we can do what demuxing in an optional way, ie. only when socket
> filtering is required, then only those that need it would pay that
> price. Actually, if we can do this demux very early, from ingress,
> performance numbers would be also good to perform any socket-based
> filtering.
For multicast, rules have to be executed for each receiver, which is
another reason why the INPUT path is the wrong place to solve to problem.
You actually convinced me yourself about these details, but you seem to
constantly change your opinion about all this. Why is this such a
whack-a-mole game?
> I guess you're using an old kernel and refering to iptables, this is
> not true for some time, so we don't have any impact now with loaded
> iptables modules.
My point is that the performance decrease introduced by my patch set is
not really measurable, even if you pipe all the wire-saturating test
traffic through the example program. At least not with my setup here. If
a local receiver has no applicable bpf in its cgroup, the logic bails
out way earlier, leading a lot less overhead even. And if no cgroup has
any program attached, the code is basically no-op thanks to the static
branch. I really see no reason to block this patch set due to unfounded
claims of bad performance.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v7 0/6] Add eBPF hooks for cgroups
From: Pablo Neira Ayuso @ 2016-10-28 11:53 UTC (permalink / raw)
To: Daniel Mack
Cc: htejun-b10kYP2dOMg, daniel-FeC+5ew28dpmcu3hnIyYJQ,
ast-b10kYP2dOMg, davem-fT/PcQaiUtIeIZ0/mPfg9Q, kafai-b10kYP2dOMg,
fw-HFFVJYpyMKqzQB+pC5nmwQ, harald-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, sargun-GaZTRHToo+CzQB+pC5nmwQ,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <c9683122-d770-355b-e275-7c446e6d1d0f-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
On Thu, Oct 27, 2016 at 10:40:14AM +0200, Daniel Mack wrote:
> On 10/26/2016 09:59 PM, Pablo Neira Ayuso wrote:
> > On Tue, Oct 25, 2016 at 12:14:08PM +0200, Daniel Mack wrote:
> > [...]
> >> Dumping programs once they are installed is problematic because of
> >> the internal optimizations done to the eBPF program during its
> >> lifetime. Also, the references to maps etc. would need to be
> >> restored during the dump.
> >>
> >> Just exposing whether or not a program is attached would be
> >> trivial to do, however, most easily through another bpf(2)
> >> command. That can be added later on though.
> >
> > I don't know if anyone told you, but during last netconf, this topic
> > took a bit of time of discussion and it was controversial, I would say
> > 1/3 of netdev hackers there showed their concerns, and that's
> > something that should not be skipped IMO.
> >
> > While xdp is pushing bpf programs at the very early packet path, not
> > interfering with the stack, before even entering the generic ingress
> > path. But this is adding hooks to push bpf programs in the middle of
> > our generic stack, this is way different domain.
>
> It's not anything new. These hooks live on the very same level as
> SO_ATTACH_FILTER. The only differences are that the BPF programs are
> stored in the cgroup, and not in the socket, and that they exist for
> egress as well.
Can we agree this is going further than SO_ATTACH_FILTER?
> > I would really like to explore way earlier filtering, by extending
> > socket lookup facilities. So far the problem seems to be that we need
> > to lookup for broadcast/multicast UDP sockets and those cannot be
> > attach via the usual skb->sk.
>
> We've been there. We've discussed all that. And we concluded that doing
> early demux in the input filter path is not the right approach. That was
> my very first take on that issue back in June 2015 (!), and it was
> rightfully turned down for good reasons.
>
> Adding it there would mean we need to early-demux *every* packet as soon
> as there is *any* such rule installed, and that renders many
> optimizations in the kernel to drop traffic that has no local receiver
> useless.
I think such concern applies to doing early demux inconditionally in
all possible scenarios (such as UDP broadcast/multicast), that implies
wasted cycles for people not requiring this.
If we can do what demuxing in an optional way, ie. only when socket
filtering is required, then only those that need it would pay that
price. Actually, if we can do this demux very early, from ingress,
performance numbers would be also good to perform any socket-based
filtering.
[...]
> > I think it would be possible to wrap
> > around this socket code in functions so we can invoke it. I guess
> > filtering of UDP and TCP should be good for you at this stage. This
> > would require more work though, but this would come with no hooks in
> > the stack and packets will not have to consume *lots of cycles* just
> > to be dropped before entering the socket queue.
> >
> > How useful can be to drop lots of unwanted traffic at such a late
> > stage? How would the performance numbers to drop packets would look
> > like? Extremely bad, I predict.
>
> I fear I'm repeating myself here, but this is unfounded. I'm not sure
> why you keep bringing it up. As I said weeks ago - just loading the
> netfilter modules without any rules deployed has more impact than
> running the example program in 6/6 on every packet in the test traffic.
I guess you're using an old kernel and refering to iptables, this is
not true for some time, so we don't have any impact now with loaded
iptables modules.
^ permalink raw reply
* Re: [PATCH] netfilter: ip_vs_sync: fix bogus maybe-uninitialized warning
From: Simon Horman @ 2016-10-28 11:40 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Julian Anastasov, Arnd Bergmann, Wensong Zhang, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller, Quentin Armitage, netdev,
lvs-devel, netfilter-devel, coreteam, linux-kernel
In-Reply-To: <20161028093422.GA29559@salvia>
On Fri, Oct 28, 2016 at 11:34:22AM +0200, Pablo Neira Ayuso wrote:
> On Mon, Oct 24, 2016 at 10:47:54PM +0300, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Mon, 24 Oct 2016, Arnd Bergmann wrote:
> >
> > > Building the ip_vs_sync code with CONFIG_OPTIMIZE_INLINING on x86
> > > confuses the compiler to the point where it produces a rather
> > > dubious warning message:
> > >
> > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘opt.init_seq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > struct ip_vs_sync_conn_options opt;
> > > ^~~
> > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘opt.delta’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘opt.previous_delta’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘*((void *)&opt+12).init_seq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘*((void *)&opt+12).delta’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > > net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘*((void *)&opt+12).previous_delta’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > >
> > > The problem appears to be a combination of a number of factors, including
> > > the __builtin_bswap32 compiler builtin being slightly odd, having a large
> > > amount of code inlined into a single function, and the way that some
> > > functions only get partially inlined here.
> > >
> > > I've spent way too much time trying to work out a way to improve the
> > > code, but the best I've come up with is to add an explicit memset
> > > right before the ip_vs_seq structure is first initialized here. When
> > > the compiler works correctly, this has absolutely no effect, but in the
> > > case that produces the warning, the warning disappears.
> > >
> > > In the process of analysing this warning, I also noticed that
> > > we use memcpy to copy the larger ip_vs_sync_conn_options structure
> > > over two members of the ip_vs_conn structure. This works because
> > > the layout is identical, but seems error-prone, so I'm changing
> > > this in the process to directly copy the two members. This change
> > > seemed to have no effect on the object code or the warning, but
> > > it deals with the same data, so I kept the two changes together.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > OK,
> >
> > Acked-by: Julian Anastasov <ja@ssi.bg>
> >
> > I guess, Simon will take the patch for ipvs-next.
>
> @Simon: If you have no more pending updates, I can save you one pull
> request for this small fix by placing this.
Thanks Pablo, please do.
Signed-off-by: Simon Horman <horms@verge.net.au>
^ permalink raw reply
* Re: [PATCH v7 0/6] Add eBPF hooks for cgroups
From: Pablo Neira Ayuso @ 2016-10-28 11:28 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Mack, htejun-b10kYP2dOMg, daniel-FeC+5ew28dpmcu3hnIyYJQ,
ast-b10kYP2dOMg, davem-fT/PcQaiUtIeIZ0/mPfg9Q, kafai-b10kYP2dOMg,
fw-HFFVJYpyMKqzQB+pC5nmwQ, harald-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, sargun-GaZTRHToo+CzQB+pC5nmwQ,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161027033502.GA43960-+o4/htvd0TDFYCXBM6kdu7fOX0fSgVTm@public.gmane.org>
Hi Alexei,
On Wed, Oct 26, 2016 at 08:35:04PM -0700, Alexei Starovoitov wrote:
> On Wed, Oct 26, 2016 at 09:59:33PM +0200, Pablo Neira Ayuso wrote:
> > On Tue, Oct 25, 2016 at 12:14:08PM +0200, Daniel Mack wrote:
> > [...]
> > > Dumping programs once they are installed is problematic because of
> > > the internal optimizations done to the eBPF program during its
> > > lifetime. Also, the references to maps etc. would need to be
> > > restored during the dump.
> > >
> > > Just exposing whether or not a program is attached would be
> > > trivial to do, however, most easily through another bpf(2)
> > > command. That can be added later on though.
> >
> > I don't know if anyone told you, but during last netconf, this topic
> > took a bit of time of discussion and it was controversial, I would say
> > 1/3 of netdev hackers there showed their concerns, and that's
> > something that should not be skipped IMO.
>
> Though I attended netconf over hangouts, I think it was pretty
> clear that bpf needs 'introspection' of loaded bpf programs and it
> was a universal desire of everyone. Not 1/3 of hackers.
Introspection is a different thing, very useful, no doubt. But this
infrastructure is allowing way more than simple innocuous introspection.
> As commit log says it's an orthogonal work and over the last
> month we've been discussing pros and cons of different approaches.
> The audit infra, tracepoints and other ideas.
> We kept the discussion in private because, unfortunately, public
> discussions are not fruitful due to threads like this one.
We need to understand what people are trying to solve and it what way.
That's why we have all those conferences and places to meet and
discuss too. Please, don't think like that, this is sending the wrong
message to everyone here, that is kind of: bypass public discussions
and don't take time to describe what you're doing since it is a waste
of time. That's not good.
> The further points below were disputed many times in the past.
> Let's address them one more time:
>
> > path. But this is adding hooks to push bpf programs in the middle of
> > our generic stack, this is way different domain.
>
> incorrect. look at socket filters, cls_bpf.
Classic socket filters don't allow you to deploy a global policy in
such a fine grain way as this is doing. Then, cls_bpf is fine since it
is visible via tc command, so sysadmins can use tools they are
familiar with to inspect policies and say "oh look, some of the
processes I'm deploying have installed filters via cls_bpf". However,
this approach is visible in no way.
[...]
> > around this socket code in functions so we can invoke it. I guess
> > filtering of UDP and TCP should be good for you at this stage.
>
> DanielM mentioned few times that it's not only about UDP and TCP.
OK, since this is limited to the scope of inet sockets, let's revisit
what we have around: DCCP is hopeless, who cares. We also have SCTP,
that is deployed by telcos in datacenters, it cannot reach that domain
because many Internet gateways are broken for it, so you may not get
too far with it. Arguably it would be good to have SCTP support at
some point, but I guess this is not a priority now. Then, UDPlite
almost comes for free since it relies on the existing UDP
infrastructure, it's basically UDP with a bit more features. What
else?
> > This would require more work though, but this would come with no
> > hooks in the stack and packets will not have to consume *lots of
> > cycles* just to be dropped before entering the socket queue.
>
> packets don't consume 'lost of cycles'. This is not a typical
> n-tuple firewall framework. Not a DoS mitigation either. Please read
> the cover letter and earlier submissions.
> It's a framework centered around cgroups.
> _Nothing_ in the current stack provides cgroup based monitoring
> and application protection. Earlier cgroupv1 controllers don't
> scale and we really cannot have more of v1 net controllers.
> At the same time we've been brainstorming how this patch set
> can work with v1. It's not easy. We're not giving up though.
> For now it's v2 only.
> Note that another two patchsets depend on this core cgroup+bpf framework.
I saw those, I would really like to have a closer look at David
Ahern's usecase since that skb iif mangling looks kludgy to me, and
given this is exposing a new helper for general use, not only vrf, it
would be good to make sure helpers provide something useful for
everyone. So that new helper is questionable at this stage IMO. I'm
concerned that people may start using bpf as the adhesive tape to glue
things to solve probably design problems.
The other patchset, I guess you refer to the new lsm module: I would
suggest we address one thing at a time, I guess he can starts without
relying on this chunk, as it can follow up later anyway.
In general, I think bpf is very useful, but I think we have to
accomodate new things in a way that makes sense into what we have. We
have traditionally followed an "add in-kernel infrastructured +
provide userspace interface as control plane" approach for long time.
I have concerns (and my impression is that others were concerned in
netconf too) on if we can go from the existing approach to a fully
uninfrastructured use-bpf-everywhere, from one day to another without
even taking the time to discuss the consequences of this decision.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v1 13/16] tipc: create TIPC_DISCONNECTING as a new sk_state
From: Parthasarathy Bhuvaragan @ 2016-10-28 11:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, tipc-discussion, jon.maloy, maloy, ying.xue
In-Reply-To: <1477580603.7065.210.camel@edumazet-glaptop3.roam.corp.google.com>
On 10/27/2016 05:03 PM, Eric Dumazet wrote:
> On Thu, 2016-10-27 at 16:22 +0200, Parthasarathy Bhuvaragan wrote:
>> In this commit, we create a new tipc socket state TIPC_DISCONNECTING in
>> sk_state. TIPC_DISCONNECTING is replacing the socket connection status
>> update using SS_DISCONNECTING.
>> TIPC_DISCONNECTING is set for connection oriented sockets at:
>> - tipc_shutdown()
>> - connection probe timeout
>> - when we receive an error message on the connection.
>>
>> There is no functional change in this commit.
>>
>> Acked-by: Ying Xue <ying.xue@windriver.com>
>> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
>> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
>> ---
>> include/uapi/linux/tipc.h | 1 +
>> net/tipc/socket.c | 39 +++++++++++++++++++++++----------------
>> 2 files changed, 24 insertions(+), 16 deletions(-)
>>
>> diff --git a/include/uapi/linux/tipc.h b/include/uapi/linux/tipc.h
>> index ae45de5e0d93..f5c03fdfc8a8 100644
>> --- a/include/uapi/linux/tipc.h
>> +++ b/include/uapi/linux/tipc.h
>> @@ -184,6 +184,7 @@ enum {
>> TIPC_PROBING,
>> TIPC_ESTABLISHED,
>> TIPC_OPEN,
>> + TIPC_DISCONNECTING,
>> };
>
>
> Note that all these TIPC socket states might conflict with
> sk_fullsock(), sk_listener(), inet6_sk(), ip_skb_dst_mtu(),
> sk_const_to_full_sk() , skb_to_full_sk() helpers.
>
> So there is definitely a high risk.
>
>
Eric, i can map the tipc state to a corresponding tcp state like the
patch below. This resembles the way its done in l2tp and sctp.
Do you see any issue with that?
diff --git a/include/uapi/linux/tipc.h b/include/uapi/linux/tipc.h
index f2d9294d0920..e697f809549e 100644
--- a/include/uapi/linux/tipc.h
+++ b/include/uapi/linux/tipc.h
@@ -180,15 +180,17 @@ struct tipc_event {
* Definitions for the TIPC protocol sk_state field.
*/
enum {
- TIPC_LISTEN = 1,
- TIPC_PROBING,
- TIPC_ESTABLISHED,
- TIPC_OPEN,
- TIPC_DISCONNECTING,
- TIPC_CLOSING,
- TIPC_CONNECTING,
+ TIPC_LISTEN = TCP_LISTEN,
+ TIPC_ESTABLISHED = TCP_ESTABLISHED,
+ TIPC_CLOSE = TCP_CLOSE,
+ TIPC_CONNECTING = TCP_SYN_SENT,
+ TIPC_DISCONNECTING = TCP_CLOSE_WAIT,
};
I will deleted TIPC_OPEN and TIPC_PROBING, the former can be set to
TIPC_CLOSE like its done in tcp and the later can be replaced this with
a probes_out counter.
/Partha
^ permalink raw reply related
* Bonding MAC address
From: Igor Ryzhov @ 2016-10-28 11:09 UTC (permalink / raw)
To: netdev
Hello everyone,
Studying the bonding driver I found that bonding device doesn't choose a new MAC address when the slave which MAC is in use is released.
This is a warning about that - "the permanent HWaddr of slave is still in use by bond - set the HWaddr of slave to a different address to avoid conflicts".
Why not to choose a new MAC for bonding device? Is it intentional or just not implemented?
Best regards,
Igor
^ permalink raw reply
* [v2] pull-request: mac80211-next 2016-10-28
From: Johannes Berg @ 2016-10-28 11:02 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
First update for 4.10 - nothing major, new features as usual (FILS), and
sometimes we deprecate old stuff (WDS).
I don't have the fixes for the on-stack crypto/SG handling in this tree
(you already have them via mac80211.git), but we did make sure that the
fils_aead code doesn't re-introduce such an issue.
This one is with Arnd's fix included.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 6b25e21fa6f26d0f0d45f161d169029411c84286:
Merge tag 'drm-for-v4.9' of git://people.freedesktop.org/~airlied/linux (2016-10-11 18:12:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-10-28
for you to fetch changes up to 514877182b537372352c14a0a50822572f66e831:
mac80211: fils_aead: fix encrypt error handling (2016-10-28 12:59:12 +0200)
----------------------------------------------------------------
Among various cleanups and improvements, we have the following:
* client FILS authentication support in mac80211 (Jouni)
* AP/VLAN multicast improvements (Michael Braun)
* config/advertising support for differing beacon intervals on
multiple virtual interfaces (Purushottam Kushwaha, myself)
* deprecate the old WDS mode for cfg80211-based drivers, the
mode is hardly usable since it doesn't support any "modern"
features like WPA encryption (2003), HT (2009) or VHT (2014),
I'm not even sure WEP (introduced in 1997) could be done.
----------------------------------------------------------------
Andrei Otcheretianski (1):
cfg80211: allow vendor commands to be sent to nan interface
Arend Van Spriel (1):
cfg80211: add generic helper to check interface is running
Arnd Bergmann (1):
mac80211: fils_aead: fix encrypt error handling
Emmanuel Grumbach (2):
mac80211: allow the driver not to pass the tid to ieee80211_sta_uapsd_trigger
mac80211: uapsd_queues is in QoS IE order
Ilan Peer (1):
cfg80211: allow aborting in-progress connection atttempts
Johannes Berg (17):
mac80211: remove unnecessary mesh check
mac80211_hwsim: make multi-channel ops const
mac80211: preserve more bits when building QoS header
nl80211: correctly use nl80211_nan_srf_policy
nl80211: ifdef WoWLAN related policies
wireless: radiotap: fix timestamp sampling position values
mac80211: fix tid_agg_rx NULL dereference
mac80211: improve RX aggregation data in debugfs
wireless: deprecate WDS and disable by default
cfg80211: fix beacon interval in interface combination iteration
cfg80211: mesh: track (and thus validate) beacon interval
cfg80211: disallow beacon_int_min_gcd with IBSS
cfg80211: validate beacon int as part of iface combinations
mac80211: validate new interface's beacon intervals
nl80211: move unsplit command advertising to a separate function
nl80211: use nla_parse_nested() instead of nla_parse()
cfg80211: handle fragmented IEs in splitting
Jouni Malinen (9):
cfg80211: Rename SAE_DATA to more generic AUTH_DATA
mac80211: Allow AUTH_DATA to be used for FILS
cfg80211: Add feature flag for Fast Initial Link Setup (FILS) as STA
cfg80211: Define IEEE P802.11ai (FILS) information elements
cfg80211: Add Fast Initial Link Setup (FILS) auth algs
cfg80211: Add KEK/nonces for FILS association frames
mac80211: Add FILS auth alg mapping
mac80211: FILS AEAD protection for station mode association frames
mac80211: Claim Fast Initial Link Setup (FILS) STA support
Linus Lüssing (1):
mac80211_hwsim: suggest nl80211 instead of wext driver in documentation
Michael Braun (5):
mac80211: remove unnecessary num_mcast_sta check
mac80211: filter multicast data packets on AP / AP_VLAN
mac80211: avoid extra memcpy in A-MSDU head creation
mac80211: fix A-MSDU outer SA/DA
cfg80211: configure multicast to unicast for AP interfaces
Purushottam Kushwaha (2):
cfg80211: pass struct to interface combination check/iter
cfg80211: support virtual interfaces with different beacon intervals
Sara Sharon (1):
mac80211: add a HW flag for supporting HW TX fragmentation
Wei Yongjun (1):
cfg80211: fix possible memory leak in cfg80211_iter_combinations()
vamsi krishna (1):
cfg80211: Add support to update connection parameters
Documentation/networking/mac80211_hwsim/README | 2 +-
drivers/net/wireless/Kconfig | 13 +
drivers/net/wireless/ath/ath10k/mac.c | 1 +
drivers/net/wireless/ath/ath9k/init.c | 6 +
drivers/net/wireless/broadcom/b43/main.c | 2 +
drivers/net/wireless/broadcom/b43legacy/main.c | 2 +
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 22 +-
drivers/net/wireless/mac80211_hwsim.c | 79 ++--
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 6 +-
drivers/net/wireless/ti/wlcore/main.c | 1 +
include/linux/ieee80211.h | 26 ++
include/net/cfg80211.h | 150 +++++--
include/net/ieee80211_radiotap.h | 4 +-
include/net/mac80211.h | 19 +-
include/uapi/linux/nl80211.h | 69 +++-
net/mac80211/Makefile | 1 +
net/mac80211/aes_cmac.c | 8 +-
net/mac80211/aes_cmac.h | 4 +
net/mac80211/agg-rx.c | 8 +-
net/mac80211/cfg.c | 35 +-
net/mac80211/debugfs.c | 1 +
net/mac80211/debugfs_netdev.c | 11 +
net/mac80211/debugfs_sta.c | 9 +-
net/mac80211/fils_aead.c | 342 ++++++++++++++++
net/mac80211/fils_aead.h | 19 +
net/mac80211/ieee80211_i.h | 26 +-
net/mac80211/iface.c | 16 +
net/mac80211/main.c | 5 +
net/mac80211/mlme.c | 60 ++-
net/mac80211/rx.c | 11 +-
net/mac80211/sta_info.c | 23 +-
net/mac80211/sta_info.h | 4 +-
net/mac80211/tx.c | 55 ++-
net/mac80211/util.c | 61 +--
net/mac80211/wme.c | 23 +-
net/mac80211/wpa.c | 2 +-
net/wireless/core.c | 33 +-
net/wireless/core.h | 4 +-
net/wireless/mesh.c | 2 +
net/wireless/mlme.c | 6 +-
net/wireless/nl80211.c | 445 +++++++++++++--------
net/wireless/rdev-ops.h | 24 ++
net/wireless/sme.c | 2 +-
net/wireless/trace.h | 37 ++
net/wireless/util.c | 125 ++++--
45 files changed, 1383 insertions(+), 421 deletions(-)
create mode 100644 net/mac80211/fils_aead.c
create mode 100644 net/mac80211/fils_aead.h
^ permalink raw reply
* Re: [PATCH] mac80211: fils_aead: fix encrypt error handling
From: Johannes Berg @ 2016-10-28 10:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Jouni Malinen, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20161028102621.1881878-1-arnd@arndb.de>
On Fri, 2016-10-28 at 12:25 +0200, Arnd Bergmann wrote:
> gcc -Wmaybe-uninitialized reports a bug in aes_siv_encryp:
>
> net/mac80211/fils_aead.c: In function ‘aes_siv_encrypt.constprop’:
> net/mac80211/fils_aead.c:84:26: error: ‘tfm2’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>
> At the time that the memory allocation fails, 'tfm2' has not been
> allocated, so we should not attempt to free it later, and we can
> simply return an error.
>
> Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode
> association frames")
Ahrg, how did I miss that.
Dave, I'll apply this, and send a new pull request.
johannes
^ permalink raw reply
* Re: [v15, 0/7] Fix eSDHC host version register bug
From: Arnd Bergmann @ 2016-10-28 10:53 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Yangbo Lu, linux-mmc, ulf.hansson, Scott Wood, Mark Rutland,
Greg Kroah-Hartman, Xiaobo Xie, Minghuan Lian, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Jochen Friedrich, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, netdev, linux-kernel, Leo Li, iommu
In-Reply-To: <1477637418-38938-1-git-send-email-yangbo.lu@nxp.com>
On Friday, October 28, 2016 2:50:11 PM CEST Yangbo Lu wrote:
> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 10 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only available
> method left now. This v11 patchset introduces the soc_device_match interface in
> soc driver.
>
> The first five patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
Looks good overall. With patch 3 dropped (or an explanation why it's still
needed), everything
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply
* Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Arnd Bergmann @ 2016-10-28 10:52 UTC (permalink / raw)
To: linuxppc-dev
Cc: Yangbo Lu, linux-mmc, ulf.hansson, Scott Wood, Mark Rutland,
Greg Kroah-Hartman, Xiaobo Xie, Minghuan Lian, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Rob Herring, Santosh Shilimkar,
linux-arm-kernel, netdev, linux-kernel, Leo Li, iommu
In-Reply-To: <1477637418-38938-4-git-send-email-yangbo.lu@nxp.com>
On Friday, October 28, 2016 2:50:14 PM CEST Yangbo Lu wrote:
> Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
> header file. This SVR numberspace is used on some ARM chips as well as
> PPC, and even to check for a PPC SVR multi-arch drivers would otherwise
> need to ifdef the header inclusion and all references to the SVR symbols.
>
>
I don't see any of the contents of this header referenced by the soc driver
any more. I think you can just drop this patch.
Arnd
^ permalink raw reply
* Re: [v15, 6/7] base: soc: introduce soc_device_match() interface
From: Arnd Bergmann @ 2016-10-28 10:47 UTC (permalink / raw)
To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
Geert Uytterhoeven, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Minghuan Lian, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil, devicetree-u79uwXL29TY76Z2rM5mHXA,
Kumar Gala, Scott Wood, Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman, linux-mmc-u79uwXL29TY76Z2rM5mHXA, Xiaobo Xie,
Leo Li, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Yangbo Lu
In-Reply-To: <1477637418-38938-7-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
On Friday, October 28, 2016 2:50:17 PM CEST Yangbo Lu wrote:
> +
> +static int soc_device_match_one(struct device *dev, void *arg)
> +{
> + struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
> + const struct soc_device_attribute *match = arg;
> +
> + if (match->machine &&
> + !glob_match(match->machine, soc_dev->attr->machine))
> + return 0;
> +
> + if (match->family &&
> + !glob_match(match->family, soc_dev->attr->family))
> + return 0;
> +
>
Geert found a bug in my code, and submitted a fix at
https://patchwork.kernel.org/patch/9361395/
I think you should include that one in your series.
Arnd
^ permalink raw reply
* [PATCH net-next 1/1] net: phy: Add support for Microsemi VSC 8530/40 Fast Ethernet PHY
From: Allan W. Nielsen @ 2016-10-28 10:10 UTC (permalink / raw)
To: netdev; +Cc: andrew, raju.lakkaraju, allan.nielsen, Raju Lakkaraju
In-Reply-To: <1477649411-31036-1-git-send-email-allan.nielsen@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
---
drivers/net/phy/Kconfig | 2 +-
drivers/net/phy/mscc.c | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 45f68ea..ff31c10 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -290,7 +290,7 @@ config MICROCHIP_PHY
config MICROSEMI_PHY
tristate "Microsemi PHYs"
---help---
- Currently supports the VSC8531 and VSC8541 PHYs
+ Currently supports VSC8530, VSC8531, VSC8540 and VSC8541 PHYs
config NATIONAL_PHY
tristate "National Semiconductor PHYs"
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index 113616b..d0026ab 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -65,7 +65,9 @@ enum rgmii_rx_clock_delay {
#define SECURE_ON_PASSWD_LEN_4 0x4000
/* Microsemi PHY ID's */
+#define PHY_ID_VSC8530 0x00070560
#define PHY_ID_VSC8531 0x00070570
+#define PHY_ID_VSC8540 0x00070760
#define PHY_ID_VSC8541 0x00070770
#define MSCC_VDDMAC_1500 1500
@@ -399,6 +401,25 @@ static int vsc85xx_probe(struct phy_device *phydev)
/* Microsemi VSC85xx PHYs */
static struct phy_driver vsc85xx_driver[] = {
{
+ .phy_id = PHY_ID_VSC8530,
+ .name = "Microsemi FE VSC8530",
+ .phy_id_mask = 0xfffffff0,
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .soft_reset = &genphy_soft_reset,
+ .config_init = &vsc85xx_config_init,
+ .config_aneg = &genphy_config_aneg,
+ .aneg_done = &genphy_aneg_done,
+ .read_status = &genphy_read_status,
+ .ack_interrupt = &vsc85xx_ack_interrupt,
+ .config_intr = &vsc85xx_config_intr,
+ .suspend = &genphy_suspend,
+ .resume = &genphy_resume,
+ .probe = &vsc85xx_probe,
+ .set_wol = &vsc85xx_wol_set,
+ .get_wol = &vsc85xx_wol_get,
+},
+{
.phy_id = PHY_ID_VSC8531,
.name = "Microsemi VSC8531",
.phy_id_mask = 0xfffffff0,
@@ -418,6 +439,25 @@ static struct phy_driver vsc85xx_driver[] = {
.get_wol = &vsc85xx_wol_get,
},
{
+ .phy_id = PHY_ID_VSC8540,
+ .name = "Microsemi FE VSC8540 SyncE",
+ .phy_id_mask = 0xfffffff0,
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .soft_reset = &genphy_soft_reset,
+ .config_init = &vsc85xx_config_init,
+ .config_aneg = &genphy_config_aneg,
+ .aneg_done = &genphy_aneg_done,
+ .read_status = &genphy_read_status,
+ .ack_interrupt = &vsc85xx_ack_interrupt,
+ .config_intr = &vsc85xx_config_intr,
+ .suspend = &genphy_suspend,
+ .resume = &genphy_resume,
+ .probe = &vsc85xx_probe,
+ .set_wol = &vsc85xx_wol_set,
+ .get_wol = &vsc85xx_wol_get,
+},
+{
.phy_id = PHY_ID_VSC8541,
.name = "Microsemi VSC8541 SyncE",
.phy_id_mask = 0xfffffff0,
@@ -442,7 +482,9 @@ static struct phy_driver vsc85xx_driver[] = {
module_phy_driver(vsc85xx_driver);
static struct mdio_device_id __maybe_unused vsc85xx_tbl[] = {
+ { PHY_ID_VSC8530, 0xfffffff0, },
{ PHY_ID_VSC8531, 0xfffffff0, },
+ { PHY_ID_VSC8540, 0xfffffff0, },
{ PHY_ID_VSC8541, 0xfffffff0, },
{ }
};
--
2.7.3
^ permalink raw reply related
* [PATCH] mac80211: fils_aead: fix encrypt error handling
From: Arnd Bergmann @ 2016-10-28 10:25 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, David S. Miller, Jouni Malinen, linux-wireless,
netdev, linux-kernel
gcc -Wmaybe-uninitialized reports a bug in aes_siv_encryp:
net/mac80211/fils_aead.c: In function ‘aes_siv_encrypt.constprop’:
net/mac80211/fils_aead.c:84:26: error: ‘tfm2’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
At the time that the memory allocation fails, 'tfm2' has not been
allocated, so we should not attempt to free it later, and we can
simply return an error.
Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/mac80211/fils_aead.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/fils_aead.c b/net/mac80211/fils_aead.c
index b81b4f2472cf..ecfdd97758a3 100644
--- a/net/mac80211/fils_aead.c
+++ b/net/mac80211/fils_aead.c
@@ -110,10 +110,8 @@ static int aes_siv_encrypt(const u8 *key, size_t key_len,
* overwriting this during AES-CTR.
*/
tmp = kmemdup(plain, plain_len, GFP_KERNEL);
- if (!tmp) {
- res = -ENOMEM;
- goto fail;
- }
+ if (!tmp)
+ return -ENOMEM;
/* IV for CTR before encrypted data */
memcpy(out, v, AES_BLOCK_SIZE);
--
2.9.0
^ permalink raw reply related
* [PATCH net] ipv6: add mtu lock check in __ip6_rt_update_pmtu
From: Xin Long @ 2016-10-28 10:18 UTC (permalink / raw)
To: network dev; +Cc: davem, hannes
Prior to this patch, ipv6 didn't do mtu lock check in ip6_update_pmtu.
It leaded to that mtu lock doesn't really work when receiving the pkt
of ICMPV6_PKT_TOOBIG.
This patch is to add mtu lock check in __ip6_rt_update_pmtu just as ipv4
did in __ip_rt_update_pmtu.
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv6/route.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 947ed1d..7403d90 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1364,6 +1364,9 @@ static void __ip6_rt_update_pmtu(struct dst_entry *dst, const struct sock *sk,
if (rt6->rt6i_flags & RTF_LOCAL)
return;
+ if (dst_metric_locked(dst, RTAX_MTU))
+ return;
+
dst_confirm(dst);
mtu = max_t(u32, mtu, IPV6_MIN_MTU);
if (mtu >= dst_mtu(dst))
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] Revert "usb: dwc3: gadget: use allocated/queued reqs for LST bit"
From: Felipe Balbi @ 2016-10-28 10:16 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: linux-usb, stable, davem, Oliver Neukum, netdev
In-Reply-To: <20161027154016.GD4617@intel.com>
[-- Attachment #1: Type: text/plain, Size: 5856 bytes --]
Hi,
Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> On Thu, Oct 06, 2016 at 12:08:26PM +0300, Ville Syrjälä wrote:
>> On Thu, Oct 06, 2016 at 10:36:09AM +0300, Felipe Balbi wrote:
>> >
>> > Hi,
>> >
>> > Felipe Balbi <felipe.balbi@linux.intel.com> writes:
>> <snip>
>> > Okay, I have found a regression on dwc3 and another patch follows:
>> >
>> > commit 5e1a2af3e46248c55098cdae643c4141851b703e
>> > Author: Felipe Balbi <felipe.balbi@linux.intel.com>
>> > Date: Wed Oct 5 14:24:37 2016 +0300
>> >
>> > usb: dwc3: gadget: properly account queued requests
>> >
>> > Some requests could be accounted for multiple
>> > times. Let's fix that so each and every requests is
>> > accounted for only once.
>> >
>> > Cc: <stable@vger.kernel.org> # v4.8
>> > Fixes: 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for LST bit")
>> > Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>> >
>> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> > index 07cc8929f271..3c3ced128c77 100644
>> > --- a/drivers/usb/dwc3/gadget.c
>> > +++ b/drivers/usb/dwc3/gadget.c
>> > @@ -783,6 +783,7 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
>> > req->trb = trb;
>> > req->trb_dma = dwc3_trb_dma_offset(dep, trb);
>> > req->first_trb_index = dep->trb_enqueue;
>> > + dep->queued_requests++;
>> > }
>> >
>> > dwc3_ep_inc_enq(dep);
>> > @@ -833,8 +834,6 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
>> >
>> > trb->ctrl |= DWC3_TRB_CTRL_HWO;
>> >
>> > - dep->queued_requests++;
>> > -
>> > trace_dwc3_prepare_trb(dep, trb);
>> > }
>> >
>> > @@ -1861,8 +1860,11 @@ static int __dwc3_cleanup_done_trbs(struct dwc3 *dwc, struct dwc3_ep *dep,
>> > unsigned int s_pkt = 0;
>> > unsigned int trb_status;
>> >
>> > - dep->queued_requests--;
>> > dwc3_ep_inc_deq(dep);
>> > +
>> > + if (req->trb == trb)
>> > + dep->queued_requests--;
>> > +
>> > trace_dwc3_complete_trb(dep, trb);
>> >
>> > /*
>> >
>> > I have also built a branch which you can use for testing. Here's a pull
>> > request, once you tell me it works for you, then I can send proper
>> > patches out:
>> >
>> > The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
>> >
>> > Linux 4.8 (2016-10-02 16:24:33 -0700)
>> >
>> > are available in the git repository at:
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tmp-test-v4.8
>> >
>> > for you to fetch changes up to c968b8d1effe64a7980802d1eef29f4e1922faca:
>> >
>> > usb: dwc3: gadget: properly account queued requests (2016-10-06 10:16:37 +0300)
>> >
>> > ----------------------------------------------------------------
>> > Felipe Balbi (2):
>> > usb: gadget: function: u_ether: don't starve tx request queue
>> > usb: dwc3: gadget: properly account queued requests
>> >
>> > drivers/usb/dwc3/gadget.c | 7 ++++---
>> > drivers/usb/gadget/function/u_ether.c | 5 +++--
>> > 2 files changed, 7 insertions(+), 5 deletions(-)
>>
>> Tried your branch, but unfortunately I'm still seeing the lags. New trace
>> attached.
>
> Just a reminder that the regressions is still there in 4.9-rc2.
> Unfortunateyly with all the stuff already piled on top, getting USB
> working on my device is no longer a simple matter of reverting the
> one commit. I had to revert 10 patches to get even a clean revert, but
> unfortunately that approach just lead to the transfer hanging immediately.
>
> So what I ended up doing is reverting all of this:
> git log --no-merges --format=oneline 55a0237f8f47957163125e20ee9260538c5c341c^..HEAD -- drivers/usb/dwc3/ include/linux/ulpi/interface.h drivers/usb/Kconfig drivers/usb/core/Kconfig
>
> which comes out at whopping 70 commits. Having to carry that around
> is going to be quite a pain especially as more stuff might be piled on
> top.
>
> /me thinks a stable backport of any fix (assuming one is found
> eventually) is going to be quite the challenge...
Yeah, I'm guessing we're gonna need some help from networking folks. The
only thing we did since v4.7 was actually respect req->no_interrupt flag
coming from u_ether itself. No idea why that causes so much trouble for
u_ether.
BTW, Instead of reverting so many patches, you can just remove
throttling:
diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
index f4a640216913..119a2e5848e8 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -589,14 +589,6 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
req->length = length;
- /* throttle high/super speed IRQ rate back slightly */
- if (gadget_is_dualspeed(dev->gadget))
- req->no_interrupt = (((dev->gadget->speed == USB_SPEED_HIGH ||
- dev->gadget->speed == USB_SPEED_SUPER)) &&
- !list_empty(&dev->tx_reqs))
- ? ((atomic_read(&dev->tx_qlen) % dev->qmult) != 0)
- : 0;
-
retval = usb_ep_queue(in, req, GFP_ATOMIC);
switch (retval) {
default:
I'm adding netdev and couple other folks to the loop.
Just to summarize, USB peripheral controller now actually throttles
interrupt when requested to do so and that causes lags for USB
networking gadgets.
Without throttle we, potentially, call netif_wake_queue() more
frequently than with throttling. I'm wondering if something changed in
NET layer within the past few years but the USB networking gadgets ended
up being forgotten.
Anyway, if anybody has any hints, I'd be glad to hear about them.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply related
* [PATCH net 3/3] sctp: hold transport instead of assoc when lookup assoc in rx path
From: Xin Long @ 2016-10-28 10:10 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, Marcelo Ricardo Leitner, Vlad Yasevich, daniel
In-Reply-To: <cover.1477649076.git.lucien.xin@gmail.com>
Prior to this patch, in rx path, before calling lock_sock, it needed to
hold assoc when got it by __sctp_lookup_association, in case other place
would free/put assoc.
But in __sctp_lookup_association, it lookup and hold transport, then got
assoc by transport->assoc, then hold assoc and put transport. It means
it didn't hold transport, yet it was returned and later on directly
assigned to chunk->transport.
Without the protection of sock lock, the transport may be freed/put by
other places, which would cause a use-after-free issue.
This patch is to fix this issue by holding transport instead of assoc.
As holding transport can make sure to access assoc is also safe, and
actually it looks up assoc by searching transport rhashtable, to hold
transport here makes more sense.
Note that the function will be renamed later on on another patch.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/sctp/sctp.h | 2 +-
net/sctp/input.c | 32 ++++++++++++++++----------------
net/sctp/ipv6.c | 2 +-
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 87a7f42..31acc3f 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -152,7 +152,7 @@ void sctp_unhash_endpoint(struct sctp_endpoint *);
struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *,
struct sctphdr *, struct sctp_association **,
struct sctp_transport **);
-void sctp_err_finish(struct sock *, struct sctp_association *);
+void sctp_err_finish(struct sock *, struct sctp_transport *);
void sctp_icmp_frag_needed(struct sock *, struct sctp_association *,
struct sctp_transport *t, __u32 pmtu);
void sctp_icmp_redirect(struct sock *, struct sctp_transport *,
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 8e0bc58..a01a56e 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -181,9 +181,10 @@ int sctp_rcv(struct sk_buff *skb)
* bound to another interface, via SO_BINDTODEVICE, treat it as OOTB
*/
if (sk->sk_bound_dev_if && (sk->sk_bound_dev_if != af->skb_iif(skb))) {
- if (asoc) {
- sctp_association_put(asoc);
+ if (transport) {
+ sctp_transport_put(transport);
asoc = NULL;
+ transport = NULL;
} else {
sctp_endpoint_put(ep);
ep = NULL;
@@ -269,8 +270,8 @@ int sctp_rcv(struct sk_buff *skb)
bh_unlock_sock(sk);
/* Release the asoc/ep ref we took in the lookup calls. */
- if (asoc)
- sctp_association_put(asoc);
+ if (transport)
+ sctp_transport_put(transport);
else
sctp_endpoint_put(ep);
@@ -283,8 +284,8 @@ int sctp_rcv(struct sk_buff *skb)
discard_release:
/* Release the asoc/ep ref we took in the lookup calls. */
- if (asoc)
- sctp_association_put(asoc);
+ if (transport)
+ sctp_transport_put(transport);
else
sctp_endpoint_put(ep);
@@ -300,6 +301,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
{
struct sctp_chunk *chunk = SCTP_INPUT_CB(skb)->chunk;
struct sctp_inq *inqueue = &chunk->rcvr->inqueue;
+ struct sctp_transport *t = chunk->transport;
struct sctp_ep_common *rcvr = NULL;
int backloged = 0;
@@ -351,7 +353,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
done:
/* Release the refs we took in sctp_add_backlog */
if (SCTP_EP_TYPE_ASSOCIATION == rcvr->type)
- sctp_association_put(sctp_assoc(rcvr));
+ sctp_transport_put(t);
else if (SCTP_EP_TYPE_SOCKET == rcvr->type)
sctp_endpoint_put(sctp_ep(rcvr));
else
@@ -363,6 +365,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
static int sctp_add_backlog(struct sock *sk, struct sk_buff *skb)
{
struct sctp_chunk *chunk = SCTP_INPUT_CB(skb)->chunk;
+ struct sctp_transport *t = chunk->transport;
struct sctp_ep_common *rcvr = chunk->rcvr;
int ret;
@@ -373,7 +376,7 @@ static int sctp_add_backlog(struct sock *sk, struct sk_buff *skb)
* from us
*/
if (SCTP_EP_TYPE_ASSOCIATION == rcvr->type)
- sctp_association_hold(sctp_assoc(rcvr));
+ sctp_transport_hold(t);
else if (SCTP_EP_TYPE_SOCKET == rcvr->type)
sctp_endpoint_hold(sctp_ep(rcvr));
else
@@ -537,15 +540,15 @@ struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *skb,
return sk;
out:
- sctp_association_put(asoc);
+ sctp_transport_put(transport);
return NULL;
}
/* Common cleanup code for icmp/icmpv6 error handler. */
-void sctp_err_finish(struct sock *sk, struct sctp_association *asoc)
+void sctp_err_finish(struct sock *sk, struct sctp_transport *t)
{
bh_unlock_sock(sk);
- sctp_association_put(asoc);
+ sctp_transport_put(t);
}
/*
@@ -641,7 +644,7 @@ void sctp_v4_err(struct sk_buff *skb, __u32 info)
}
out_unlock:
- sctp_err_finish(sk, asoc);
+ sctp_err_finish(sk, transport);
}
/*
@@ -952,11 +955,8 @@ static struct sctp_association *__sctp_lookup_association(
goto out;
asoc = t->asoc;
- sctp_association_hold(asoc);
*pt = t;
- sctp_transport_put(t);
-
out:
return asoc;
}
@@ -986,7 +986,7 @@ int sctp_has_association(struct net *net,
struct sctp_transport *transport;
if ((asoc = sctp_lookup_association(net, laddr, paddr, &transport))) {
- sctp_association_put(asoc);
+ sctp_transport_put(transport);
return 1;
}
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index f473779..176af30 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -198,7 +198,7 @@ static void sctp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
}
out_unlock:
- sctp_err_finish(sk, asoc);
+ sctp_err_finish(sk, transport);
out:
if (likely(idev != NULL))
in6_dev_put(idev);
--
2.1.0
^ permalink raw reply related
* [PATCH net 2/3] sctp: return back transport in __sctp_rcv_init_lookup
From: Xin Long @ 2016-10-28 10:10 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, Marcelo Ricardo Leitner, Vlad Yasevich, daniel
In-Reply-To: <cover.1477649076.git.lucien.xin@gmail.com>
Prior to this patch, it used a local variable to save the transport that is
looked up by __sctp_lookup_association(), and didn't return it back. But in
sctp_rcv, it is used to initialize chunk->transport. So when hitting this
code, it was initializing chunk->transport with some random stack value
instead.
This patch is to return the transport back through transport pointer
that is from __sctp_rcv_lookup_harder().
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/input.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/sctp/input.c b/net/sctp/input.c
index a2ea1d1..8e0bc58 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -1021,7 +1021,6 @@ static struct sctp_association *__sctp_rcv_init_lookup(struct net *net,
struct sctphdr *sh = sctp_hdr(skb);
union sctp_params params;
sctp_init_chunk_t *init;
- struct sctp_transport *transport;
struct sctp_af *af;
/*
@@ -1052,7 +1051,7 @@ static struct sctp_association *__sctp_rcv_init_lookup(struct net *net,
af->from_addr_param(paddr, params.addr, sh->source, 0);
- asoc = __sctp_lookup_association(net, laddr, paddr, &transport);
+ asoc = __sctp_lookup_association(net, laddr, paddr, transportp);
if (asoc)
return asoc;
}
--
2.1.0
^ permalink raw reply related
* [PATCH net 1/3] sctp: hold transport instead of assoc in sctp_diag
From: Xin Long @ 2016-10-28 10:10 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, Marcelo Ricardo Leitner, Vlad Yasevich, daniel
In-Reply-To: <cover.1477649076.git.lucien.xin@gmail.com>
In sctp_transport_lookup_process(), Commit 1cceda784980 ("sctp: fix
the issue sctp_diag uses lock_sock in rcu_read_lock") moved cb() out
of rcu lock, but it put transport and hold assoc instead, and ignore
that cb() still uses transport. It may cause a use-after-free issue.
This patch is to hold transport instead of assoc there.
Fixes: 1cceda784980 ("sctp: fix the issue sctp_diag uses lock_sock in rcu_read_lock")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/socket.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 9fbb6fe..71b75f9 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4480,12 +4480,9 @@ int sctp_transport_lookup_process(int (*cb)(struct sctp_transport *, void *),
if (!transport || !sctp_transport_hold(transport))
goto out;
- sctp_association_hold(transport->asoc);
- sctp_transport_put(transport);
-
rcu_read_unlock();
err = cb(transport, p);
- sctp_association_put(transport->asoc);
+ sctp_transport_put(transport);
out:
return err;
--
2.1.0
^ permalink raw reply related
* [PATCH net 0/3] sctp: a bunch of fixes by holding transport
From: Xin Long @ 2016-10-28 10:10 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, Marcelo Ricardo Leitner, Vlad Yasevich, daniel
There are several places where it holds assoc after getting transport by
searching from transport rhashtable, it may cause use-after- free issue.
This patchset is to fix them by holding transport instead.
Xin Long (3):
sctp: hold transport instead of assoc in sctp_diag
sctp: return back transport in __sctp_rcv_init_lookup
sctp: hold transport instead of assoc when lookup assoc in rx path
include/net/sctp/sctp.h | 2 +-
net/sctp/input.c | 35 +++++++++++++++++------------------
net/sctp/ipv6.c | 2 +-
net/sctp/socket.c | 5 +----
4 files changed, 20 insertions(+), 24 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net-next 0/1] net: phy: Add support for Microsemi VSC 8530/40 Fast Ethernet PHY
From: Allan W. Nielsen @ 2016-10-28 10:10 UTC (permalink / raw)
To: netdev; +Cc: andrew, raju.lakkaraju, allan.nielsen
Hi All,
This patch adds support for VSC 8530/40 which is 10/100 Mbps variants of VSC
8531/41.
Please review.
Best regards
Allan and Raju
Raju Lakkaraju (1):
net: phy: Add support for Microsemi VSC 8530/40 Fast Ethernet PHY
drivers/net/phy/Kconfig | 2 +-
drivers/net/phy/mscc.c | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletion(-)
--
2.7.3
^ permalink raw reply
* [PATCH iproute2] ip: update link types to show 6lowpan and ieee802.15.4 monitor
From: Stefan Schmidt @ 2016-10-28 9:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-wpan, Stefan Schmidt
Both types have been missing here and thus ip always showed
only the numbers.
Based on a suggestion from Alexander Aring.
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
---
lib/ll_types.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/ll_types.c b/lib/ll_types.c
index 2c5bf8b..eca617f 100644
--- a/lib/ll_types.c
+++ b/lib/ll_types.c
@@ -100,11 +100,13 @@ __PF(IEEE80211,ieee802.11)
__PF(IEEE80211_PRISM,ieee802.11/prism)
__PF(IEEE80211_RADIOTAP,ieee802.11/radiotap)
__PF(IEEE802154, ieee802.15.4)
+__PF(IEEE802154_MONITOR, ieee802.15.4/monitor)
__PF(PHONET, phonet)
__PF(PHONET_PIPE, phonet_pipe)
__PF(CAIF, caif)
__PF(IP6GRE, gre6)
__PF(NETLINK, netlink)
+__PF(6LOWPAN, 6lowpan)
__PF(NONE, none)
__PF(VOID,void)
--
2.5.5
^ permalink raw reply related
* [PATCH] net: phy: dp83848: add dp83822 PHY support
From: Roger Quadros @ 2016-10-28 9:40 UTC (permalink / raw)
To: f.fainelli; +Cc: afd, dmurphy, netdev, linux-kernel, Roger Quadros
This PHY has a compatible register set with DP83848x so
add support for it.
Acked-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/net/phy/dp83848.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c
index 03d54c4..800b39f 100644
--- a/drivers/net/phy/dp83848.c
+++ b/drivers/net/phy/dp83848.c
@@ -19,6 +19,7 @@
#define TI_DP83848C_PHY_ID 0x20005ca0
#define NS_DP83848C_PHY_ID 0x20005c90
#define TLK10X_PHY_ID 0x2000a210
+#define TI_DP83822_PHY_ID 0x2000a240
/* Registers */
#define DP83848_MICR 0x11 /* MII Interrupt Control Register */
@@ -77,6 +78,7 @@ static struct mdio_device_id __maybe_unused dp83848_tbl[] = {
{ TI_DP83848C_PHY_ID, 0xfffffff0 },
{ NS_DP83848C_PHY_ID, 0xfffffff0 },
{ TLK10X_PHY_ID, 0xfffffff0 },
+ { TI_DP83822_PHY_ID, 0xfffffff0 },
{ }
};
MODULE_DEVICE_TABLE(mdio, dp83848_tbl);
@@ -105,6 +107,7 @@ static struct phy_driver dp83848_driver[] = {
DP83848_PHY_DRIVER(TI_DP83848C_PHY_ID, "TI DP83848C 10/100 Mbps PHY"),
DP83848_PHY_DRIVER(NS_DP83848C_PHY_ID, "NS DP83848C 10/100 Mbps PHY"),
DP83848_PHY_DRIVER(TLK10X_PHY_ID, "TI TLK10X 10/100 Mbps PHY"),
+ DP83848_PHY_DRIVER(TI_DP83822_PHY_ID, "TI DP83822 10/100 Mbps PHY"),
};
module_phy_driver(dp83848_driver);
--
2.7.4
^ permalink raw reply related
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