Re: [PATCH net-next v2 0/8] net: thunderx: New features and fixes
>> >> Series applied, thanks. >> -- Thanks a lot. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 net-next] netfilter: ipset: Fixing unnamed union initg
On Fri, Aug 28, 2015 at 4:21 PM, Akemi Yagi wrote: > On Fri, Aug 28, 2015 at 3:59 PM, Pablo Neira Ayuso > wrote: >> On Sat, Aug 22, 2015 at 08:44:48PM +0200, Pablo Neira Ayuso wrote: >> [...] >>> I'll wait for some little time just in case someone raises any >>> concern. >> >> JFYI, I'll be passing up this patch to David via the nf tree soon. >> Thanks. > > Thank you for pushing this forward. > > Akemi Linux 4.2 was released without this patch. Please also backport it to the 4.2 stable branch. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPv6 xfrm GSO fragmentation bug
On Sun, Aug 30, 2015 at 04:24:32PM +0800, Herbert Xu wrote: > Hi Steffen: > > I received a bug report regarding poor IPComp performance over > IPv6: > > https://bugzilla.redhat.com/show_bug.cgi?id=1257952 > > It appears to have been caused by > > commit dd767856a36e00b631d65ebc4bb81b19915532d6 > Author: Steffen Klassert > Date: Tue Oct 11 01:44:30 2011 + > > xfrm6: Don't call icmpv6_send on local error > > which addded an MTU check without a GSO override. > > Fixing it obviously isn't difficult, but I am wondering why I > can't find a corresponding patch for IPv4. Do we need that check > to be present in xfrm6_output at all? If we do why isn't it needed > for IPv4 as well? As far as I remember, this was to catch local message size errors before __xfrm6_output calls ip6_fragment which would use icmpv6_send for the error notification. IPv4 does not do fragmentation in the xfrm4_output functions, so this mtu check was not needed there. I think just adding the gso checks should be fine. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usbnet: Fix a race between usbnet_stop() and the BH
Eugene Shatokhin writes: > 28.08.2015 11:55, Bjørn Mork пишет: > >> I guess you are right. At least I cannot prove that you are not :) >> >> There is a bit too much complexity involved here for me... > > :-) > > Yes, it is quite complex. > > I admit, it was easier for me to find the races in usbnet (the tools > like KernelStrider and RaceHound do the dirty work) than to analyze > their consequences. The latter often requires some time and effort, > and so it did this time. > > Well, any objections to this patch? No objections from me. But I would have liked it much better if the code became simpler instead of more complex. Bjørn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPv6 xfrm GSO fragmentation bug
On Mon, Aug 31, 2015 at 09:19:16AM +0200, Steffen Klassert wrote: > > As far as I remember, this was to catch local message size > errors before __xfrm6_output calls ip6_fragment which would > use icmpv6_send for the error notification. IPv4 does not do > fragmentation in the xfrm4_output functions, so this mtu > check was not needed there. > > I think just adding the gso checks should be fine. I see where the bug came from. Indeed IPv6 does do fragmentation but only for tunnel mode. While your patch added a check that also affected transport mode. So in addition to the GSO fix we should also make the MTU check conditional to tunnel mode. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usbnet: Fix a race between usbnet_stop() and the BH
31.08.2015 10:32, Bjørn Mork пишет: Eugene Shatokhin writes: 28.08.2015 11:55, Bjørn Mork пишет: I guess you are right. At least I cannot prove that you are not :) There is a bit too much complexity involved here for me... :-) Yes, it is quite complex. I admit, it was easier for me to find the races in usbnet (the tools like KernelStrider and RaceHound do the dirty work) than to analyze their consequences. The latter often requires some time and effort, and so it did this time. Well, any objections to this patch? No objections from me. But I would have liked it much better if the code became simpler instead of more complex. Me too, but I can see no other way here. The code is simpler without locking, indeed, but locking is needed to prevent the problems described earlier. One needs to make sure that checking if txq or rxq is empty in usbnet_terminate_urbs() cannot get inbetween of processing of these queues and dev->done in defer_bh(). So 'list' and 'dev->done' must be updated under a common lock in defer_bh(). list->lock is an obvious candidate for this. For the same reason, skb_queue_empty(q) must be called under q->lock. So the code takes it, calls skb_queue_empty(q) and then releases it to wait a little. Rinse and repeat. The last complex piece is that spin_lock_nested() in defer_bh. It is safe to take both list->lock and dev->done.lock there (defer_bh can only be called for list = dev->rxq or dev->txq but not for dev->done). For lockdep, however, this is suspicious because '*list' and 'dev->done' are of the same type so the lock class is the same. So it complained. To tell lockdep it is OK to use such locking scheme in this particular case, the recommended pattern was used: spin_lock_nested with SINGLE_DEPTH_NESTING. Regards, Eugene -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 net-next 0/3] ipv4: Hash-based multipath routing
On 08/30/15 at 03:29pm, Tom Herbert wrote: > On Sun, Aug 30, 2015 at 2:28 PM, Peter N??rlund wrote: > > It would definitely be simpler, and it would be nice to just fetch the > > hash directly from the NIC - and for link aggregation it would probably > > be fine. But with L4, we always need to consider fragmented packets, > > which might cause some packets of a flow to be routed differently - and > > with ECMP, the ramifications of suddenly choosing another path for a > > flow are worse than for link aggregation. The latency through the > > different paths may differ enough to cause out-or-order packets and bad > > TCP performance as a consequence. Both Cisco and Juniper routers > > defaults to L3 for ECMP - exactly for that reason, I believe. RFC 2991 > > also points out that ports probably shouldn't be used as part of the > > flow key with ECMP. > > > That's more reason why we need vendors to use IPv6 flow label instead > of ports to do ECMP :-). In any case, if we're fragmenting TCP packets > then we're already in a bad place performance-wise-- we really don't > need to optimize for that case. Albeit, it would be nice if fragments > of packet followed same path, but the would require devices to not do > L4 hash over ports when MF is set-- I don't know if anyone does that > (I have been meaning to add that to stack). +1 for solving this at hash level. Being able to rely on the L4 HW hash for multipath routing is very desirable. A simple MF bit || FO > 0 check with fall back to flow dissector to generate an L3 hash in case the HW provided an L4 hash should be sufficient to address the fragmentation concern. Since performance is gone anyway, I'm not sure it's worth offloading this behaviour to the HW. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] ip-tunnel: Use API to access tunnel metadata options.
On 08/30/15 at 06:09pm, Pravin B Shelar wrote: > Currently tun-info options pointer is used in few cases to > pass options around. But tunnel options can be accessed using > ip_tunnel_info_opts() API without using the pointer. Following > patch removes the redundant pointer and consistently make use > of API. > > Signed-off-by: Pravin B Shelar Nice! Acked-by: Thomas Graf -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH iproute2] iplink: Add support for IFLA_BR_VLAN_PROTOCOL attribute
This patch adds support for bridge vlan_protocol.
Example:
$ ip link set br0 type bridge vlan_protocol 802.1ad
$ ip -d link show br0
4: br0: mtu 1500 qdisc noqueue state
UP mode DEFAULT group default qlen 1000
link/ether 44:37:e6:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity 0
bridge forward_delay 0 hello_time 200 max_age 2000 ageing_time 3
stp_state 0 priority 32768 vlan_filtering 0 vlan_protocol 802.1ad
addrgenmode eui64
Signed-off-by: Toshiaki Makita
---
include/linux/if_link.h | 1 +
ip/iplink_bridge.c | 21 +
2 files changed, 22 insertions(+)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 8f105cf..3c6d81c 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -229,6 +229,7 @@ enum {
IFLA_BR_STP_STATE,
IFLA_BR_PRIORITY,
IFLA_BR_VLAN_FILTERING,
+ IFLA_BR_VLAN_PROTOCOL,
__IFLA_BR_MAX,
};
diff --git a/ip/iplink_bridge.c b/ip/iplink_bridge.c
index f1c6968..0080409 100644
--- a/ip/iplink_bridge.c
+++ b/ip/iplink_bridge.c
@@ -14,6 +14,7 @@
#include
#include
+#include "rt_names.h"
#include "utils.h"
#include "ip_common.h"
@@ -27,6 +28,9 @@ static void print_explain(FILE *f)
" [ stp_state STP_STATE ]\n"
" [ priority PRIORITY ]\n"
" [ vlan_filtering VLAN_FILTERING ]\n"
+ " [ vlan_protocol VLAN_PROTOCOL ]\n"
+ "\n"
+ "Where: VLAN_PROTOCOL := { 802.1Q | 802.1ad }\n"
);
}
@@ -88,6 +92,15 @@ static int bridge_parse_opt(struct link_util *lu, int argc,
char **argv,
return -1;
}
addattr8(n, 1024, IFLA_BR_VLAN_FILTERING, vlan_filter);
+ } else if (matches(*argv, "vlan_protocol") == 0) {
+ __u16 vlan_proto;
+
+ NEXT_ARG();
+ if (ll_proto_a2n(&vlan_proto, *argv)) {
+ invarg("invalid vlan_protocol", *argv);
+ return -1;
+ }
+ addattr16(n, 1024, IFLA_BR_VLAN_PROTOCOL, vlan_proto);
} else if (matches(*argv, "help") == 0) {
explain();
return -1;
@@ -134,6 +147,14 @@ static void bridge_print_opt(struct link_util *lu, FILE
*f, struct rtattr *tb[])
if (tb[IFLA_BR_VLAN_FILTERING])
fprintf(f, "vlan_filtering %u ",
rta_getattr_u8(tb[IFLA_BR_VLAN_FILTERING]));
+
+ if (tb[IFLA_BR_VLAN_PROTOCOL]) {
+ SPRINT_BUF(b1);
+
+ fprintf(f, "vlan_protocol %s ",
+ ll_proto_n2a(rta_getattr_u16(tb[IFLA_BR_VLAN_PROTOCOL]),
+b1, sizeof(b1)));
+ }
}
static void bridge_print_help(struct link_util *lu, int argc, char **argv,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] IGMP: Inhibit reports for local multicast groups - DOCUMENT
Document the addition of a new sysctl variable which controls the generation of IGMP reports for link local multicast groups in the 224.0.0.X range. IGMP reports for local multicast groups can now be optionally inhibited by setting the value to zero e.g.: echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports To retain backwards compatibility the previous behaviour is retained by default on system boot or reverted by setting the value back to non-zero. Signed-off-by: Philip Downey --- Documentation/networking/ip-sysctl.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 5fae770..5f394d5 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -1181,6 +1181,11 @@ tag - INTEGER Allows you to write a number, which can be used as required. Default value is 0. +igmp_link_local_mcast_reports - BOOLEAN + Enable IGMP reports for link local multicast groups in the + 224.0.0.X range. + Default TRUE + Alexey Kuznetsov. kuz...@ms2.inr.ac.ru -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] IGMP: Inhibit reports for local multicast groups
> -Original Message- > From: Cong Wang [mailto:cw...@twopensource.com] > Sent: Friday, August 28, 2015 10:20 PM > To: Philip Downey > Cc: David Miller; Alexey Kuznetsov; James Morris; Hideaki YOSHIFUJI; Patrick > McHardy; linux-ker...@vger.kernel.org; netdev > Subject: Re: [PATCH] IGMP: Inhibit reports for local multicast groups > > On Thu, Aug 27, 2015 at 8:46 AM, Philip Downey > wrote: > > IGMP reports for local multicast groups can now be optionally > > inhibited by means of a system control variable (by setting the value > > to zero) e.g.: > > echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports > > > > To retain backwards compatibility the previous behaviour is retained > > by default on system boot or reverted by setting the value back to > > non-zero e.g.: > > echo 1 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports > > > > Please document it in Documentation/networking/ip-sysctl.txt. Thanks for the comment. I have generated a new patch for the proposed documentation change. Hope this is the correct thing to do. Regards Philip
Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads
On Sun, Aug 30, 2015 at 03:47:17PM +0800, Herbert Xu wrote: > Phil Sutter wrote: > > > > Should we introduce a new field to struct rhashtable to track the > > internal state? This might allow to clean up some rather obscure tests, > > e.g. whether a table resize is in progress or not. > > Why would we want to do that? The deferred expansion is done > on a best effort basis so its failure has nothing to do with > the failure of a subsequent insertion. The variable would be used to track if the worker has failed to allocate memory in background. Since the failing insertion will be retried, subsequent inserts are not necessary unrelated. > The insertion must have tried its own last-ditch synchronous > expansion and only fail if that fails. Who do you mean with "the insertion"? The user or the API? Cheers, Phil -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [net-next:master 1512/1524] net/ipv4/af_inet.c:1486:26: error: 'offt' undeclared
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> Subject: Re: [net-next:master 1512/1524] net/ipv4/af_inet.c:1486:26: error:
> 'offt' undeclared
>
> From: kbuild test robot
> Date: Mon, 31 Aug 2015 13:06:10 +0800
>
> >net/ipv4/af_inet.c: In function 'snmp_get_cpu_field64':
> >>> net/ipv4/af_inet.c:1486:26: error: 'offt' undeclared (first use in this
> function)
> > v = *(((u64 *)bhptr) + offt);
> > ^
> >net/ipv4/af_inet.c:1486:26: note: each undeclared identifier is reported
> only once for each function it appears in
> >net/ipv4/af_inet.c: In function 'snmp_fold_field64':
> >>> net/ipv4/af_inet.c:1499:39: error: 'offct' undeclared (first use in this
> function)
> > res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
> > ^
> >>> net/ipv4/af_inet.c:1499:10: error: too many arguments to function
> 'snmp_get_cpu_field'
> > res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
> > ^
> >net/ipv4/af_inet.c:1455:5: note: declared here
> > u64 snmp_get_cpu_field(void __percpu *mib, int cpu, int offt)
> > ^
> >net/ipv4/af_inet.c:1499: confused by earlier errors, bailing out
>
> Thanks, this should fix it:
>
>
> [PATCH] ipv4: Fix 32-bit build.
>
>net/ipv4/af_inet.c: In function 'snmp_get_cpu_field64':
> >> net/ipv4/af_inet.c:1486:26: error: 'offt' undeclared (first use in this
> function)
> v = *(((u64 *)bhptr) + offt);
> ^
>net/ipv4/af_inet.c:1486:26: note: each undeclared identifier is reported
> only once for each function it appears in
>net/ipv4/af_inet.c: In function 'snmp_fold_field64':
> >> net/ipv4/af_inet.c:1499:39: error: 'offct' undeclared (first use in this
> function)
> res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
> ^
> >> net/ipv4/af_inet.c:1499:10: error: too many arguments to function
> 'snmp_get_cpu_field'
> res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
> ^
>net/ipv4/af_inet.c:1455:5: note: declared here
> u64 snmp_get_cpu_field(void __percpu *mib, int cpu, int offt)
> ^
>
> Reported-by: kbuild test robot
> Signed-off-by: David S. Miller
> ---
> net/ipv4/af_inet.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 0c69c0b..c2d0ebc 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1471,7 +1471,7 @@ EXPORT_SYMBOL_GPL(snmp_fold_field);
>
> #if BITS_PER_LONG==32
>
> -u64 snmp_get_cpu_field64(void __percpu *mib, int cpu, int offct,
> +u64 snmp_get_cpu_field64(void __percpu *mib, int cpu, int offt,
>size_t syncp_offset)
> {
> void *bhptr;
> @@ -1496,7 +1496,7 @@ u64 snmp_fold_field64(void __percpu *mib, int
> offt, size_t syncp_offset)
> int cpu;
>
> for_each_possible_cpu(cpu) {
> - res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
> + res += snmp_get_cpu_field(mib, cpu, offt, syncp_offset);
> }
> return res;
> }
> --
> 2.1.0
>
> --
Hi,
shouldn't that be snmp_get_cpu_field64() ?
- res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
+ res += snmp_get_cpu_field64(mib, cpu, offt, syncp_offset);
Madalin
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ipv4: fix 32b build
Address remaining issue after 80ec192.
Signed-off-by: Madalin Bucur
---
net/ipv4/af_inet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index c2d0ebc..96773a2 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1496,7 +1496,7 @@ u64 snmp_fold_field64(void __percpu *mib, int offt,
size_t syncp_offset)
int cpu;
for_each_possible_cpu(cpu) {
- res += snmp_get_cpu_field(mib, cpu, offt, syncp_offset);
+ res += snmp_get_cpu_field64(mib, cpu, offt, syncp_offset);
}
return res;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipv4: fix 32b build
On 08/31/2015 06:16 PM, Madalin Bucur wrote:
Address remaining issue after 80ec192.
Signed-off-by: Madalin Bucur
---
net/ipv4/af_inet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index c2d0ebc..96773a2 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1496,7 +1496,7 @@ u64 snmp_fold_field64(void __percpu *mib, int offt,
size_t syncp_offset)
int cpu;
for_each_possible_cpu(cpu) {
- res += snmp_get_cpu_field(mib, cpu, offt, syncp_offset);
+ res += snmp_get_cpu_field64(mib, cpu, offt, syncp_offset);
}
return res;
}
Thanks Madlin for catching this for 32bit.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 2/4] net: fib6: reduce identation in ip6_convert_metrics
Reduce the identation a bit, there's no need to artificically have
it increased.
Signed-off-by: Daniel Borkmann
---
net/ipv6/route.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 308dd5f..0261b72 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1711,26 +1711,26 @@ static int ip6_convert_metrics(struct mx6_config *mxc,
nla_for_each_attr(nla, cfg->fc_mx, cfg->fc_mx_len, remaining) {
int type = nla_type(nla);
+ u32 val;
- if (type) {
- u32 val;
-
- if (unlikely(type > RTAX_MAX))
- goto err;
- if (type == RTAX_CC_ALGO) {
- char tmp[TCP_CA_NAME_MAX];
+ if (!type)
+ continue;
+ if (unlikely(type > RTAX_MAX))
+ goto err;
- nla_strlcpy(tmp, nla, sizeof(tmp));
- val = tcp_ca_get_key_by_name(tmp);
- if (val == TCP_CA_UNSPEC)
- goto err;
- } else {
- val = nla_get_u32(nla);
- }
+ if (type == RTAX_CC_ALGO) {
+ char tmp[TCP_CA_NAME_MAX];
- mp[type - 1] = val;
- __set_bit(type - 1, mxc->mx_valid);
+ nla_strlcpy(tmp, nla, sizeof(tmp));
+ val = tcp_ca_get_key_by_name(tmp);
+ if (val == TCP_CA_UNSPEC)
+ goto err;
+ } else {
+ val = nla_get_u32(nla);
}
+
+ mp[type - 1] = val;
+ __set_bit(type - 1, mxc->mx_valid);
}
mxc->mx = mp;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 0/4] tcp: receive-side per route dctcp handling
Original cover letter: Currently, the following case doesn't use DCTCP, even if it should: - responder has f.e. cubic as system wide default - 'ip route congctl dctcp $src' was set Then, DCTCP is NOT used if a DCTCP sender attempts to connect from a host in the $src range: ECT(0) is set, but listen_sk is not dctcp, so we fail the INET_ECN_is_not_ect sanity check. We also have to examine the dst used for the SYN/ACK reply to make this case work. In order to minimize additional cost, store the 'ecn is must have' information is the dst_features field. The set targets -next instead of -net since this doesn't seem to be a serious bug and to give the change more soak time until it hits linus tree. v1 -> v2: - Addressed Dave's feedback, not exposing any bits to user space - Added patch 3 to reject incorrect configurations - Rest as is, rebased and retested Thanks! Daniel Borkmann (3): net: fib6: reduce identation in ip6_convert_metrics fib, fib6: reject invalid feature bits tcp: use dctcp if enabled on the route to the initiator Florian Westphal (1): net: fib: move metrics parsing to a helper include/net/dst.h | 6 include/net/tcp.h | 2 +- include/uapi/linux/rtnetlink.h | 11 +++--- net/core/rtnetlink.c | 6 net/ipv4/fib_semantics.c | 77 ++ net/ipv4/tcp_cong.c| 9 +++-- net/ipv4/tcp_input.c | 7 ++-- net/ipv6/route.c | 39 - 8 files changed, 101 insertions(+), 56 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ipv6: send NEWLINK on RA managed/otherconf changes
The kernel is applying the RA managed/otherconf flags silently and
forgets to send ifinfo notify to inform about their change when the
router provides a zero reachable_time and retrans_timer as dnsmasq
and many routers send it, which just means unspecified by this router
and the host should continue using whatever value it is already using.
Userspace may monitor the ifinfo notifications to activate dhcpv6.
Signed-off-by: Marius Tomaschewski
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index c53331c..99ea9dd 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1074,6 +1074,7 @@ static void ndisc_router_discovery(struct sk_buff *skb)
struct ndisc_options ndopts;
int optlen;
unsigned int pref = 0;
+ __u32 old_if_flags;
__u8 *opt = (__u8 *)(ra_msg + 1);
@@ -1144,6 +1145,7 @@ static void ndisc_router_discovery(struct sk_buff *skb)
* Remember the managed/otherconf flags from most recently
* received RA message (RFC 2462) -- yoshfuji
*/
+ old_if_flags = in6_dev->if_flags;
in6_dev->if_flags = (in6_dev->if_flags & ~(IF_RA_MANAGED |
IF_RA_OTHERCONF)) |
(ra_msg->icmph.icmp6_addrconf_managed ?
@@ -1151,6 +1153,9 @@ static void ndisc_router_discovery(struct sk_buff *skb)
(ra_msg->icmph.icmp6_addrconf_other ?
IF_RA_OTHERCONF : 0);
+ if (old_if_flags != in6_dev->if_flags)
+ inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
+
if (!in6_dev->cnf.accept_ra_defrtr) {
ND_PRINTK(2, info,
"RA: %s, defrtr is false for dev: %s\n",
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 1/4] net: fib: move metrics parsing to a helper
From: Florian Westphal
fib_create_info() is already quite large, so before adding more
code to the metrics section move that to a helper, similar to
ip6_convert_metrics.
Suggested-by: Daniel Borkmann
Signed-off-by: Florian Westphal
---
net/ipv4/fib_semantics.c | 71
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 1b2d011..88afbae 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -876,6 +876,44 @@ static bool fib_valid_prefsrc(struct fib_config *cfg,
__be32 fib_prefsrc)
return true;
}
+static int
+fib_convert_metrics(struct fib_info *fi, const struct fib_config *cfg)
+{
+ struct nlattr *nla;
+ int remaining;
+
+ if (!cfg->fc_mx)
+ return 0;
+
+ nla_for_each_attr(nla, cfg->fc_mx, cfg->fc_mx_len, remaining) {
+ int type = nla_type(nla);
+ u32 val;
+
+ if (!type)
+ continue;
+ if (type > RTAX_MAX)
+ return -EINVAL;
+
+ if (type == RTAX_CC_ALGO) {
+ char tmp[TCP_CA_NAME_MAX];
+
+ nla_strlcpy(tmp, nla, sizeof(tmp));
+ val = tcp_ca_get_key_by_name(tmp);
+ if (val == TCP_CA_UNSPEC)
+ return -EINVAL;
+ } else {
+ val = nla_get_u32(nla);
+ }
+ if (type == RTAX_ADVMSS && val > 65535 - 40)
+ val = 65535 - 40;
+ if (type == RTAX_MTU && val > 65535 - 15)
+ val = 65535 - 15;
+ fi->fib_metrics[type - 1] = val;
+ }
+
+ return 0;
+}
+
struct fib_info *fib_create_info(struct fib_config *cfg)
{
int err;
@@ -948,36 +986,9 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
goto failure;
} endfor_nexthops(fi)
- if (cfg->fc_mx) {
- struct nlattr *nla;
- int remaining;
-
- nla_for_each_attr(nla, cfg->fc_mx, cfg->fc_mx_len, remaining) {
- int type = nla_type(nla);
-
- if (type) {
- u32 val;
-
- if (type > RTAX_MAX)
- goto err_inval;
- if (type == RTAX_CC_ALGO) {
- char tmp[TCP_CA_NAME_MAX];
-
- nla_strlcpy(tmp, nla, sizeof(tmp));
- val = tcp_ca_get_key_by_name(tmp);
- if (val == TCP_CA_UNSPEC)
- goto err_inval;
- } else {
- val = nla_get_u32(nla);
- }
- if (type == RTAX_ADVMSS && val > 65535 - 40)
- val = 65535 - 40;
- if (type == RTAX_MTU && val > 65535 - 15)
- val = 65535 - 15;
- fi->fib_metrics[type - 1] = val;
- }
- }
- }
+ err = fib_convert_metrics(fi, cfg);
+ if (err)
+ goto failure;
if (cfg->fc_mp) {
#ifdef CONFIG_IP_ROUTE_MULTIPATH
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 3/4] fib, fib6: reject invalid feature bits
Feature bits that are invalid should not be accepted by the kernel,
only the lower 4 bits may be configured, but not the remaining ones.
Even from these 4, 2 of them are unused.
Signed-off-by: Daniel Borkmann
---
include/uapi/linux/rtnetlink.h | 11 +++
net/ipv4/fib_semantics.c | 2 ++
net/ipv6/route.c | 2 ++
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 0d3d3cc..7020247 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -418,10 +418,13 @@ enum {
#define RTAX_MAX (__RTAX_MAX - 1)
-#define RTAX_FEATURE_ECN 0x0001
-#define RTAX_FEATURE_SACK 0x0002
-#define RTAX_FEATURE_TIMESTAMP 0x0004
-#define RTAX_FEATURE_ALLFRAG 0x0008
+#define RTAX_FEATURE_ECN (1 << 0)
+#define RTAX_FEATURE_SACK (1 << 1)
+#define RTAX_FEATURE_TIMESTAMP (1 << 2)
+#define RTAX_FEATURE_ALLFRAG (1 << 3)
+
+#define RTAX_FEATURE_MASK (RTAX_FEATURE_ECN | RTAX_FEATURE_SACK | \
+RTAX_FEATURE_TIMESTAMP | RTAX_FEATURE_ALLFRAG)
struct rta_session {
__u8proto;
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 88afbae..115a08e 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -908,6 +908,8 @@ fib_convert_metrics(struct fib_info *fi, const struct
fib_config *cfg)
val = 65535 - 40;
if (type == RTAX_MTU && val > 65535 - 15)
val = 65535 - 15;
+ if (type == RTAX_FEATURES && (val & ~RTAX_FEATURE_MASK))
+ return -EINVAL;
fi->fib_metrics[type - 1] = val;
}
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 0261b72..8771530 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1728,6 +1728,8 @@ static int ip6_convert_metrics(struct mx6_config *mxc,
} else {
val = nla_get_u32(nla);
}
+ if (type == RTAX_FEATURES && (val & ~RTAX_FEATURE_MASK))
+ goto err;
mp[type - 1] = val;
__set_bit(type - 1, mxc->mx_valid);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 4/4] tcp: use dctcp if enabled on the route to the initiator
Currently, the following case doesn't use DCTCP, even if it should:
A responder has f.e. Cubic as system wide default, but for a specific
route to the initiating host, DCTCP is being set in RTAX_CC_ALGO. The
initiating host then uses DCTCP as congestion control, but since the
initiator sets ECT(0), tcp_ecn_create_request() doesn't set ecn_ok,
and we have to fall back to Reno after 3WHS completes.
We were thinking on how to solve this in a minimal, non-intrusive
way without bloating tcp_ecn_create_request() needlessly: lets cache
the CA ecn option flag in RTAX_FEATURES. In other words, when ECT(0)
is set on the SYN packet, set ecn_ok=1 iff route RTAX_FEATURES
contains the unexposed (internal-only) DST_FEATURE_ECN_CA. This allows
to only do a single metric feature lookup inside tcp_ecn_create_request().
Joint work with Florian Westphal.
Signed-off-by: Daniel Borkmann
Signed-off-by: Florian Westphal
---
include/net/dst.h| 6 ++
include/net/tcp.h| 2 +-
net/core/rtnetlink.c | 6 ++
net/ipv4/fib_semantics.c | 6 +-
net/ipv4/tcp_cong.c | 9 ++---
net/ipv4/tcp_input.c | 7 +--
net/ipv6/route.c | 9 +++--
7 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 4c48016..9261d92 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -207,6 +207,12 @@ static inline void dst_metric_set(struct dst_entry *dst,
int metric, u32 val)
p[metric-1] = val;
}
+/* Kernel-internal feature bits that are unallocated in user space. */
+#define DST_FEATURE_ECN_CA (1 << 31)
+
+#define DST_FEATURE_MASK (DST_FEATURE_ECN_CA)
+#define DST_FEATURE_ECN_MASK (DST_FEATURE_ECN_CA | RTAX_FEATURE_ECN)
+
static inline u32
dst_feature(const struct dst_entry *dst, u32 feature)
{
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 4a7b039..0cab28c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -888,7 +888,7 @@ void tcp_reno_cong_avoid(struct sock *sk, u32 ack, u32
acked);
extern struct tcp_congestion_ops tcp_reno;
struct tcp_congestion_ops *tcp_ca_find_key(u32 key);
-u32 tcp_ca_get_key_by_name(const char *name);
+u32 tcp_ca_get_key_by_name(const char *name, bool *ecn_ca);
#ifdef CONFIG_INET
char *tcp_ca_get_name_by_key(u32 key, char *buffer);
#else
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 788ceed..a466821 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -678,6 +678,12 @@ int rtnetlink_put_metrics(struct sk_buff *skb, u32
*metrics)
continue;
if (nla_put_string(skb, i + 1, name))
goto nla_put_failure;
+ } else if (i == RTAX_FEATURES - 1) {
+ u32 user_features = metrics[i] &
RTAX_FEATURE_MASK;
+
+ BUILD_BUG_ON(RTAX_FEATURE_MASK &
DST_FEATURE_MASK);
+ if (nla_put_u32(skb, i + 1, user_features))
+ goto nla_put_failure;
} else {
if (nla_put_u32(skb, i + 1, metrics[i]))
goto nla_put_failure;
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 115a08e..992a959 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -879,6 +879,7 @@ static bool fib_valid_prefsrc(struct fib_config *cfg,
__be32 fib_prefsrc)
static int
fib_convert_metrics(struct fib_info *fi, const struct fib_config *cfg)
{
+ bool ecn_ca = false;
struct nlattr *nla;
int remaining;
@@ -898,7 +899,7 @@ fib_convert_metrics(struct fib_info *fi, const struct
fib_config *cfg)
char tmp[TCP_CA_NAME_MAX];
nla_strlcpy(tmp, nla, sizeof(tmp));
- val = tcp_ca_get_key_by_name(tmp);
+ val = tcp_ca_get_key_by_name(tmp, &ecn_ca);
if (val == TCP_CA_UNSPEC)
return -EINVAL;
} else {
@@ -913,6 +914,9 @@ fib_convert_metrics(struct fib_info *fi, const struct
fib_config *cfg)
fi->fib_metrics[type - 1] = val;
}
+ if (ecn_ca)
+ fi->fib_metrics[RTAX_FEATURES - 1] |= DST_FEATURE_ECN_CA;
+
return 0;
}
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index a2ed23c..93c4dc3 100644
--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -114,16 +114,19 @@ void tcp_unregister_congestion_control(struct
tcp_congestion_ops *ca)
}
EXPORT_SYMBOL_GPL(tcp_unregister_congestion_control);
-u32 tcp_ca_get_key_by_name(const char *name)
+u32 tcp_ca_get_key_by_name(const char *name, bool *ecn_ca)
{
const struct tcp_congestion_ops *ca;
- u32 key;
+ u32 key = TCP_CA_UNSPEC;
might_sleep();
rcu_read_lock();
ca = __tcp_ca_find_autoload(
Re: [PATCH] net/smsc911x: Fix deferred probe for interrupt
On 08/30/2015 12:33 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 8/28/2015 9:50 PM, Tony Lindgren wrote:
>
>> The interrupt handler may not be available when smsc911x probes if the
>> interrupt handler is a GPIO controller for example. Let's fix that
>> by adding handling for -EPROBE_DEFER.
>
>> Cc: Steve Glendinning
>> Signed-off-by: Tony Lindgren
>> ---
>> drivers/net/ethernet/smsc/smsc911x.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/smsc/smsc911x.c
>> b/drivers/net/ethernet/smsc/smsc911x.c
>> index 959aeea..cb9f166f 100644
>> --- a/drivers/net/ethernet/smsc/smsc911x.c
>> +++ b/drivers/net/ethernet/smsc/smsc911x.c
>> @@ -2435,7 +2435,10 @@ static int smsc911x_drv_probe(struct
>> platform_device *pdev)
>> res_size = resource_size(res);
>>
>> irq = platform_get_irq(pdev, 0);
>> -if (irq <= 0) {
>> +if (irq == -EPROBE_DEFER) {
>> +retval = -EPROBE_DEFER;
>> +goto out_0;
>> +} else if (irq <= 0) {
>> pr_warn("Could not allocate irq resource\n");
>> retval = -ENODEV;
>
> I'd propagate the error code from platfrom_get_irq() instead (in
> fact, I've submitted a couple of such patches yesterday and they have
> been already merged).
Have you paid some attention on current platform_get_irq_() implementation?
The platform_get_irq() can return 0 in case of DT-boot.
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2 RFT net-next 3/9] phy: fixed_phy: Set supported speed in phydev
Set the supported field of the phydev to indicate the speed features
of the phy. If the phy is never attached to a netdev, but used in an
adjust_link() function, the speed will be incorrectly evaluated to
10/half rather than the correct speed/duplex.
Signed-off-by: Andrew Lunn
Acked-by: Florian Fainelli
---
drivers/net/phy/fixed_phy.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index ce46428ff21f..2f9457f05a2e 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -305,6 +305,18 @@ struct phy_device *fixed_phy_register(unsigned int irq,
phy->dev.of_node = np;
phy->is_pseudo_fixed_link = true;
+ switch (status->speed) {
+ case SPEED_1000:
+ phy->supported = PHY_1000BT_FEATURES;
+ break;
+ case SPEED_100:
+ phy->supported = PHY_100BT_FEATURES;
+ break;
+ case SPEED_10:
+ default:
+ phy->supported = PHY_10BT_FEATURES;
+ }
+
ret = phy_device_register(phy);
if (ret) {
phy_device_free(phy);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2 RFT net-next 7/9] dsa: mv88e6xxx: Don't poll forced interfaces for state changes
When polling for link status, don't consider ports which have a forced
link. Such ports don't monitor their phy or may not even have a phy.
Signed-off-by: Andrew Lunn
Acked-by: Florian Fainelli
---
drivers/net/dsa/mv88e6xxx.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 90dee97ae793..6f13f7206762 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -395,6 +395,7 @@ void mv88e6xxx_poll_link(struct dsa_switch *ds)
for (i = 0; i < DSA_MAX_PORTS; i++) {
struct net_device *dev;
int uninitialized_var(port_status);
+ int pcs_ctrl;
int link;
int speed;
int duplex;
@@ -404,6 +405,10 @@ void mv88e6xxx_poll_link(struct dsa_switch *ds)
if (dev == NULL)
continue;
+ pcs_ctrl = mv88e6xxx_reg_read(ds, REG_PORT(i), PORT_PCS_CTRL);
+ if (pcs_ctrl < 0 || pcs_ctrl & PORT_PCS_CTRL_FORCE_LINK)
+ continue;
+
link = 0;
if (dev->flags & IFF_UP) {
port_status = mv88e6xxx_reg_read(ds, REG_PORT(i),
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2 RFT net-next 4/9] net: dsa: Allow configuration of CPU & DSA port speeds/duplex
By default, DSA and CPU ports are configured to the maximum speed the
switch supports. However there can be use cases where the peer devices
port is slower. Allow a fixed-link property to be used with the DSA
and CPU port in the device tree, and use this information to configure
the port.
Signed-off-by: Andrew Lunn
Reviewed-by: Florian Fainelli
---
net/dsa/dsa.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 053eb2b8e682..afff17341b73 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -176,6 +176,35 @@ __ATTRIBUTE_GROUPS(dsa_hwmon);
#endif /* CONFIG_NET_DSA_HWMON */
/* basic switch operations **/
+static int dsa_cpu_dsa_setup(struct dsa_switch *ds, struct net_device *master)
+{
+ struct dsa_chip_data *cd = ds->pd;
+ struct device_node *port_dn;
+ struct phy_device *phydev;
+ int ret, port;
+
+ for (port = 0; port < DSA_MAX_PORTS; port++) {
+ if (!(dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port)))
+ continue;
+
+ port_dn = cd->port_dn[port];
+ if (of_phy_is_fixed_link(port_dn)) {
+ ret = of_phy_register_fixed_link(port_dn);
+ if (ret) {
+ netdev_err(master,
+ "failed to register fixed PHY\n");
+ return ret;
+ }
+ phydev = of_phy_find_device(port_dn);
+ genphy_config_init(phydev);
+ genphy_read_status(phydev);
+ if (ds->drv->adjust_link)
+ ds->drv->adjust_link(ds, port, phydev);
+ }
+ }
+ return 0;
+}
+
static int dsa_switch_setup_one(struct dsa_switch *ds, struct device *parent)
{
struct dsa_switch_driver *drv = ds->drv;
@@ -297,6 +326,14 @@ static int dsa_switch_setup_one(struct dsa_switch *ds,
struct device *parent)
}
}
+ /* Perform configuration of the CPU and DSA ports */
+ ret = dsa_cpu_dsa_setup(ds, dst->master_netdev);
+ if (ret < 0) {
+ netdev_err(dst->master_netdev, "[%d] : can't configure CPU and
DSA ports\n",
+ index);
+ ret = 0;
+ }
+
#ifdef CONFIG_NET_DSA_HWMON
/* If the switch provides a temperature sensor,
* register with hardware monitoring subsystem.
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2 RFT net-next 8/9] phy: fixed_phy: Add gpio to determine link up/down.
An SFP module may have a link up/down status pin which can be
connection to a GPIO line of the host. Add support for reading such an
GPIO in the fixed_phy driver.
Signed-off-by: Andrew Lunn
Reviewed-by: Florian Fainelli
---
.../devicetree/bindings/net/fixed-link.txt | 14 +++-
Documentation/networking/stmmac.txt| 2 +-
arch/m68k/coldfire/m5272.c | 2 +-
arch/mips/ar7/platform.c | 5 +++--
arch/mips/bcm47xx/setup.c | 2 +-
drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 +-
drivers/net/phy/fixed_phy.c| 26 +++---
drivers/of/of_mdio.c | 13 ---
include/linux/phy_fixed.h | 8 +--
9 files changed, 59 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt
b/Documentation/devicetree/bindings/net/fixed-link.txt
index 82bf7e0f47b6..ec5d889fe3d8 100644
--- a/Documentation/devicetree/bindings/net/fixed-link.txt
+++ b/Documentation/devicetree/bindings/net/fixed-link.txt
@@ -17,6 +17,8 @@ properties:
enabled.
* 'asym-pause' (boolean, optional), to indicate that asym_pause should
be enabled.
+* 'link-gpios' ('gpio-list', optional), to indicate if a gpio can be read
+ to determine if the link is up.
Old, deprecated 'fixed-link' binding:
@@ -30,7 +32,7 @@ Old, deprecated 'fixed-link' binding:
- e: asymmetric pause configuration: 0 for no asymmetric pause, 1 for
asymmetric pause
-Example:
+Examples:
ethernet@0 {
...
@@ -40,3 +42,13 @@ ethernet@0 {
};
...
};
+
+ethernet@1 {
+ ...
+ fixed-link {
+ speed = <1000>;
+ pause;
+ link-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+ };
+ ...
+};
diff --git a/Documentation/networking/stmmac.txt
b/Documentation/networking/stmmac.txt
index 2903b1cf4d70..d64a14714236 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -254,7 +254,7 @@ static struct fixed_phy_status stmmac0_fixed_phy_status = {
During the board's device_init we can configure the first
MAC for fixed_link by calling:
- fixed_phy_add(PHY_POLL, 1, &stmmac0_fixed_phy_status));)
+ fixed_phy_add(PHY_POLL, 1, &stmmac0_fixed_phy_status, -1);
and the second one, with a real PHY device attached to the bus,
by using the stmmac_mdio_bus_data structure (to provide the id, the
reset procedure etc).
diff --git a/arch/m68k/coldfire/m5272.c b/arch/m68k/coldfire/m5272.c
index b15219ed22bf..c525e4c08f84 100644
--- a/arch/m68k/coldfire/m5272.c
+++ b/arch/m68k/coldfire/m5272.c
@@ -126,7 +126,7 @@ static struct fixed_phy_status nettel_fixed_phy_status
__initdata = {
static int __init init_BSP(void)
{
m5272_uarts_init();
- fixed_phy_add(PHY_POLL, 0, &nettel_fixed_phy_status);
+ fixed_phy_add(PHY_POLL, 0, &nettel_fixed_phy_status, -1);
return 0;
}
diff --git a/arch/mips/ar7/platform.c b/arch/mips/ar7/platform.c
index be9ff1673ded..298b97715d5f 100644
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -679,7 +679,8 @@ static int __init ar7_register_devices(void)
}
if (ar7_has_high_cpmac()) {
- res = fixed_phy_add(PHY_POLL, cpmac_high.id, &fixed_phy_status);
+ res = fixed_phy_add(PHY_POLL, cpmac_high.id,
+ &fixed_phy_status, -1);
if (!res) {
cpmac_get_mac(1, cpmac_high_data.dev_addr);
@@ -692,7 +693,7 @@ static int __init ar7_register_devices(void)
} else
cpmac_low_data.phy_mask = 0x;
- res = fixed_phy_add(PHY_POLL, cpmac_low.id, &fixed_phy_status);
+ res = fixed_phy_add(PHY_POLL, cpmac_low.id, &fixed_phy_status, -1);
if (!res) {
cpmac_get_mac(0, cpmac_low_data.dev_addr);
res = platform_device_register(&cpmac_low);
diff --git a/arch/mips/bcm47xx/setup.c b/arch/mips/bcm47xx/setup.c
index 98c075f81795..17503a05938e 100644
--- a/arch/mips/bcm47xx/setup.c
+++ b/arch/mips/bcm47xx/setup.c
@@ -263,7 +263,7 @@ static int __init bcm47xx_register_bus_complete(void)
bcm47xx_leds_register();
bcm47xx_workarounds();
- fixed_phy_add(PHY_POLL, 0, &bcm47xx_fixed_phy_status);
+ fixed_phy_add(PHY_POLL, 0, &bcm47xx_fixed_phy_status, -1);
return 0;
}
device_initcall(bcm47xx_register_bus_complete);
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index b3679ad1c1c7..c8affad76f36 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -585,7 +585,7 @@ static int bcmgenet_mii_pd_init(struct bcmgenet_priv *priv)
.asym_pause = 0,
};
- phydev = fixed_phy_register(PHY_POLL, &fphy_status, NULL);
[Patch v2 RFT net-next 2/9] dsa: mv88e6xxx: Allow speed/duplex of port to be configured
The current code sets user ports to perform auto negotiation using the
phy. CPU and DSA ports are configured to full duplex and maximum speed
the switch supports.
There are however use cases where the CPU has a slower port, and when
user ports have SFP modules with fixed speed. In these cases, port
settings to be read from a fixed_phy devices. The switch driver then
needs to implement the adjust_link op, so the port settings can be
set.
Signed-off-by: Andrew Lunn
Reviewed-by: Florian Fainelli
---
drivers/net/dsa/mv88e6123_61_65.c | 1 +
drivers/net/dsa/mv88e6131.c | 1 +
drivers/net/dsa/mv88e6171.c | 1 +
drivers/net/dsa/mv88e6352.c | 1 +
drivers/net/dsa/mv88e6xxx.c | 58 +++
drivers/net/dsa/mv88e6xxx.h | 2 ++
6 files changed, 64 insertions(+)
diff --git a/drivers/net/dsa/mv88e6123_61_65.c
b/drivers/net/dsa/mv88e6123_61_65.c
index 71a29a7ce538..3de2a6d73fdc 100644
--- a/drivers/net/dsa/mv88e6123_61_65.c
+++ b/drivers/net/dsa/mv88e6123_61_65.c
@@ -129,6 +129,7 @@ struct dsa_switch_driver mv88e6123_61_65_switch_driver = {
.get_strings= mv88e6xxx_get_strings,
.get_ethtool_stats = mv88e6xxx_get_ethtool_stats,
.get_sset_count = mv88e6xxx_get_sset_count,
+ .adjust_link= mv88e6xxx_adjust_link,
#ifdef CONFIG_NET_DSA_HWMON
.get_temp = mv88e6xxx_get_temp,
#endif
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index 32f4a08e9bc9..3e8386529965 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -182,6 +182,7 @@ struct dsa_switch_driver mv88e6131_switch_driver = {
.get_strings= mv88e6xxx_get_strings,
.get_ethtool_stats = mv88e6xxx_get_ethtool_stats,
.get_sset_count = mv88e6xxx_get_sset_count,
+ .adjust_link= mv88e6xxx_adjust_link,
};
MODULE_ALIAS("platform:mv88e6085");
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 735f04cd83ee..d54b7400e8d8 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -108,6 +108,7 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
.get_strings= mv88e6xxx_get_strings,
.get_ethtool_stats = mv88e6xxx_get_ethtool_stats,
.get_sset_count = mv88e6xxx_get_sset_count,
+ .adjust_link= mv88e6xxx_adjust_link,
#ifdef CONFIG_NET_DSA_HWMON
.get_temp = mv88e6xxx_get_temp,
#endif
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 14b71779df99..1f5129c105fb 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -328,6 +328,7 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.get_strings= mv88e6xxx_get_strings,
.get_ethtool_stats = mv88e6xxx_get_ethtool_stats,
.get_sset_count = mv88e6xxx_get_sset_count,
+ .adjust_link= mv88e6xxx_adjust_link,
.set_eee= mv88e6xxx_set_eee,
.get_eee= mv88e6xxx_get_eee,
#ifdef CONFIG_NET_DSA_HWMON
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 3774f53d28d7..1a8c45f3e680 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -560,6 +561,63 @@ static bool mv88e6xxx_6352_family(struct dsa_switch *ds)
return false;
}
+/* We expect the switch to perform auto negotiation if there is a real
+ * phy. However, in the case of a fixed link phy, we force the port
+ * settings from the fixed link settings.
+ */
+void mv88e6xxx_adjust_link(struct dsa_switch *ds, int port,
+ struct phy_device *phydev)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ u32 ret, reg;
+
+ if (!phy_is_pseudo_fixed_link(phydev))
+ return;
+
+ mutex_lock(&ps->smi_mutex);
+
+ ret = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_PCS_CTRL);
+ if (ret < 0)
+ goto out;
+
+ reg = ret & ~(PORT_PCS_CTRL_LINK_UP |
+ PORT_PCS_CTRL_FORCE_LINK |
+ PORT_PCS_CTRL_DUPLEX_FULL |
+ PORT_PCS_CTRL_FORCE_DUPLEX |
+ PORT_PCS_CTRL_UNFORCED);
+
+ reg |= PORT_PCS_CTRL_FORCE_LINK;
+ if (phydev->link)
+ reg |= PORT_PCS_CTRL_LINK_UP;
+
+ if (mv88e6xxx_6065_family(ds) && phydev->speed > SPEED_100)
+ goto out;
+
+ switch (phydev->speed) {
+ case SPEED_1000:
+ reg |= PORT_PCS_CTRL_1000;
+ break;
+ case SPEED_100:
+ reg |= PORT_PCS_CTRL_100;
+ break;
+ case SPEED_10:
+ reg |= PORT_PCS_CTRL_10;
+ break;
+ default:
+ pr_info("Unknown speed")
[Patch v2 RFT net-next 5/9] net: dsa: Allow DSA and CPU ports to have a phy-mode property
It can be useful for DSA and CPU ports to have a phy-mode property, in
particular to specify RGMII delays. Parse the property and set it in
the fixed-link phydev.
Signed-off-by: Andrew Lunn
Acked-by: Florian Fainelli
---
net/dsa/dsa.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index afff17341b73..76e3800765f8 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -181,7 +181,7 @@ static int dsa_cpu_dsa_setup(struct dsa_switch *ds, struct
net_device *master)
struct dsa_chip_data *cd = ds->pd;
struct device_node *port_dn;
struct phy_device *phydev;
- int ret, port;
+ int ret, port, mode;
for (port = 0; port < DSA_MAX_PORTS; port++) {
if (!(dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port)))
@@ -196,6 +196,12 @@ static int dsa_cpu_dsa_setup(struct dsa_switch *ds, struct
net_device *master)
return ret;
}
phydev = of_phy_find_device(port_dn);
+
+ mode = of_get_phy_mode(port_dn);
+ if (mode < 0)
+ mode = PHY_INTERFACE_MODE_NA;
+ phydev->interface = mode;
+
genphy_config_init(phydev);
genphy_read_status(phydev);
if (ds->drv->adjust_link)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2 RFT net-next 6/9] dsa: mv88e6xxx: Set the RGMII delay based on phy interface
Some Marvell switches allow the RGMII Rx and Tx clock to be delayed
when the port is using RGMII. Have the adjust_link function look at
the phy interface type and enable this delay as requested.
Signed-off-by: Andrew Lunn
Reviewed-by: Florian Fainelli
---
drivers/net/dsa/mv88e6xxx.c | 10 ++
drivers/net/dsa/mv88e6xxx.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 1a8c45f3e680..90dee97ae793 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -612,6 +612,16 @@ void mv88e6xxx_adjust_link(struct dsa_switch *ds, int port,
if (phydev->duplex == DUPLEX_FULL)
reg |= PORT_PCS_CTRL_DUPLEX_FULL;
+ if ((mv88e6xxx_6352_family(ds) || mv88e6xxx_6351_family(ds)) &&
+ (port >= ps->num_ports - 2)) {
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+ reg |= PORT_PCS_CTRL_RGMII_DELAY_RXCLK;
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+ reg |= PORT_PCS_CTRL_RGMII_DELAY_TXCLK;
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ reg |= (PORT_PCS_CTRL_RGMII_DELAY_RXCLK |
+ PORT_PCS_CTRL_RGMII_DELAY_TXCLK);
+ }
_mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_PCS_CTRL, reg);
out:
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 79003c55fe62..9b6f3d9d5ae1 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -46,6 +46,8 @@
#define PORT_STATUS_TX_PAUSED BIT(5)
#define PORT_STATUS_FLOW_CTRL BIT(4)
#define PORT_PCS_CTRL 0x01
+#define PORT_PCS_CTRL_RGMII_DELAY_RXCLKBIT(15)
+#define PORT_PCS_CTRL_RGMII_DELAY_TXCLKBIT(14)
#define PORT_PCS_CTRL_FC BIT(7)
#define PORT_PCS_CTRL_FORCE_FC BIT(6)
#define PORT_PCS_CTRL_LINK_UP BIT(5)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2 RFT net-next 9/9] net: phy: fixed_phy: Set phy capabilities even when link down.
What features a phy supports is masked in genphy_config_init() by
looking at the PHYs BMSR register.
If the link is down, fixed_phy_update_regs() will only set the auto-
negotiation capable bit in BMSR. Thus genphy_config_init() comes to
the conclusion the PHY can only perform 10/Half, and masks out the
higher speed features. If however the link it up, BMSR is set to
indicate the speed the PHY is capable of auto-negotiating, and
genphy_config_init() does not mask out the high speed features.
To fix this, when the link is down, have fixed_phy_update_regs() leave
the link status, auto-negotiation complete, and link partner
capabilities unset, but set all the local capabilities depending on
the fixed phy speed.
Signed-off-by: Andrew Lunn
---
drivers/net/phy/fixed_phy.c | 73 +
1 file changed, 48 insertions(+), 25 deletions(-)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index 1bb70e3cc03e..12c7eb2c604e 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -57,61 +57,84 @@ static int fixed_phy_update_regs(struct fixed_phy *fp)
if (gpio_is_valid(fp->link_gpio))
fp->status.link = !!gpio_get_value_cansleep(fp->link_gpio);
- if (!fp->status.link)
- goto done;
- bmsr |= BMSR_LSTATUS | BMSR_ANEGCOMPLETE;
-
if (fp->status.duplex) {
- bmcr |= BMCR_FULLDPLX;
-
switch (fp->status.speed) {
case 1000:
bmsr |= BMSR_ESTATEN;
- bmcr |= BMCR_SPEED1000;
- lpagb |= LPA_1000FULL;
break;
case 100:
bmsr |= BMSR_100FULL;
- bmcr |= BMCR_SPEED100;
- lpa |= LPA_100FULL;
break;
case 10:
bmsr |= BMSR_10FULL;
- lpa |= LPA_10FULL;
break;
default:
- pr_warn("fixed phy: unknown speed\n");
- return -EINVAL;
+ break;
}
} else {
switch (fp->status.speed) {
case 1000:
bmsr |= BMSR_ESTATEN;
- bmcr |= BMCR_SPEED1000;
- lpagb |= LPA_1000HALF;
break;
case 100:
bmsr |= BMSR_100HALF;
- bmcr |= BMCR_SPEED100;
- lpa |= LPA_100HALF;
break;
case 10:
bmsr |= BMSR_10HALF;
- lpa |= LPA_10HALF;
break;
default:
- pr_warn("fixed phy: unknown speed\n");
- return -EINVAL;
+ break;
}
}
- if (fp->status.pause)
- lpa |= LPA_PAUSE_CAP;
+ if (fp->status.link) {
+ bmsr |= BMSR_LSTATUS | BMSR_ANEGCOMPLETE;
+
+ if (fp->status.duplex) {
+ bmcr |= BMCR_FULLDPLX;
+
+ switch (fp->status.speed) {
+ case 1000:
+ bmcr |= BMCR_SPEED1000;
+ lpagb |= LPA_1000FULL;
+ break;
+ case 100:
+ bmcr |= BMCR_SPEED100;
+ lpa |= LPA_100FULL;
+ break;
+ case 10:
+ lpa |= LPA_10FULL;
+ break;
+ default:
+ pr_warn("fixed phy: unknown speed\n");
+ return -EINVAL;
+ }
+ } else {
+ switch (fp->status.speed) {
+ case 1000:
+ bmcr |= BMCR_SPEED1000;
+ lpagb |= LPA_1000HALF;
+ break;
+ case 100:
+ bmcr |= BMCR_SPEED100;
+ lpa |= LPA_100HALF;
+ break;
+ case 10:
+ lpa |= LPA_10HALF;
+ break;
+ default:
+ pr_warn("fixed phy: unknown speed\n");
+ return -EINVAL;
+ }
+ }
+
+ if (fp->status.pause)
+ lpa |= LPA_PAUSE_CAP;
- if (fp->status.asym_pause)
- lpa |= LPA_PAUSE_ASYM;
+ if (fp->status.asym_pause)
+ lpa |= LPA_PAUSE_ASYM;
+ }
-done:
fp->regs[MII_
[Patch v2 RFT net-next 0/9] DSA port configuration and status
Changes since v1:
Rewrite 9/9 so that it hopefully does not regression on
868a4215be9a6d80 ("net: phy: fixed_phy: handle link-down case")
Stas, please could you test your use case.
Added the Acked-by and Reviewed by from Florian
Andrew
This patchset allows various switch port settings to be configured and
port status to be sampled. Some of these patches have been posted
before.
The first three patches provide infrastructure for configuring a
switch ports link speed and duplex from a fixed_link phy.
Patch four then uses this infrastructure to allow the CPU and DSA
ports of a switch to be configured using a fixed-link property in the
device tree.
Patches five and six allow a phy-mode property to be specified in the
device tree, and allow this to be used for configuring RGMII delays.
Patches seven through nine allow link status, for example that of an
SFP module, to be read from a gpio.
Andrew Lunn (8):
dsa: mv88e6xxx: Allow speed/duplex of port to be configured
phy: fixed_phy: Set supported speed in phydev
net: dsa: Allow configuration of CPU & DSA port speeds/duplex
net: dsa: Allow DSA and CPU ports to have a phy-mode property
dsa: mv88e6xxx: Set the RGMII delay based on phy interface
dsa: mv88e6xxx: Don't poll forced interfaces for state changes
phy: fixed_phy: Add gpio to determine link up/down.
net: phy: fixed_phy: Set phy capabilities even when link down.
Florian Fainelli (1):
net: phy: Allow PHY devices to identify themselves as Ethernet
switches, etc.
.../devicetree/bindings/net/fixed-link.txt | 14 ++-
Documentation/networking/stmmac.txt| 2 +-
arch/m68k/coldfire/m5272.c | 2 +-
arch/mips/ar7/platform.c | 5 +-
arch/mips/bcm47xx/setup.c | 2 +-
drivers/net/dsa/mv88e6123_61_65.c | 1 +
drivers/net/dsa/mv88e6131.c| 1 +
drivers/net/dsa/mv88e6171.c| 1 +
drivers/net/dsa/mv88e6352.c| 1 +
drivers/net/dsa/mv88e6xxx.c| 73 ++
drivers/net/dsa/mv88e6xxx.h| 4 +
drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 +-
drivers/net/phy/fixed_phy.c| 110 -
drivers/of/of_mdio.c | 13 ++-
include/linux/phy.h| 12 +++
include/linux/phy_fixed.h | 8 +-
net/dsa/dsa.c | 43
17 files changed, 255 insertions(+), 39 deletions(-)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2 RFT net-next 1/9] net: phy: Allow PHY devices to identify themselves as Ethernet switches, etc.
From: Florian Fainelli
Some Ethernet MAC drivers using the PHY library require the hardcoding
of link parameters when interfaced to a switch device, SFP module,
switch to switch port, etc. This has typically lead to various ad-hoc
implementations looking like this:
- using a "fixed PHY" emulated device, which will provide link
indication towards the Ethernet MAC driver and hardware
- pretend there is no PHY and hardcode link parameters, ala mv643x_eth
Based on that, it is desireable to have the PHY drivers advertise the
correct link parameters, just like regular Ethernet PHYs towards their
CPU Ethernet MAC drivers, however, Ethernet MAC drivers should be able
to tell whether this link should be monitored or not. In the context
of an Ethernet switch, SFP module, switch to switch link, we do not
need to monitor this link since it should be always up.
Signed-off-by: Florian Fainelli
Signed-off-by: Andrew Lunn
---
v2: set is_pseudo_fixed_link before registering the phy
---
drivers/net/phy/fixed_phy.c | 1 +
include/linux/phy.h | 12
2 files changed, 13 insertions(+)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index 99d9bc19c94a..ce46428ff21f 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -303,6 +303,7 @@ struct phy_device *fixed_phy_register(unsigned int irq,
of_node_get(np);
phy->dev.of_node = np;
+ phy->is_pseudo_fixed_link = true;
ret = phy_device_register(phy);
if (ret) {
diff --git a/include/linux/phy.h b/include/linux/phy.h
index e5fb1d415961..962387a192f1 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -330,6 +330,7 @@ struct phy_c45_device_ids {
* c45_ids: 802.3-c45 Device Identifers if is_c45.
* is_c45: Set to true if this phy uses clause 45 addressing.
* is_internal: Set to true if this phy is internal to a MAC.
+ * is_pseudo_fixed_link: Set to true if this phy is an Ethernet switch, etc.
* has_fixups: Set to true if this phy has fixups/quirks.
* suspended: Set to true if this phy has been suspended successfully.
* state: state of the PHY for management purposes
@@ -368,6 +369,7 @@ struct phy_device {
struct phy_c45_device_ids c45_ids;
bool is_c45;
bool is_internal;
+ bool is_pseudo_fixed_link;
bool has_fixups;
bool suspended;
@@ -688,6 +690,16 @@ static inline bool phy_interface_is_rgmii(struct
phy_device *phydev)
{
return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
+};
+
+/*
+ * phy_is_pseudo_fixed_link - Convenience function for testing if this
+ * PHY is the CPU port facing side of an Ethernet switch, or similar.
+ * @phydev: the phy_device struct
+ */
+static inline bool phy_is_pseudo_fixed_link(struct phy_device *phydev)
+{
+ return phydev->is_pseudo_fixed_link;
}
/**
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 RFT net-next 0/9] DSA port configuration and status
31.08.2015 16:56, Andrew Lunn пишет:
> Changes since v1:
>
> Rewrite 9/9 so that it hopefully does not regression on
> 868a4215be9a6d80 ("net: phy: fixed_phy: handle link-down case")
>
> Stas, please could you test your use case.
This was actually not mine.
The change was fixing the regression reported by other people.
I have added them to CC for this e-mail.
I'll let you know if it breaks something for me.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] lib: move strncpy_from_unsafe() into mm/maccess.c
To fix build errors:
kernel/built-in.o: In function `bpf_trace_printk':
bpf_trace.c:(.text+0x11a254): undefined reference to `strncpy_from_unsafe'
kernel/built-in.o: In function `fetch_memory_string':
trace_kprobe.c:(.text+0x11acf8): undefined reference to `strncpy_from_unsafe'
move strncpy_from_unsafe() next to probe_kernel_read/write()
which use the same memory access style.
Reported-by: Fengguang Wu
Reported-by: Guenter Roeck
Fixes: 1a6877b9c0c2 ("lib: introduce strncpy_from_unsafe()")
Signed-off-by: Alexei Starovoitov
---
For configs without kprobes and bpf the cost of this unused function is
~200 bytes which I think is a better trade off vs creating
new Kconfig selector just for this single function.
Another alternative is to move it to kernel/trace/trace_kprobe.c,
but then it will lose generality and probably should be removed
from include/linux/uaccess.h, so mm/maccess.c looks the best.
lib/strncpy_from_user.c | 41 -
mm/maccess.c| 41 +
2 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
index ead8c4a068d1..e0af6ff73d14 100644
--- a/lib/strncpy_from_user.c
+++ b/lib/strncpy_from_user.c
@@ -112,44 +112,3 @@ long strncpy_from_user(char *dst, const char __user *src,
long count)
return -EFAULT;
}
EXPORT_SYMBOL(strncpy_from_user);
-
-/**
- * strncpy_from_unsafe: - Copy a NUL terminated string from unsafe address.
- * @dst: Destination address, in kernel space. This buffer must be at
- * least @count bytes long.
- * @src: Unsafe address.
- * @count: Maximum number of bytes to copy, including the trailing NUL.
- *
- * Copies a NUL-terminated string from unsafe address to kernel buffer.
- *
- * On success, returns the length of the string INCLUDING the trailing NUL.
- *
- * If access fails, returns -EFAULT (some data may have been copied
- * and the trailing NUL added).
- *
- * If @count is smaller than the length of the string, copies @count-1 bytes,
- * sets the last byte of @dst buffer to NUL and returns @count.
- */
-long strncpy_from_unsafe(char *dst, const void *unsafe_addr, long count)
-{
- mm_segment_t old_fs = get_fs();
- const void *src = unsafe_addr;
- long ret;
-
- if (unlikely(count <= 0))
- return 0;
-
- set_fs(KERNEL_DS);
- pagefault_disable();
-
- do {
- ret = __copy_from_user_inatomic(dst++,
- (const void __user __force
*)src++, 1);
- } while (dst[-1] && ret == 0 && src - unsafe_addr < count);
-
- dst[-1] = '\0';
- pagefault_enable();
- set_fs(old_fs);
-
- return ret < 0 ? ret : src - unsafe_addr;
-}
diff --git a/mm/maccess.c b/mm/maccess.c
index d53adf9ba84b..34fe24759ed1 100644
--- a/mm/maccess.c
+++ b/mm/maccess.c
@@ -60,3 +60,44 @@ long __probe_kernel_write(void *dst, const void *src, size_t
size)
return ret ? -EFAULT : 0;
}
EXPORT_SYMBOL_GPL(probe_kernel_write);
+
+/**
+ * strncpy_from_unsafe: - Copy a NUL terminated string from unsafe address.
+ * @dst: Destination address, in kernel space. This buffer must be at
+ * least @count bytes long.
+ * @src: Unsafe address.
+ * @count: Maximum number of bytes to copy, including the trailing NUL.
+ *
+ * Copies a NUL-terminated string from unsafe address to kernel buffer.
+ *
+ * On success, returns the length of the string INCLUDING the trailing NUL.
+ *
+ * If access fails, returns -EFAULT (some data may have been copied
+ * and the trailing NUL added).
+ *
+ * If @count is smaller than the length of the string, copies @count-1 bytes,
+ * sets the last byte of @dst buffer to NUL and returns @count.
+ */
+long strncpy_from_unsafe(char *dst, const void *unsafe_addr, long count)
+{
+ mm_segment_t old_fs = get_fs();
+ const void *src = unsafe_addr;
+ long ret;
+
+ if (unlikely(count <= 0))
+ return 0;
+
+ set_fs(KERNEL_DS);
+ pagefault_disable();
+
+ do {
+ ret = __copy_from_user_inatomic(dst++,
+ (const void __user __force
*)src++, 1);
+ } while (dst[-1] && ret == 0 && src - unsafe_addr < count);
+
+ dst[-1] = '\0';
+ pagefault_enable();
+ set_fs(old_fs);
+
+ return ret < 0 ? ret : src - unsafe_addr;
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] net: Add tos to validate source tracepoint
TOS is another key aspect of the lookup passed to fib_validate_source.
Add it to the tracepoint.
Signed-off-by: David Ahern
---
include/trace/events/fib.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/trace/events/fib.h b/include/trace/events/fib.h
index 4030f75410d7..acd1d22571a2 100644
--- a/include/trace/events/fib.h
+++ b/include/trace/events/fib.h
@@ -83,6 +83,7 @@ TRACE_EVENT(fib_validate_source,
__string( name, dev->name )
__field(int,oif )
__field(int,iif )
+ __field(__u8, tos )
__array(__u8, src,4 )
__array(__u8, dst,4 )
),
@@ -93,6 +94,7 @@ TRACE_EVENT(fib_validate_source,
__assign_str(name, dev ? dev->name : "not set");
__entry->oif = flp->flowi4_oif;
__entry->iif = flp->flowi4_iif;
+ __entry->tos = flp->flowi4_tos;
p32 = (__be32 *) __entry->src;
*p32 = flp->saddr;
@@ -101,8 +103,8 @@ TRACE_EVENT(fib_validate_source,
*p32 = flp->daddr;
),
- TP_printk("dev %s oif %d iif %d src %pI4 dst %pI4",
- __get_str(name), __entry->oif, __entry->iif,
+ TP_printk("dev %s oif %d iif %d tos %d src %pI4 dst %pI4",
+ __get_str(name), __entry->oif, __entry->iif, __entry->tos,
__entry->src, __entry->dst)
);
#endif /* _TRACE_FIB_H */
--
2.3.2 (Apple Git-55)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] net: Remove VRF change to udp_sendmsg
Remove the VRF change in udp_sendmsg to set the source address. The VRF
driver already has access to the packet on the TX path via the dst. It
can be used to update the source address in the header.
Update function based on OVS.
Cc: Tom Herbert
Signed-off-by: David Ahern
---
drivers/net/vrf.c | 63 ++-
net/ipv4/udp.c| 18
2 files changed, 58 insertions(+), 23 deletions(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index e7094fbd7568..169418254636 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -160,6 +160,58 @@ static netdev_tx_t vrf_process_v6_outbound(struct sk_buff
*skb,
return NET_XMIT_DROP;
}
+static void update_ipv4_saddr(struct sk_buff *skb, struct iphdr *iph,
+ __be32 new_addr)
+{
+ int tlen = skb->len - skb_transport_offset(skb);
+
+ if (iph->protocol == IPPROTO_TCP) {
+ if (likely(tlen >= sizeof(struct tcphdr))) {
+ inet_proto_csum_replace4(&tcp_hdr(skb)->check, skb,
+iph->saddr, new_addr, 1);
+ }
+ } else if (iph->protocol == IPPROTO_UDP) {
+ if (likely(tlen >= sizeof(struct udphdr))) {
+ struct udphdr *uh = udp_hdr(skb);
+
+ if (uh->check || skb->ip_summed == CHECKSUM_PARTIAL) {
+ inet_proto_csum_replace4(&uh->check, skb,
+iph->saddr, new_addr,
+1);
+ if (!uh->check)
+ uh->check = CSUM_MANGLED_0;
+ }
+ }
+ }
+
+ csum_replace4(&iph->check, iph->saddr, new_addr);
+ skb_clear_hash(skb);
+ iph->saddr = new_addr;
+}
+
+static int vrf_set_ip_saddr(struct sk_buff *skb, struct net_device *dev)
+{
+ struct iphdr *ip4h = ip_hdr(skb);
+ struct flowi4 fl4 = {
+ .flowi4_oif = dev->ifindex,
+ .flowi4_iif = LOOPBACK_IFINDEX,
+ .flowi4_tos = RT_TOS(ip4h->tos),
+ .flowi4_flags = FLOWI_FLAG_ANYSRC | FLOWI_FLAG_VRFSRC,
+ .daddr = ip4h->daddr,
+ };
+ struct rtable *rt;
+
+ rt = __ip_route_output_key(dev_net(dev), &fl4);
+ if (IS_ERR(rt))
+ return 1;
+
+ ip_rt_put(rt);
+
+ update_ipv4_saddr(skb, ip4h, fl4.saddr);
+
+ return 0;
+}
+
static int vrf_send_v4_prep(struct sk_buff *skb, struct flowi4 *fl4,
struct net_device *vrf_dev)
{
@@ -200,11 +252,6 @@ static netdev_tx_t vrf_process_v4_outbound(struct sk_buff
*skb,
if (vrf_send_v4_prep(skb, &fl4, vrf_dev))
goto err;
- if (!ip4h->saddr) {
- ip4h->saddr = inet_select_addr(skb_dst(skb)->dev, 0,
- RT_SCOPE_LINK);
- }
-
ret = ip_local_out(skb);
if (unlikely(net_xmit_eval(ret)))
vrf_dev->stats.tx_errors++;
@@ -298,12 +345,18 @@ static int vrf_finish_output(struct sock *sk, struct
sk_buff *skb)
static int vrf_output(struct sock *sk, struct sk_buff *skb)
{
struct net_device *dev = skb_dst(skb)->dev;
+ struct iphdr *iph = ip_hdr(skb);
IP_UPD_PO_STATS(dev_net(dev), IPSTATS_MIB_OUT, skb->len);
skb->dev = dev;
skb->protocol = htons(ETH_P_IP);
+ if (!iph->saddr && vrf_set_ip_saddr(skb, dev)) {
+ vrf_tx_error(dev, skb);
+ return -EINVAL;
+ }
+
return NF_HOOK_COND(NFPROTO_IPV4, NF_INET_POST_ROUTING, sk, skb,
NULL, dev,
vrf_finish_output,
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index c0a15e7f359f..ee3ba30f1ca5 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1017,24 +1017,6 @@ int udp_sendmsg(struct sock *sk, struct msghdr *msg,
size_t len)
fl4 = &fl4_stack;
- /* unconnected socket. If output device is enslaved to a VRF
-* device lookup source address from VRF table. This mimics
-* behavior of ip_route_connect{_init}.
-*/
- if (netif_index_is_vrf(net, ipc.oif)) {
- flowi4_init_output(fl4, ipc.oif, sk->sk_mark, tos,
- RT_SCOPE_UNIVERSE, sk->sk_protocol,
- (flow_flags | FLOWI_FLAG_VRFSRC),
- faddr, saddr, dport,
- inet->inet_sport);
-
- rt = ip_route_output_flow(net, fl4, sk);
- if (!IS_ERR(rt)) {
- saddr = fl4->saddr;
- ip_rt_put(rt);
- }
- }
-
flowi4
Re: igmp broadcast storm Red Hat EL7 3.1 Kernel
(Cc'ing netdev) On Sat, Aug 29, 2015 at 3:50 PM, Jeffrey Merkey wrote: > When installing Centos 7 running kernel 3.1 (Centos 7 distro) the > system generates an igmp broadcast storm which locks up and knocks > down a Century Link DSL router. Powering the router off clears the > broadcast storm. > > The bug is kernel related and resembles very closely another bug seen > about 10 years ago with Caldera's distro's on 2.4. The bug occurs on > the ia32 beta build. The bug DOES NOT exist in the 64 bit x86_64 > versions.I will attempt to debug it further since I have my own > debugger and try to run it down and provide more info. > A reproducer and/or bisect would help a lot. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg
On Mon, Aug 31, 2015 at 9:29 AM, David Ahern wrote:
> Remove the VRF change in udp_sendmsg to set the source address. The VRF
> driver already has access to the packet on the TX path via the dst. It
> can be used to update the source address in the header.
>
I don't understand this. The previous code was about selecting a
source address for packets being sourced ed on a socket, but this new
patch seems to essentially be doing SNAT in the VRF transmit path
which seems like a fundamentally different behavior. Is this really
your intention?
Thanks,
Tom
>
> Cc: Tom Herbert
> Signed-off-by: David Ahern
> ---
> drivers/net/vrf.c | 63
> ++-
> net/ipv4/udp.c| 18
> 2 files changed, 58 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
> index e7094fbd7568..169418254636 100644
> --- a/drivers/net/vrf.c
> +++ b/drivers/net/vrf.c
> @@ -160,6 +160,58 @@ static netdev_tx_t vrf_process_v6_outbound(struct
> sk_buff *skb,
> return NET_XMIT_DROP;
> }
>
> +static void update_ipv4_saddr(struct sk_buff *skb, struct iphdr *iph,
> + __be32 new_addr)
> +{
> + int tlen = skb->len - skb_transport_offset(skb);
> +
> + if (iph->protocol == IPPROTO_TCP) {
> + if (likely(tlen >= sizeof(struct tcphdr))) {
> + inet_proto_csum_replace4(&tcp_hdr(skb)->check, skb,
> +iph->saddr, new_addr, 1);
> + }
> + } else if (iph->protocol == IPPROTO_UDP) {
> + if (likely(tlen >= sizeof(struct udphdr))) {
> + struct udphdr *uh = udp_hdr(skb);
> +
> + if (uh->check || skb->ip_summed == CHECKSUM_PARTIAL) {
> + inet_proto_csum_replace4(&uh->check, skb,
> +iph->saddr, new_addr,
> +1);
> + if (!uh->check)
> + uh->check = CSUM_MANGLED_0;
> + }
> + }
> + }
> +
> + csum_replace4(&iph->check, iph->saddr, new_addr);
> + skb_clear_hash(skb);
> + iph->saddr = new_addr;
> +}
> +
> +static int vrf_set_ip_saddr(struct sk_buff *skb, struct net_device *dev)
> +{
> + struct iphdr *ip4h = ip_hdr(skb);
> + struct flowi4 fl4 = {
> + .flowi4_oif = dev->ifindex,
> + .flowi4_iif = LOOPBACK_IFINDEX,
> + .flowi4_tos = RT_TOS(ip4h->tos),
> + .flowi4_flags = FLOWI_FLAG_ANYSRC | FLOWI_FLAG_VRFSRC,
> + .daddr = ip4h->daddr,
> + };
> + struct rtable *rt;
> +
> + rt = __ip_route_output_key(dev_net(dev), &fl4);
> + if (IS_ERR(rt))
> + return 1;
> +
> + ip_rt_put(rt);
> +
> + update_ipv4_saddr(skb, ip4h, fl4.saddr);
> +
> + return 0;
> +}
> +
> static int vrf_send_v4_prep(struct sk_buff *skb, struct flowi4 *fl4,
> struct net_device *vrf_dev)
> {
> @@ -200,11 +252,6 @@ static netdev_tx_t vrf_process_v4_outbound(struct
> sk_buff *skb,
> if (vrf_send_v4_prep(skb, &fl4, vrf_dev))
> goto err;
>
> - if (!ip4h->saddr) {
> - ip4h->saddr = inet_select_addr(skb_dst(skb)->dev, 0,
> - RT_SCOPE_LINK);
> - }
> -
> ret = ip_local_out(skb);
> if (unlikely(net_xmit_eval(ret)))
> vrf_dev->stats.tx_errors++;
> @@ -298,12 +345,18 @@ static int vrf_finish_output(struct sock *sk, struct
> sk_buff *skb)
> static int vrf_output(struct sock *sk, struct sk_buff *skb)
> {
> struct net_device *dev = skb_dst(skb)->dev;
> + struct iphdr *iph = ip_hdr(skb);
>
> IP_UPD_PO_STATS(dev_net(dev), IPSTATS_MIB_OUT, skb->len);
>
> skb->dev = dev;
> skb->protocol = htons(ETH_P_IP);
>
> + if (!iph->saddr && vrf_set_ip_saddr(skb, dev)) {
> + vrf_tx_error(dev, skb);
> + return -EINVAL;
> + }
> +
> return NF_HOOK_COND(NFPROTO_IPV4, NF_INET_POST_ROUTING, sk, skb,
> NULL, dev,
> vrf_finish_output,
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index c0a15e7f359f..ee3ba30f1ca5 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1017,24 +1017,6 @@ int udp_sendmsg(struct sock *sk, struct msghdr *msg,
> size_t len)
>
> fl4 = &fl4_stack;
>
> - /* unconnected socket. If output device is enslaved to a VRF
> -* device lookup source address from VRF table. This mimics
> -* behavior of ip_route_connect{_init}.
> -*/
> - if (netif_index_is_vrf(net, ipc.oif)) {
> - flowi4_init_output(fl4, ipc.oif, sk->sk_mark, tos,
>
Re: [PATCH] net/smsc911x: Fix deferred probe for interrupt
Hello.
On 08/31/2015 05:03 PM, Grygorii Strashko wrote:
The interrupt handler may not be available when smsc911x probes if the
interrupt handler is a GPIO controller for example. Let's fix that
by adding handling for -EPROBE_DEFER.
Cc: Steve Glendinning
Signed-off-by: Tony Lindgren
---
drivers/net/ethernet/smsc/smsc911x.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 959aeea..cb9f166f 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2435,7 +2435,10 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
res_size = resource_size(res);
irq = platform_get_irq(pdev, 0);
-if (irq <= 0) {
+if (irq == -EPROBE_DEFER) {
+retval = -EPROBE_DEFER;
+goto out_0;
+} else if (irq <= 0) {
pr_warn("Could not allocate irq resource\n");
retval = -ENODEV;
I'd propagate the error code from platfrom_get_irq() instead (in
fact, I've submitted a couple of such patches yesterday and they have
been already merged).
Have you paid some attention on current platform_get_irq_() implementation?
The platform_get_irq() can return 0 in case of DT-boot.
This is what's indeed worth filtering out and converting to -ENODEV. ;-)
But my patches just ignored this possibility. I'm not at all fond of Linus'
idea about IRQ0 being invalid, BTW...
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg
On 8/31/15 11:02 AM, Tom Herbert wrote: On Mon, Aug 31, 2015 at 9:29 AM, David Ahern wrote: Remove the VRF change in udp_sendmsg to set the source address. The VRF driver already has access to the packet on the TX path via the dst. It can be used to update the source address in the header. I don't understand this. The previous code was about selecting a source address for packets being sourced ed on a socket, but this new patch seems to essentially be doing SNAT in the VRF transmit path which seems like a fundamentally different behavior. Is this really your intention? The original code and this new code are only controlling FIB lookups which in turn set the source address. Functionally both versions do the same thing. David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg
On Mon, Aug 31, 2015 at 10:05 AM, David Ahern wrote: > On 8/31/15 11:02 AM, Tom Herbert wrote: >> >> On Mon, Aug 31, 2015 at 9:29 AM, David Ahern >> wrote: >>> >>> Remove the VRF change in udp_sendmsg to set the source address. The VRF >>> driver already has access to the packet on the TX path via the dst. It >>> can be used to update the source address in the header. >>> >> >> I don't understand this. The previous code was about selecting a >> source address for packets being sourced ed on a socket, but this new >> patch seems to essentially be doing SNAT in the VRF transmit path >> which seems like a fundamentally different behavior. Is this really >> your intention? >> > > The original code and this new code are only controlling FIB lookups which > in turn set the source address. Functionally both versions do the same > thing. > It's a major departure from current convention. The source address of the packet should be set before doing ip_send_skb. In UDP unconnected case ip_route_output_flow calls inet_select_addr. AKAIK there is no provision for not setting the source address and relying on the output device to do this in its transmit routine. I still think it would be better to call into the VRF device from inet_select_addr using an ndo function. Tom > David > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg
Hi Tom: On 8/31/15 11:22 AM, Tom Herbert wrote: It's a major departure from current convention. The source address of the packet should be set before doing ip_send_skb. In UDP unconnected case ip_route_output_flow calls inet_select_addr. AKAIK there is no provision for not setting the source address and relying on the output device to do this in its transmit routine. I still think it would be better to call into the VRF device from inet_select_addr using an ndo function. I was not disregarding your suggestion and definitely appreciate the advice. I will look into it in time. In fact I was looking at how to better encapsulate FIB oif changes (e.g., with ndo) on the plane home yesterday, but those take time and seem more appropriate for 4.4. My intention with this patch is to reign in the VRF footprint and by extension impact for 4.3 without losing functionality. During the merge window for 4.3 net-next will be closed and it provides a good time to investigate abstractions like ndo handlers. David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] sctp: support global vtag assochash and per endpoint s(d)port assochash table
for telecom center, the usual case is that a server is connected by thousands
of clients. but if the server with only one enpoint(udp style) use the same
sport and dport to communicate with every clients, and every assoc in server
will be hashed in the same chain of global assoc hashtable due to currently we
choose dport and sport as the hash key.
when a packet is received, sctp_rcv try to find the assoc with sport and dport,
since that chain is too long to find it fast, it make the performance turn to
very low, some test data is as follow:
in server:
$./ss [start a udp server there]
in client:
$./cc [start 2500 sockets to connect server with same port and different ip,
and use one of them to send data to server]
*spend time is 854s, send pkt is 1000*
in server: #perf top
46.60% [kernel] [k] sctp_assoc_is_match
8.81% [kernel] [k] sctp_v4_cmp_addr
5.15% [kernel] [k] sctp_assoc_lookup_paddr
...
in client: #perf top
88.42% [kernel][k] __sctp_endpoint_lookup_assoc
2.06% libnl-3.so.200.16.1 [.] nl_object_identical
1.23% libnl-3.so.200.16.1 [.] nl_addr_cmp
...
we need to change the way to calculate the hash key, vtag is good value for
that, insteading the sport and dport. this way can work well for looking for
assoc in sctp_rcv.
becides, for the clients, if we turn the dport and sport global hash to per
endpoint's, which can make sctp_sendmsg look up assoc more quickly.
after that, the data of the same test is:
*spend time is 25s, send pkt is 1000*
in server: #perf top
9.92% libnl-3.so.200.16.1 [.] nl_object_identical
6.05% libnl-3.so.200.16.1 [.] nl_addr_cmp
4.72% libc-2.17.so[.] __memcmp_sse2
...
in client: #perf top
6.79% libc-2.17.so[.] __libc_calloc
6.50% [kernel][k] memcpy
6.35% libc-2.17.so[.] _int_free
...
Signed-off-by: Xin Long
---
include/net/sctp/sctp.h| 8 +--
include/net/sctp/structs.h | 8 ++-
net/sctp/endpointola.c | 22 +--
net/sctp/input.c | 160 +
4 files changed, 129 insertions(+), 69 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index ce13cf2..df14452 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -524,18 +524,16 @@ static inline int sctp_assoc_hashfn(struct net *net,
__u16 lport, __u16 rport)
{
int h = (lport << 16) + rport + net_hash_mix(net);
h ^= h>>8;
- return h & (sctp_assoc_hashsize - 1);
+ return h & (256 - 1);
}
/* This is the hash function for the association hash table. This is
* not used yet, but could be used as a better hash function when
* we have a vtag.
*/
-static inline int sctp_vtag_hashfn(__u16 lport, __u16 rport, __u32 vtag)
+static inline int sctp_vtag_hashfn(struct net *net, __u32 vtag)
{
- int h = (lport << 16) + rport;
- h ^= vtag;
- return h & (sctp_assoc_hashsize - 1);
+ return vtag & (sctp_assoc_hashsize - 1);
}
#define sctp_for_each_hentry(epb, head) \
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 495c87e..e0edfed 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -1150,6 +1150,9 @@ struct sctp_ep_common {
struct hlist_node node;
int hashent;
+ struct hlist_node node_ep;
+ int hashent_ep;
+
/* Runtime type information. What kind of endpoint is this? */
sctp_endpoint_type_t type;
@@ -1210,6 +1213,8 @@ struct sctp_endpoint {
/* This is really a list of struct sctp_association entries. */
struct list_head asocs;
+ struct sctp_hashbucket *asocshash;
+
/* Secret Key: A secret key used by this endpoint to compute
*the MAC. This SHOULD be a cryptographic quality
*random number with a sufficient length.
@@ -1272,7 +1277,8 @@ int sctp_endpoint_is_peeled_off(struct sctp_endpoint *,
const union sctp_addr *);
struct sctp_endpoint *sctp_endpoint_is_match(struct sctp_endpoint *,
struct net *, const union sctp_addr *);
-int sctp_has_association(struct net *net, const union sctp_addr *laddr,
+int sctp_has_association(struct net *net, struct sctp_endpoint *ep,
+const union sctp_addr *laddr,
const union sctp_addr *paddr);
int sctp_verify_init(struct net *net, const struct sctp_endpoint *ep,
diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
index 9da76ba..adcaded 100644
--- a/net/sctp/endpointola.c
+++ b/net/sctp/endpointola.c
@@ -62,7 +62,7 @@ static struct sctp_endpoint *sctp_endpoint_init(struct
sctp_endpoint *ep,
struct sctp_hmac_algo_param *auth_hmacs = NULL;
struct sctp_chunks_param *auth_chunks
[PATCH net] mpls: fix mpls_net_init memory leak
From: Nikolay Aleksandrov
Fix a memory leak in the mpls netns init function in case of failure. If
register_net_sysctl fails then we need to free the ctl_table.
Fixes: 7720c01f3f59 ("mpls: Add a sysctl to control the size of the mpls label
table")
Signed-off-by: Nikolay Aleksandrov
---
net/mpls/af_mpls.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 1f93a5978f2a..b1faa2dc0e6a 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -1066,8 +1066,10 @@ static int mpls_net_init(struct net *net)
table[0].data = net;
net->mpls.ctl = register_net_sysctl(net, "net/mpls", table);
- if (net->mpls.ctl == NULL)
+ if (net->mpls.ctl == NULL) {
+ kfree(table);
return -ENOMEM;
+ }
return 0;
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mwifiex: Make mwifiex_dbg a function, reduce object size
The mwifiex_dbg macro has two tests that could be consolidated
into a function reducing overall object size ~10KB (~4%).
So convert the macro into a function.
$ size drivers/net/wireless/mwifiex/built-in.o* (x86-64 defconfig)
textdata bss dec hex filename
23310286284809 246539 3c30b
drivers/net/wireless/mwifiex/built-in.o.new
24394986284809 257386 3ed6a
drivers/net/wireless/mwifiex/built-in.o.old
Signed-off-by: Joe Perches
---
drivers/net/wireless/mwifiex/main.c | 20
drivers/net/wireless/mwifiex/main.h | 17 -
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/main.c
b/drivers/net/wireless/mwifiex/main.c
index 278dc94..4fa8ca3 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -1447,6 +1447,26 @@ exit_sem_err:
}
EXPORT_SYMBOL_GPL(mwifiex_remove_card);
+void _mwifiex_dbg(const struct mwifiex_adapter *adapter, int mask,
+ const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ if (!adapter->dev || !(adapter->debug_mask & mask))
+ return;
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ dev_info(adapter->dev, "%pV", &vaf);
+
+ va_end(args);
+}
+EXPORT_SYMBOL_GPL(_mwifiex_dbg);
+
/*
* This function initializes the module.
*
diff --git a/drivers/net/wireless/mwifiex/main.h
b/drivers/net/wireless/mwifiex/main.h
index 6b95121..96663214 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -48,6 +48,9 @@
extern const char driver_version[];
+struct mwifiex_adapter;
+struct mwifiex_private;
+
enum {
MWIFIEX_ASYNC_CMD,
MWIFIEX_SYNC_CMD
@@ -180,12 +183,11 @@ enum MWIFIEX_DEBUG_LEVEL {
MWIFIEX_DBG_FATAL | \
MWIFIEX_DBG_ERROR)
-#define mwifiex_dbg(adapter, dbg_mask, fmt, args...) \
-do { \
- if ((adapter)->debug_mask & MWIFIEX_DBG_##dbg_mask) \
- if ((adapter)->dev) \
- dev_info((adapter)->dev, fmt, ## args); \
-} while (0)
+__printf(3, 4)
+void _mwifiex_dbg(const struct mwifiex_adapter *adapter, int mask,
+ const char *fmt, ...);
+#define mwifiex_dbg(adapter, mask, fmt, ...) \
+ _mwifiex_dbg(adapter, MWIFIEX_DBG_##mask, fmt, ##__VA_ARGS__)
#define DEBUG_DUMP_DATA_MAX_LEN128
#define mwifiex_dbg_dump(adapter, dbg_mask, str, buf, len) \
@@ -506,9 +508,6 @@ enum mwifiex_iface_work_flags {
MWIFIEX_IFACE_WORK_CARD_RESET,
};
-struct mwifiex_adapter;
-struct mwifiex_private;
-
struct mwifiex_private {
struct mwifiex_adapter *adapter;
u8 bss_type;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] sctp: support global vtag assochash and per endpoint s(d)port assochash table
attachment is the test script above-mentioned. sctperf.tar.gz Description: GNU Zip compressed data
Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg
On 8/31/15 11:22 AM, Tom Herbert wrote: It's a major departure from current convention. The source address of the packet should be set before doing ip_send_skb. In UDP unconnected case ip_route_output_flow calls inet_select_addr. AKAIK there is no provision for not setting the source address and relying on the output device to do this in its transmit routine. BTW, one other clarification the code setting the source address is NOT in the xmit function but the dst.output function. The VRF device uses a dst to direct packets to it. The output function (equivalent to ip_output) is what sets the source address if necessary. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg
On Mon, Aug 31, 2015 at 10:40 AM, David Ahern wrote: > Hi Tom: > > On 8/31/15 11:22 AM, Tom Herbert wrote: >> >> It's a major departure from current convention. The source address of >> the packet should be set before doing ip_send_skb. In UDP unconnected >> case ip_route_output_flow calls inet_select_addr. AKAIK there is no >> provision for not setting the source address and relying on the output >> device to do this in its transmit routine. I still think it would be >> better to call into the VRF device from inet_select_addr using an ndo >> function. > > > I was not disregarding your suggestion and definitely appreciate the advice. > I will look into it in time. In fact I was looking at how to better > encapsulate FIB oif changes (e.g., with ndo) on the plane home yesterday, > but those take time and seem more appropriate for 4.4. > > My intention with this patch is to reign in the VRF footprint and by > extension impact for 4.3 without losing functionality. During the merge > window for 4.3 net-next will be closed and it provides a good time to > investigate abstractions like ndo handlers. > Personally, I would opt to keep the existing patches as they are until the underlying abstraction issues can be properly addressed. Turning this into some sort of NAT problem for expediency doesn't seem like the right approach. Tom > David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: igmp broadcast storm Red Hat EL7 3.1 Kernel
I was able to reproduce it last night with 2.6.32 on Centos 6.3 so it does not seem confined to just the 3.X tree. I think this is something that's been lurking in the kernel for years and just has a hard time showing up. Bugs that go away on their own come back on their own. I got a trace of the traffic but need one of the os. I'll attempt to get a trace of this again since I seem to be able to reproduce it by routing NetFlix traffic through the router while I am streaming live videos on Linux. I will setup the system to trap the bug and post the traces. Jeff On 8/31/15, Cong Wang wrote: > (Cc'ing netdev) > > On Sat, Aug 29, 2015 at 3:50 PM, Jeffrey Merkey > wrote: >> When installing Centos 7 running kernel 3.1 (Centos 7 distro) the >> system generates an igmp broadcast storm which locks up and knocks >> down a Century Link DSL router. Powering the router off clears the >> broadcast storm. >> >> The bug is kernel related and resembles very closely another bug seen >> about 10 years ago with Caldera's distro's on 2.4. The bug occurs on >> the ia32 beta build. The bug DOES NOT exist in the 64 bit x86_64 >> versions.I will attempt to debug it further since I have my own >> debugger and try to run it down and provide more info. >> > > A reproducer and/or bisect would help a lot. > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] sctp: support global vtag assochash and per endpoint s(d)port assochash table
that patch is actually meant for net-next, need to state. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next:master 1512/1524] net/ipv4/af_inet.c:1486:26: error: 'offt' undeclared
On 31/08/15 05:25, Madalin-Cristian Bucur wrote:
>> -Original Message-
>> From: netdev-ow...@vger.kernel.org [mailto:netdev-
>> Subject: Re: [net-next:master 1512/1524] net/ipv4/af_inet.c:1486:26: error:
>> 'offt' undeclared
>>
>> From: kbuild test robot
>> Date: Mon, 31 Aug 2015 13:06:10 +0800
>>
>>>net/ipv4/af_inet.c: In function 'snmp_get_cpu_field64':
> net/ipv4/af_inet.c:1486:26: error: 'offt' undeclared (first use in this
>> function)
>>> v = *(((u64 *)bhptr) + offt);
>>> ^
>>>net/ipv4/af_inet.c:1486:26: note: each undeclared identifier is reported
>> only once for each function it appears in
>>>net/ipv4/af_inet.c: In function 'snmp_fold_field64':
> net/ipv4/af_inet.c:1499:39: error: 'offct' undeclared (first use in this
>> function)
>>> res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
>>> ^
> net/ipv4/af_inet.c:1499:10: error: too many arguments to function
>> 'snmp_get_cpu_field'
>>> res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
>>> ^
>>>net/ipv4/af_inet.c:1455:5: note: declared here
>>> u64 snmp_get_cpu_field(void __percpu *mib, int cpu, int offt)
>>> ^
>>>net/ipv4/af_inet.c:1499: confused by earlier errors, bailing out
>>
>> Thanks, this should fix it:
>>
>>
>> [PATCH] ipv4: Fix 32-bit build.
>>
>>net/ipv4/af_inet.c: In function 'snmp_get_cpu_field64':
net/ipv4/af_inet.c:1486:26: error: 'offt' undeclared (first use in this
>> function)
>> v = *(((u64 *)bhptr) + offt);
>> ^
>>net/ipv4/af_inet.c:1486:26: note: each undeclared identifier is reported
>> only once for each function it appears in
>>net/ipv4/af_inet.c: In function 'snmp_fold_field64':
net/ipv4/af_inet.c:1499:39: error: 'offct' undeclared (first use in this
>> function)
>> res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
>> ^
net/ipv4/af_inet.c:1499:10: error: too many arguments to function
>> 'snmp_get_cpu_field'
>> res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
>> ^
>>net/ipv4/af_inet.c:1455:5: note: declared here
>> u64 snmp_get_cpu_field(void __percpu *mib, int cpu, int offt)
>> ^
>>
>> Reported-by: kbuild test robot
>> Signed-off-by: David S. Miller
>> ---
>> net/ipv4/af_inet.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
>> index 0c69c0b..c2d0ebc 100644
>> --- a/net/ipv4/af_inet.c
>> +++ b/net/ipv4/af_inet.c
>> @@ -1471,7 +1471,7 @@ EXPORT_SYMBOL_GPL(snmp_fold_field);
>>
>> #if BITS_PER_LONG==32
>>
>> -u64 snmp_get_cpu_field64(void __percpu *mib, int cpu, int offct,
>> +u64 snmp_get_cpu_field64(void __percpu *mib, int cpu, int offt,
>> size_t syncp_offset)
>> {
>> void *bhptr;
>> @@ -1496,7 +1496,7 @@ u64 snmp_fold_field64(void __percpu *mib, int
>> offt, size_t syncp_offset)
>> int cpu;
>>
>> for_each_possible_cpu(cpu) {
>> -res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
>> +res += snmp_get_cpu_field(mib, cpu, offt, syncp_offset);
>> }
>> return res;
>> }
>> --
>> 2.1.0
>>
>> --
>
> Hi,
>
> shouldn't that be snmp_get_cpu_field64() ?
>
> - res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
> + res += snmp_get_cpu_field64(mib, cpu, offt, syncp_offset);
Yes, that fixes the build for me as well and sounds like the intent.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: qmi_wwan: Sierra Wireless MC73xx -> Sierra Wireless MC7304/MC7354
Other Sierra Wireless MC73xx devices exist, with different USB IDs.
Cc: Bjørn Mork
Signed-off-by: David Ward
---
drivers/net/usb/qmi_wwan.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 64a60af..7621b68 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -752,8 +752,8 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)},/* Sierra Wireless MC7750 */
{QMI_FIXED_INTF(0x1199, 0x68a2, 8)},/* Sierra Wireless MC7710 in
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)}, /* Sierra Wireless MC7710 in
QMI mode */
- {QMI_FIXED_INTF(0x1199, 0x68c0, 8)},/* Sierra Wireless MC73xx */
- {QMI_FIXED_INTF(0x1199, 0x68c0, 10)}, /* Sierra Wireless MC73xx */
+ {QMI_FIXED_INTF(0x1199, 0x68c0, 8)},/* Sierra Wireless
MC7304/MC7354 */
+ {QMI_FIXED_INTF(0x1199, 0x68c0, 10)}, /* Sierra Wireless
MC7304/MC7354 */
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
{QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
{QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless
MC7305/MC7355 */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipv4: fix 32b build
From: Madalin Bucur Date: Mon, 31 Aug 2015 15:46:07 +0300 > Address remaining issue after 80ec192. > > Signed-off-by: Madalin Bucur Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] ip-tunnel: Use API to access tunnel metadata options.
On Sun, Aug 30, 2015 at 6:09 PM, Pravin B Shelar wrote: > Currently tun-info options pointer is used in few cases to > pass options around. But tunnel options can be accessed using > ip_tunnel_info_opts() API without using the pointer. Following > patch removes the redundant pointer and consistently make use > of API. > > Signed-off-by: Pravin B Shelar Reviewed-by: Jesse Gross -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 10/10] ss: extended json_writer for hex field and value output
> diff --git a/lib/json_writer.c b/lib/json_writer.c
> index 2af16e1..495ce57 100644
> --- a/lib/json_writer.c
> +++ b/lib/json_writer.c
> @@ -22,6 +22,8 @@
>
> #include "json_writer.h"
>
> +#define notused
> +
Gack. Just take out the #ifdef
> struct json_writer {
> FILE*out; /* output file */
> unsigneddepth; /* nesting */
> @@ -223,6 +225,14 @@ void jsonw_int(json_writer_t *self, int64_t num)
> jsonw_printf(self, "%"PRId64, num);
> }
>
> +void jsonw_hex(json_writer_t *self, uint64_t num)
> +{
> + char tmp[17];
> +
> + sprintf(tmp, "%"PRIx64, num);
> + jsonw_string(self, tmp);
> +}
> +
No. JSON is a standard. The output has to be one of the formats in the
standard. hex is a display issue not an encoding style.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] airo: fix IW_AUTH_ALG_OPEN_SYSTEM
Handle IW_AUTH_ALG_OPEN_SYSTEM in set_auth.
This allows wpa_supplicant (and thus NetworkManager) to work with open APs.
Signed-off-by: Ondrej Zary
---
drivers/net/wireless/airo.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index d0c97c2..2066a1f 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -6670,10 +6670,9 @@ static int airo_set_auth(struct net_device *dev,
break;
case IW_AUTH_80211_AUTH_ALG: {
- /* FIXME: What about AUTH_OPEN? This API seems to
-* disallow setting our auth to AUTH_OPEN.
-*/
- if (param->value & IW_AUTH_ALG_SHARED_KEY) {
+ if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
+ local->config.authType = AUTH_OPEN;
+ } else if (param->value & IW_AUTH_ALG_SHARED_KEY) {
local->config.authType = AUTH_SHAREDKEY;
} else if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
local->config.authType = AUTH_ENCRYPT;
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] airo: Implement netif_carrier_on/off
Add calls to netif_carrier_on and netif_carrier_off
Signed-off-by: Ondrej Zary
---
drivers/net/wireless/airo.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 2066a1f..1a9ddcd 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -3266,6 +3266,7 @@ static void airo_handle_link(struct airo_info *ai)
wake_up_interruptible(&ai->thr_wait);
} else
airo_send_event(ai->dev);
+ netif_carrier_on(ai->dev);
} else if (!scan_forceloss) {
if (auto_wep && !ai->expires) {
ai->expires = RUN_AT(3*HZ);
@@ -3276,7 +3277,9 @@ static void airo_handle_link(struct airo_info *ai)
eth_zero_addr(wrqu.ap_addr.sa_data);
wrqu.ap_addr.sa_family = ARPHRD_ETHER;
wireless_send_event(ai->dev, SIOCGIWAP, &wrqu, NULL);
- }
+ netif_carrier_off(ai->dev);
+ } else
+ netif_carrier_off(ai->dev);
}
static void airo_handle_rx(struct airo_info *ai)
@@ -3612,6 +3615,7 @@ static void disable_MAC( struct airo_info *ai, int lock )
{
return;
if (test_bit(FLAG_ENABLED, &ai->flags)) {
+ netif_carrier_off(ai->dev);
memset(&cmd, 0, sizeof(cmd));
cmd.cmd = MAC_DISABLE; // disable in case already enabled
issuecommand(ai, &cmd, &rsp);
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] ip-tunnel: Use API to access tunnel metadata options.
From: Pravin B Shelar Date: Sun, 30 Aug 2015 18:09:38 -0700 > Currently tun-info options pointer is used in few cases to > pass options around. But tunnel options can be accessed using > ip_tunnel_info_opts() API without using the pointer. Following > patch removes the redundant pointer and consistently make use > of API. > > Signed-off-by: Pravin B Shelar Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] IGMP: Inhibit reports for local multicast groups - DOCUMENT
From: Philip Downey Date: Mon, 31 Aug 2015 11:30:38 +0100 > Document the addition of a new sysctl variable which controls the > generation of IGMP reports for link local multicast groups in the > 224.0.0.X range. > > IGMP reports for local multicast groups can now be optionally > inhibited by setting the value to zero e.g.: > echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports > > To retain backwards compatibility the previous behaviour is retained > by default on system boot or reverted by setting the value back to > non-zero. > > Signed-off-by: Philip Downey Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2 0/4] tcp: receive-side per route dctcp handling
From: Daniel Borkmann Date: Mon, 31 Aug 2015 15:58:43 +0200 > Original cover letter: > > Currently, the following case doesn't use DCTCP, even if it should: > > - responder has f.e. cubic as system wide default > - 'ip route congctl dctcp $src' was set > > Then, DCTCP is NOT used if a DCTCP sender attempts to connect from a > host in the $src range: ECT(0) is set, but listen_sk is not dctcp, so > we fail the INET_ECN_is_not_ect sanity check. > > We also have to examine the dst used for the SYN/ACK reply to make > this case work. > > In order to minimize additional cost, store the 'ecn is must have' > information is the dst_features field. > > The set targets -next instead of -net since this doesn't seem to be a > serious bug and to give the change more soak time until it hits linus > tree. > > v1 -> v2: > - Addressed Dave's feedback, not exposing any bits to user space > - Added patch 3 to reject incorrect configurations > - Rest as is, rebased and retested Series applied, thanks Daniel. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] lib: move strncpy_from_unsafe() into mm/maccess.c
From: Alexei Starovoitov
Date: Mon, 31 Aug 2015 08:57:10 -0700
> To fix build errors:
> kernel/built-in.o: In function `bpf_trace_printk':
> bpf_trace.c:(.text+0x11a254): undefined reference to `strncpy_from_unsafe'
> kernel/built-in.o: In function `fetch_memory_string':
> trace_kprobe.c:(.text+0x11acf8): undefined reference to `strncpy_from_unsafe'
>
> move strncpy_from_unsafe() next to probe_kernel_read/write()
> which use the same memory access style.
>
> Reported-by: Fengguang Wu
> Reported-by: Guenter Roeck
> Fixes: 1a6877b9c0c2 ("lib: introduce strncpy_from_unsafe()")
> Signed-off-by: Alexei Starovoitov
> ---
> For configs without kprobes and bpf the cost of this unused function is
> ~200 bytes which I think is a better trade off vs creating
> new Kconfig selector just for this single function.
> Another alternative is to move it to kernel/trace/trace_kprobe.c,
> but then it will lose generality and probably should be removed
> from include/linux/uaccess.h, so mm/maccess.c looks the best.
Ok, applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: Add tos to validate source tracepoint
From: David Ahern Date: Mon, 31 Aug 2015 09:57:12 -0600 > TOS is another key aspect of the lookup passed to fib_validate_source. > Add it to the tracepoint. > > Signed-off-by: David Ahern Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] lib: move strncpy_from_unsafe() into mm/maccess.c
On 08/31/2015 12:36 PM, David Miller wrote:
From: Alexei Starovoitov
Date: Mon, 31 Aug 2015 08:57:10 -0700
To fix build errors:
kernel/built-in.o: In function `bpf_trace_printk':
bpf_trace.c:(.text+0x11a254): undefined reference to `strncpy_from_unsafe'
kernel/built-in.o: In function `fetch_memory_string':
trace_kprobe.c:(.text+0x11acf8): undefined reference to `strncpy_from_unsafe'
move strncpy_from_unsafe() next to probe_kernel_read/write()
which use the same memory access style.
Reported-by: Fengguang Wu
Reported-by: Guenter Roeck
Too late, but:
Tested-by: Guenter Roeck
Guenter
Fixes: 1a6877b9c0c2 ("lib: introduce strncpy_from_unsafe()")
Signed-off-by: Alexei Starovoitov
---
For configs without kprobes and bpf the cost of this unused function is
~200 bytes which I think is a better trade off vs creating
new Kconfig selector just for this single function.
Another alternative is to move it to kernel/trace/trace_kprobe.c,
but then it will lose generality and probably should be removed
from include/linux/uaccess.h, so mm/maccess.c looks the best.
Ok, applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg
From: David Ahern Date: Mon, 31 Aug 2015 09:29:40 -0700 > Remove the VRF change in udp_sendmsg to set the source address. The VRF > driver already has access to the packet on the TX path via the dst. It > can be used to update the source address in the header. > > Update function based on OVS. > > Cc: Tom Herbert > Signed-off-by: David Ahern This is worse. You have the source address in the VRF driver's output routine in fl4.saddr, just use it as-is. You're adding even more route lookups, at least the existing code just walks the device address less which is often cheaper than a full-blown route lookup. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] mpls: fix mpls_net_init memory leak
From: Nikolay Aleksandrov
Date: Mon, 31 Aug 2015 10:44:19 -0700
> From: Nikolay Aleksandrov
>
> Fix a memory leak in the mpls netns init function in case of failure. If
> register_net_sysctl fails then we need to free the ctl_table.
>
> Fixes: 7720c01f3f59 ("mpls: Add a sysctl to control the size of the mpls
> label table")
> Signed-off-by: Nikolay Aleksandrov
Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
vethpair creation performance, 3.14 versus 4.2.0
On 08/29/2015 10:59 PM, Raghavendra K T wrote: > Please note that similar overhead was also reported while creating > veth pairs https://lkml.org/lkml/2013/3/19/556 That got me curious, so I took the veth pair creation script from there, and started running it out to 10K pairs, comparing a 3.14.44 kernel with a 4.2.0-rc4+ from net-next and then net-next after pulling to get the snmp stat aggregation perf change (4.2.0-rc8+). Indeed, the 4.2.0-rc8+ kernel with the change was faster than the 4.2.0-rc4+ kernel without it, but both were slower than the 3.14.44 kernel. I've put a spreadsheet with the results at: ftp://ftp.netperf.org/vethpair/vethpair_compare.ods A perf top for the 4.20-rc8+ kernel from the net-next tree looks like this out around 10K pairs: PerfTop: 11155 irqs/sec kernel:94.2% exact: 0.0% [4000Hz cycles], (all, 32 CPUs) --- 23.44% [kernel] [k] vsscanf 7.32% [kernel] [k] mutex_spin_on_owner.isra.4 5.63% [kernel] [k] __memcpy 5.27% [kernel] [k] __dev_alloc_name 3.46% [kernel] [k] format_decode 3.44% [kernel] [k] vsnprintf 3.16% [kernel] [k] acpi_os_write_port 2.71% [kernel] [k] number.isra.13 1.50% [kernel] [k] strncmp 1.21% [kernel] [k] _parse_integer 0.93% [kernel] [k] filemap_map_pages 0.82% [kernel] [k] put_dec_trunc8 0.82% [kernel] [k] unmap_single_vma 0.78% [kernel] [k] native_queued_spin_lock_slowpath 0.71% [kernel] [k] menu_select 0.65% [kernel] [k] clear_page 0.64% [kernel] [k] _raw_spin_lock 0.62% [kernel] [k] page_fault 0.60% [kernel] [k] find_busiest_group 0.53% [kernel] [k] snprintf 0.52% [kernel] [k] int_sqrt 0.46% [kernel] [k] simple_strtoull 0.44% [kernel] [k] page_remove_rmap My attempts to get a call-graph have been met with very limited success. Even though I've installed the dbg package from "make deb-pkg" the symbol resolution doesn't seem to be working. happy benchmarking, rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg
On 8/31/15 1:44 PM, David Miller wrote: From: David Ahern Date: Mon, 31 Aug 2015 09:29:40 -0700 Remove the VRF change in udp_sendmsg to set the source address. The VRF driver already has access to the packet on the TX path via the dst. It can be used to update the source address in the header. Update function based on OVS. Cc: Tom Herbert Signed-off-by: David Ahern This is worse. You have the source address in the VRF driver's output routine in fl4.saddr, just use it as-is. The original saddr code in vrf_xmit was just wrong. It should not have been there and was a leftover from early development days. The saddr needs to be set in the dst output function (vrf_output) as I did in this patch otherwise the packet hits the tcpdump tap with potentially no source address. You're adding even more route lookups, at least the existing code just walks the device address less which is often cheaper than a full-blown route lookup. TCP (and connected sockets) do not hit this lookup in vrf_output. If anything I should be going straight to fib_table_lookup in the VRF driver for this new lookup to get the source address. It knows the exact table that should be used and hence can avoid the rules walk + local table miss which happens using the ip_route_x functions as well as the rth lookup/create which is not needed here. Opinions before I work on another version? David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] airo: fix IW_AUTH_ALG_OPEN_SYSTEM
On Mon, 2015-08-31 at 21:19 +0200, Ondrej Zary wrote:
> Handle IW_AUTH_ALG_OPEN_SYSTEM in set_auth.
> This allows wpa_supplicant (and thus NetworkManager) to work with open APs.
>
> Signed-off-by: Ondrej Zary
> ---
> drivers/net/wireless/airo.c |7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
> index d0c97c2..2066a1f 100644
> --- a/drivers/net/wireless/airo.c
> +++ b/drivers/net/wireless/airo.c
> @@ -6670,10 +6670,9 @@ static int airo_set_auth(struct net_device *dev,
> break;
>
> case IW_AUTH_80211_AUTH_ALG: {
> - /* FIXME: What about AUTH_OPEN? This API seems to
> - * disallow setting our auth to AUTH_OPEN.
> - */
> - if (param->value & IW_AUTH_ALG_SHARED_KEY) {
> + if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
> + local->config.authType = AUTH_OPEN;
> + } else if (param->value & IW_AUTH_ALG_SHARED_KEY) {
> local->config.authType = AUTH_SHAREDKEY;
> } else if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
> local->config.authType = AUTH_ENCRYPT;
NAK; there are two problems with this patch. First, there's already an
if test for OPEN_SYSTEM which sets authType to AUTH_ENCRYPT. Second,
AUTH_OPEN means to disable encryption entirely. The decision being made
here is whether to use Shared Key or Open authentication, not whether
encryption is being used or not. Thus this patch would appear to break
most WEP APs?
Airo really wants to know the auth type *and* whether encryption will
actually be used at the same time, and we don't have that information
here. I guess the only thing you can do here is call get_wep_key() for
all the indexes and see if any keys are set, and if any keys are set,
use AUTH_ENCRYPT. If get_wep_key() returns -1 for all 4 indexes, use
AUTH_OPEN. But you have to make sure that this all gets protected by
local->wep_capable and that you're not checking indexes above
ai->max_wep_idx. Yay airo!
Dan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] gro_cells: remove spinlock protecting receive queues
From: Eric Dumazet
As David pointed out, spinlock are no longer needed
to protect the per cpu queues used in gro cells infrastructure.
Also use new napi_complete_done() API so that gro_flush_timeout
tweaks have an effect.
Signed-off-by: Eric Dumazet
---
include/net/gro_cells.h | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/include/net/gro_cells.h b/include/net/gro_cells.h
index 0f712c0..cf6c745 100644
--- a/include/net/gro_cells.h
+++ b/include/net/gro_cells.h
@@ -32,37 +32,28 @@ static inline void gro_cells_receive(struct gro_cells
*gcells, struct sk_buff *s
return;
}
- /* We run in BH context */
- spin_lock(&cell->napi_skbs.lock);
-
__skb_queue_tail(&cell->napi_skbs, skb);
if (skb_queue_len(&cell->napi_skbs) == 1)
napi_schedule(&cell->napi);
-
- spin_unlock(&cell->napi_skbs.lock);
}
-/* called unser BH context */
+/* called under BH context */
static inline int gro_cell_poll(struct napi_struct *napi, int budget)
{
struct gro_cell *cell = container_of(napi, struct gro_cell, napi);
struct sk_buff *skb;
int work_done = 0;
- spin_lock(&cell->napi_skbs.lock);
while (work_done < budget) {
skb = __skb_dequeue(&cell->napi_skbs);
if (!skb)
break;
- spin_unlock(&cell->napi_skbs.lock);
napi_gro_receive(napi, skb);
work_done++;
- spin_lock(&cell->napi_skbs.lock);
}
if (work_done < budget)
- napi_complete(napi);
- spin_unlock(&cell->napi_skbs.lock);
+ napi_complete_done(napi, work_done);
return work_done;
}
@@ -77,7 +68,7 @@ static inline int gro_cells_init(struct gro_cells *gcells,
struct net_device *de
for_each_possible_cpu(i) {
struct gro_cell *cell = per_cpu_ptr(gcells->cells, i);
- skb_queue_head_init(&cell->napi_skbs);
+ __skb_queue_head_init(&cell->napi_skbs);
netif_napi_add(dev, &cell->napi, gro_cell_poll, 64);
napi_enable(&cell->napi);
}
@@ -92,8 +83,9 @@ static inline void gro_cells_destroy(struct gro_cells *gcells)
return;
for_each_possible_cpu(i) {
struct gro_cell *cell = per_cpu_ptr(gcells->cells, i);
+
netif_napi_del(&cell->napi);
- skb_queue_purge(&cell->napi_skbs);
+ __skb_queue_purge(&cell->napi_skbs);
}
free_percpu(gcells->cells);
gcells->cells = NULL;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] e1000: fix e1000e_disable_aspm_locked() warning
From: Dave Hansen
I have a .config with CONFIG_PM disabled. I get the following whenever
compiling the e1000 driver:
...net/ethernet/intel/e1000e/netdev.c:6450:13: warning:
'e1000e_disable_aspm_locked' defined but not used [-Wunused-function]
static void e1000e_disable_aspm_locked(struct pci_dev *pdev, u16 state)
Looks like we just need to move e1000e_disable_aspm_locked() to
be underneath the CONFIG_PM #ifdef.
Signed-off-by: Dave Hansen
Cc: Jeff Kirsher (supporter:INTEL ETHERNET
DRIVERS)
Cc: Jesse Brandeburg (reviewer)
Cc: Shannon Nelson (reviewer)
Cc: Carolyn Wyborny (reviewer)
Cc: Don Skidmore (reviewer)
Cc: Matthew Vick (reviewer)
Cc: John Ronciak (reviewer)
Cc: Mitch Williams (reviewer)
Cc: intel-wired-...@lists.osuosl.org (open list:INTEL ETHERNET DRIVERS)
Cc: netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
Cc: linux-ker...@vger.kernel.org (open list)
---
b/drivers/net/ethernet/intel/e1000e/netdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/ethernet/intel/e1000e/netdev.c~fix-e1000-warning
drivers/net/ethernet/intel/e1000e/netdev.c
--- a/drivers/net/ethernet/intel/e1000e/netdev.c~fix-e1000-warning
2015-08-31 14:19:11.520115321 -0700
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c2015-08-31
14:19:11.525115549 -0700
@@ -6439,6 +6439,7 @@ static void e1000e_disable_aspm(struct p
__e1000e_disable_aspm(pdev, state, 0);
}
+#ifdef CONFIG_PM
/**
* e1000e_disable_aspm_locked Disable ASPM states.
* @pdev: pointer to PCI device struct
@@ -6452,7 +6453,6 @@ static void e1000e_disable_aspm_locked(s
__e1000e_disable_aspm(pdev, state, 1);
}
-#ifdef CONFIG_PM
static int __e1000_resume(struct pci_dev *pdev)
{
struct net_device *netdev = pci_get_drvdata(pdev);
_
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vethpair creation performance, 3.14 versus 4.2.0
On 8/31/15 1:48 PM, Rick Jones wrote: My attempts to get a call-graph have been met with very limited success. Even though I've installed the dbg package from "make deb-pkg" the symbol resolution doesn't seem to be working. Looks like Debian does not enable framepointers by default: $ grep FRAME /boot/config-3.2.0-4-amd64 ... # CONFIG_FRAME_POINTER is not set Similar result for jessie. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vethpair creation performance, 3.14 versus 4.2.0
On 08/31/2015 02:29 PM, David Ahern wrote: On 8/31/15 1:48 PM, Rick Jones wrote: My attempts to get a call-graph have been met with very limited success. Even though I've installed the dbg package from "make deb-pkg" the symbol resolution doesn't seem to be working. Looks like Debian does not enable framepointers by default: $ grep FRAME /boot/config-3.2.0-4-amd64 ... # CONFIG_FRAME_POINTER is not set Similar result for jessie. And indeed, my config file has a Debian lineage. rick -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 RFT net-next 0/9] DSA port configuration and status
From: Andrew Lunn Date: Mon, 31 Aug 2015 15:56:45 +0200 > This patchset allows various switch port settings to be configured and > port status to be sampled. Some of these patches have been posted > before. > > The first three patches provide infrastructure for configuring a > switch ports link speed and duplex from a fixed_link phy. > > Patch four then uses this infrastructure to allow the CPU and DSA > ports of a switch to be configured using a fixed-link property in the > device tree. > > Patches five and six allow a phy-mode property to be specified in the > device tree, and allow this to be used for configuring RGMII delays. > > Patches seven through nine allow link status, for example that of an > SFP module, to be read from a gpio. Series applied, thanks Andrew. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipv6: send NEWLINK on RA managed/otherconf changes
From: Marius Tomaschewski Date: Mon, 31 Aug 2015 15:59:22 +0200 > The kernel is applying the RA managed/otherconf flags silently and > forgets to send ifinfo notify to inform about their change when the > router provides a zero reachable_time and retrans_timer as dnsmasq > and many routers send it, which just means unspecified by this router > and the host should continue using whatever value it is already using. > Userspace may monitor the ifinfo notifications to activate dhcpv6. > > Signed-off-by: Marius Tomaschewski Applied, but more ideally this function should emit only a single NEWLINK message rather than potentially 3. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] airo: fix IW_AUTH_ALG_OPEN_SYSTEM
On Monday 31 August 2015 22:44:54 Dan Williams wrote:
> On Mon, 2015-08-31 at 21:19 +0200, Ondrej Zary wrote:
> > Handle IW_AUTH_ALG_OPEN_SYSTEM in set_auth.
> > This allows wpa_supplicant (and thus NetworkManager) to work with open
> > APs.
> >
> > Signed-off-by: Ondrej Zary
> > ---
> > drivers/net/wireless/airo.c |7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
> > index d0c97c2..2066a1f 100644
> > --- a/drivers/net/wireless/airo.c
> > +++ b/drivers/net/wireless/airo.c
> > @@ -6670,10 +6670,9 @@ static int airo_set_auth(struct net_device *dev,
> > break;
> >
> > case IW_AUTH_80211_AUTH_ALG: {
> > - /* FIXME: What about AUTH_OPEN? This API seems to
> > -* disallow setting our auth to AUTH_OPEN.
> > -*/
> > - if (param->value & IW_AUTH_ALG_SHARED_KEY) {
> > + if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
> > + local->config.authType = AUTH_OPEN;
> > + } else if (param->value & IW_AUTH_ALG_SHARED_KEY) {
> > local->config.authType = AUTH_SHAREDKEY;
> > } else if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
> > local->config.authType = AUTH_ENCRYPT;
>
> NAK; there are two problems with this patch. First, there's already an
> if test for OPEN_SYSTEM which sets authType to AUTH_ENCRYPT. Second,
> AUTH_OPEN means to disable encryption entirely. The decision being made
> here is whether to use Shared Key or Open authentication, not whether
> encryption is being used or not. Thus this patch would appear to break
> most WEP APs?
>
> Airo really wants to know the auth type *and* whether encryption will
> actually be used at the same time, and we don't have that information
> here. I guess the only thing you can do here is call get_wep_key() for
> all the indexes and see if any keys are set, and if any keys are set,
> use AUTH_ENCRYPT. If get_wep_key() returns -1 for all 4 indexes, use
> AUTH_OPEN. But you have to make sure that this all gets protected by
> local->wep_capable and that you're not checking indexes above
> ai->max_wep_idx. Yay airo!
Sorry, I got confused (and it worked with WEP with a test AP, although there's
no open system/shared key setting in the firmware).
Reading the wpa_supplicant code, it uses IW_AUTH_ALG_OPEN_SYSTEM for WEP open
system and also as a default value - which gets used when encryption is
disabled:
static int wpa_driver_wext_set_auth_alg(void *priv, int auth_alg)
{
struct wpa_driver_wext_data *drv = priv;
int algs = 0, res;
if (auth_alg & WPA_AUTH_ALG_OPEN)
algs |= IW_AUTH_ALG_OPEN_SYSTEM;
if (auth_alg & WPA_AUTH_ALG_SHARED)
algs |= IW_AUTH_ALG_SHARED_KEY;
if (auth_alg & WPA_AUTH_ALG_LEAP)
algs |= IW_AUTH_ALG_LEAP;
if (algs == 0) {
/* at least one algorithm should be set */
algs = IW_AUTH_ALG_OPEN_SYSTEM;
}
res = wpa_driver_wext_set_auth_param(drv, IW_AUTH_80211_AUTH_ALG,
algs);
drv->auth_alg_fallback = res == -2;
return res;
}
However, when SIOCSIWAUTH fails with EOPNOTSUPP, it tries SIOCSIWENCODE. This
patch seems to work too with my AP:
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index d0c97c2..2610fe3 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -6670,14 +6670,17 @@ static int airo_set_auth(struct net_device *dev,
break;
case IW_AUTH_80211_AUTH_ALG: {
- /* FIXME: What about AUTH_OPEN? This API seems to
-* disallow setting our auth to AUTH_OPEN.
+ /*
+* IW_AUTH_ALG_OPEN_SYSTEM is ambiguous here for WEP as
+* wpa_supplicant uses it for both no encryption and
+* WEP open system. So we return -EOPNOTSUPP and
+* wpa_supplicant will use SIOCSIWENCODE instead.
*/
- if (param->value & IW_AUTH_ALG_SHARED_KEY) {
+ if (param->value & IW_AUTH_ALG_OPEN_SYSTEM)
+ return -EOPNOTSUPP;
+ if (param->value & IW_AUTH_ALG_SHARED_KEY)
local->config.authType = AUTH_SHAREDKEY;
- } else if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
- local->config.authType = AUTH_ENCRYPT;
- } else
+ else
return -EINVAL;
/* Commit the changes to flags if needed */
--
Ondrej Zary
--
To unsubscribe from this list: send the line "uns
Re: [PATCH net] sctp: support global vtag assochash and per endpoint s(d)port assochash table
From: Xin Long
Date: Tue, 1 Sep 2015 01:44:28 +0800
> @@ -524,18 +524,16 @@ static inline int sctp_assoc_hashfn(struct net *net,
> __u16 lport, __u16 rport)
> {
> int h = (lport << 16) + rport + net_hash_mix(net);
> h ^= h>>8;
> - return h & (sctp_assoc_hashsize - 1);
> + return h & (256 - 1);
It is not acceptable to use a magic constant for the hash table size.
You need to define this using a macro and use it consistently.
Furthermore, you should be looking into dynamically sized
hash tables because not everyone will need this many entries.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: qmi_wwan: Sierra Wireless MC73xx -> Sierra Wireless MC7304/MC7354
From: David Ward Date: Mon, 31 Aug 2015 14:15:14 -0400 > Other Sierra Wireless MC73xx devices exist, with different USB IDs. > > Cc: Bjørn Mork > Signed-off-by: David Ward Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] gro_cells: remove spinlock protecting receive queues
From: Eric Dumazet Date: Mon, 31 Aug 2015 13:57:34 -0700 > From: Eric Dumazet > > As David pointed out, spinlock are no longer needed > to protect the per cpu queues used in gro cells infrastructure. > > Also use new napi_complete_done() API so that gro_flush_timeout > tweaks have an effect. > > Signed-off-by: Eric Dumazet Applied, thanks Eric. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/bonding: send arp in interval if no active slave
On 2015-08-17 4:51 PM, Uwe Koziolek wrote: On Mon, Aug 17, 2015 at 09:14PM +0200, Jay Vosburgh wrote: Uwe Koziolek wrote: On2015-08-17 07:12 PM,Jarod Wilson wrote: ... Uwe, can you perhaps further enlighten us as to what num_grat_arp settings were tried that didn't help? I'm still of the mind that if num_grat_arp *didn't* help, we probably need to do something keyed off num_grat_arp. The bonding slaves are connected to high available switches, each of the slaves is connected to a different switch. If the bond is starting, only the selected slave sends one arp-request. If a matching arp_response was received, this slave and the bond is going into state up, sending the gratitious arps... But if you got no arp reply the next slave was selected. With most of the newer switches, not overloaded, or with other software bugs, or with a single switch configuration, you would get a arp response on the first arp request. But in case of high availability configuration with non perfect switches like HP ProCurve 54xx, also with some Cisco models, you may not get a response on the first arp request. I have seen network snoops, there the switches are not responding to the first arp request on slave 1, the second arp request was sent on slave 2 but the response was received on slave one, and all following arp requests are anwsered on the wrong slave for a longer time. Could you elaborate on the exact "high availability configuration" here, including the model(s) of switch(es) involved? Is this some kind of race between the switch or switches updating the forwarding tables and the bond flip flopping between the slaves? E.g., source MAC from ARP sent on slave 1 is used to populate the forwarding table, but (for whatever reason) there is no reply. ARP on slave 2 is sent (using the same source MAC, unless you set fail_over_mac), but forwarding tables still send that MAC to slave 1, so reply is sent there. High availability: 2 managed switches with routing capabilities have an interconnect. One slave of a bonding interface is connected to the first switch, the second slave is connected to the other switch. The switch models are HP ProCurve 5406 and HP ProCurve 5412. As far as i remember also HP E 3500 and E 3800 are also affected, for the affected Cisco models I can't answer today. Affected single switch configurations was not seen. Yes, race conditions with delayed upgrades of the forwarding tables is a well matching explanation for the problem. The proposed change sents up to 3 arp requests on a down bond using the same slave, delayed by arp_interval. Using problematic switches i have seen the the arp response on the right slave at latest on the second arp request. So the bond is going into state up. How does it works: The bonds in up state are handled on the beginning of bond_ab_arp_probe procedure, the other part of this procedure is handling the slave change. The proposed change is bypassing the slave change for 2 additional calls of bond_ab_arp_probe. Now the retries are not only for an up bond available, they are also implemented for a down bond. Does this delay failover or bringup on switches that are not "problematic"? I.e., if arp_interval is, say, 1000 (1 second), will this impact failover / recovery times? -J It depends. failover times are not impacted, this is handled different. Only the transition from a down bonding interface (bond and all slaves are down) to the state up can be increased by up to 2 times arp_interval, If the selected interface did not came up .If well working switches are used, and everything other is also ok, there are no impacts. Jay, any further thoughts on this given Uwe's reply? Uwe, did you have a chance to get affected Cisco model numbers too? -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] skbuff: Fix skb checksum flag on skb pull
VXLAN device can receive skb with checksum partial. But the checksum
offset could be in outer header which is pulled on receive. Such skb
can cause the panic when checksum is calculated on skb. Following patch
fixes the bug by setting checksum unnecessary while pulling outer header.
---8<---
[ 13.800141] RIP: 0010:[] []
skb_checksum_help+0x144/0x150
[ 13.800141] RSP: :88011fd83940 EFLAGS: 00010292
[ 13.800141] RAX: 0042 RBX: 880114dd56c0 RCX: 8801188d9580
...
...
[ 13.852308] Call Trace:
[ 13.852308]
[ 13.852308] [] queue_userspace_packet+0x408/0x470
[openvswitch]
[ 13.852308] [] ovs_dp_upcall+0x5d/0x60 [openvswitch]
[ 13.852308] [] ovs_dp_process_packet_with_key+0xe6/0x100
[openvswitch]
[ 13.852308] [] ovs_dp_process_received_packet+0x4b/0x80
[openvswitch]
[ 13.852308] [] ovs_vport_receive+0x2a/0x30 [openvswitch]
[ 13.852308] [] vxlan_rcv+0x53/0x60 [openvswitch]
[ 13.852308] [] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
[ 13.852308] [] udp_queue_rcv_skb+0x2dc/0x3b0
[ 13.852308] [] __udp4_lib_rcv+0x1cf/0x6c0
[ 13.852308] [] udp_rcv+0x1a/0x20
[ 13.852308] [] ip_local_deliver_finish+0xdd/0x280
[ 13.852308] [] ip_local_deliver+0x88/0x90
[ 13.852308] [] ip_rcv_finish+0x10d/0x370
[ 13.852308] [] ip_rcv+0x235/0x300
[ 13.852308] [] __netif_receive_skb+0x55d/0x620
[ 13.852308] [] netif_receive_skb+0x80/0x90
[ 13.852308] [] virtnet_poll+0x555/0x6f0
[ 13.852308] [] net_rx_action+0x134/0x290
[ 13.852308] [] __do_softirq+0xa8/0x210
[ 13.852308] [] call_softirq+0x1c/0x30
[ 13.852308] [] do_softirq+0x65/0xa0
[ 13.852308] [] irq_exit+0x8e/0xb0
[ 13.852308] [] do_IRQ+0x63/0xe0
[ 13.852308] [] common_interrupt+0x6e/0x6e
[ 13.852308]
[ 13.852308] [] ? system_call_fastpath+0x16/0x1b
Reported-by: Anupam Chanda
Signed-off-by: Pravin B Shelar
---
include/linux/skbuff.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 9b88536..6238e9f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2601,6 +2601,9 @@ static inline void skb_postpull_rcsum(struct sk_buff *skb,
{
if (skb->ip_summed == CHECKSUM_COMPLETE)
skb->csum = csum_sub(skb->csum, csum_partial(start, len, 0));
+ else if (skb->ip_summed == CHECKSUM_PARTIAL &&
+skb_checksum_start_offset(skb) <= len)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
}
unsigned char *skb_pull_rcsum(struct sk_buff *skb, unsigned int len);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vethpair creation performance, 3.14 versus 4.2.0
On Mon, 2015-08-31 at 12:48 -0700, Rick Jones wrote: > On 08/29/2015 10:59 PM, Raghavendra K T wrote: > > Please note that similar overhead was also reported while creating > > veth pairs https://lkml.org/lkml/2013/3/19/556 > > > That got me curious, so I took the veth pair creation script from there, > and started running it out to 10K pairs, comparing a 3.14.44 kernel with > a 4.2.0-rc4+ from net-next and then net-next after pulling to get the > snmp stat aggregation perf change (4.2.0-rc8+). > > Indeed, the 4.2.0-rc8+ kernel with the change was faster than the > 4.2.0-rc4+ kernel without it, but both were slower than the 3.14.44 kernel. > > I've put a spreadsheet with the results at: > > ftp://ftp.netperf.org/vethpair/vethpair_compare.ods > > A perf top for the 4.20-rc8+ kernel from the net-next tree looks like > this out around 10K pairs: > > PerfTop: 11155 irqs/sec kernel:94.2% exact: 0.0% [4000Hz > cycles], (all, 32 CPUs) > --- > > 23.44% [kernel] [k] vsscanf > 7.32% [kernel] [k] mutex_spin_on_owner.isra.4 > 5.63% [kernel] [k] __memcpy > 5.27% [kernel] [k] __dev_alloc_name > 3.46% [kernel] [k] format_decode > 3.44% [kernel] [k] vsnprintf > 3.16% [kernel] [k] acpi_os_write_port > 2.71% [kernel] [k] number.isra.13 > 1.50% [kernel] [k] strncmp > 1.21% [kernel] [k] _parse_integer > 0.93% [kernel] [k] filemap_map_pages > 0.82% [kernel] [k] put_dec_trunc8 > 0.82% [kernel] [k] unmap_single_vma > 0.78% [kernel] [k] native_queued_spin_lock_slowpath > 0.71% [kernel] [k] menu_select > 0.65% [kernel] [k] clear_page > 0.64% [kernel] [k] _raw_spin_lock > 0.62% [kernel] [k] page_fault > 0.60% [kernel] [k] find_busiest_group > 0.53% [kernel] [k] snprintf > 0.52% [kernel] [k] int_sqrt > 0.46% [kernel] [k] simple_strtoull > 0.44% [kernel] [k] page_remove_rmap > > My attempts to get a call-graph have been met with very limited success. > Even though I've installed the dbg package from "make deb-pkg" the > symbol resolution doesn't seem to be working. Well, you do not need call graph to spot the well known issue with __dev_alloc_name() which has O(N) behavior If we really need to be fast here, and keep eth%d or veth%d names with guarantee of lowest numbers, we would need an IDR -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ss format bug
On Wed, 26 Aug 2015 11:59:17 -0400
Mike Saal wrote:
> Hi:
>
> I found a formatting bug in the 4.1.1 ss command. The following line was
> incorrectly output due to passing a negative length to printf() when
> displaying the local address. In this instance hostapd does a "bind to
> device" on cdreth0 and then does a udp "in address any" port 67 bind.
> Please note the whitespace between the '*' and ' %cdreth0:67'
>
> 'udp UNCONN 0 0 ** %cdreth0:67* *:* users:(("hostapd",pid=19241,fd=5))'
>
> Attached is my patch for the bug fix, it might be prudent to add more
> guard code looking for negative length format codes.
>
> Sincerely, Mike
I think the root cause of this is actually down in the main program
where it is computing addr_width. It is not accounting for the size correctly,
or maybe your case just occurs if screen is too narrow to fit the full width.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH iproute2 v3] add support for brief output for link and addresses
On Fri, 28 Aug 2015 17:45:41 + Andy Gospodarek wrote: > This adds support for slightly less output than is normally provided by > 'ip link show' and 'ip addr show'. This is a bit better when you have a > host with lots of interfaces. Sample output: > > $ ip -br link show > lo UNKNOWN00:00:00:00:00:00 > p2p1 UP 08:00:27:ee:0b:3b > > p7p1 UP 08:00:27:9d:62:9f > > p8p1 DOWN 08:00:27:dc:d8:ca > > p9p1 UP 08:00:27:76:d9:75 > > p7p1.100@p7p1UP 08:00:27:9d:62:9f > > > $ ip -br -4 addr show > lo UNKNOWN127.0.0.1/8 > p2p1 UP 192.168.56.2/24 > p7p1 UP 70.0.0.1/24 > p8p1 DOWN 80.0.0.1/24 > p9p1 UP 10.0.5.15/24 > p7p1.100@p7p1UP 200.0.0.1/24 > > $ ip -br -6 addr show > lo UNKNOWN::1/128 > p2p1 UP fe80::a00:27ff:feee:b3b/64 > p7p1 UP 7000::1/8 fe80::a00:27ff:fe9d:629f/64 > p8p1 DOWN 8000::1/8 > p9p1 UP fe80::a00:27ff:fe76:d975/64 > p7p1.100@p7p1UP fe80::a00:27ff:fe9d:629f/64 > > $ ip -br addr show p7p1 > p7p1 UP 70.0.0.1/24 7000::1/8 > fe80::a00:27ff:fe9d:629f/64 > > v2: Now with color support! > v3: Better field width estimation (except netdev names to keep output at a > decent width) and whitespace fixup. > > Signed-off-by: Andy Gospodarek Applied, thanks -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH iproute2 v3] add 'vti'/'vti6' tunnel modes to ip-tunnel manual page
On Sat, 29 Aug 2015 18:36:32 + Konstantin Shemyak wrote: > * "vti" and "vti6" tunnel modes added to ip-tunnel.8 manual page > * Added "hoplimit" terminology for IPv6 > * Corrected usage line > * Minor language fix > --- > man/man8/ip-tunnel.8 | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) Applied, thanks -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH iproute2] iplink: Add support for IFLA_BR_VLAN_PROTOCOL attribute
On Mon, 31 Aug 2015 18:48:46 +0900 Toshiaki Makita wrote: > This patch adds support for bridge vlan_protocol. > > Example: > $ ip link set br0 type bridge vlan_protocol 802.1ad > $ ip -d link show br0 > 4: br0: mtu 1500 qdisc noqueue state > UP mode DEFAULT group default qlen 1000 > link/ether 44:37:e6:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity 0 > bridge forward_delay 0 hello_time 200 max_age 2000 ageing_time 3 > stp_state 0 priority 32768 vlan_filtering 0 vlan_protocol 802.1ad > addrgenmode eui64 > > Signed-off-by: Toshiaki Makita Applied to net-next branch -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] iproute2 4.2.0
Regular release of iproute2 for Linux 4.2
Update to iproute2 utility to support new features in Linux 4.2.
Lots of work went into extending ss and bpf. Also some nicer
formatting in ip commands with brief mode.
Source:
http://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-4.2.0.tar.gz
Repository:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
Report problems (or enhancements) to the netdev@vger.kernel.org mailing list.
---
Andy Gospodarek (2):
iproute2: add support to print 'linkdown' nexthop flag
add support for brief output for link and addresses
Antti Paila (1):
ip: Preserve original portocol family in batch mode
Craig Gallek (2):
ss: add support for segs_in and segs_out
ss: Include -E option for socket destroy events
Daniel Borkmann (2):
tc: {f,m}_bpf: add tail call support for parser
tc: {f,m}_bpf: allow to retrieve uds path from env
David Ward (1):
tc: gred: Add support for TCA_GRED_LIMIT attribute
Eran Ben Elisha (1):
Add displaying VF traffic statistics
Eric Dumazet (2):
ss: add support for bytes_acked & bytes_received
codel: add ce_threshold support to codel & fc_codel
Felix Janda (1):
Replace BSD MAXPATHLEN by POSIX PATH_MAX
Gustavo Zacarias (1):
tipc: make build conditional on having libmnl
Jan Engelhardt (1):
build: must honor pkg-config flags for libmnl
Jiri Pirko (2):
tc: add support for Flower classifier
iproute2: ipa: show switch id
John W. Linville (4):
iproute2: GENEVE support
iproute2: update ip-link.8 for geneve tunnels
iplink_geneve: add ttl configuration at link creation
iplink_geneve: add tos configuration at link creation
Jonathan Toppins (1):
iplink_bond: add support for ad_actor and port_key options
Konstantin Shemyak (1):
add 'vti'/'vti6' tunnel modes to ip-tunnel manual page
Michal Kubeček (1):
include: add copy of tipc.h
Nicolas Dichtel (6):
man: update ip monitor page
libnetlink: introduce rtnl_listen_filter_t
ipmonitor: introduce print_headers
ipmonitor: allows to monitor in several netns
xfrmmonitor: allows to monitor in several netns
tc: fix bpf compilation with old glibc
Nikolay Aleksandrov (7):
bonding: export 3ad actor and partner port state
iplink_bridge: add support for ageing_time
iplink_bridge: add support for stp_state
iplink_bridge: add support for priority
ss: fix display of raw sockets
bridge: mdb: add support for router add/del notifications monitoring
iplink: add ageing_time, stp_state and priority for bridge
Pavel Šimerda (3):
ip: fix and extend documentation
ip-link: fix and extend documentation
ip-address: fix and extend documentation
Phil Sutter (10):
ss: print value of IPV6_V6ONLY socket option if set
misc/ss: don't imply -a when -A was specified
ip-link: fix minor typo in manpage
misc/ss: avoid NULL pointer dereference
misc/ss: simplify buffer realloc, fix checking realloc failure
misc/ss: add missing fclose() calls
lib/namespace: don't leak fd in error case
misc/ss: fix memory leak in user_ent_hash_build()
lib/namespace: fix fd leakage in non-error case
ip-address.8.in: fix BNF syntax error
Richard Alpe (1):
tipc: fix bearer get/set help synopsis
Roopa Prabhu (3):
mpls: always set type RTN_UNICAST and scope RT_SCOPE_UNIVERSE for
support batching of ip route get commands
bridge fdb: add 'use' option to set NTF_USE flag in fdb add requests
Stephen Hemminger (19):
update kernel kernel headers from 3.19-rc
update to lateset net-next headers
update headers to 4.1-rc1 net-next
Update kernels for net-next
pkt_cls: update header
configure: cleanup
update to 4.2-pre-rc headers
headers update
update kernel headers for 4.2-rc1
remove unnecessary checks for NULL before free
ip: fix all the checkpatch warnings
bridge: drop man page fragment
ipnetns: make net namespace cache variable size
remove unnecessary extern
tc: fix return after invarg
bond: fix return after invarg
provide common json output formatter
iplink: cleanup whitespace and checkpatch issues
v4.2.0
Vadim Kochan (4):
ss: fix crash when dump stats from /proc with '-p'
man ss: Fix explanation when no options specified
man ip-link: Add more explanation about vlan reordering
man ip-link: Add little explanations about VLAN qos map
Zhang Shengju (10):
xfrm: remove duplicated include
ip/ip6tunnel: fix missing return value check
iplink: add missing link type
iplink: use the short format to print help info
iplink: shortify printing the usage of link type
ip-link: fix a typo in help message
ip-link: enhance prompt message
ip-link: remove unnecessary return
Re: [PATCH] ipv6: send NEWLINK on RA managed/otherconf changes
Am 01.09.2015 um 00:13 schrieb David Miller:
> From: Marius Tomaschewski
> Date: Mon, 31 Aug 2015 15:59:22 +0200
>
>> The kernel is applying the RA managed/otherconf flags silently and
>> forgets to send ifinfo notify to inform about their change when the
>> router provides a zero reachable_time and retrans_timer as dnsmasq
>> and many routers send it, which just means unspecified by this router
>> and the host should continue using whatever value it is already using.
>> Userspace may monitor the ifinfo notifications to activate dhcpv6.
>>
>> Signed-off-by: Marius Tomaschewski
>
> Applied, but more ideally this function should emit only a single
> NEWLINK message rather than potentially 3.
Yes, you're right of course.
I've attached a follow-up patch doing this. Please let me know if you
need it in a separate mail.
Gruesse / Regards,
Marius Tomaschewski ,
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg),
Maxfeldstraße 5, 90409 Nürnberg, Germany
>From b6b55b5383c9b89cfd5ad9b4584c044c6c8d3722 Mon Sep 17 00:00:00 2001
From: Marius Tomaschewski
Date: Tue, 1 Sep 2015 01:40:57 +0200
Subject: [PATCH] ipv6: send only one NEWLINK when RA causes changes
Signed-off-by: Marius Tomaschewski
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 99ea9dd..7baca60 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1075,6 +1075,7 @@ static void ndisc_router_discovery(struct sk_buff *skb)
int optlen;
unsigned int pref = 0;
__u32 old_if_flags;
+ int send_ifinfo_notify = 0;
__u8 *opt = (__u8 *)(ra_msg + 1);
@@ -1154,7 +1155,7 @@ static void ndisc_router_discovery(struct sk_buff *skb)
IF_RA_OTHERCONF : 0);
if (old_if_flags != in6_dev->if_flags)
- inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
+ send_ifinfo_notify = 1;
if (!in6_dev->cnf.accept_ra_defrtr) {
ND_PRINTK(2, info,
@@ -1259,7 +1260,7 @@ skip_defrtr:
rtime = HZ/10;
NEIGH_VAR_SET(in6_dev->nd_parms, RETRANS_TIME, rtime);
in6_dev->tstamp = jiffies;
- inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
+ send_ifinfo_notify = 1;
}
rtime = ntohl(ra_msg->reachable_time);
@@ -1276,11 +1277,17 @@ skip_defrtr:
GC_STALETIME, 3 * rtime);
in6_dev->nd_parms->reachable_time = neigh_rand_reach_time(rtime);
in6_dev->tstamp = jiffies;
-inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
+send_ifinfo_notify = 1;
}
}
}
+ /*
+ * Send a notify if RA changed managed/otherconf flags or timer settings
+ */
+ if (send_ifinfo_notify)
+ inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
+
skip_linkparms:
/*
--
2.1.4
Re: [PATCH net] skbuff: Fix skb checksum flag on skb pull
On Mon, Aug 31, 2015 at 3:55 PM, Pravin B Shelar wrote:
> VXLAN device can receive skb with checksum partial. But the checksum
> offset could be in outer header which is pulled on receive. Such skb
> can cause the panic when checksum is calculated on skb. Following patch
> fixes the bug by setting checksum unnecessary while pulling outer header.
>
> ---8<---
> [ 13.800141] RIP: 0010:[] []
> skb_checksum_help+0x144/0x150
> [ 13.800141] RSP: :88011fd83940 EFLAGS: 00010292
> [ 13.800141] RAX: 0042 RBX: 880114dd56c0 RCX: 8801188d9580
> ...
> ...
> [ 13.852308] Call Trace:
> [ 13.852308]
> [ 13.852308] [] queue_userspace_packet+0x408/0x470
> [openvswitch]
> [ 13.852308] [] ovs_dp_upcall+0x5d/0x60 [openvswitch]
> [ 13.852308] [] ovs_dp_process_packet_with_key+0xe6/0x100
> [openvswitch]
> [ 13.852308] [] ovs_dp_process_received_packet+0x4b/0x80
> [openvswitch]
> [ 13.852308] [] ovs_vport_receive+0x2a/0x30 [openvswitch]
> [ 13.852308] [] vxlan_rcv+0x53/0x60 [openvswitch]
> [ 13.852308] [] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
> [ 13.852308] [] udp_queue_rcv_skb+0x2dc/0x3b0
> [ 13.852308] [] __udp4_lib_rcv+0x1cf/0x6c0
> [ 13.852308] [] udp_rcv+0x1a/0x20
> [ 13.852308] [] ip_local_deliver_finish+0xdd/0x280
> [ 13.852308] [] ip_local_deliver+0x88/0x90
> [ 13.852308] [] ip_rcv_finish+0x10d/0x370
> [ 13.852308] [] ip_rcv+0x235/0x300
> [ 13.852308] [] __netif_receive_skb+0x55d/0x620
> [ 13.852308] [] netif_receive_skb+0x80/0x90
> [ 13.852308] [] virtnet_poll+0x555/0x6f0
> [ 13.852308] [] net_rx_action+0x134/0x290
> [ 13.852308] [] __do_softirq+0xa8/0x210
> [ 13.852308] [] call_softirq+0x1c/0x30
> [ 13.852308] [] do_softirq+0x65/0xa0
> [ 13.852308] [] irq_exit+0x8e/0xb0
> [ 13.852308] [] do_IRQ+0x63/0xe0
> [ 13.852308] [] common_interrupt+0x6e/0x6e
> [ 13.852308]
> [ 13.852308] [] ? system_call_fastpath+0x16/0x1b
>
> Reported-by: Anupam Chanda
> Signed-off-by: Pravin B Shelar
> ---
> include/linux/skbuff.h |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 9b88536..6238e9f 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -2601,6 +2601,9 @@ static inline void skb_postpull_rcsum(struct sk_buff
> *skb,
> {
> if (skb->ip_summed == CHECKSUM_COMPLETE)
> skb->csum = csum_sub(skb->csum, csum_partial(start, len, 0));
> + else if (skb->ip_summed == CHECKSUM_PARTIAL &&
> +skb_checksum_start_offset(skb) <= len)
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
No, this isn't right. We should never be converting CHECKSUM_PARTIAL
into CHECKSUM_UNNECESSARY.
> }
>
> unsigned char *skb_pull_rcsum(struct sk_buff *skb, unsigned int len);
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipv6: send NEWLINK on RA managed/otherconf changes
From: Marius Tomaschewski Date: Tue, 1 Sep 2015 01:43:39 +0200 > I've attached a follow-up patch doing this. Please let me know if you > need it in a separate mail. I want it in a separate mail, and please use "bool" for the type. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] sctp: support global vtag assochash and per endpoint s(d)port assochash table
On 08/31/2015 01:44 PM, Xin Long wrote:
> for telecom center, the usual case is that a server is connected by thousands
> of clients. but if the server with only one enpoint(udp style) use the same
> sport and dport to communicate with every clients, and every assoc in server
> will be hashed in the same chain of global assoc hashtable due to currently we
> choose dport and sport as the hash key.
>
> when a packet is received, sctp_rcv try to find the assoc with sport and
> dport,
> since that chain is too long to find it fast, it make the performance turn to
> very low, some test data is as follow:
>
> in server:
> $./ss [start a udp server there]
> in client:
> $./cc [start 2500 sockets to connect server with same port and different ip,
>and use one of them to send data to server]
>
> *spend time is 854s, send pkt is 1000*
>
> in server: #perf top
> 46.60% [kernel] [k] sctp_assoc_is_match
>8.81% [kernel] [k] sctp_v4_cmp_addr
>5.15% [kernel] [k] sctp_assoc_lookup_paddr
>...
>
> in client: #perf top
> 88.42% [kernel][k] __sctp_endpoint_lookup_assoc
>2.06% libnl-3.so.200.16.1 [.] nl_object_identical
>1.23% libnl-3.so.200.16.1 [.] nl_addr_cmp
>...
>
> we need to change the way to calculate the hash key, vtag is good value for
> that, insteading the sport and dport. this way can work well for looking for
> assoc in sctp_rcv.
> becides, for the clients, if we turn the dport and sport global hash to per
> endpoint's, which can make sctp_sendmsg look up assoc more quickly.
>
> after that, the data of the same test is:
>
> *spend time is 25s, send pkt is 1000*
>
> in server: #perf top
>9.92% libnl-3.so.200.16.1 [.] nl_object_identical
>6.05% libnl-3.so.200.16.1 [.] nl_addr_cmp
>4.72% libc-2.17.so[.] __memcmp_sse2
>...
>
> in client: #perf top
>6.79% libc-2.17.so[.] __libc_calloc
>6.50% [kernel][k] memcpy
>6.35% libc-2.17.so[.] _int_free
>...
>
> Signed-off-by: Xin Long
> ---
> include/net/sctp/sctp.h| 8 +--
> include/net/sctp/structs.h | 8 ++-
> net/sctp/endpointola.c | 22 +--
> net/sctp/input.c | 160
> +
> 4 files changed, 129 insertions(+), 69 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index ce13cf2..df14452 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -524,18 +524,16 @@ static inline int sctp_assoc_hashfn(struct net *net,
> __u16 lport, __u16 rport)
> {
> int h = (lport << 16) + rport + net_hash_mix(net);
> h ^= h>>8;
> - return h & (sctp_assoc_hashsize - 1);
> + return h & (256 - 1);
In addition to what David said and looking at it from a different angle... 256
buckets
may not be enough for someone with a single endpoint and alot of associations.
You
will still hit a long chain on INIT and COOKIE-ECHO chunks.
Switching to using rhashtable for association hash would be very nice.
Also, see if you can split this into 2 parts, one that does vtag hash and
the other is refactoring. It would make it much easier to review.
-vlad
> }
>
> /* This is the hash function for the association hash table. This is
> * not used yet, but could be used as a better hash function when
> * we have a vtag.
> */
> -static inline int sctp_vtag_hashfn(__u16 lport, __u16 rport, __u32 vtag)
> +static inline int sctp_vtag_hashfn(struct net *net, __u32 vtag)
> {
> - int h = (lport << 16) + rport;
> - h ^= vtag;
> - return h & (sctp_assoc_hashsize - 1);
> + return vtag & (sctp_assoc_hashsize - 1);
> }
>
> #define sctp_for_each_hentry(epb, head) \
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 495c87e..e0edfed 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -1150,6 +1150,9 @@ struct sctp_ep_common {
> struct hlist_node node;
> int hashent;
>
> + struct hlist_node node_ep;
> + int hashent_ep;
> +
> /* Runtime type information. What kind of endpoint is this? */
> sctp_endpoint_type_t type;
>
> @@ -1210,6 +1213,8 @@ struct sctp_endpoint {
> /* This is really a list of struct sctp_association entries. */
> struct list_head asocs;
>
> + struct sctp_hashbucket *asocshash;
> +
> /* Secret Key: A secret key used by this endpoint to compute
>*the MAC. This SHOULD be a cryptographic quality
>*random number with a sufficient length.
> @@ -1272,7 +1277,8 @@ int sctp_endpoint_is_peeled_off(struct sctp_endpoint *,
> const union sctp_addr *);
> struct sctp_endpoint *sctp_endpoint_is_match(struct sctp_endpoint *,
> struct net *, const uni
[PATCH] ipv6: send only one NEWLINK when RA causes changes
Signed-off-by: Marius Tomaschewski
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 99ea9dd..8456c75 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1075,6 +1075,7 @@ static void ndisc_router_discovery(struct sk_buff *skb)
int optlen;
unsigned int pref = 0;
__u32 old_if_flags;
+ bool send_ifinfo_notify = false;
__u8 *opt = (__u8 *)(ra_msg + 1);
@@ -1154,7 +1155,7 @@ static void ndisc_router_discovery(struct sk_buff *skb)
IF_RA_OTHERCONF : 0);
if (old_if_flags != in6_dev->if_flags)
- inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
+ send_ifinfo_notify = true;
if (!in6_dev->cnf.accept_ra_defrtr) {
ND_PRINTK(2, info,
@@ -1259,7 +1260,7 @@ skip_defrtr:
rtime = HZ/10;
NEIGH_VAR_SET(in6_dev->nd_parms, RETRANS_TIME, rtime);
in6_dev->tstamp = jiffies;
- inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
+ send_ifinfo_notify = true;
}
rtime = ntohl(ra_msg->reachable_time);
@@ -1276,11 +1277,17 @@ skip_defrtr:
GC_STALETIME, 3 * rtime);
in6_dev->nd_parms->reachable_time =
neigh_rand_reach_time(rtime);
in6_dev->tstamp = jiffies;
- inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
+ send_ifinfo_notify = true;
}
}
}
+ /*
+* Send a notify if RA changed managed/otherconf flags or timer
settings
+*/
+ if (send_ifinfo_notify)
+ inet6_ifinfo_notify(RTM_NEWLINK, in6_dev);
+
skip_linkparms:
/*
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] airo: fix IW_AUTH_ALG_OPEN_SYSTEM
On Tue, 2015-09-01 at 00:12 +0200, Ondrej Zary wrote:
>
> On Monday 31 August 2015 22:44:54 Dan Williams wrote:
> > On Mon, 2015-08-31 at 21:19 +0200, Ondrej Zary wrote:
> > > Handle IW_AUTH_ALG_OPEN_SYSTEM in set_auth.
> > > This allows wpa_supplicant (and thus NetworkManager) to work with open
> > > APs.
> > >
> > > Signed-off-by: Ondrej Zary
> > > ---
> > > drivers/net/wireless/airo.c |7 +++
> > > 1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
> > > index d0c97c2..2066a1f 100644
> > > --- a/drivers/net/wireless/airo.c
> > > +++ b/drivers/net/wireless/airo.c
> > > @@ -6670,10 +6670,9 @@ static int airo_set_auth(struct net_device *dev,
> > > break;
> > >
> > > case IW_AUTH_80211_AUTH_ALG: {
> > > - /* FIXME: What about AUTH_OPEN? This API seems to
> > > - * disallow setting our auth to AUTH_OPEN.
> > > - */
> > > - if (param->value & IW_AUTH_ALG_SHARED_KEY) {
> > > + if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
> > > + local->config.authType = AUTH_OPEN;
> > > + } else if (param->value & IW_AUTH_ALG_SHARED_KEY) {
> > > local->config.authType = AUTH_SHAREDKEY;
> > > } else if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
> > > local->config.authType = AUTH_ENCRYPT;
> >
> > NAK; there are two problems with this patch. First, there's already an
> > if test for OPEN_SYSTEM which sets authType to AUTH_ENCRYPT. Second,
> > AUTH_OPEN means to disable encryption entirely. The decision being made
> > here is whether to use Shared Key or Open authentication, not whether
> > encryption is being used or not. Thus this patch would appear to break
> > most WEP APs?
> >
> > Airo really wants to know the auth type *and* whether encryption will
> > actually be used at the same time, and we don't have that information
> > here. I guess the only thing you can do here is call get_wep_key() for
> > all the indexes and see if any keys are set, and if any keys are set,
> > use AUTH_ENCRYPT. If get_wep_key() returns -1 for all 4 indexes, use
> > AUTH_OPEN. But you have to make sure that this all gets protected by
> > local->wep_capable and that you're not checking indexes above
> > ai->max_wep_idx. Yay airo!
>
> Sorry, I got confused (and it worked with WEP with a test AP, although there's
> no open system/shared key setting in the firmware).
>
> Reading the wpa_supplicant code, it uses IW_AUTH_ALG_OPEN_SYSTEM for WEP open
> system and also as a default value - which gets used when encryption is
> disabled:
I think you're still confusing the relationship between Open System and
WEP in the code and comments here. 802.11 always uses an "auth method"
regardless of whether encryption is used or not. There are 3 possible
settings here:
AuthEncryption
--
OPENNONE
OPENWEP
SHARED WEP
The problem here is that:
1) the WEXT SIWAUTH call only sets authentication, but says nothing
about encryption
2) that airo is currently structured such that it wants both auth &
encryption specified at the same time. It tracks the states in the
table above with the authType variable, but at the point of SIWAUTH
there is no information about whether the requested mode is OPEN+NONE or
OPEN+WEP.
The patches might work for some cases, but they are ignoring others
where clients might send WEXT calls in different order. WEXT doesn't
specify any kind of ordering, which is one reason it's been deprecated
and replaced with nl80211. So in your case, the supplicant does [IWAUTH
+ IWENCODE] but that's just how the supplicant decided to implement it.
If some other client does a perfectly legal [IWENCODE + IWAUTH] then
your original patch will turn off WEP, when the client wanted OPEN +
WEP.
> static int wpa_driver_wext_set_auth_alg(void *priv, int auth_alg)
> {
> struct wpa_driver_wext_data *drv = priv;
> int algs = 0, res;
>
> if (auth_alg & WPA_AUTH_ALG_OPEN)
> algs |= IW_AUTH_ALG_OPEN_SYSTEM;
> if (auth_alg & WPA_AUTH_ALG_SHARED)
> algs |= IW_AUTH_ALG_SHARED_KEY;
> if (auth_alg & WPA_AUTH_ALG_LEAP)
> algs |= IW_AUTH_ALG_LEAP;
> if (algs == 0) {
> /* at least one algorithm should be set */
> algs = IW_AUTH_ALG_OPEN_SYSTEM;
> }
>
> res = wpa_driver_wext_set_auth_param(drv, IW_AUTH_80211_AUTH_ALG,
> algs);
> drv->auth_alg_fallback = res == -2;
> return res;
> }
>
>
> However, when SIOCSIWAUTH fails with EOPNOTSUPP, it tries SIOCSIWENCODE. This
> patch seems to work too with my AP:
>
> diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
> index d0c97c2..2610fe3 100644
> --- a/drivers/net/wireless/airo.
Re: [PATCH net] skbuff: Fix skb checksum flag on skb pull
On Mon, Aug 31, 2015 at 03:55:46PM -0700, Pravin B Shelar wrote: > VXLAN device can receive skb with checksum partial. But the checksum > offset could be in outer header which is pulled on receive. Such skb > can cause the panic when checksum is calculated on skb. Following patch > fixes the bug by setting checksum unnecessary while pulling outer header. > > ---8<--- > [ 13.800141] RIP: 0010:[] [] > skb_checksum_help+0x144/0x150 > [ 13.800141] RSP: :88011fd83940 EFLAGS: 00010292 > [ 13.800141] RAX: 0042 RBX: 880114dd56c0 RCX: 8801188d9580 > ... > ... > [ 13.852308] Call Trace: > [ 13.852308] > [ 13.852308] [] queue_userspace_packet+0x408/0x470 > [openvswitch] > [ 13.852308] [] ovs_dp_upcall+0x5d/0x60 [openvswitch] > [ 13.852308] [] ovs_dp_process_packet_with_key+0xe6/0x100 > [openvswitch] > [ 13.852308] [] ovs_dp_process_received_packet+0x4b/0x80 > [openvswitch] that doesn't look like upstream kernel. The above two functions don't exist in net-next. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] tun_dst: Remove opts_size
opts_size is only written and never read. Following patch
removes this unused variable.
Signed-off-by: Pravin B Shelar
---
include/net/dst_metadata.h |1 -
net/core/dst.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/net/dst_metadata.h b/include/net/dst_metadata.h
index 547ab82..af9d538 100644
--- a/include/net/dst_metadata.h
+++ b/include/net/dst_metadata.h
@@ -7,7 +7,6 @@
struct metadata_dst {
struct dst_entrydst;
- size_t opts_len;
union {
struct ip_tunnel_info tun_info;
} u;
diff --git a/net/core/dst.c b/net/core/dst.c
index 477035e..0771c8c 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -378,7 +378,6 @@ static void __metadata_dst_init(struct metadata_dst
*md_dst, u8 optslen)
dst->output = dst_md_discard_sk;
memset(dst + 1, 0, sizeof(*md_dst) + optslen - sizeof(*dst));
- md_dst->opts_len = optslen;
}
struct metadata_dst *metadata_dst_alloc(u8 optslen, gfp_t flags)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] skbuff: Fix skb checksum flag on skb pull
On Mon, Aug 31, 2015 at 4:44 PM, Tom Herbert wrote:
> On Mon, Aug 31, 2015 at 3:55 PM, Pravin B Shelar wrote:
>> VXLAN device can receive skb with checksum partial. But the checksum
>> offset could be in outer header which is pulled on receive. Such skb
>> can cause the panic when checksum is calculated on skb. Following patch
>> fixes the bug by setting checksum unnecessary while pulling outer header.
>>
>> ---8<---
>> [ 13.800141] RIP: 0010:[] []
>> skb_checksum_help+0x144/0x150
>> [ 13.800141] RSP: :88011fd83940 EFLAGS: 00010292
>> [ 13.800141] RAX: 0042 RBX: 880114dd56c0 RCX:
>> 8801188d9580
>> ...
>> ...
>> [ 13.852308] Call Trace:
>> [ 13.852308]
>> [ 13.852308] [] queue_userspace_packet+0x408/0x470
>> [openvswitch]
>> [ 13.852308] [] ovs_dp_upcall+0x5d/0x60 [openvswitch]
>> [ 13.852308] [] ovs_dp_process_packet_with_key+0xe6/0x100
>> [openvswitch]
>> [ 13.852308] [] ovs_dp_process_received_packet+0x4b/0x80
>> [openvswitch]
>> [ 13.852308] [] ovs_vport_receive+0x2a/0x30 [openvswitch]
>> [ 13.852308] [] vxlan_rcv+0x53/0x60 [openvswitch]
>> [ 13.852308] [] vxlan_udp_encap_recv+0x8b/0xf0
>> [openvswitch]
>> [ 13.852308] [] udp_queue_rcv_skb+0x2dc/0x3b0
>> [ 13.852308] [] __udp4_lib_rcv+0x1cf/0x6c0
>> [ 13.852308] [] udp_rcv+0x1a/0x20
>> [ 13.852308] [] ip_local_deliver_finish+0xdd/0x280
>> [ 13.852308] [] ip_local_deliver+0x88/0x90
>> [ 13.852308] [] ip_rcv_finish+0x10d/0x370
>> [ 13.852308] [] ip_rcv+0x235/0x300
>> [ 13.852308] [] __netif_receive_skb+0x55d/0x620
>> [ 13.852308] [] netif_receive_skb+0x80/0x90
>> [ 13.852308] [] virtnet_poll+0x555/0x6f0
>> [ 13.852308] [] net_rx_action+0x134/0x290
>> [ 13.852308] [] __do_softirq+0xa8/0x210
>> [ 13.852308] [] call_softirq+0x1c/0x30
>> [ 13.852308] [] do_softirq+0x65/0xa0
>> [ 13.852308] [] irq_exit+0x8e/0xb0
>> [ 13.852308] [] do_IRQ+0x63/0xe0
>> [ 13.852308] [] common_interrupt+0x6e/0x6e
>> [ 13.852308]
>> [ 13.852308] [] ? system_call_fastpath+0x16/0x1b
>>
>> Reported-by: Anupam Chanda
>> Signed-off-by: Pravin B Shelar
>> ---
>> include/linux/skbuff.h |3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 9b88536..6238e9f 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -2601,6 +2601,9 @@ static inline void skb_postpull_rcsum(struct sk_buff
>> *skb,
>> {
>> if (skb->ip_summed == CHECKSUM_COMPLETE)
>> skb->csum = csum_sub(skb->csum, csum_partial(start, len, 0));
>> + else if (skb->ip_summed == CHECKSUM_PARTIAL &&
>> +skb_checksum_start_offset(skb) <= len)
>> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> No, this isn't right. We should never be converting CHECKSUM_PARTIAL
> into CHECKSUM_UNNECESSARY.
>
But checksum is valid for inner packet. So I do not see any other
appropriate checksum flag here. Can you suggest another flag which is
better suited?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] skbuff: Fix skb checksum flag on skb pull
On Mon, Aug 31, 2015 at 6:40 PM, Alexei Starovoitov wrote: > On Mon, Aug 31, 2015 at 03:55:46PM -0700, Pravin B Shelar wrote: >> VXLAN device can receive skb with checksum partial. But the checksum >> offset could be in outer header which is pulled on receive. Such skb >> can cause the panic when checksum is calculated on skb. Following patch >> fixes the bug by setting checksum unnecessary while pulling outer header. >> >> ---8<--- >> [ 13.800141] RIP: 0010:[] [] >> skb_checksum_help+0x144/0x150 >> [ 13.800141] RSP: :88011fd83940 EFLAGS: 00010292 >> [ 13.800141] RAX: 0042 RBX: 880114dd56c0 RCX: >> 8801188d9580 >> ... >> ... >> [ 13.852308] Call Trace: >> [ 13.852308] >> [ 13.852308] [] queue_userspace_packet+0x408/0x470 >> [openvswitch] >> [ 13.852308] [] ovs_dp_upcall+0x5d/0x60 [openvswitch] >> [ 13.852308] [] ovs_dp_process_packet_with_key+0xe6/0x100 >> [openvswitch] >> [ 13.852308] [] ovs_dp_process_received_packet+0x4b/0x80 >> [openvswitch] > > that doesn't look like upstream kernel. > The above two functions don't exist in net-next. > Bug was reported on older kernel. But the issue exist on net-next kernel. For example when vxlan checksum is turned on. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] skbuff: Fix skb checksum flag on skb pull
On Mon, Aug 31, 2015 at 8:25 PM, Pravin Shelar wrote:
> On Mon, Aug 31, 2015 at 4:44 PM, Tom Herbert wrote:
>> On Mon, Aug 31, 2015 at 3:55 PM, Pravin B Shelar wrote:
>>> VXLAN device can receive skb with checksum partial. But the checksum
>>> offset could be in outer header which is pulled on receive. Such skb
>>> can cause the panic when checksum is calculated on skb. Following patch
>>> fixes the bug by setting checksum unnecessary while pulling outer header.
>>>
>>> ---8<---
>>> [ 13.800141] RIP: 0010:[] []
>>> skb_checksum_help+0x144/0x150
>>> [ 13.800141] RSP: :88011fd83940 EFLAGS: 00010292
>>> [ 13.800141] RAX: 0042 RBX: 880114dd56c0 RCX:
>>> 8801188d9580
>>> ...
>>> ...
>>> [ 13.852308] Call Trace:
>>> [ 13.852308]
>>> [ 13.852308] [] queue_userspace_packet+0x408/0x470
>>> [openvswitch]
>>> [ 13.852308] [] ovs_dp_upcall+0x5d/0x60 [openvswitch]
>>> [ 13.852308] [] ovs_dp_process_packet_with_key+0xe6/0x100
>>> [openvswitch]
>>> [ 13.852308] [] ovs_dp_process_received_packet+0x4b/0x80
>>> [openvswitch]
>>> [ 13.852308] [] ovs_vport_receive+0x2a/0x30 [openvswitch]
>>> [ 13.852308] [] vxlan_rcv+0x53/0x60 [openvswitch]
>>> [ 13.852308] [] vxlan_udp_encap_recv+0x8b/0xf0
>>> [openvswitch]
>>> [ 13.852308] [] udp_queue_rcv_skb+0x2dc/0x3b0
>>> [ 13.852308] [] __udp4_lib_rcv+0x1cf/0x6c0
>>> [ 13.852308] [] udp_rcv+0x1a/0x20
>>> [ 13.852308] [] ip_local_deliver_finish+0xdd/0x280
>>> [ 13.852308] [] ip_local_deliver+0x88/0x90
>>> [ 13.852308] [] ip_rcv_finish+0x10d/0x370
>>> [ 13.852308] [] ip_rcv+0x235/0x300
>>> [ 13.852308] [] __netif_receive_skb+0x55d/0x620
>>> [ 13.852308] [] netif_receive_skb+0x80/0x90
>>> [ 13.852308] [] virtnet_poll+0x555/0x6f0
>>> [ 13.852308] [] net_rx_action+0x134/0x290
>>> [ 13.852308] [] __do_softirq+0xa8/0x210
>>> [ 13.852308] [] call_softirq+0x1c/0x30
>>> [ 13.852308] [] do_softirq+0x65/0xa0
>>> [ 13.852308] [] irq_exit+0x8e/0xb0
>>> [ 13.852308] [] do_IRQ+0x63/0xe0
>>> [ 13.852308] [] common_interrupt+0x6e/0x6e
>>> [ 13.852308]
>>> [ 13.852308] [] ? system_call_fastpath+0x16/0x1b
>>>
>>> Reported-by: Anupam Chanda
>>> Signed-off-by: Pravin B Shelar
>>> ---
>>> include/linux/skbuff.h |3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>> index 9b88536..6238e9f 100644
>>> --- a/include/linux/skbuff.h
>>> +++ b/include/linux/skbuff.h
>>> @@ -2601,6 +2601,9 @@ static inline void skb_postpull_rcsum(struct sk_buff
>>> *skb,
>>> {
>>> if (skb->ip_summed == CHECKSUM_COMPLETE)
>>> skb->csum = csum_sub(skb->csum, csum_partial(start, len,
>>> 0));
>>> + else if (skb->ip_summed == CHECKSUM_PARTIAL &&
>>> +skb_checksum_start_offset(skb) <= len)
>>> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>>
>> No, this isn't right. We should never be converting CHECKSUM_PARTIAL
>> into CHECKSUM_UNNECESSARY.
>>
>
> But checksum is valid for inner packet. So I do not see any other
> appropriate checksum flag here. Can you suggest another flag which is
> better suited?
You don't need to do any conversion. skb_checksum_unnecessary checks
CHECKSUM_PARTIAL values. If the checksum offset being checked goes
past CHECKSUM_PARTIAL, then skb_checksum_unnecessary will fail and
checksum complete will be called to get CHECKSUM_COMPLETE. I'm not
sure why openvswitch is even calling skb_checksum_help in the first
place, the stack should be able to handle CHECKSUM_PARTIAL.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] skbuff: Fix skb checksum flag on skb pull
On Mon, Aug 31, 2015 at 3:55 PM, Pravin B Shelar wrote:
> VXLAN device can receive skb with checksum partial. But the checksum
> offset could be in outer header which is pulled on receive. Such skb
> can cause the panic when checksum is calculated on skb. Following patch
> fixes the bug by setting checksum unnecessary while pulling outer header.
>
Okay, I think I understand what you are doing. I suggest in the
openvswitch path, if there is a checksum CHECKSUM_PARTIAL that refers
to the outer headers which must have been verified at this point then
set to CHECKSUM_NONE-- assuming CHECKSUM_UNNECESSARY on the inner
header is not correct in this case. If the CHECKSUM_PARTIAL refers to
the inner header then you can call skb_checksum_help to resolve an
inner checksum.
> ---8<---
> [ 13.800141] RIP: 0010:[] [] +0x144/0x150
> [ 13.800141] RSP: :88011fd83940 EFLAGS: 00010292
> [ 13.800141] RAX: 0042 RBX: 880114dd56c0 RCX: 8801188d9580
> ...
> ...
> [ 13.852308] Call Trace:
> [ 13.852308]
> [ 13.852308] [] queue_userspace_packet+0x408/0x470
> [openvswitch]
> [ 13.852308] [] ovs_dp_upcall+0x5d/0x60 [openvswitch]
> [ 13.852308] [] ovs_dp_process_packet_with_key+0xe6/0x100
> [openvswitch]
> [ 13.852308] [] ovs_dp_process_received_packet+0x4b/0x80
> [openvswitch]
> [ 13.852308] [] ovs_vport_receive+0x2a/0x30 [openvswitch]
> [ 13.852308] [] vxlan_rcv+0x53/0x60 [openvswitch]
> [ 13.852308] [] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
> [ 13.852308] [] udp_queue_rcv_skb+0x2dc/0x3b0
> [ 13.852308] [] __udp4_lib_rcv+0x1cf/0x6c0
> [ 13.852308] [] udp_rcv+0x1a/0x20
> [ 13.852308] [] ip_local_deliver_finish+0xdd/0x280
> [ 13.852308] [] ip_local_deliver+0x88/0x90
> [ 13.852308] [] ip_rcv_finish+0x10d/0x370
> [ 13.852308] [] ip_rcv+0x235/0x300
> [ 13.852308] [] __netif_receive_skb+0x55d/0x620
> [ 13.852308] [] netif_receive_skb+0x80/0x90
> [ 13.852308] [] virtnet_poll+0x555/0x6f0
> [ 13.852308] [] net_rx_action+0x134/0x290
> [ 13.852308] [] __do_softirq+0xa8/0x210
> [ 13.852308] [] call_softirq+0x1c/0x30
> [ 13.852308] [] do_softirq+0x65/0xa0
> [ 13.852308] [] irq_exit+0x8e/0xb0
> [ 13.852308] [] do_IRQ+0x63/0xe0
> [ 13.852308] [] common_interrupt+0x6e/0x6e
> [ 13.852308]
> [ 13.852308] [] ? system_call_fastpath+0x16/0x1b
>
> Reported-by: Anupam Chanda
> Signed-off-by: Pravin B Shelar
> ---
> include/linux/skbuff.h |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 9b88536..6238e9f 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -2601,6 +2601,9 @@ static inline void skb_postpull_rcsum(struct sk_buff
> *skb,
> {
> if (skb->ip_summed == CHECKSUM_COMPLETE)
> skb->csum = csum_sub(skb->csum, csum_partial(start, len, 0));
> + else if (skb->ip_summed == CHECKSUM_PARTIAL &&
> +skb_checksum_start_offset(skb) <= len)
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
> }
>
> unsigned char *skb_pull_rcsum(struct sk_buff *skb, unsigned int len);
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipv6: send only one NEWLINK when RA causes changes
From: Marius Tomaschewski Date: Tue, 1 Sep 2015 01:57:30 +0200 > Signed-off-by: Marius Tomaschewski Applied, thanks. I wonder what to do about the situations right before the first assignment of send_ifinfo_notify to true where the dst_neigh_lookup() fails. Since we updated if_flags, we probably should still emit the notification. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] tun_dst: Remove opts_size
From: Pravin B Shelar Date: Mon, 31 Aug 2015 20:05:57 -0700 > opts_size is only written and never read. Following patch > removes this unused variable. > > Signed-off-by: Pravin B Shelar Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
