net: icmp vs udp_poll race?

Hi all, On the latest linux-next I'm seeing issues that look like an icmp socket destruction racing with poll(). It manifests in two ways, first: BUG: KASAN: slab-out-of-bounds in skb_queue_empty include/linux/skbuff.h:1197 [inline] BUG: KASAN: slab-out-of-bounds in udp_poll+0x5fb/0x6f0

[PATCH net] net: dsa: Fix stale cpu_switch reference after unbind then bind

Commit 9520ed8fb841 ("net: dsa: use cpu_switch instead of ds[0]") replaced the use of dst->ds[0] with dst->cpu_switch since that is functionally equivalent, however, we can now run into an use after free scenario after unbinding then rebinding the switch driver. The use after free happens because

[PATCH v2 2/3] PCI: Enable PCIe Relaxed Ordering if supported

The PCIe Device Control Register use the bit 4 to indicate that whether the device is permitted to enable relaxed ordering or not. But relaxed ordering is not safe for some platform which could only use strong write ordering, so devices are allowed (but not required) to enable relaxed ordering bit

[PATCH v2 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

From: Casey Leedom cxgb4 Ethernet driver now queries Root Complex Port to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. Signed-off-by: Casey Leedom Signed-off-by: Ding Tianhong ---

[PATCH v2 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

From: Casey Leedom The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed Ordering Attribute should not be used on Transaction Layer Packets destined for the PCIe End Node so flagged. Initially flagged this way are Intel E5-26xx Root Complex Ports which

[PATCH v2 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Some devices have problems with Transaction Layer Packets with the Relaxed Ordering Attribute set. This patch set adds a new PCIe Device Flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known devices with Relaxed Ordering issues, and a use of this new flag by the cxgb4

[PATCH v4 net-next 0/3] bpf: Add BPF support to all perf_event

v3->v4: one more tweak to reject unsupported events at map update time as Peter suggested v2->v3: more refactoring to address Peter's feedback. Now all perf_events are attachable and readable v1->v2: address Peter's feedback. Refactor patch 1 to allow attaching bpf programs to all event types

[PATCH v4 net-next 1/3] perf, bpf: Add BPF support to all perf_event types

Allow BPF_PROG_TYPE_PERF_EVENT program types to attach to all perf_event types, including HW_CACHE, RAW, and dynamic pmu events. Only tracepoint/kprobe events are treated differently which require BPF_PROG_TYPE_TRACEPOINT/BPF_PROG_TYPE_KPROBE program types accordingly. Also add support for

[PATCH v4 net-next 2/3] samples/bpf: add tests for more perf event types

From: Teng Qin $ trace_event tests attaching BPF program to HW_CPU_CYCLES, SW_CPU_CLOCK, HW_CACHE_L1D and other events. It runs 'dd' in the background while bpf program collects user and kernel stack trace on counter overflow. User space expects to see sys_read and sys_write in

[PATCH v4 net-next 3/3] bpf: update perf event helper functions documentation

From: Teng Qin This commit updates documentation of the bpf_perf_event_output and bpf_perf_event_read helpers to match their implementation. Signed-off-by: Teng Qin Signed-off-by: Alexei Starovoitov --- include/uapi/linux/bpf.h | 11

RE: [PATCH net-next] net: phy: smsc: Implement PHY statistics

>> Just cosmetic thing. >> How about aligning with other members in structure like > >Yes, i can do that. v2 tomorrow sometime. Thanks. > >Can you confirm the LAN911x Internal PHY don't have this. The register >is not listed in the switch datasheet. > This register is NOT in LAN911x internal phy.

Re: [PATCH v2 net-next 0/8] Introduce bpf ID

On Wed, May 31, 2017 at 07:35:18PM -0400, David Miller wrote: > From: Martin KaFai Lau > Date: Wed, 31 May 2017 11:58:54 -0700 > > > This patch series: > > 1) Introduce ID for both bpf_prog and bpf_map. > > 2) Add bpf commands to iterate the prog IDs and map > >IDs of the

Re: [PATCH net-next] net: phy: smsc: Implement PHY statistics

Hi Woojung > Just cosmetic thing. > How about aligning with other members in structure like Yes, i can do that. v2 tomorrow sometime. > > + .get_sset_count = smsc_get_sset_count, > > + .get_strings = smsc_get_strings, > > + .get_stats= smsc_get_stats, > > Reviewed-By: Woojung

Re: [PATCH net-next] net: phy: smsc: Implement PHY statistics

On 06/02/2017 02:24 PM, Andrew Lunn wrote: > Most of the PHYs supported by the SMSC driver have a counter of symbol > errors. This is 16 bit wide and wraps around when it reaches its > maximum value. > > Signed-off-by: Andrew Lunn Reviewed-by: Florian Fainelli

[PATCH v3 7/7] net: pch_gbe: Allow build on MIPS platforms

Allow the pch_gbe driver to be built on MIPS platforms, in preparation for its use on the MIPS Boston board. Signed-off-by: Paul Burton Cc: David S. Miller Cc: Eric Dumazet Cc: Jarod Wilson Cc: Tobias Klauser

Re: [PATCH net-next] liquidio: Fix checkpatch errors with references crossing single line

On Fri, 2017-06-02 at 23:11 +, Chickles, Derek wrote: > > -Original Message- > > From: Joe Perches [mailto:j...@perches.com] p[ > > Subject: Re: [PATCH net-next] liquidio: Fix checkpatch errors with > > references crossing single line [] > > Did you see the patch I sent? [] > We'll

[PATCH v3 6/7] net: pch_gbe: Allow longer for resets

Resets of the EG20T MAC on the MIPS Boston development board take longer than the 1000 loops that pch_gbe_wait_clr_bit was performing. Rather than simply increasing the number of loops, switch to using readl_poll_timeout_atomic() from linux/iopoll.h in order to provide some independence from the

[PATCH v3 5/7] net: pch_gbe: Always reset PHY along with MAC

On the MIPS Boston development board, the EG20T MAC does not report receiving the RX clock from the (RGMII) RTL8211E PHY unless the PHY is reset at the same time as the MAC. Since the pch_gbe driver resets the MAC a number of times - twice during probe, and when taking down the network interface -

[PATCH v3 3/7] dt-bindings: net: Document Intel pch_gbe binding

Introduce documentation for a device tree binding for the Intel Platform Controller Hub (PCH) GigaBit Ethernet (GBE) device. Although this is a PCIe device & thus largely auto-detectable, this binding will be used to provide the driver with the PHY reset GPIO. Signed-off-by: Paul Burton

[PATCH v3 4/7] net: pch_gbe: Add device tree support

Introduce support for retrieving the PHY reset GPIO from device tree, which will be used on the MIPS Boston development board. This requires support for probe deferral in order to work correctly, since the order of device probe is not guaranteed & typically the EG20T GPIO controller device will be

[PATCH v3 2/7] net: pch_gbe: Pull PHY GPIO handling out of Minnow code

The MIPS Boston development board uses the Intel EG20T Platform Controller Hub, including its gigabit ethernet controller, and requires that its RTL8211E PHY be reset much like the Minnow platform. Pull the PHY reset GPIO handling out of Minnow-specific code such that it can be shared by later

[PATCH v3 1/7] net: pch_gbe: Mark Minnow PHY reset GPIO active low

The Minnow PHY reset GPIO is set to 0 to enter reset & 1 to leave reset - that is, it is an active low GPIO. In order to allow for the code to be made more generic by further patches, indicate to the GPIO subsystem that the GPIO is active low & invert the values it is set to such that they reflect

[PATCH v3 0/7] net: pch_gbe: Fixes & MIPS support

The Intel EG20T Platform Controller Hub is used on the MIPS Boston development board to provide various peripherals including ethernet. This series fixes some issues with the pch_gbe driver discovered whilst in use on the Boston board, and implements support for device tree which we use to provide

RE: [PATCH net-next] net: phy: smsc: Implement PHY statistics

Andrew, > static int smsc_phy_probe(struct phy_device *phydev) > { > struct device *dev = >mdio.dev; > @@ -206,6 +258,11 @@ static struct phy_driver smsc_phy_driver[] = { > .ack_interrupt = smsc_phy_ack_interrupt, > .config_intr= smsc_phy_config_intr, > > + /*

Re: loosing netdevices with namespaces and unshare?

On Wed, May 31, 2017 at 11:32 PM, Eric W. Biederman wrote: > Cong Wang writes: >> Network namespace does not special-case the physical devices, >> it treats them all equally as abstract net devices. > > Absolutely not true. > > The relevant code

RE: [PATCH net-next] liquidio: Fix checkpatch errors with references crossing single line

> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Friday, June 02, 2017 3:44 PM > To: David Miller ; Manlunas, Felix > > Cc: netdev@vger.kernel.org; Vatsavayi, Raghu ; > Chickles, Derek

Re: [PATCH net-next] liquidio: Fix checkpatch errors with references crossing single line

On Fri, 2017-06-02 at 14:17 -0400, David Miller wrote: > From: Felix Manlunas > Date: Wed, 31 May 2017 10:45:15 -0700 > > > From: Satanand Burla > > > > Signed-off-by: Satanand Burla > > Signed-off-by: Derek

[PATCH v2] brcmfmac: Fix glom_skb leak in brcmf_sdiod_recv_chain

An earlier change to this function (3bdae810721b) fixed a leak in the case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the glom_skb buffer, used for emulating a scattering read, is never used or referenced after its contents are copied into the destination buffers, and therefore

Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver

Hi, On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote: > From: Maxime Ripard > Date: Fri, 2 Jun 2017 11:13:20 +0200 > > > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote: > >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller

ath9k - Division by zero in kernel (as well as firmware panic)

ODroid XU4 $ uname -a Linux computer 4.12.0-rc3-dirty #1 SMP Wed May 31 15:02:05 CDT 2017 armv7l GNU/Linux $ lsusb ... Bus 001 Device 002: ID 2109:2813 VIA Labs, Inc. Bus 001 Device 010: ID 0cf3:7015 Qualcomm Atheros Communications TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros

Re: [PATCH][net-next] rxrpc: remove redundant proc_remove call

Colin King wrote: > From: Colin Ian King > > The proc_remove call is dead code as it occurs after a return and > hence can never be called. Remove it. > > Detected by CoverityScan, CID#1437743 ("Logically dead code") > > Signed-off-by:

Re: Cherry pick commit *net: better skb->sender_cpu and skb->napi_id cohabitation* to 4.4 series?

Dear David, On 2017-06-02 20:37, David Miller wrote: From: Cong Wang Date: Fri, 2 Jun 2017 10:51:39 -0700 On Thu, Jun 1, 2017 at 10:32 AM, Paul Menzel wrote: On 06/01/17 18:19, David Miller wrote: Neither of us have anything to do with

Re: [PATCH net-next 0/2] Fixes for mv88e6161

Hi Andrew, Andrew Lunn writes: > Testing a board with an mv88e6161 turned up two issues. The PHYs were > not found, because the wrong method to access them was used. The > statistics did not work, because the wrong snapshot method was used Thanks for testing!

Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: 6161 uses global 2 for PHY access

Andrew Lunn writes: > Access to the internal PHYs of the 6161 and 6123 go through global 2 > SMI registers. Fix the ops structure. > > Signed-off-by: Andrew Lunn Reviewed-by: Vivien Didelot

Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: mv88e6161 uses mv88e6320 stats snapshot

Andrew Lunn writes: > The mv88e6161 was using the wrong method to perform statistics > snapshot. > > Signed-off-by: Andrew Lunn Reviewed-by: Vivien Didelot

[PATCH net-next] net: phy: smsc: Implement PHY statistics

Most of the PHYs supported by the SMSC driver have a counter of symbol errors. This is 16 bit wide and wraps around when it reaches its maximum value. Signed-off-by: Andrew Lunn --- drivers/net/phy/smsc.c | 72 ++ 1 file changed,

[PATCH net-next 0/2] Fixes for mv88e6161

Testing a board with an mv88e6161 turned up two issues. The PHYs were not found, because the wrong method to access them was used. The statistics did not work, because the wrong snapshot method was used Andrew Lunn (2): net: dsa: mv88e6xxx: mv88e6161 uses global 2 for PHY access net: dsa:

[PATCH net-next 2/2] net: dsa: mv88e6xxx: mv88e6161 uses mv88e6320 stats snapshot

The mv88e6161 was using the wrong method to perform statistics snapshot. Signed-off-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx/chip.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c

[PATCH net-next 1/2] net: dsa: mv88e6xxx: 6161 uses global 2 for PHY access

Access to the internal PHYs of the 6161 and 6123 go through global 2 SMI registers. Fix the ops structure. Signed-off-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx/chip.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c

Re: [PATCH net-next 0/5] net: dsa: mv88e6xxx: move registers macros

On Fri, Jun 02, 2017 at 05:06:14PM -0400, Vivien Didelot wrote: > This patchset brings no functional changes. > > It is the first step of a cleanup renaming the chip header file and > moving the Register definitions _as is_ in their proper header files. > > A following patchset will prefix them

[PATCH net-next 4/5] net: dsa: mv88e6xxx: move the Global 1 macros

Move the GLOBAL_* macros where they belong, in the related global1.h header. Include it in global2.c which uses GLOBAL_STATUS_IRQ_DEVICE. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.h| 141

[PATCH net-next 5/5] net: dsa: mv88e6xxx: move the Global 2 macros

Move the GLOBAL2_* macros where they belong, in the related global2.h header. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.h| 101 --- drivers/net/dsa/mv88e6xxx/global2.c | 2 -

[PATCH net-next 3/5] net: dsa: mv88e6xxx: move the Port macros

Move the PORT_* macros where they belong, in the related port.h header. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.h | 160 --- drivers/net/dsa/mv88e6xxx/port.h | 160

[PATCH net-next 2/5] net: dsa: mv88e6xxx: move PHY macros

Move the PHY_* macros where they belong, in the related phy.h header. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.h | 4 drivers/net/dsa/mv88e6xxx/phy.h | 3 +++ 2 files changed, 3 insertions(+), 4 deletions(-) diff --git

[PATCH net-next 0/5] net: dsa: mv88e6xxx: move registers macros

This patchset brings no functional changes. It is the first step of a cleanup renaming the chip header file and moving the Register definitions _as is_ in their proper header files. A following patchset will prefix them with the appropriate model (MV88E6XXX_ or e.g. MV88E6390_) to respect an

[PATCH net-next 1/5] net: dsa: mv88e6xxx: rename chip header

The mv88e6xxx.h is meant to contains the chip structures and data. Rename it to chip.h, as for other source/header pairs of the driver. At the same time, ensure that relative header inclusions are separated by a newline and sorted alphabetically. Signed-off-by: Vivien Didelot

Re: [PATCH] amd-xgbe: use PAGE_ALLOC_COSTLY_ORDER in xgbe_map_rx_buffer

On 6/2/2017 10:54 AM, Michal Hocko wrote: From: Michal Hocko xgbe_map_rx_buffer is rather confused about what PAGE_ALLOC_COSTLY_ORDER means. It uses PAGE_ALLOC_COSTLY_ORDER-1 assuming that PAGE_ALLOC_COSTLY_ORDER is the first costly order which is not the case actually because

Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

On Fri, 2017-06-02 at 16:31 -0400, Jes Sorensen wrote: >  > > It is already modular like that. See CONFIG_MLX5_FPGA. > > [jes@xpeas netdev.git]$ grep CONFIG_MLX5_FPGA  > drivers/net/ethernet/mellanox/mlx5/core/* > [jes@xpeas netdev.git]$ > > Which git tree am I supposed to look at? net-next --

Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

On 05/28/2017 03:24 AM, Ilan Tayari wrote: -Original Message- From: Jes Sorensen [mailto:jsoren...@fb.com] On 05/26/2017 04:29 AM, Saeed Mahameed wrote: On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen wrote: On 05/25/2017 06:40 AM, Saeed Mahameed wrote: Hi Jes, No,

Re: [PATCH] virtio_net: lower limit on buffer size

On Fri, Jun 02, 2017 at 12:34:57PM +0300, Sergei Shtylyov wrote: > Hello! > > On 6/2/2017 2:56 AM, Michael S. Tsirkin wrote: > > >commit d85b758f72b0 "virtio_net: fix support for small rings" > >Commit d85b758f72b0 ("virtio_net: fix support for small rings") > > >was supposed to increase

Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set

On 05/28/2017 02:03 AM, Or Gerlitz wrote: On Sun, May 28, 2017 at 5:23 AM, Jes Sorensen wrote: On 05/27/2017 05:02 PM, Or Gerlitz wrote: On Sat, May 27, 2017 at 12:16 AM, Jes Sorensen wrote: This gets rid of the temporary #ifdef spaghetti

Re: [PATCH 3/3] net: dsa: Initialize all CPU and enabled ports masks in dsa_ds_parse()

Florian Fainelli writes: > There was no reason for duplicating the code that initializes > ds->enabled_port_mask in both dsa_parse_ports_dn() and > dsa_parse_ports(), instead move this to dsa_ds_parse() which is early > enough before ops->setup() has run. > > While at it,

Re: [PATCH 1/3] net: dsa: Pass dsa_port reference to ethtool setup/restore

Florian Fainelli writes: > We do not need to have a reference to a dsa_switch, instead we should > pass a reference to a CPU dsa_port, change that. This is a preliminary > change to better support multiple CPU ports. > > Signed-off-by: Florian Fainelli

Re: [PATCH 2/3] net: dsa: Consistently use dsa_port for dsa_*_port_{apply,unapply}

Florian Fainelli writes: > We have all the information we need in dsa_port, so use it instead of > repeating the same arguments over and over again. > > Suggested-by: Vivien Didelot > Signed-off-by: Florian Fainelli

[PATCH 2/3] net: dsa: Consistently use dsa_port for dsa_*_port_{apply,unapply}

We have all the information we need in dsa_port, so use it instead of repeating the same arguments over and over again. Suggested-by: Vivien Didelot Signed-off-by: Florian Fainelli --- net/dsa/dsa2.c | 90

[PATCH 3/3] net: dsa: Initialize all CPU and enabled ports masks in dsa_ds_parse()

There was no reason for duplicating the code that initializes ds->enabled_port_mask in both dsa_parse_ports_dn() and dsa_parse_ports(), instead move this to dsa_ds_parse() which is early enough before ops->setup() has run. While at it, we can now make dsa_is_cpu_port() check ds->cpu_port_mask

[PATCH 0/3] net: dsa: Cleanups before multi-CPU port

Hi all, This patch series does a bunch of cleanups before we start adding support for multiple CPU ports. Florian Fainelli (3): net: dsa: Pass dsa_port reference to ethtool setup/restore net: dsa: Consistently use dsa_port for dsa_*_port_{apply,unapply} net: dsa: Initialize all CPU and

[PATCH 1/3] net: dsa: Pass dsa_port reference to ethtool setup/restore

We do not need to have a reference to a dsa_switch, instead we should pass a reference to a CPU dsa_port, change that. This is a preliminary change to better support multiple CPU ports. Signed-off-by: Florian Fainelli --- net/dsa/dsa.c | 6 -- net/dsa/dsa2.c |

Re: Leak in ipv6_gso_segment()?

On Fri, Jun 2, 2017 at 2:25 PM, Craig Gallek wrote: > On Fri, Jun 2, 2017 at 2:05 PM, David Miller wrote: >> From: Ben Hutchings >> Date: Wed, 31 May 2017 13:26:02 +0100 >> >>> If I'm not mistaken, ipv6_gso_segment() now leaks

[PATCH net] geneve: fix needed_headroom and max_mtu for collect_metadata

Since commit 9b4437a5b870 ("geneve: Unify LWT and netdev handling.") when using COLLECT_METADATA geneve devices are created with too small of a needed_headroom and too large of a max_mtu. This is because ip_tunnel_info_af() is not valid with the device level info when using COLLECT_METADATA and we

Re: [PATCH] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain

On Fri, Jun 2, 2017 at 10:22 AM, Peter S. Housel wrote: > 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

Re: [PATCH] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain

On 06/02/2017 10:22 AM, Peter S. Housel wrote: > 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

Re: [PATCH V5 net-next] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"

Hello, On Fri, 2 Jun 2017, Sowmini Varadhan wrote: > The command > # arp -s 62.2.0.1 a:b:c:d:e:f dev eth2 > adds an entry like the following (listed by "arp -an") > ? (62.2.0.1) at 0a:0b:0c:0d:0e:0f [ether] PERM on eth2 > but the symmetric deletion command > # arp -i eth2 -d

Re: Cherry pick commit *net: better skb->sender_cpu and skb->napi_id cohabitation* to 4.4 series?

From: Cong Wang Date: Fri, 2 Jun 2017 10:51:39 -0700 > On Thu, Jun 1, 2017 at 10:32 AM, Paul Menzel 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

Re: [PATCH v2] virtio_net: lower limit on buffer size

From: "Michael S. Tsirkin" Date: Fri, 2 Jun 2017 17:54:33 +0300 > commit d85b758f72b0 ("virtio_net: fix support for small rings") > was supposed to increase the buffer size for small rings but had an > unintentional side effect of decreasing it for large rings. This seems > to

Re: [PATCH net 1/1] qlcnic: Fix tunnel offload for 82xx adapters

From: Manish Chopra Date: Fri, 2 Jun 2017 06:52:54 -0700 > Qlogic's 82xx series adapter doesn't support > tunnel offloads, driver incorrectly assumes that it is > supported and causes firmware hang while running tunnel IO. > > This patch fixes this by not advertising

Re: [net,V2] vxlan: fix use-after-free on deletion

From: Mark Bloch Date: Fri, 2 Jun 2017 03:24:08 +0300 > Adding a vxlan interface to a socket isn't symmetrical, while adding > is done in vxlan_open() the deletion is done in vxlan_dellink(). > This can cause a use-after-free error when we close the vxlan > interface before

Re: [PATCH net-next] tcp: remove unnecessary skb_reset_tail_pointer()

From: Eric Dumazet Date: Thu, 01 Jun 2017 14:18:36 -0700 > From: Eric Dumazet > > __pskb_trim_head() does not need to reset skb tail pointer. > > Also change the comments, __pskb_pull_head() does not exist. > > Signed-off-by: Eric Dumazet

Re: [PATCH net v2] ibmvnic: Remove module author mailing address

From: Thomas Falcon Date: Thu, 1 Jun 2017 15:32:34 -0500 > The original author left the project and so far has not > responded to emails sent to the listed address. > > Signed-off-by: John Allen > Signed-off-by: Thomas Falcon

Re: [PATCH net-next v2 2/2] bpf: Remove the capability check for cgroup skb eBPF program

From: Chenbo Feng Date: Wed, 31 May 2017 18:16:00 -0700 > From: Chenbo Feng > > Currently loading a cgroup skb eBPF program require a CAP_SYS_ADMIN > capability while attaching the program to a cgroup only requires the > user have CAP_NET_ADMIN

Re: Leak in ipv6_gso_segment()?

On Fri, Jun 2, 2017 at 2:05 PM, David Miller wrote: > From: Ben Hutchings > 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 >>

Re: [PATCH net-next v2 1/2] bpf: Allow CGROUP_SKB eBPF program to access sk_buff

From: Chenbo Feng Date: Wed, 31 May 2017 18:15:59 -0700 > From: Chenbo Feng > > This allows cgroup eBPF program to classify packet based on their > protocol or other detail information. Currently program need > CAP_NET_ADMIN privilege to attach a

Re: [PATCH net-next] net: phy: use of_mdio_parse_addr

From: Jon Mason 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 Applied,

Re: [PATCH] net: ethernet: stmmac: Fix altr_tse_pcs SGMII Initialization

From: thor.tha...@linux.intel.com Date: Wed, 31 May 2017 14:28:47 -0500 > From: Thor Thayer > > Fix NETDEV WATCHDOG timeout on startup by adding missing register > writes that properly setup SGMII. > > Signed-off-by: Thor Thayer

Re: [PATCH net-next] tcp: use TS opt on RTTs for congestion control

From: Yuchung Cheng 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

Re: [PATCH net] tcp: disallow cwnd undo when switching congestion control

From: Yuchung Cheng 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.

Re: [PATCH net-next] liquidio: Fix checkpatch errors with references crossing single line

From: Felix Manlunas Date: Wed, 31 May 2017 10:45:15 -0700 > From: Satanand Burla > > Signed-off-by: Satanand Burla > Signed-off-by: Derek Chickles > Signed-off-by: Felix Manlunas

Re: [PATCH net-next, 2/2] tools: hv: set hotplug for VF on Suse

From: Simon Xiao 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

Re: [PATCH net-next, 1/2] tools: hv: set allow-hotplug for VF on Ubuntu

From: Simon Xiao 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

Re: [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

From: Jani Nikula Date: Wed, 31 May 2017 18:50:43 +0300 > From: Chris Wilson > > An error during suspend (e100e_pm_suspend), ... > lead to complete failure: ... > The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM >

Re: [PATCH net-next] liquidio: VF interrupt initialization cleanup

From: Felix Manlunas Date: Wed, 31 May 2017 09:48:09 -0700 > From: Rick Farrington > > Set initialization state variable to (reflect interrupt initialization) at > correct time (immediately after having configured interrupts). This

Re: [PATCH] net: davicom: dm9000: Avoid spinlock recursion during dm9000_timeout routine

From: Liu Xiang 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

Re: [PATCH net-next] cxgb4: fix incorrect cim_la output for T6

From: Ganesh Goudar Date: Wed, 31 May 2017 19:10:21 +0530 > take care of UpDbgLaRdPtr[0-3] restriction for T6. > > Signed-off-by: Ganesh Goudar > --- > v2: > - not using loop to increment UPDBGLARDPTR Applied, thank you.

Re: [PATCH net] cxgb4: avoid enabling napi twice to the same queue

From: Ganesh Goudar 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 Applied and queued up for -stable,

Re: Leak in ipv6_gso_segment()?

From: Ben Hutchings 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.

ethtool 4.11 released

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

Re: [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt()

From: Ben Hutchings 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

Re: [PATCH net-next 0/2] sctp: improve asoc streams management

From: Xin Long 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.

Re: [net-next 00/14][pull request] 40GbE Intel Wired LAN Driver Updates 2017-06-01

From: Jeff Kirsher 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

Re: Cherry pick commit *net: better skb->sender_cpu and skb->napi_id cohabitation* to 4.4 series?

On Thu, Jun 1, 2017 at 10:32 AM, Paul Menzel 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

[PATCH] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain

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

Re: [PATCH][wireless-next] qtnfmac: check band before allocating cmd_skb to avoid resource leak

On 06/02/2017 08:40 AM, Colin King wrote: External Email From: Colin Ian King 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

[PATCH] ip: link add vxcan support

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 ---

Re: [pull request][for-next 0/6] Mellanox mlx5 updates 2017-05-23

On Fri, Jun 02, 2017 at 12:08:39PM -0400, David Miller wrote: > From: Alexei Starovoitov > 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:

Re: [PATCH][V2] net: phy: marvell: make some functions static

On 06/02/2017 07:13 AM, Colin King wrote: > From: Colin Ian King > > 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

[PATCH net] sock: reset sk_err when the error queue is empty

From: Soheil Hassas Yeganeh 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

Re: [pull request][for-next 0/6] Mellanox mlx5 updates 2017-05-23

From: Alexei Starovoitov 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:

Re: [pull request][for-next 0/6] Mellanox mlx5 updates 2017-05-23

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 > > > Date: Tue, 23 May 2017 14:43:58 +0300 > > > > > > > Hi

[PATCH V5 net-next] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"

The command # arp -s 62.2.0.1 a:b:c:d:e:f dev eth2 adds an entry like the following (listed by "arp -an") ? (62.2.0.1) at 0a:0b:0c:0d:0e:0f [ether] PERM on eth2 but the symmetric deletion command # arp -i eth2 -d 62.2.0.1 does not remove the PERM entry from the table, and instead leaves

[PATCH] amd-xgbe: use PAGE_ALLOC_COSTLY_ORDER in xgbe_map_rx_buffer

From: Michal Hocko xgbe_map_rx_buffer is rather confused about what PAGE_ALLOC_COSTLY_ORDER means. It uses PAGE_ALLOC_COSTLY_ORDER-1 assuming that PAGE_ALLOC_COSTLY_ORDER is the first costly order which is not the case actually because orders larger than that are costly. And

  1   2   >