* Re: [pull request][for-next 0/6] Mellanox mlx5 updates 2017-05-23
From: David Miller @ 2017-06-02 16:08 UTC (permalink / raw)
To: alexei.starovoitov-Re5JQEeQqe8AvxtiuMwx3w
Cc: leon-DgEjT+Ai2ygdnm+yROfE0A, dledford-H+wXaHxf7aLQT0dZR+AlfA,
saeedm-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, ilant-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <20170602160641.ylowbobe5v72ui7g-+o4/htvd0TCa6kscz5V53/3mLCh9rsb+VpNB7YpNyf8@public.gmane.org>
From: Alexei Starovoitov <alexei.starovoitov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Fri, 2 Jun 2017 09:06:43 -0700
> On Fri, Jun 02, 2017 at 06:39:40PM +0300, Leon Romanovsky wrote:
>> On Thu, Jun 01, 2017 at 06:57:59PM -0400, Doug Ledford wrote:
>> > On Thu, 2017-05-25 at 12:02 -0400, David Miller wrote:
>> > > From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>> > > Date: Tue, 23 May 2017 14:43:58 +0300
>> > >
>> > > > Hi Dave and Doug,
>> > > >
>> > > > This series introduces some small updates and FPGA support to the
>> > > mlx5
>> > > > core/ethernet and IB drivers.
>> > > >
>> > > > For more details please see below.
>> > > >
>> > > > Please pull and let me know if there's any problem.
>> > >
>> > > Ok, I've pulled this into net-next.
>> > >
>> > > Doug let me know if there are any merge hassles we need to coordinate
>> > > on.
>> > >
>> > > Thanks.
>> >
>> > Will do. But is the question of a possible revert settled? Because
>> > once I pull, a revert means I have to pull all the way up to the revert
>> > as well...
>>
>> Revert is unlikely to happen, Saeed is working with Alexey to resolve
>> his raised concerns.
>
> I still think the direction is absolutely wrong.
> Reinventing fpga interfaces via nic driver is no-go.
> mlx needs to send a patch to revert it to show that they are willing
> to listen to the community.
"Two people from Facebook" is not the commnity Alexei. :-)
And ironically, you guys will want to be one of the main users of
these facilities for the KTLS offload bits, so the desire to separate
it out and make "backports easier" really confuses me.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] sock: reset sk_err when the error queue is empty
From: Soheil Hassas Yeganeh @ 2017-06-02 16:38 UTC (permalink / raw)
To: davem, netdev
Cc: chrubis, Soheil Hassas Yeganeh, Eric Dumazet, Willem de Bruijn
From: Soheil Hassas Yeganeh <soheil@google.com>
Prior to f5f99309fa74 (sock: do not set sk_err in
sock_dequeue_err_skb), sk_err was reset to the error of
the skb on the head of the error queue.
Applications, most notably ping, are relying on this
behavior to reset sk_err for ICMP packets.
Set sk_err to the ICMP error when there is an ICMP packet
at the head of the error queue.
Fixes: f5f99309fa74 (sock: do not set sk_err in sock_dequeue_err_skb)
Reported-by: Cyril Hrubis <chrubis@suse.cz>
Test-by: Cyril Hrubis <chrubis@suse.cz>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/core/skbuff.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 346d3e85dfbc..b1be7c01efe2 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3754,8 +3754,11 @@ struct sk_buff *sock_dequeue_err_skb(struct sock *sk)
spin_lock_irqsave(&q->lock, flags);
skb = __skb_dequeue(q);
- if (skb && (skb_next = skb_peek(q)))
+ if (skb && (skb_next = skb_peek(q))) {
icmp_next = is_icmp_err_skb(skb_next);
+ if (icmp_next)
+ sk->sk_err = SKB_EXT_ERR(skb_next)->ee.ee_origin;
+ }
spin_unlock_irqrestore(&q->lock, flags);
if (is_icmp_err_skb(skb) && !icmp_next)
--
2.13.0.506.g27d5fe0cd-goog
^ permalink raw reply related
* Re: [PATCH][V2] net: phy: marvell: make some functions static
From: Florian Fainelli @ 2017-06-02 16:48 UTC (permalink / raw)
To: Colin King, Andrew Lunn, netdev; +Cc: kernel-janitors, linux-kernel
In-Reply-To: <20170602141334.26506-1-colin.king@canonical.com>
On 06/02/2017 07:13 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> functions m88e1510_get_temp_critical, m88e1510_set_temp_critical and
> m88e1510_get_temp_alarm can be made static as they not need to be
> in global scope.
>
> Cleans up sparse warnings:
> "symbol 'm88e1510_get_temp_alarm' was not declared. Should it be static?"
> "symbol 'm88e1510_get_temp_critical' was not declared. Should it be
> static?"
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [pull request][for-next 0/6] Mellanox mlx5 updates 2017-05-23
From: Alexei Starovoitov @ 2017-06-02 16:57 UTC (permalink / raw)
To: David Miller
Cc: leon-DgEjT+Ai2ygdnm+yROfE0A, dledford-H+wXaHxf7aLQT0dZR+AlfA,
saeedm-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, ilant-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <20170602.120839.1394660754953676217.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Fri, Jun 02, 2017 at 12:08:39PM -0400, David Miller wrote:
> From: Alexei Starovoitov <alexei.starovoitov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Fri, 2 Jun 2017 09:06:43 -0700
>
> > On Fri, Jun 02, 2017 at 06:39:40PM +0300, Leon Romanovsky wrote:
> >> On Thu, Jun 01, 2017 at 06:57:59PM -0400, Doug Ledford wrote:
> >> > On Thu, 2017-05-25 at 12:02 -0400, David Miller wrote:
> >> > > From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> >> > > Date: Tue, 23 May 2017 14:43:58 +0300
> >> > >
> >> > > > Hi Dave and Doug,
> >> > > >
> >> > > > This series introduces some small updates and FPGA support to the
> >> > > mlx5
> >> > > > core/ethernet and IB drivers.
> >> > > >
> >> > > > For more details please see below.
> >> > > >
> >> > > > Please pull and let me know if there's any problem.
> >> > >
> >> > > Ok, I've pulled this into net-next.
> >> > >
> >> > > Doug let me know if there are any merge hassles we need to coordinate
> >> > > on.
> >> > >
> >> > > Thanks.
> >> >
> >> > Will do. But is the question of a possible revert settled? Because
> >> > once I pull, a revert means I have to pull all the way up to the revert
> >> > as well...
> >>
> >> Revert is unlikely to happen, Saeed is working with Alexey to resolve
> >> his raised concerns.
> >
> > I still think the direction is absolutely wrong.
> > Reinventing fpga interfaces via nic driver is no-go.
> > mlx needs to send a patch to revert it to show that they are willing
> > to listen to the community.
>
> "Two people from Facebook" is not the commnity Alexei. :-)
I've read the thread that fpga folks are not excited about
fpga behind the nic either... but yeah i'm mainly expressing
my opinions here.
> And ironically, you guys will want to be one of the main users of
> these facilities for the KTLS offload bits, so the desire to separate
> it out and make "backports easier" really confuses me.
We will not be using ktls offload via hidden fpga which
is not properly exposed to the kernel.
We've learned our lesson with eswitch.
ktls patches are independent of hw offload. It's great that
mlx fpga can accelerate ktls tx which is extra confirmation
that ktls api is on the right track. There is still 'ktls rx'
to finish and 'ktls rx offload' is even trickier, since it's
more intrusive into the core networking. Once crypto scatter gather
is improved, we expect to see 8% perf gain out of sw ktls alone.
So ktls hw offload is complementary and not mandatory.
Back to eswitch analogy. All I hear from mlx is "at this stage
it's not approriate ...". Well, I've been asking to do
'the right thing' for eswitch for months now and eswitch was
in the driver for years. What are the chances that this fpga
will ever be exposed? Once the code is merged there is no
incentive for the vendor to do it differently.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ip: link add vxcan support
From: Oliver Hartkopp @ 2017-06-02 17:04 UTC (permalink / raw)
To: linux-can, stephen; +Cc: Oliver Hartkopp, mkl, netdev
Since commit a8f820a380a2a06 ('can: add Virtual CAN Tunnel driver (vxcan)')
for Linux 4.12 a virtual CAN tunnel driver analogue to veth is available in
Linux.
This patch adds the ability to create vxcan device pairs.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
include/linux/can/vxcan.h | 12 ++++++
ip/Makefile | 2 +-
ip/iplink_vxcan.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 112 insertions(+), 1 deletion(-)
create mode 100644 include/linux/can/vxcan.h
create mode 100644 ip/iplink_vxcan.c
diff --git a/include/linux/can/vxcan.h b/include/linux/can/vxcan.h
new file mode 100644
index 00000000..ffb0b715
--- /dev/null
+++ b/include/linux/can/vxcan.h
@@ -0,0 +1,12 @@
+#ifndef _UAPI_CAN_VXCAN_H
+#define _UAPI_CAN_VXCAN_H
+
+enum {
+ VXCAN_INFO_UNSPEC,
+ VXCAN_INFO_PEER,
+
+ __VXCAN_INFO_MAX
+#define VXCAN_INFO_MAX (__VXCAN_INFO_MAX - 1)
+};
+
+#endif
diff --git a/ip/Makefile b/ip/Makefile
index e08c170a..8424b1f6 100644
--- a/ip/Makefile
+++ b/ip/Makefile
@@ -2,7 +2,7 @@ IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o ipnetns.o \
rtm_map.o iptunnel.o ip6tunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \
ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o iptuntap.o iptoken.o \
ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o iplink_dummy.o \
- iplink_ifb.o iplink_nlmon.o iplink_team.o iplink_vcan.o \
+ iplink_ifb.o iplink_nlmon.o iplink_team.o iplink_vcan.o iplink_vxcan.o \
iplink_vlan.o link_veth.o link_gre.o iplink_can.o iplink_xdp.o \
iplink_macvlan.o ipl2tp.o link_vti.o link_vti6.o \
iplink_vxlan.o tcp_metrics.o iplink_ipoib.o ipnetconf.o link_ip6tnl.o \
diff --git a/ip/iplink_vxcan.c b/ip/iplink_vxcan.c
new file mode 100644
index 00000000..680f640f
--- /dev/null
+++ b/ip/iplink_vxcan.c
@@ -0,0 +1,99 @@
+/*
+ * iplink_vxcan.c vxcan device support (Virtual CAN Tunnel)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Author: Oliver Hartkopp <socketcan@hartkopp.net>
+ * Based on: link_veth.c from Pavel Emelianov <xemul@openvz.org>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <net/if.h>
+#include <linux/can/vxcan.h>
+
+#include "utils.h"
+#include "ip_common.h"
+
+static void print_usage(FILE *f)
+{
+ printf("Usage: ip link <options> type vxcan [peer <options>]\n"
+ "To get <options> type 'ip link add help'\n");
+}
+
+static void usage(void)
+{
+ print_usage(stderr);
+}
+
+static int vxcan_parse_opt(struct link_util *lu, int argc, char **argv,
+ struct nlmsghdr *hdr)
+{
+ char *dev = NULL;
+ char *name = NULL;
+ char *link = NULL;
+ char *type = NULL;
+ int index = 0;
+ int err, len;
+ struct rtattr *data;
+ int group;
+ struct ifinfomsg *ifm, *peer_ifm;
+ unsigned int ifi_flags, ifi_change;
+
+ if (strcmp(argv[0], "peer") != 0) {
+ usage();
+ return -1;
+ }
+
+ ifm = NLMSG_DATA(hdr);
+ ifi_flags = ifm->ifi_flags;
+ ifi_change = ifm->ifi_change;
+ ifm->ifi_flags = 0;
+ ifm->ifi_change = 0;
+
+ data = NLMSG_TAIL(hdr);
+ addattr_l(hdr, 1024, VXCAN_INFO_PEER, NULL, 0);
+
+ hdr->nlmsg_len += sizeof(struct ifinfomsg);
+
+ err = iplink_parse(argc - 1, argv + 1, (struct iplink_req *)hdr,
+ &name, &type, &link, &dev, &group, &index);
+ if (err < 0)
+ return err;
+
+ if (name) {
+ len = strlen(name) + 1;
+ if (len > IFNAMSIZ)
+ invarg("\"name\" too long\n", *argv);
+ addattr_l(hdr, 1024, IFLA_IFNAME, name, len);
+ }
+
+ peer_ifm = RTA_DATA(data);
+ peer_ifm->ifi_index = index;
+ peer_ifm->ifi_flags = ifm->ifi_flags;
+ peer_ifm->ifi_change = ifm->ifi_change;
+ ifm->ifi_flags = ifi_flags;
+ ifm->ifi_change = ifi_change;
+
+ if (group != -1)
+ addattr32(hdr, 1024, IFLA_GROUP, group);
+
+ data->rta_len = (void *)NLMSG_TAIL(hdr) - (void *)data;
+ return argc - 1 - err;
+}
+
+static void vxcan_print_help(struct link_util *lu, int argc, char **argv,
+ FILE *f)
+{
+ print_usage(f);
+}
+
+struct link_util vxcan_link_util = {
+ .id = "vxcan",
+ .parse_opt = vxcan_parse_opt,
+ .print_help = vxcan_print_help,
+};
--
2.11.0
^ permalink raw reply related
* [PATCH] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain
From: Peter S. Housel @ 2017-06-02 17:22 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo,
Christian Daudt, Pieter-Paul Giesberts, Martin Blumenstingl,
Florian Fainelli, Peter S. Housel,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
An earlier change to this function (3bdae810721b) fixed a leak in the
case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the
glob_skb buffer, used for emulating a scattering read, is never used
or referenced after its contents are copied into the destination
buffers, and therefore always needs to be freed by the end of the
function.
Signed-off-by: Peter S. Housel <housel-HInyCGIudOg@public.gmane.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 9b970dc..4c5064f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -727,15 +727,16 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
return -ENOMEM;
err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
glom_skb);
- if (err) {
- brcmu_pkt_buf_free_skb(glom_skb);
- goto done;
- }
+ if (err)
+ goto free_glom_skb;
skb_queue_walk(pktq, skb) {
memcpy(skb->data, glom_skb->data, skb->len);
skb_pull(glom_skb, skb->len);
}
+
+free_glom_skb:
+ brcmu_pkt_buf_free_skb(glom_skb);
} else
err = brcmf_sdiod_sglist_rw(sdiodev, SDIO_FUNC_2, false, addr,
pktq);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH][wireless-next] qtnfmac: check band before allocating cmd_skb to avoid resource leak
From: Igor Mitsyanko @ 2017-06-02 17:32 UTC (permalink / raw)
To: Colin King, Avinash Patil, Sergey Matyukevich, Kalle Valo,
Dmitrii Lebed, Huizhao Wang, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20170602154045.28948-1-colin.king@canonical.com>
On 06/02/2017 08:40 AM, Colin King wrote:
> External Email
>
>
> From: Colin Ian King <colin.king@canonical.com>
>
> The current code allocates cmd_skb and then will leak this if band->band
> is an illegal value. It is simpler to sanity check the band first before
> allocating cmd_skb so that we don't have to free cmd_skb if an invalid
> band occurs.
>
> Detected by CoverityScan, CID#1437561 ("Resource Leak")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/wireless/quantenna/qtnfmac/commands.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c b/drivers/net/wireless/quantenna/qtnfmac/commands.c
> index f0a0cfa7d8a1..cce62f39edaf 100644
> --- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
> +++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
> @@ -1300,12 +1300,6 @@ int qtnf_cmd_get_mac_chan_info(struct qtnf_wmac *mac,
> int ret = 0;
> u8 qband;
>
> - cmd_skb = qtnf_cmd_alloc_new_cmdskb(mac->macid, 0,
> - QLINK_CMD_CHANS_INFO_GET,
> - sizeof(*cmd));
> - if (!cmd_skb)
> - return -ENOMEM;
> -
> switch (band->band) {
> case NL80211_BAND_2GHZ:
> qband = QLINK_BAND_2GHZ;
> @@ -1320,6 +1314,12 @@ int qtnf_cmd_get_mac_chan_info(struct qtnf_wmac *mac,
> return -EINVAL;
> }
>
> + cmd_skb = qtnf_cmd_alloc_new_cmdskb(mac->macid, 0,
> + QLINK_CMD_CHANS_INFO_GET,
> + sizeof(*cmd));
> + if (!cmd_skb)
> + return -ENOMEM;
> +
> cmd = (struct qlink_cmd_chans_info_get *)cmd_skb->data;
> cmd->band = qband;
> ret = qtnf_cmd_send_with_reply(mac->bus, cmd_skb, &resp_skb, &res_code,
> --
> 2.11.0
>
Reviewed-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
^ permalink raw reply
* Re: Cherry pick commit *net: better skb->sender_cpu and skb->napi_id cohabitation* to 4.4 series?
From: Cong Wang @ 2017-06-02 17:51 UTC (permalink / raw)
To: Paul Menzel
Cc: David Miller, Eric Dumazet, Linux Kernel Network Developers,
Alexei Starovoitov, it+linux-netdev, Greg Kroah-Hartman
In-Reply-To: <409abefe-62ff-563a-b5c6-a3149ae672e0@molgen.mpg.de>
On Thu, Jun 1, 2017 at 10:32 AM, Paul Menzel <pmenzel@molgen.mpg.de> wrote:
> Dear David,
>
>
> On 06/01/17 18:19, David Miller wrote:
>>
>> Neither of us have anything to do with the 4.4 -stable series. We only
>> manage stable backport submissions for the most recent two releases.
>
>
> Thank you for the prompt response. Should the netdev FAQ be updated then to
> contain that information?
+1
It is quite helpful to know which stable releases contain network fixes
which don't, especially for those who rely on stable releases, at least
we could do backport by ourselves when we know they are missing.
^ permalink raw reply
* Re: [net-next 00/14][pull request] 40GbE Intel Wired LAN Driver Updates 2017-06-01
From: David Miller @ 2017-06-02 17:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20170601213840.36286-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 1 Jun 2017 14:38:26 -0700
> This series contains updates to i40e, i40evf and the "new" AVF virtchnl.
>
> This is the introduction of the Intel(R) Ethernet Adaptive Virtual
> Function driver code and device ID, as presented at the NetDEV 1.2
> conference in 2016.
> http://netdevconf.org/1.2/session.html?anjali-singhai
>
> The idea is to convert the interface between the i40evf driver
> and the parent i40e PF driver to be generic, as the i40evf driver
> should in the future be able to run on top of other Intel PF
> drivers, and negotiate any features beyond a "base expected" set.
>
> The following are changes since commit 0266f79778de0afadd070941aae493c28529d974:
> mlxsw: spectrum: Add bridge dependency for spectrum
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Ok, doesn't look too bad.
I might have preferred if patch #11 used a compile time BUILD_BUG_ON()
of some sort in a core init function or similar. But I can understand
the desire to use a scheme that allows annotations right next to the
datastructure definitions themselves.
Pulled, th anks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] sctp: improve asoc streams management
From: David Miller @ 2017-06-02 17:56 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <cover.1496219741.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 31 May 2017 16:36:30 +0800
> This patchset changes to define asoc->stream as an object, and also
> improve some codes to make it more clearly.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt()
From: David Miller @ 2017-06-02 17:57 UTC (permalink / raw)
To: ben; +Cc: kraig, netdev
In-Reply-To: <20170531121541.GA16923@decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 31 May 2017 13:15:41 +0100
> xfrm6_find_1stfragopt() may now return an error code and we must
> not treat it as a length.
>
> Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied and queued up for -stable, thanks Ben.
^ permalink raw reply
* ethtool 4.11 released
From: John W. Linville @ 2017-06-02 17:55 UTC (permalink / raw)
To: netdev
ethtool version 4.11 has been released.
Home page: https://www.kernel.org/pub/software/network/ethtool/
Download link:
https://www.kernel.org/pub/software/network/ethtool/ethtool-4.11.tar.xz
Release notes:
* Feature: Support for configurable RSS hash function
* Feature: support queue and VF fields for rxclass filters
* Feature: Add support for 2500baseT/5000baseT link modes
* Fix: Fix SFF 8079 cable technology bit parsing
* Fix: sync help output for -x/-X with man page
John
--
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: Leak in ipv6_gso_segment()?
From: David Miller @ 2017-06-02 18:05 UTC (permalink / raw)
To: ben; +Cc: kraig, netdev
In-Reply-To: <1496233562.3992.10.camel@decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 31 May 2017 13:26:02 +0100
> If I'm not mistaken, ipv6_gso_segment() now leaks segs if
> ip6_find_1stfragopt() fails. I'm not sure whether the fix would be as
> simple as adding a kfree_skb(segs) or whether more complex cleanup is
> needed.
I think we need to use kfree_skb_list(), like the following.
Can someone please audit and review this for me? We need to
get this to -stable.
Thanks.
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 280268f..cdb3728 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -116,8 +116,10 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
if (udpfrag) {
int err = ip6_find_1stfragopt(skb, &prevhdr);
- if (err < 0)
+ if (err < 0) {
+ kfree_skb_list(segs);
return ERR_PTR(err);
+ }
fptr = (struct frag_hdr *)((u8 *)ipv6h + err);
fptr->frag_off = htons(offset);
if (skb->next)
^ permalink raw reply related
* Re: [PATCH net] cxgb4: avoid enabling napi twice to the same queue
From: David Miller @ 2017-06-02 18:06 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil
In-Reply-To: <1496235388-20496-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 31 May 2017 18:26:28 +0530
> Take uld mutex to avoid race between cxgb_up() and
> cxgb4_register_uld() to enable napi for the same uld
> queue.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: fix incorrect cim_la output for T6
From: David Miller @ 2017-06-02 18:07 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil
In-Reply-To: <1496238021-23996-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 31 May 2017 19:10:21 +0530
> take care of UpDbgLaRdPtr[0-3] restriction for T6.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> v2:
> - not using loop to increment UPDBGLARDPTR
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: davicom: dm9000: Avoid spinlock recursion during dm9000_timeout routine
From: David Miller @ 2017-06-02 18:12 UTC (permalink / raw)
To: liu.xiang6; +Cc: netdev, linux-kernel
In-Reply-To: <1496243202-3492-1-git-send-email-liu.xiang6@zte.com.cn>
From: Liu Xiang <liu.xiang6@zte.com.cn>
Date: Wed, 31 May 2017 23:06:42 +0800
> On the DM9000B, dm9000_phy_write() is called after the main spinlock
> is held, during the dm9000_timeout() routine. Spinlock recursion
> occurs because the main spinlock is requested again in
> dm9000_phy_write(). So spinlock should be avoided in dm9000_phy_write()
> during the dm9000_timeout() routine.
>
> Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn>
It think this is racy.
Now, during a timeout device reset, another thread of control can come
in and access phy registers without any synchronization whatsoever.
^ permalink raw reply
* Re: [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails
From: David Miller @ 2017-06-02 18:14 UTC (permalink / raw)
To: jani.nikula
Cc: daniel.vetter, intel-gfx, bruce.w.allan, linux-kernel,
davidx.m.ertman, intel-wired-lan, dri-devel, netdev,
jeffrey.t.kirsher
In-Reply-To: <20170531155043.3596-2-jani.nikula@intel.com>
From: Jani Nikula <jani.nikula@intel.com>
Date: Wed, 31 May 2017 18:50:43 +0300
> From: Chris Wilson <chris@chris-wilson.co.uk>
>
> An error during suspend (e100e_pm_suspend),
...
> lead to complete failure:
...
> The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
> flows"), but it may be a later patch that introduced the non-recoverable
> behaviour.
>
> Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Cc: Dave Ertman <davidx.m.ertman@intel.com>
> Cc: Bruce Allan <bruce.w.allan@intel.com>
> Cc: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> [Jani: bikeshed repainted]
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jeff, please make sure this gets submitted to me soon.
Thanks.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH net-next] liquidio: VF interrupt initialization cleanup
From: David Miller @ 2017-06-02 18:14 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
ricardo.farrington
In-Reply-To: <20170531164809.GA1497@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 31 May 2017 09:48:09 -0700
> From: Rick Farrington <ricardo.farrington@cavium.com>
>
> Set initialization state variable to (reflect interrupt initialization) at
> correct time (immediately after having configured interrupts). This fixes
> problem of inconsistent IRQ allocation in case of [obscure] failure when
> negotiating with PF driver during init.
>
> Clean-up of interrupt enablement during initialization & avoid potential
> race condition with chip-specific code (i.e. perform interrupt control in
> main driver module). Added explanatory comments regarding interrupt
> enablement.
>
> Signed-off-by: Rick Farrington <ricardo.farrington@cavium.com>
> Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next, 1/2] tools: hv: set allow-hotplug for VF on Ubuntu
From: David Miller @ 2017-06-02 18:16 UTC (permalink / raw)
To: sixiao; +Cc: netdev, kys, haiyangz, sthemmin
In-Reply-To: <1496251693-14277-1-git-send-email-sixiao@microsoft.com>
From: Simon Xiao <sixiao@microsoft.com>
Date: Wed, 31 May 2017 10:28:13 -0700
> On HyperV, the VF interface can be offered by a host at any time.
> Mark the VF interface as hotplug, to make sure it will be brought up
> automatically when it is registered.
>
> Signed-off-by: Simon Xiao <sixiao@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next, 2/2] tools: hv: set hotplug for VF on Suse
From: David Miller @ 2017-06-02 18:16 UTC (permalink / raw)
To: sixiao; +Cc: netdev, kys, haiyangz, sthemmin
In-Reply-To: <1496251707-14330-1-git-send-email-sixiao@microsoft.com>
From: Simon Xiao <sixiao@microsoft.com>
Date: Wed, 31 May 2017 10:28:27 -0700
> On HyperV, the VF interface can be offered by a host at any time.
> Mark the VF interface as hotplug, to make sure it will be brought up
> automatically when it is registered.
>
> Signed-off-by: Simon Xiao <sixiao@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: Fix checkpatch errors with references crossing single line
From: David Miller @ 2017-06-02 18:17 UTC (permalink / raw)
To: felix.manlunas; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
In-Reply-To: <20170531174515.GA1539@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 31 May 2017 10:45:15 -0700
> From: Satanand Burla <satananda.burla@cavium.com>
>
> Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
> Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] tcp: disallow cwnd undo when switching congestion control
From: David Miller @ 2017-06-02 18:18 UTC (permalink / raw)
To: ycheng; +Cc: netdev, ncardwell, edumazet, soheil
In-Reply-To: <20170531182127.161289-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 31 May 2017 11:21:27 -0700
> When the sender switches its congestion control during loss
> recovery, if the recovery is spurious then it may incorrectly
> revert cwnd and ssthresh to the older values set by a previous
> congestion control. Consider a congestion control (like BBR)
> that does not use ssthresh and keeps it infinite: the connection
> may incorrectly revert cwnd to an infinite value when switching
> from BBR to another congestion control.
>
> This patch fixes it by disallowing such cwnd undo operation
> upon switching congestion control. Note that undo_marker
> is not reset s.t. the packets that were incorrectly marked
> lost would be corrected. We only avoid undoing the cwnd in
> tcp_undo_cwnd_reduction().
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net-next] tcp: use TS opt on RTTs for congestion control
From: David Miller @ 2017-06-02 18:19 UTC (permalink / raw)
To: ycheng; +Cc: netdev, ncardwell, edumazet, soheil
In-Reply-To: <20170531183053.16602-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 31 May 2017 11:30:53 -0700
> Currently when a data packet is retransmitted, we do not compute an
> RTT sample for congestion control due to Kern's check. Therefore the
> congestion control that uses RTT signals may not receive any update
> during loss recovery which could last many round trips. For example,
> BBR and Vegas may not be able to update its min RTT estimation if the
> network path has shortened until it recovers from losses. This patch
> mitigates that by using TCP timestamp options for RTT measurement
> for congestion control. Note that we already use timestamps for
> RTT estimation.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Also applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: ethernet: stmmac: Fix altr_tse_pcs SGMII Initialization
From: David Miller @ 2017-06-02 18:20 UTC (permalink / raw)
To: thor.thayer; +Cc: peppe.cavallaro, alexandre.torgue, netdev, linux-kernel
In-Reply-To: <1496258927-5493-1-git-send-email-thor.thayer@linux.intel.com>
From: thor.thayer@linux.intel.com
Date: Wed, 31 May 2017 14:28:47 -0500
> From: Thor Thayer <thor.thayer@linux.intel.com>
>
> Fix NETDEV WATCHDOG timeout on startup by adding missing register
> writes that properly setup SGMII.
>
> Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: use of_mdio_parse_addr
From: David Miller @ 2017-06-02 18:22 UTC (permalink / raw)
To: jon.mason
Cc: andrew, f.fainelli, netdev, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1496259810-3602-1-git-send-email-jon.mason@broadcom.com>
From: Jon Mason <jon.mason@broadcom.com>
Date: Wed, 31 May 2017 15:43:30 -0400
> use of_mdio_parse_addr() in place of an OF read of reg and a bounds
> check (which is litterally the exact same thing that
> of_mdio_parse_addr() does)
>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
Applied, thanks Jon.
^ 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