* Re: [PATCH net-next 2/2] net/sched: cls_flower: Support matching on ICMP type and code
From: Jiri Pirko @ 2016-12-02 18:38 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, netdev, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, Jamal Hadi Salim, Jiri Pirko
In-Reply-To: <1480701951-3686-3-git-send-email-simon.horman@netronome.com>
Fri, Dec 02, 2016 at 07:05:51PM CET, simon.horman@netronome.com wrote:
>Support matching on ICMP type and code.
>
>Example usage:
>
>tc qdisc add dev eth0 ingress
>
>tc filter add dev eth0 protocol ip parent ffff: flower \
> indev eth0 ip_proto icmp type 8 code 0 action drop
>
>tc filter add dev eth0 protocol ipv6 parent ffff: flower \
> indev eth0 ip_proto icmpv6 type 128 code 0 action drop
>
>Signed-off-by: Simon Horman <simon.horman@netronome.com>
>---
> include/net/flow_dissector.h | 24 ++++++++++++++++++++++--
> include/uapi/linux/pkt_cls.h | 10 ++++++++++
> net/sched/cls_flower.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 74 insertions(+), 2 deletions(-)
>
>diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
>index 8880025914e3..5540dfa18872 100644
>--- a/include/net/flow_dissector.h
>+++ b/include/net/flow_dissector.h
>@@ -199,10 +199,30 @@ struct flow_keys_digest {
> void make_flow_keys_digest(struct flow_keys_digest *digest,
> const struct flow_keys *flow);
>
>+static inline bool flow_protos_are_icmpv4(__be16 n_proto, u8 ip_proto)
>+{
>+ return n_proto == htons(ETH_P_IP) && ip_proto == IPPROTO_ICMP;
>+}
>+
>+static inline bool flow_protos_are_icmpv6(__be16 n_proto, u8 ip_proto)
>+{
>+ return n_proto == htons(ETH_P_IPV6) && ip_proto == IPPROTO_ICMPV6;
>+}
>+
> static inline bool flow_protos_are_icmp_any(__be16 n_proto, u8 ip_proto)
> {
>- return (n_proto == htons(ETH_P_IP) && ip_proto == IPPROTO_ICMP) ||
>- (n_proto == htons(ETH_P_IPV6) && ip_proto == IPPROTO_ICMPV6);
>+ return flow_protos_are_icmpv4(n_proto, ip_proto) ||
>+ flow_protos_are_icmpv6(n_proto, ip_proto);
>+}
>+
>+static inline bool flow_basic_key_is_icmpv4(const struct flow_dissector_key_basic *basic)
>+{
>+ return flow_protos_are_icmpv4(basic->n_proto, basic->ip_proto);
>+}
>+
>+static inline bool flow_basic_key_is_icmpv6(const struct flow_dissector_key_basic *basic)
>+{
>+ return flow_protos_are_icmpv6(basic->n_proto, basic->ip_proto);
> }
>
This hunk looks like it should be squashed to the previous patch.
> static inline bool flow_keys_are_icmp_any(const struct flow_keys *keys)
>diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
>index 86786d45ee66..58160fe80b80 100644
>--- a/include/uapi/linux/pkt_cls.h
>+++ b/include/uapi/linux/pkt_cls.h
>@@ -457,6 +457,16 @@ enum {
> TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK, /* be16 */
> TCA_FLOWER_KEY_ENC_UDP_DST_PORT, /* be16 */
> TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK, /* be16 */
>+
>+ TCA_FLOWER_KEY_ICMPV4_CODE, /* u8 */
>+ TCA_FLOWER_KEY_ICMPV4_CODE_MASK,/* u8 */
>+ TCA_FLOWER_KEY_ICMPV4_TYPE, /* u8 */
>+ TCA_FLOWER_KEY_ICMPV4_TYPE_MASK,/* u8 */
>+ TCA_FLOWER_KEY_ICMPV6_CODE, /* u8 */
>+ TCA_FLOWER_KEY_ICMPV6_CODE_MASK,/* u8 */
>+ TCA_FLOWER_KEY_ICMPV6_TYPE, /* u8 */
>+ TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,/* u8 */
>+
> __TCA_FLOWER_MAX,
> };
>
>diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
>index e8dd09af0d0c..412efa7de226 100644
>--- a/net/sched/cls_flower.c
>+++ b/net/sched/cls_flower.c
>@@ -355,6 +355,14 @@ static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
> [TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK] = { .type = NLA_U16 },
> [TCA_FLOWER_KEY_ENC_UDP_DST_PORT] = { .type = NLA_U16 },
> [TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK] = { .type = NLA_U16 },
>+ [TCA_FLOWER_KEY_ICMPV4_TYPE] = { .type = NLA_U8 },
>+ [TCA_FLOWER_KEY_ICMPV4_TYPE_MASK] = { .type = NLA_U8 },
>+ [TCA_FLOWER_KEY_ICMPV4_CODE] = { .type = NLA_U8 },
>+ [TCA_FLOWER_KEY_ICMPV4_CODE_MASK] = { .type = NLA_U8 },
>+ [TCA_FLOWER_KEY_ICMPV6_TYPE] = { .type = NLA_U8 },
>+ [TCA_FLOWER_KEY_ICMPV6_TYPE_MASK] = { .type = NLA_U8 },
>+ [TCA_FLOWER_KEY_ICMPV6_CODE] = { .type = NLA_U8 },
>+ [TCA_FLOWER_KEY_ICMPV6_CODE_MASK] = { .type = NLA_U8 },
> };
>
> static void fl_set_key_val(struct nlattr **tb,
>@@ -471,6 +479,20 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
> fl_set_key_val(tb, &key->tp.dst, TCA_FLOWER_KEY_SCTP_DST,
> &mask->tp.dst, TCA_FLOWER_KEY_SCTP_DST_MASK,
> sizeof(key->tp.dst));
>+ } else if (flow_basic_key_is_icmpv4(&key->basic)) {
>+ fl_set_key_val(tb, &key->tp.type, TCA_FLOWER_KEY_ICMPV4_TYPE,
>+ &mask->tp.type, TCA_FLOWER_KEY_ICMPV4_TYPE_MASK,
>+ sizeof(key->tp.type));
>+ fl_set_key_val(tb, &key->tp.code, TCA_FLOWER_KEY_ICMPV4_CODE,
>+ &mask->tp.code, TCA_FLOWER_KEY_ICMPV4_CODE_MASK,
>+ sizeof(key->tp.code));
>+ } else if (flow_basic_key_is_icmpv6(&key->basic)) {
>+ fl_set_key_val(tb, &key->tp.type, TCA_FLOWER_KEY_ICMPV6_TYPE,
>+ &mask->tp.type, TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,
>+ sizeof(key->tp.type));
>+ fl_set_key_val(tb, &key->tp.code, TCA_FLOWER_KEY_ICMPV4_CODE,
>+ &mask->tp.code, TCA_FLOWER_KEY_ICMPV4_CODE_MASK,
>+ sizeof(key->tp.code));
> }
>
> if (tb[TCA_FLOWER_KEY_ENC_IPV4_SRC] ||
>@@ -943,6 +965,26 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
> &mask->tp.dst, TCA_FLOWER_KEY_SCTP_DST_MASK,
> sizeof(key->tp.dst))))
> goto nla_put_failure;
>+ else if (flow_basic_key_is_icmpv4(&key->basic) &&
>+ (fl_dump_key_val(skb, &key->tp.type,
>+ TCA_FLOWER_KEY_ICMPV4_TYPE, &mask->tp.type,
>+ TCA_FLOWER_KEY_ICMPV4_TYPE_MASK,
>+ sizeof(key->tp.type)) ||
>+ fl_dump_key_val(skb, &key->tp.code,
>+ TCA_FLOWER_KEY_ICMPV4_CODE, &mask->tp.code,
>+ TCA_FLOWER_KEY_ICMPV4_CODE_MASK,
>+ sizeof(key->tp.code))))
>+ goto nla_put_failure;
>+ else if (flow_basic_key_is_icmpv6(&key->basic) &&
>+ (fl_dump_key_val(skb, &key->tp.type,
>+ TCA_FLOWER_KEY_ICMPV6_TYPE, &mask->tp.type,
>+ TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,
>+ sizeof(key->tp.type)) ||
>+ fl_dump_key_val(skb, &key->tp.code,
>+ TCA_FLOWER_KEY_ICMPV6_CODE, &mask->tp.code,
>+ TCA_FLOWER_KEY_ICMPV6_CODE_MASK,
>+ sizeof(key->tp.code))))
>+ goto nla_put_failure;
>
> if (key->enc_control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS &&
> (fl_dump_key_val(skb, &key->enc_ipv4.src,
>--
>2.7.0.rc3.207.g0ac5344
>
^ permalink raw reply
* bpf bounded loops. Was: [flamebait] xdp
From: Alexei Starovoitov @ 2016-12-02 18:39 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Tom Herbert, Thomas Graf, Linux Kernel Network Developers,
Daniel Borkmann, David S. Miller
In-Reply-To: <9b4264f8-26b9-a611-56f0-0840cecf9c44@stressinduktion.org>
On Thu, Dec 01, 2016 at 10:27:12PM +0100, Hannes Frederic Sowa wrote:
> like") and the problematic of parsing DNS packets in XDP due to string
> processing and looping inside eBPF.
Hannes,
Not too long ago you proposed a very interesting idea to add
support for bounded loops without adding any new bpf instructions and
changing llvm (which was way better than my 'rep' like instructions
I was experimenting with). I thought systemtap guys also wanted bounded
loops and you were cooperating on the design, so I gave up on my work and
was expecting an imminent patch from you. I guess it sounds like you know
believe that bounded loops are impossible or I misunderstand your statement ?
As far as pattern search for DNS packets...
it was requested by Cloudflare guys back in March:
https://github.com/iovisor/bcc/issues/471
and it is useful for several tracing use cases as well.
Unfortunately no one had time to implement it yet.
^ permalink raw reply
* Re: arp_filter and IPv6 ND
From: Hannes Frederic Sowa @ 2016-12-02 18:39 UTC (permalink / raw)
To: Saku Ytti; +Cc: netdev
In-Reply-To: <CAAeewD_erNdBw-zjPP9iFuju6FDgAgWrMKhMXPb58nqa0r22rA@mail.gmail.com>
Hi,
On 02.12.2016 18:51, Saku Ytti wrote:
> On 2 December 2016 at 18:45, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>
>> next-hop-self attribute on your neighbor in that direction? BGP in
>> general doesn't lead to ND entry installs, protocols like IS-IS afair
>> can short circuit here.
>
> That's the whole problem, Linux does not think of ND or ARP as
> interface specific thing, but as global thing. ND and ARP will happily
> answer to query from any interface if any other interface has said IP.
> I'm not sure why the Loopback ended up in Cisco ND Cache, answer is
> either Cisco queried for it or Linux did gratuitous answer. I believe
> gratuitous.
>
>> Hmm, I would keep the Loopback announcements out of the BGP.
>
> It's extremely common way to do anycast, but not interesting for the
> topic at hand.
Okay, sorry, I understood that you terminate the bgp sessions on those
IPs and use them for router-ids. But they are merely service IPs bound
to the loopback interface. I take it back and even for end system bgp
speakers/service announcement that is fine.
>> For enterprise and cloud stuff it is certainly very surprising, as some
>> isolations don't work as expected. OTOH it is really easy to build up
>> home networks and things are more plug and play.
>
> Can you give me practical example when the behaviour is desirable, my
> imagination is failing me. I'm not arguing, I just want to understand
> it, as I've never had the need myself.
The major difference is that you e.g. keep connectivity in some
scenarios where strong end systems would fail.
E.g. you can use IP addresses bound to other interfaces to send replys
on another interface. This can be useful if you have a limited amount of
IP addresses on the system but much more interfaces. Especially if they
are limited in scope, like in IPv6.
Basically Cisco's feature of "unnumbered interface" is always provided
in Linux. And there are certainly cases where you would want to use it,
e.g. emulate private-vlan feature for network separation.
Also in the BGP setup, you might have it easier to establish loopback
neighbor contact by just using static on-link routes, without caring
about more complex numbering there (otherwise you pretty soon introduce
OSPF or some other routing protocol to do the recursive forward resolution).
> I've never ran into setup which needs it, but cursory googling shows
> several people having broken networks because of the behaviour. If it
> is needed, I'm sure it's esoteric setup and perhaps saner default
> would that extra sysctl config is needed to get this interface
> agnostic ARP/ND behaviour.
Yes, it is a very problematic situation at internet exchanges and weak
end behavior must be disabled there as it causes havoc.
As global IPv6 addresses are more or less global, such problems actually
shouldn't exist, as no conflicting IP addresses should show up. Link
Local addresses are anyway handled in a strong end manner. Thus if the
Cisco router would install your routing entry you would probably not
have noticed. :)
>> Some RFCs require that for some router implementations (CPE), on the
>> other hand weak end model in Linux was probably inherited by IPv4. The
>> addition of duplicate address detection (which of course only makes
>> sense in strong end systems) to IPv6, basically shows that IPv6 is more
>> or less designed to be a strong end system model.
>>
>> Anyway, a patch to suppress ndisc requests on those interfaces will
>> probably be accepted.
>
> Grand, not that I feel comfortable writing it. I'd rather see the
> whole suppression functionality moved to neighbour.c from being AFI
> specific.
Yes sure, please provide a patch. A separate sysctl is necessary anyway
because the current one is within the ipv4 procfs directory hierarchy.
Bye,
Hannes
^ permalink raw reply
* Re: [PATH net v2] cdc_ether: Fix handling connection notification
From: David Miller @ 2016-12-02 18:40 UTC (permalink / raw)
To: kristian.evensen; +Cc: oliver, linux-usb, netdev, linux-kernel
In-Reply-To: <20161201132317.32324-1-kristian.evensen@gmail.com>
From: Kristian Evensen <kristian.evensen@gmail.com>
Date: Thu, 1 Dec 2016 14:23:17 +0100
> Commit bfe9b9d2df66 ("cdc_ether: Improve ZTE MF823/831/910 handling")
> introduced a work-around in usbnet_cdc_status() for devices that exported
> cdc carrier on twice on connect. Before the commit, this behavior caused
> the link state to be incorrect. It was assumed that all CDC Ethernet
> devices would either export this behavior, or send one off and then one on
> notification (which seems to be the default behavior).
>
> Unfortunately, it turns out multiple devices sends a connection
> notification multiple times per second (via an interrupt), even when
> connection state does not change. This has been observed with several
> different USB LAN dongles (at least), for example 13b1:0041 (Linksys).
> After bfe9b9d2df66, the link state has been set as down and then up for
> each notification. This has caused a flood of Netlink NEWLINK messages and
> syslog to be flooded with messages similar to:
>
> cdc_ether 2-1:2.0 eth1: kevent 12 may have been dropped
>
> This commit fixes the behavior by reverting usbnet_cdc_status() to how it
> was before bfe9b9d2df66. The work-around has been moved to a separate
> status-function which is only called when a known, affect device is
> detected.
>
> v1->v2:
>
> * Do not open-code netif_carrier_ok() (thanks Henning Schild).
> * Call netif_carrier_off() instead of usb_link_change(). This prevents
> calling schedule_work() twice without giving the work queue a chance to be
> processed (thanks Bjørn Mork).
>
> Fixes: bfe9b9d2df66 ("cdc_ether: Improve ZTE MF823/831/910 handling")
> Reported-by: Henning Schild <henning.schild@siemens.com>
> Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] NET: usb: qmi_wwan: add support for Telit LE922A PID 0x1040
From: David Miller @ 2016-12-02 18:42 UTC (permalink / raw)
To: dnlplm; +Cc: bjorn, netdev
In-Reply-To: <1480607525-23044-2-git-send-email-dnlplm@gmail.com>
From: Daniele Palmas <dnlplm@gmail.com>
Date: Thu, 1 Dec 2016 16:52:05 +0100
> This patch adds support for PID 0x1040 of Telit LE922A.
>
> The qmi adapter requires to have DTR set for proper working,
> so QMI_WWAN_QUIRK_DTR has been enabled.
>
> Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] geneve: avoid use-after-free of skb->data
From: John W. Linville @ 2016-12-02 18:33 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: netdev
In-Reply-To: <027c88dd060f5ca4535cb346db125829b2181a88.1480675406.git.sd@queasysnail.net>
On Fri, Dec 02, 2016 at 04:49:29PM +0100, Sabrina Dubroca wrote:
> geneve{,6}_build_skb can end up doing a pskb_expand_head(), which
> makes the ip_hdr(skb) reference we stashed earlier stale. Since it's
> only needed as an argument to ip_tunnel_ecn_encap(), move this
> directly in the function call.
>
> Fixes: 08399efc6319 ("geneve: ensure ECN info is handled properly in all tx/rx paths")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: John W. Linville <linville@tuxdriver.com>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH v7 net-next 0/6] net: Add bpf support for sockets
From: David Miller @ 2016-12-02 18:46 UTC (permalink / raw)
To: dsa; +Cc: netdev, daniel, ast, daniel, maheshb, tgraf
In-Reply-To: <1480610888-31082-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Thu, 1 Dec 2016 08:48:02 -0800
> The recently added VRF support in Linux leverages the bind-to-device
> API for programs to specify an L3 domain for a socket. While
> SO_BINDTODEVICE has been around for ages, not every ipv4/ipv6 capable
> program has support for it. Even for those programs that do support it,
> the API requires processes to be started as root (CAP_NET_RAW) which
> is not desirable from a general security perspective.
>
> This patch set leverages Daniel Mack's work to attach bpf programs to
> a cgroup to provide a capability to set sk_bound_dev_if for all
> AF_INET{6} sockets opened by a process in a cgroup when the sockets
> are allocated.
...
Series applied, thanks David.
^ permalink raw reply
* Re: [PATCH v6 net-next 0/7] Support Armada 37xx SoC (ARMv8 64-bits) in mvneta driver
From: David Miller @ 2016-12-02 18:52 UTC (permalink / raw)
To: gregory.clement
Cc: linux-kernel, netdev, jszhang, arnd, jason, andrew,
sebastian.hesselbarth, thomas.petazzoni, linux-arm-kernel, nadavh,
mw, dima, yelena
In-Reply-To: <cover.dd374b7aaa358be0211d7ead81129a399fa692f4.1480611779.git-series.gregory.clement@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Thu, 1 Dec 2016 18:03:03 +0100
> The Armada 37xx is a new ARMv8 SoC from Marvell using same network
> controller as the older Armada 370/38x/XP SoCs. This series adapts the
> driver in order to be able to use it on this new SoC. The main changes
> are:
>
> - 64-bits support: the first patches allow using the driver on a 64-bit
> architecture.
>
> - MBUS support: the mbus configuration is different on Armada 37xx
> from the older SoCs.
>
> - per cpu interrupt: Armada 37xx do not support per cpu interrupt for
> the NETA IP, the non-per-CPU behavior was added back.
>
> The first patch is an optimization in the rx path in swbm mode.
> The second patch remove unnecessary allocation for HWBM.
> The first item is solved by patches 4 and 5.
> The 2 last items are solved by patch 6.
> In patch 7 the dt support is added.
>
> Beside Armada 37xx, this series have been again tested on Armada XP
> and Armada 38x (with Hardware Buffer Management and with Software
> Buffer Management).
...
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2] net: bcmgenet: Utilize correct struct device for all DMA operations
From: David Miller @ 2016-12-02 18:54 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, pgynther, jaedon.shin, opendmb
In-Reply-To: <1480614345-5827-1-git-send-email-florian.fainelli@broadcom.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 1 Dec 2016 09:45:45 -0800
> From: Florian Fainelli <f.fainelli@gmail.com>
>
> __bcmgenet_tx_reclaim() and bcmgenet_free_rx_buffers() are not using the
> same struct device during unmap that was used for the map operation,
> which makes DMA-API debugging warn about it. Fix this by always using
> &priv->pdev->dev throughout the driver, using an identical device
> reference for all map/unmap calls.
>
> Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH net] net: avoid signed overflows for SO_{SND|RCV}BUFFORCE
From: Eric Dumazet @ 2016-12-02 17:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andrey Konovalov
From: Eric Dumazet <edumazet@google.com>
CAP_NET_ADMIN users should not be allowed to set negative
sk_sndbuf or sk_rcvbuf values, as it can lead to various memory
corruptions, crashes, OOM...
Note that before commit 82981930125a ("net: cleanups in
sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF
and SO_RCVBUF were vulnerable.
This needs to be backported to all known linux kernels.
Again, many thanks to syzkaller team for discovering this gem.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
---
net/core/sock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 5e3ca414357e2404db28eeacc5e9306051161493..00a074dbfe9bf169c2b81498e6ae265199745b22 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -715,7 +715,7 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
val = min_t(u32, val, sysctl_wmem_max);
set_sndbuf:
sk->sk_userlocks |= SOCK_SNDBUF_LOCK;
- sk->sk_sndbuf = max_t(u32, val * 2, SOCK_MIN_SNDBUF);
+ sk->sk_sndbuf = max_t(int, val * 2, SOCK_MIN_SNDBUF);
/* Wake up sending tasks if we upped the value. */
sk->sk_write_space(sk);
break;
@@ -751,7 +751,7 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
* returning the value we actually used in getsockopt
* is the most desirable behavior.
*/
- sk->sk_rcvbuf = max_t(u32, val * 2, SOCK_MIN_RCVBUF);
+ sk->sk_rcvbuf = max_t(int, val * 2, SOCK_MIN_RCVBUF);
break;
case SO_RCVBUFFORCE:
^ permalink raw reply related
* Re: [PATCH v3] sh_eth: remove unchecked interrupts for RZ/A1
From: David Miller @ 2016-12-02 18:55 UTC (permalink / raw)
To: chris.brandt
Cc: sergei.shtylyov, horms+renesas, geert+renesas, netdev,
linux-renesas-soc
In-Reply-To: <20161201183214.30196-1-chris.brandt@renesas.com>
From: Chris Brandt <chris.brandt@renesas.com>
Date: Thu, 1 Dec 2016 13:32:14 -0500
> When streaming a lot of data and the RZ/A1 can't keep up, some status bits
> will get set that are not being checked or cleared which cause the
> following messages and the Ethernet driver to stop working. This
> patch fixes that issue.
>
> irq 21: nobody cared (try booting with the "irqpoll" option)
> handlers:
> [<c036b71c>] sh_eth_interrupt
> Disabling IRQ #21
>
> Fixes: db893473d313a4ad ("sh_eth: Add support for r7s72100")
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-12-01
From: David Miller @ 2016-12-02 18:58 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <877f7jsdmm.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 01 Dec 2016 20:33:37 +0200
> here's another pull request for net-next. Nothing special to mention
> about, the details are in the signed tag below.
>
> This time there's a trivial conflict in
> drivers/net/wireless/ath/ath10k/mac.c:
>
> <<<<<<< HEAD
> ieee80211_hw_set(ar->hw, SUPPORTS_TX_FRAG);
> =======
> ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK);
>>>>>>>> d5fb3a138048798ce4cc4b4ced47d07d1794c577
>
> We want to have both flags enabled in ath10k.
>
> I'm planning to submit at least one more pull request, if Linus gives us
> one more week I might send even two. For example there are patches to
> convert wcn36xx to use the real SMD bus subsystem but they depend on few
> arm-soc patches. I'll send a separate email about that, they are not
> part of this pull request.
>
> Please let me know if there are any problems.
Pulled, thanks so much for the heads up about the ath10k merge conflict.
^ permalink raw reply
* Re: [patch] net: renesas: ravb: unintialized return value
From: David Miller @ 2016-12-02 19:00 UTC (permalink / raw)
To: dan.carpenter
Cc: sergei.shtylyov, johan, ykaneko0929, kazuya.mizuguchi.ks,
horms+renesas, wsa+renesas, andrew, tremyfr,
niklas.soderlund+renesas, arnd, netdev, linux-renesas-soc,
kernel-janitors
In-Reply-To: <20161201205744.GB10701@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 1 Dec 2016 23:57:44 +0300
> We want to set the other "err" variable here so that we can return it
> later. My version of GCC misses this issue but I caught it with a
> static checker.
>
> Fixes: 9f70eb339f52 ("net: ethernet: renesas: ravb: fix fixed-link phydev leaks")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH] iproute2: ss: escape all null bytes in abstract unix domain socket
From: Eric Dumazet @ 2016-12-02 18:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Isaac Boukris, davem, netdev, linux-kernel
In-Reply-To: <20161112101729.4d400929@samsung9>
On Sat, 2016-11-12 at 10:17 +0300, Stephen Hemminger wrote:
> On Sat, 29 Oct 2016 22:20:19 +0300
> Isaac Boukris <iboukris@gmail.com> wrote:
>
> > Abstract unix domain socket may embed null characters,
> > these should be translated to '@' when printed by ss the
> > same way the null prefix is currently being translated.
> >
> > Signed-off-by: Isaac Boukris <iboukris@gmail.com>
>
> Applied
Probably not a good idea to have :
for (int i = 0; i < len; i++)
if (name[i] == '\0')
name[i] = '@';
ss.c: In function 'unix_show_sock':
ss.c:3128:4: error: 'for' loop initial declarations are only allowed in C99 mode
ss.c:3128:4: note: use option -std=c99 or -std=gnu99 to compile your code
make[1]: *** [ss.o] Error 1
^ permalink raw reply
* Re: pull-request: can 2016-12-02
From: David Miller @ 2016-12-02 19:02 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20161202082931.22270-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 2 Dec 2016 09:29:29 +0100
> this is a pull request for net/master.
>
> THere are two patches by Stephane Grosjean, who adds support for the new
> PCAN-USB X6 USB interface to the pcan_usb driver.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net v3] tipc: check minimum bearer MTU
From: David Miller @ 2016-12-02 19:03 UTC (permalink / raw)
To: mkubecek; +Cc: jon.maloy, zhangqian-c, netdev, linux-kernel, tipc-discussion,
ben
In-Reply-To: <20161202083341.BB955A0F33@unicorn.suse.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Fri, 2 Dec 2016 09:33:41 +0100 (CET)
> Qian Zhang (张谦) reported a potential socket buffer overflow in
> tipc_msg_build() which is also known as CVE-2016-8632: due to
> insufficient checks, a buffer overflow can occur if MTU is too short for
> even tipc headers. As anyone can set device MTU in a user/net namespace,
> this issue can be abused by a regular user.
>
> As agreed in the discussion on Ben Hutchings' original patch, we should
> check the MTU at the moment a bearer is attached rather than for each
> processed packet. We also need to repeat the check when bearer MTU is
> adjusted to new device MTU. UDP case also needs a check to avoid
> overflow when calculating bearer MTU.
>
> Fixes: b97bf3fd8f6a ("[TIPC] Initial merge")
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> Reported-by: Qian Zhang (张谦) <zhangqian-c@360.cn>
Applied and queued up for -stable, thanks.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
^ permalink raw reply
* Re: [PATCH net] net: avoid signed overflows for SO_{SND|RCV}BUFFORCE
From: David Miller @ 2016-12-02 19:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, andreyknvl
In-Reply-To: <1480700693.18162.378.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 02 Dec 2016 09:44:53 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> CAP_NET_ADMIN users should not be allowed to set negative
> sk_sndbuf or sk_rcvbuf values, as it can lead to various memory
> corruptions, crashes, OOM...
>
> Note that before commit 82981930125a ("net: cleanups in
> sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF
> and SO_RCVBUF were vulnerable.
>
> This needs to be backported to all known linux kernels.
>
> Again, many thanks to syzkaller team for discovering this gem.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCHv2 net-next 1/4] net: dsa: mv88e6xxx: Implement mv88e6390 tag remap
From: Vivien Didelot @ 2016-12-02 19:15 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Andrew Lunn
In-Reply-To: <1480701779-30633-2-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> +/* Offset 0x18: Port IEEE Priority Remapping Registers [0-3]
> + * Offset 0x19: Port IEEE Priority Remapping Registers [4-7]
> + */
> +
> +int mv88e6095_port_tag_remap(struct mv88e6xxx_chip *chip, int port)
> +{
> + int err;
> +
> + /* Use a direct priority mapping for all IEEE tagged frames */
> + err = mv88e6xxx_port_write(chip, port, PORT_TAG_REGMAP_0123, 0x3210);
> + if (err)
> + return err;
> +
> + return mv88e6xxx_port_write(chip, port, PORT_TAG_REGMAP_4567, 0x7654);
> +}
> +
> +static int mv88e6xxx_port_ieeepmt_write(struct mv88e6xxx_chip *chip,
> + int port, u16 table,
> + u8 pointer, u16 data)
> +{
> + u16 reg;
> +
> + reg = PORT_IEEE_PRIO_MAP_TABLE_UPDATE |
> + table |
> + (pointer << PORT_IEEE_PRIO_MAP_TABLE_POINTER_SHIFT) |
> + data;
> +
> + return mv88e6xxx_port_write(chip, port, PORT_IEEE_PRIO_MAP_TABLE, reg);
> +}
> +
I'll send a delta patch to introduce mv88e6xxx_port_update() so we'll
benefit from the free wait on update bit 15.
> +int mv88e6390_port_tag_remap(struct mv88e6xxx_chip *chip, int port)
> +{
> + int err, i;
> +
> + for (i = 0; i <= 7; i++) {
> + err = mv88e6xxx_port_ieeepmt_write(
> + chip, port, PORT_IEEE_PRIO_MAP_TABLE_INGRESS_PCP,
> + i, (i | i << 4));
So here you are also mapping the frame's IEEE QPRI (offset 4), this is a
bit inconsistent compared to mv88e6095_port_tag_remap, which doesn't.
But it seems like these functions are only used at the moment to write
the default values, so I guess it doesn't really matter right now...
> + if (err)
> + return err;
> +
> + err = mv88e6xxx_port_ieeepmt_write(
> + chip, port, PORT_IEEE_PRIO_MAP_TABLE_EGRESS_GREEN_PCP,
> + i, i);
> + if (err)
> + return err;
> +
> + err = mv88e6xxx_port_ieeepmt_write(
> + chip, port, PORT_IEEE_PRIO_MAP_TABLE_EGRESS_YELLOW_PCP,
> + i, i);
> + if (err)
> + return err;
> +
> + err = mv88e6xxx_port_ieeepmt_write(
> + chip, port, PORT_IEEE_PRIO_MAP_TABLE_EGRESS_AVB_PCP,
> + i, i);
> + if (err)
> + return err;
> + }
> +
> + return 0;
> +}
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net-next 2/2] net/sched: cls_flower: Support matching on ICMP type and code
From: Simon Horman @ 2016-12-02 19:17 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, netdev, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, Jamal Hadi Salim, Jiri Pirko
In-Reply-To: <20161202183848.GF1883@nanopsycho.orion>
On Fri, Dec 02, 2016 at 07:38:48PM +0100, Jiri Pirko wrote:
> Fri, Dec 02, 2016 at 07:05:51PM CET, simon.horman@netronome.com wrote:
> >Support matching on ICMP type and code.
> >
> >Example usage:
> >
> >tc qdisc add dev eth0 ingress
> >
> >tc filter add dev eth0 protocol ip parent ffff: flower \
> > indev eth0 ip_proto icmp type 8 code 0 action drop
> >
> >tc filter add dev eth0 protocol ipv6 parent ffff: flower \
> > indev eth0 ip_proto icmpv6 type 128 code 0 action drop
> >
> >Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >---
> > include/net/flow_dissector.h | 24 ++++++++++++++++++++++--
> > include/uapi/linux/pkt_cls.h | 10 ++++++++++
> > net/sched/cls_flower.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 74 insertions(+), 2 deletions(-)
> >
> >diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
> >index 8880025914e3..5540dfa18872 100644
> >--- a/include/net/flow_dissector.h
> >+++ b/include/net/flow_dissector.h
> >@@ -199,10 +199,30 @@ struct flow_keys_digest {
> > void make_flow_keys_digest(struct flow_keys_digest *digest,
> > const struct flow_keys *flow);
> >
> >+static inline bool flow_protos_are_icmpv4(__be16 n_proto, u8 ip_proto)
> >+{
> >+ return n_proto == htons(ETH_P_IP) && ip_proto == IPPROTO_ICMP;
> >+}
> >+
> >+static inline bool flow_protos_are_icmpv6(__be16 n_proto, u8 ip_proto)
> >+{
> >+ return n_proto == htons(ETH_P_IPV6) && ip_proto == IPPROTO_ICMPV6;
> >+}
> >+
> > static inline bool flow_protos_are_icmp_any(__be16 n_proto, u8 ip_proto)
> > {
> >- return (n_proto == htons(ETH_P_IP) && ip_proto == IPPROTO_ICMP) ||
> >- (n_proto == htons(ETH_P_IPV6) && ip_proto == IPPROTO_ICMPV6);
> >+ return flow_protos_are_icmpv4(n_proto, ip_proto) ||
> >+ flow_protos_are_icmpv6(n_proto, ip_proto);
> >+}
> >+
> >+static inline bool flow_basic_key_is_icmpv4(const struct flow_dissector_key_basic *basic)
> >+{
> >+ return flow_protos_are_icmpv4(basic->n_proto, basic->ip_proto);
> >+}
> >+
> >+static inline bool flow_basic_key_is_icmpv6(const struct flow_dissector_key_basic *basic)
> >+{
> >+ return flow_protos_are_icmpv6(basic->n_proto, basic->ip_proto);
> > }
> >
>
> This hunk looks like it should be squashed to the previous patch.
I included it in this patch as it is where these helpers are used
for the first time. I can shuffle it into the first patch if you prefer;
I agree it does make sense to put all the dissector changes there.
^ permalink raw reply
* Re: [PATCH net] geneve: avoid use-after-free of skb->data
From: David Miller @ 2016-12-02 19:09 UTC (permalink / raw)
To: sd; +Cc: netdev, linville
In-Reply-To: <027c88dd060f5ca4535cb346db125829b2181a88.1480675406.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Fri, 2 Dec 2016 16:49:29 +0100
> geneve{,6}_build_skb can end up doing a pskb_expand_head(), which
> makes the ip_hdr(skb) reference we stashed earlier stale. Since it's
> only needed as an argument to ip_tunnel_ecn_encap(), move this
> directly in the function call.
>
> Fixes: 08399efc6319 ("geneve: ensure ECN info is handled properly in all tx/rx paths")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Applied and queued up for -stable, thanks.
This bug happens so many times that I think it might be time for
a debugging mode for pskb_expand_head() that unconditionally
reallocates the skb->data buffer regardless of whether it's
necessary or not and somehow unmaps the previous buffer to
force a trap on stale pointers.
Better ideas welcome, of course :)
^ permalink raw reply
* Re: bpf bounded loops. Was: [flamebait] xdp
From: Hannes Frederic Sowa @ 2016-12-02 19:25 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Tom Herbert, Thomas Graf, Linux Kernel Network Developers,
Daniel Borkmann, David S. Miller
In-Reply-To: <20161202183903.GC54949@ast-mbp.thefacebook.com>
Hi,
On 02.12.2016 19:39, Alexei Starovoitov wrote:
> On Thu, Dec 01, 2016 at 10:27:12PM +0100, Hannes Frederic Sowa wrote:
>> like") and the problematic of parsing DNS packets in XDP due to string
>> processing and looping inside eBPF.
>
> Hannes,
> Not too long ago you proposed a very interesting idea to add
> support for bounded loops without adding any new bpf instructions and
> changing llvm (which was way better than my 'rep' like instructions
> I was experimenting with). I thought systemtap guys also wanted bounded
> loops and you were cooperating on the design, so I gave up on my work and
> was expecting an imminent patch from you. I guess it sounds like you know
> believe that bounded loops are impossible or I misunderstand your statement ?
Your argument was that it would need a new verifier as the current first
pass checks that we indeed can lay out the basic blocks as a DAG which
the second pass depends on. This would be violated.
Because eBPF is available by non privileged users this would need a lot
of effort to rewrite and verify (or indeed keep two verifiers in the
kernel for priv and non-priv). The verifier itself is exposed to
unprivileged users.
Also, by design, if we keep the current limits, this would not give you
more instructions to operate on compared to the flattened version of the
program, it would merely reduce the numbers of optimizations in LLVM
that let the verifier reject the program.
Only enabling the relaxed verifier for root users seemed thus being
problematic as programs wouldn't be portable between nonprivileged and
privileged users.
> As far as pattern search for DNS packets...
> it was requested by Cloudflare guys back in March:
> https://github.com/iovisor/bcc/issues/471
> and it is useful for several tracing use cases as well.
> Unfortunately no one had time to implement it yet.
The string operations you proposed on the other hand, which would count
as one eBPF instructions, would give a lot more flexibility and allow
more cycles to burn, but don't help parsing binary protocols like IPv6
extension headers.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH 4/6] net: ethernet: ti: cpts: add ptp pps support
From: Richard Cochran @ 2016-12-02 19:28 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Murali Karicheri, Wingman Kwok, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, Mugunthan V N, Sekhar Nori,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <bfbebf2d-d057-6a21-845c-48f0a9ab0404-l0cyMroinI0@public.gmane.org>
On Fri, Dec 02, 2016 at 11:58:34AM -0600, Grygorii Strashko wrote:
> or I missed smth?
You are missing three important points.
1. Unlike the code you posted, no edges will be lost.
2. The solution using the PWM is implemented in USER SPACE. If people
use this way, then they will be forced to understand the inherit
limitations. In addition, the behavior of servo will be under
their control.
3. The update rate of the PHC is not once per second. It can be any
rate at all, like 16 Hz for the telecom profile. You can't just
blindly pick out an adjustment value once per second. Using the
feedback from the time stamped PWM and adjusting THAT at the PWM
rate (also not necessarily 1 PPS) is the right way. The second
reply in that thread is an even better solution, leaving the PHC
free running and adjusting the timer input clock (probably they
used a VCO).
Just hacking in some kind of kernel PPS with unknown accuracy is just
asking for trouble later, since people will expect HW accuracy.
So just get the input time stamps working, and make PWM control
available to userspace in mainline (not sure about this, I guess it
isn't), and leave the PPS part to a userspace utility.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv2 net-next 2/4] net: dsa: mv88e6xxx: Monitor and Management tables
From: Vivien Didelot @ 2016-12-02 19:32 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Andrew Lunn
In-Reply-To: <1480701779-30633-3-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> @@ -3184,6 +3186,8 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
> .stats_get_sset_count = mv88e6095_stats_get_sset_count,
> .stats_get_strings = mv88e6095_stats_get_strings,
> .stats_get_stats = mv88e6095_stats_get_stats,
> + .g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
> + .g1_set_egress_port = mv88e6095_g1_set_egress_port,
> };
I like the implementation in this version better. But please explain me
why you are prefixing these operations with g1_?
The mv88e6xxx_ops structure is agnostic from the implementation. There
is only one way to implement a feature (e.g. setting the switch MAC) in
Marvell switches. So describing the internal location of the said
feature is wrong and brings no value.
But let's imagine we can set the CPU port in some Global 2 registers.
You are going to wrap this in chip.c with something like:
int mv88e6xxx_set_cpu_port(struct mv88e6xxx_chip *chip, int port)
{
if (chip->info->ops->g2_set_cpu_port)
return chip->info->ops->g2_set_cpu_port(chip, port);
else if (chip->info->ops->g1_set_cpu_port)
return chip->info->ops->g1_set_cpu_port(chip, port);
else
return -EOPNOTSUPP;
}
What's the point of this?
Thanks,
Vivien
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2016-12-02 19:40 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Lots more phydev and probe error path leaks in various drivers by
Johan Hovold.
2) Fix race in packet_set_ring(), from Philip Pettersson.
3) Use after free in dccp_invalid_packet(), from Eric Dumazet.
4) Signnedness overflow in SO_{SND,RCV}BUFFORCE, also from Eric
Dumazet.
5) When tunneling between ipv4 and ipv6 we can be left with the wrong
skb->protocol value as we enter the IPSEC engine and this causes
all kinds of problems. Set it before the output path does any
dst_output() calls, from Eli Cooper.
6) bcmgenet uses wrong device struct pointer in DMA API calls,
fix from Florian Fainelli.
7) Various netfilter nat bug fixes from FLorian Westphal.
8) Fix memory leak in ipvlan_link_new(), from Gao Feng.
9) Locking fixes, particularly wrt. socket lookups, in l2tp from
Guillaume Nault.
10) Avoid invoking rhash teardowns in atomic context by moving
netlink cb->done() dump completion from a worker thread. Fix
from Herbert Xu.
11) Buffer refcount problems in tun and macvtap on errors, from
Jason Wang.
12) We don't set Kconfig symbol DEFAULT_TCP_CONG properly when the
user selects BBR. Fix from Julian Wollrath.
13) Fix deadlock in transmit path on altera TSE driver, from Lino
Sanfilippo.
14) Fix unbalanced reference counting in dsa_switch_tree, from Nikita
Yushchenko.
15) tc_tunnel_key needs to be properly exported to userspace via uapi,
fix from Roi Dayan.
16) rds_tcp_init_net() doesn't unregister notifier in error path, fix
from Sowmini Varadhan.
17) Stale packet header pointer access after pskb_expand_head() in
genenve driver, fix from Sabrina Dubroca.
Please pull, thanks a lot!
The following changes since commit d8e435f3ab6fea2ea324dce72b51dd7761747523:
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2016-11-26 17:21:13 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to b98b0bc8c431e3ceb4b26b0dfc8db509518fb290:
net: avoid signed overflows for SO_{SND|RCV}BUFFORCE (2016-12-02 14:10:14 -0500)
----------------------------------------------------------------
Alexander Duyck (2):
igb/igbvf: Don't use lco_csum to compute IPv4 checksum
ixgbe/ixgbevf: Don't use lco_csum to compute IPv4 checksum
Amir Vadai (1):
net/sched: pedit: make sure that offset is valid
Anders K. Pedersen (1):
netfilter: nf_tables: fix inconsistent element expiration calculation
Arnaldo Carvalho de Melo (1):
GSO: Reload iph after pskb_may_pull
Arnd Bergmann (1):
irda: fix overly long udelay()
Artem Savkov (1):
ip6_offload: check segs for NULL in ipv6_gso_segment.
Borislav Petkov (1):
amd-xgbe: Fix unused suspend handlers build warning
Brian Norris (1):
mwifiex: printk() overflow with 32-byte SSIDs
Chris Brandt (1):
sh_eth: remove unchecked interrupts for RZ/A1
Cyrille Pitchen (1):
net: macb: fix the RX queue reset in macb_rx()
Dan Carpenter (1):
net: renesas: ravb: unintialized return value
Daniel Borkmann (1):
net, sched: respect rcu grace period on cls destruction
Daniele Di Proietto (1):
openvswitch: Fix skb leak in IPv6 reassembly.
Daniele Palmas (1):
NET: usb: qmi_wwan: add support for Telit LE922A PID 0x1040
David Ahern (3):
netfilter: Update ip_route_me_harder to consider L3 domain
netfilter: Update nf_send_reset6 to consider L3 domain
net: handle no dst on skb in icmp6_send
David S. Miller (11):
Merge branch 'more-phydev-leaks'
Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
Merge branch 'fix-RTL8211F-TX-delay-handling'
Merge branch 'mlx4-fixes'
Merge branch 'fixed-phy-phydev-leaks'
Merge branch 'l2tp-fixes'
Merge tag 'wireless-drivers-for-davem-2016-11-29' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge git://git.kernel.org/.../pablo/nf
Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
Merge branch 'stmmac-probe-error-handling-and-phydev-leaks'
Merge tag 'linux-can-fixes-for-4.9-20161201' of git://git.kernel.org/.../mkl/linux-can
Eli Cooper (3):
ipv4: Set skb->protocol properly for local output
ipv6: Set skb->protocol properly for local output
Revert: "ip6_tunnel: Update skb->protocol to ETH_P_IPV6 in ip6_tnl_xmit()"
Eric Dumazet (2):
net/dccp: fix use-after-free in dccp_invalid_packet
net: avoid signed overflows for SO_{SND|RCV}BUFFORCE
Florian Fainelli (1):
net: bcmgenet: Utilize correct struct device for all DMA operations
Florian Westphal (6):
xfrm: unbreak xfrm_sk_policy_lookup
netfilter: fix nf_conntrack_helper documentation
netfilter: nat: fix cmp return value
netfilter: nat: switch to new rhlist interface
netfilter: nat: fix crash when conntrack entry is re-used
netfilter: ipv6: nf_defrag: drop mangled skb on ream error
Gao Feng (2):
driver: ipvlan: Fix one possible memleak in ipvlan_link_new
driver: macvtap: Unregister netdev rx_handler if macvtap_newlink fails
Grygorii Strashko (1):
net: ethernet: ti: cpsw: fix ASSERT_RTNL() warning during resume
Guillaume Nault (5):
l2tp: lock socket before checking flags in connect()
l2tp: hold socket before dropping lock in l2tp_ip{, 6}_recv()
l2tp: fix racy socket lookup in l2tp_ip and l2tp_ip6 bind()
l2tp: fix lookup for sockets not bound to a device in l2tp_ip
l2tp: fix address test in __l2tp_ip6_bind_lookup()
Haishuang Yan (1):
vxlan: fix a potential issue when create a new vxlan fdb entry.
Hariprasad Shenai (1):
cxgb4: Add PCI device ID for new adapter
Herbert Xu (1):
netlink: Call cb->done from a worker thread
Hongxu Jia (1):
netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT" failed in 64bit kernel
Jack Morgenstein (1):
net/mlx4: Fix uninitialized fields in rule when adding promiscuous mode to device managed flow steering
Jason Wang (2):
tun: handle ubuf refcount correctly when meet errors
macvtap: handle ubuf refcount correctly when meet errors
Jiri Pirko (1):
sched: cls_flower: remove from hashtable only in case skip sw flag is not set
Johan Hovold (28):
net: dsa: fix fixed-link-phy device leaks
net: bcmgenet: fix phydev reference leak
net: fsl/fman: fix phydev reference leak
net: fsl/fman: fix fixed-link-phydev reference leak
net: qcom/emac: fix of_node and phydev leaks
net: dsa: slave: fix of-node leak and phy priority
of_mdio: add helper to deregister fixed-link PHYs
net: ethernet: altera: fix fixed-link phydev leaks
net: ethernet: aurora: nb8800: fix fixed-link phydev leaks
net: ethernet: bcmsysport: fix fixed-link phydev leaks
net: ethernet: bcmgenet: fix fixed-link phydev leaks
net: ethernet: fec: fix fixed-link phydev leaks
net: ethernet: fs_enet: fix fixed-link phydev leaks
net: ethernet: gianfar: fix fixed-link phydev leaks
net: ethernet: ucc_geth: fix fixed-link phydev leaks
net: ethernet: marvell: mvneta: fix fixed-link phydev leaks
net: ethernet: mediatek: fix fixed-link phydev leaks
net: ethernet: renesas: ravb: fix fixed-link phydev leaks
net: ethernet: dwc_eth_qos: fix fixed-link phydev leaks
net: ethernet: ti: davinci_emac: fix fixed-link phydev and of-node leaks
net: dsa: slave: fix fixed-link phydev leaks
net: ethernet: stmmac: dwmac-socfpga: fix use-after-free on probe errors
net: ethernet: stmmac: dwmac-sti: fix probe error path
net: ethernet: stmmac: dwmac-rk: fix probe error path
net: ethernet: stmmac: dwmac-generic: fix probe error path
net: ethernet: stmmac: dwmac-meson8b: fix probe error path
net: ethernet: stmmac: platform: fix outdated function header
net: ethernet: stmmac: fix of-node and fixed-link-phydev leaks
Jon Paul Maloy (1):
tipc: fix link statistics counter errors
Josef Bacik (1):
bpf: fix states equal logic for varlen access
Julian Wollrath (1):
tcp: Set DEFAULT_TCP_CONG to bbr if DEFAULT_BBR is set
Kristian Evensen (1):
cdc_ether: Fix handling connection notification
Laura Garcia Liebana (1):
netfilter: nft_hash: validate maximum value of u32 netlink hash attribute
Lino Sanfilippo (2):
net: ethernet: altera: TSE: Remove unneeded dma sync for tx buffers
net: ethernet: altera: TSE: do not use tx queue lock in tx completion handler
Liping Zhang (1):
netfilter: nft_range: add the missing NULL pointer check
Martin Blumenstingl (2):
Documentation: devicetree: clarify usage of the RGMII phy-modes
net: phy: realtek: fix enabling of the TX-delay for RTL8211F
Michael Holzheu (1):
bpf/samples: Fix PT_REGS_IP on s390x and use it
Michal Kubeček (1):
tipc: check minimum bearer MTU
Miroslav Urbanek (1):
flowcache: Increase threshold for refusing new allocations
Nicolas Dichtel (1):
vti6: flush x-netns xfrm cache when vti interface is removed
Nikita Yushchenko (2):
net: dsa: fix unbalanced dsa_switch_tree reference counting
net: fec: cache statistics while device is down
Philip Pettersson (1):
packet: fix race condition in packet_set_ring
Roi Dayan (1):
net/sched: Export tc_tunnel_key so its UAPI accessible
Sabrina Dubroca (1):
geneve: avoid use-after-free of skb->data
Sowmini Varadhan (1):
RDS: TCP: unregister_netdevice_notifier() in error path of rds_tcp_init_net
Stephane Grosjean (2):
can: peak: Fix bittiming fields size in bits
can: peak: Add support for PCAN-USB X6 USB interface
Tariq Toukan (1):
Revert "net/mlx4_en: Avoid unregister_netdev at shutdown flow"
Tobias Brunner (2):
esp4: Fix integrity verification when ESN are used
esp6: Fix integrity verification when ESN are used
Tobias Klauser (1):
net/rtnetlink: fix attribute name in nlmsg_size() comments
Yi Zhao (1):
xfrm_user: fix return value from xfrm_user_rcv_msg
Zumeng Chen (1):
net: macb: ensure ordering write to re-enable RX smoothly
allan (1):
net: asix: Fix AX88772_suspend() USB vendor commands failure issues
Documentation/devicetree/bindings/net/ethernet.txt | 24 ++++++++++++++++++++----
Documentation/networking/nf_conntrack-sysctl.txt | 7 +++++--
drivers/net/can/usb/peak_usb/pcan_ucan.h | 37 +++++++++++++++++++++++++++++--------
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 ++
drivers/net/can/usb/peak_usb/pcan_usb_core.h | 2 ++
drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------
drivers/net/ethernet/altera/altera_tse_main.c | 21 ++++++++-------------
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 4 ++--
drivers/net/ethernet/aurora/nb8800.c | 9 +++++++--
drivers/net/ethernet/broadcom/bcmsysport.c | 17 ++++++++++++-----
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 +++++---
drivers/net/ethernet/broadcom/genet/bcmmii.c | 10 +++++++++-
drivers/net/ethernet/cadence/macb.c | 5 +++--
drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 1 +
drivers/net/ethernet/freescale/fec.h | 2 ++
drivers/net/ethernet/freescale/fec_main.c | 28 ++++++++++++++++++++++++----
drivers/net/ethernet/freescale/fman/fman_memac.c | 3 +++
drivers/net/ethernet/freescale/fman/mac.c | 2 ++
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 7 ++++++-
drivers/net/ethernet/freescale/gianfar.c | 8 ++++++++
drivers/net/ethernet/freescale/ucc_geth.c | 23 ++++++++++++++++-------
drivers/net/ethernet/intel/igb/igb_main.c | 8 ++++++--
drivers/net/ethernet/intel/igbvf/netdev.c | 8 ++++++--
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 ++++++--
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 8 ++++++--
drivers/net/ethernet/marvell/mvneta.c | 5 +++++
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++++
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 17 ++---------------
drivers/net/ethernet/mellanox/mlx4/main.c | 5 +----
drivers/net/ethernet/mellanox/mlx4/mcg.c | 7 ++++++-
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 1 +
drivers/net/ethernet/qualcomm/emac/emac.c | 4 ++++
drivers/net/ethernet/renesas/ravb_main.c | 19 ++++++++++++++-----
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c | 17 +++++++++++++++--
drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c | 25 +++++++++++++++++++------
drivers/net/ethernet/stmicro/stmmac/dwmac-lpc18xx.c | 17 ++++++++++++++---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c | 23 ++++++++++++++++++-----
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 32 ++++++++++++++++++++++++--------
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 21 +++++++++++++++++----
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 39 ++++++++++++++++++++++++++-------------
drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 23 ++++++++++++++++++-----
drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 19 ++++++++++++++-----
drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 26 +++++++++++++++++++-------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 33 +++++++++++++++++++++++++++++----
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h | 2 ++
drivers/net/ethernet/synopsys/dwc_eth_qos.c | 20 +++++++++++++-------
drivers/net/ethernet/ti/cpsw.c | 20 ++++++--------------
drivers/net/ethernet/ti/davinci_emac.c | 10 +++++++++-
drivers/net/geneve.c | 14 ++++----------
drivers/net/ipvlan/ipvlan_main.c | 17 ++++++++++++-----
drivers/net/irda/w83977af_ir.c | 4 +++-
drivers/net/macvtap.c | 19 ++++++++++++-------
drivers/net/phy/realtek.c | 20 ++++++++++++--------
drivers/net/tun.c | 10 ++++------
drivers/net/usb/asix_devices.c | 6 +++---
drivers/net/usb/cdc_ether.c | 38 +++++++++++++++++++++++++++++++-------
drivers/net/usb/qmi_wwan.c | 1 +
drivers/net/vxlan.c | 10 +++++++---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++++++------
drivers/of/of_mdio.c | 15 +++++++++++++++
include/linux/mlx4/device.h | 1 -
include/linux/of_mdio.h | 4 ++++
include/net/ipv6.h | 2 ++
include/net/netfilter/nf_conntrack.h | 6 +++---
include/net/netfilter/nf_tables.h | 2 +-
include/uapi/linux/tc_act/Kbuild | 1 +
kernel/bpf/verifier.c | 10 ++++++++--
net/core/flow.c | 6 ++----
net/core/rtnetlink.c | 4 ++--
net/core/sock.c | 4 ++--
net/dccp/ipv4.c | 12 +++++++-----
net/dsa/dsa.c | 13 ++++---------
net/dsa/dsa2.c | 4 +++-
net/dsa/slave.c | 19 ++++++++++++++++---
net/ipv4/Kconfig | 1 +
net/ipv4/af_inet.c | 2 +-
net/ipv4/esp4.c | 2 +-
net/ipv4/ip_output.c | 2 ++
net/ipv4/netfilter.c | 5 ++++-
net/ipv4/netfilter/arp_tables.c | 4 ++--
net/ipv6/datagram.c | 4 +++-
net/ipv6/esp6.c | 2 +-
net/ipv6/icmp.c | 6 ++++--
net/ipv6/ip6_offload.c | 2 +-
net/ipv6/ip6_tunnel.c | 1 -
net/ipv6/ip6_vti.c | 31 +++++++++++++++++++++++++++++++
net/ipv6/netfilter/nf_conntrack_reasm.c | 4 ++--
net/ipv6/netfilter/nf_defrag_ipv6_hooks.c | 2 +-
net/ipv6/netfilter/nf_reject_ipv6.c | 1 +
net/ipv6/output_core.c | 2 ++
net/l2tp/l2tp_ip.c | 63 ++++++++++++++++++++++++++++++++++-----------------------------
net/l2tp/l2tp_ip6.c | 79 ++++++++++++++++++++++++++++++++++++++++++-------------------------------------
net/netfilter/nf_nat_core.c | 49 ++++++++++++++++++++++++++++++-------------------
net/netfilter/nf_tables_api.c | 14 +++++++++-----
net/netfilter/nft_hash.c | 7 +++++--
net/netfilter/nft_range.c | 6 ++++++
net/netlink/af_netlink.c | 27 +++++++++++++++++++++++----
net/netlink/af_netlink.h | 2 ++
net/openvswitch/conntrack.c | 5 ++++-
net/packet/af_packet.c | 18 ++++++++++++------
net/rds/tcp.c | 2 ++
net/sched/act_pedit.c | 24 ++++++++++++++++++++----
net/sched/cls_basic.c | 4 ----
net/sched/cls_bpf.c | 4 ----
net/sched/cls_cgroup.c | 7 +++----
net/sched/cls_flow.c | 1 -
net/sched/cls_flower.c | 41 ++++++++++++++++++++++++++++++++---------
net/sched/cls_matchall.c | 1 -
net/sched/cls_rsvp.h | 3 ++-
net/sched/cls_tcindex.c | 1 -
net/tipc/bearer.c | 11 +++++++++--
net/tipc/bearer.h | 13 +++++++++++++
net/tipc/link.c | 35 +++++++++++++++++++----------------
net/tipc/udp_media.c | 5 +++++
net/xfrm/xfrm_policy.c | 10 ++++++----
net/xfrm/xfrm_user.c | 2 +-
samples/bpf/bpf_helpers.h | 2 +-
samples/bpf/sampleip_kern.c | 2 +-
samples/bpf/trace_event_kern.c | 2 +-
121 files changed, 1064 insertions(+), 450 deletions(-)
^ permalink raw reply
* Re: [PATCHv2 net-next 3/4] net: dsa: mv88e6xxx: Move the tagging protocol into info
From: Vivien Didelot @ 2016-12-02 19:41 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Andrew Lunn
In-Reply-To: <1480701779-30633-4-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> @@ -3749,6 +3756,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
> .global1_addr = 0x1b,
> .age_time_coeff = 15000,
> .g1_irqs = 9,
> + .tag_protocol = DSA_TAG_PROTO_EDSA,
> .flags = MV88E6XXX_FLAGS_FAMILY_6352,
> .ops = &mv88e6172_ops,
> },
Since some chips support several protocols, we will have to turn
tag_protocol into a bitmask and introduce something like:
enum mv88e6xxx_tag {
MV88E6XXX_TAG_TRAILER = BIT(DSA_TAG_PROTO_TRAILER),
MV88E6XXX_TAG_DSA = BIT(DSA_TAG_PROTO_DSA),
MV88E6XXX_TAG_EDSA = BIT(DSA_TAG_PROTO_EDSA),
};
But I guess it is OK to force a single one at the moment.
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Thanks,
Vivien
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox