Re: [PATCH 00/47] arch-removal: device drivers

Hi Arnd, On Wed, 14 Mar 2018 16:35:13 +0100 Arnd Bergmann wrote: > Hi driver maintainers, > > I just posted one series with the removal of eight architectures, > see https://lkml.org/lkml/2018/3/14/505 for details, or > https://lwn.net/Articles/748074/ for more background. > >

[no subject]

Hi Netdev https://goo.gl/UjB6a9 Avery

Re: [PATCH v2 net] net: sched: fix uses after free

On 03/14/2018 08:10 PM, John Fastabend wrote: > On 03/14/2018 06:53 PM, Eric Dumazet wrote: >> syzbot reported one use-after-free in pfifo_fast_enqueue() [1] >> >> Issue here is that we can not reuse skb after a successful >> skb_array_produce() >> since another cpu might have consumed it

Re: [PATCH 06/47] net: smsc: remove m32r specific smc91x configuration

On Wed, 14 Mar 2018, Nicolas Pitre wrote: > On Wed, 14 Mar 2018, Arnd Bergmann wrote: > > > The m32r architecture is getting removed, so this part can be > > cleaned up as well. > > > > Signed-off-by: Arnd Bergmann > > Acked-by: Nicolas Pitre > > > --- > >

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On Wed, Mar 14, 2018 at 05:17:54PM -0700, Eric Dumazet wrote: > > > On 03/14/2018 11:41 AM, Alexei Starovoitov wrote: > > On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov > > wrote: > >> > >>> It seems this is exactly the case where a netns would be the correct

Re: [PATCH v2 iproute2-next 0/6] cm_id, cq, mr, and pd resource tracking

On Wed, Mar 14, 2018 at 08:14:53PM -0700, David Ahern wrote: > On 3/13/18 2:13 PM, Jason Gunthorpe wrote: > > Could you pull the uapi headers from linux-next? That tree will have > > both netdev and rdma stuff merged together properly. > > What's the merge history between linux-next, Linus' tree,

Re: [PATCH v2 iproute2-next 0/6] cm_id, cq, mr, and pd resource tracking

On 3/13/18 2:13 PM, Jason Gunthorpe wrote: > Could you pull the uapi headers from linux-next? That tree will have > both netdev and rdma stuff merged together properly. What's the merge history between linux-next, Linus' tree, net-next + rdma-next?

Re: [PATCH v2 net] net: sched: fix uses after free

On 03/14/2018 06:53 PM, Eric Dumazet wrote: > syzbot reported one use-after-free in pfifo_fast_enqueue() [1] > > Issue here is that we can not reuse skb after a successful skb_array_produce() > since another cpu might have consumed it already. > > I believe a similar problem exists in

[PATCH] mlx5: Remove call to ida_pre_get

From: Matthew Wilcox The mlx5 driver calls ida_pre_get() in a loop for no readily apparent reason. The driver uses ida_simple_get() which will call ida_pre_get() by itself and there's no need to use ida_pre_get() unless using ida_get_new(). Signed-off-by: Matthew Wilcox

[PATCH v2] rsi: Remove stack VLA usage

The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug (kernel Oops) or a security flaw (overwriting memory beyond the stack). Also, in general, as code evolves it is easy to lose track of how big a VLA can get.

Re: [PATCH 2/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On Wed, Mar 14, 2018 at 05:26:24PM -0500, Grygorii Strashko wrote: > Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per > one netdevice, as result such drivers will produce warning during system > boot and fail to connect second phy to netdevice when PHYLIB framework >

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

On 3/14/2018 9:44 PM, Alexander Duyck wrote: > On Wed, Mar 14, 2018 at 3:57 PM, Sinan Kaya wrote: >> Hi Alexander, >> >> On 3/14/2018 5:49 PM, Alexander Duyck wrote: >>> On Wed, Mar 14, 2018 at 5:13 AM, wrote: On 2018-03-14 01:08, Timur Tabi

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: net/ipv4/xfrm4_policy.c between commit: d52e5a7e7ca4 ("ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu") from the net tree and commit: 68e813aa4307 ("net/ipv4: Remove fib table id from

Re: [PATCH net] net: sched: fix uses after free

On Wed, Mar 14, 2018 at 6:48 PM Eric Dumazet wrote: > syzbot reported one use-after-free in pfifo_fast_enqueue() [1] > Issue here is that we can not reuse skb after a successful skb_array_produce() > since another cpu might have consumed it already. > I believe a similar

Re: [PATCH 1/7] i40e/i40evf: Eliminate duplicate barriers on weakly-ordered archs

On Tue, Mar 13, 2018 at 8:19 PM, Sinan Kaya wrote: > Code includes wmb() followed by writel(). writel() already has a barrier > on some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register write. > > Since code

[PATCH v2 net] net: sched: fix uses after free

syzbot reported one use-after-free in pfifo_fast_enqueue() [1] Issue here is that we can not reuse skb after a successful skb_array_produce() since another cpu might have consumed it already. I believe a similar problem exists in try_bulk_dequeue_skb_slow() in case we put an skb into

Re: [PATCH 5/7] igb: eliminate duplicate barriers on weakly-ordered archs

On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote: > Code includes wmb() followed by writel(). writel() already has a barrier > on some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register write. > > Since code

Re: [PATCH 4/7] igbvf: eliminate duplicate barriers on weakly-ordered archs

On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote: > Code includes wmb() followed by writel(). writel() already has a barrier > on some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register write. > > Since code

[PATCH net] net: sched: fix uses after free

syzbot reported one use-after-free in pfifo_fast_enqueue() [1] Issue here is that we can not reuse skb after a successful skb_array_produce() since another cpu might have consumed it already. I believe a similar problem exists in try_bulk_dequeue_skb_slow() in case we put an skb into

Re: [PATCH 2/7] ixgbe: eliminate duplicate barriers on weakly-ordered archs

On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote: > Code includes wmb() followed by writel() in multiple places. writel() > already has a barrier on some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote: > Code includes wmb() followed by writel() in multiple places. writel() > already has a barrier on some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

On Wed, Mar 14, 2018 at 3:57 PM, Sinan Kaya wrote: > Hi Alexander, > > On 3/14/2018 5:49 PM, Alexander Duyck wrote: >> On Wed, Mar 14, 2018 at 5:13 AM, wrote: >>> On 2018-03-14 01:08, Timur Tabi wrote: On 3/13/18 10:20 PM, Sinan Kaya wrote:

Re: [PATCH 6/7] e1000: eliminate duplicate barriers on weakly-ordered archs

On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote: > Code includes wmb() followed by writel(). writel() already has a barrier > on some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register write. > > Since code

Re: [PATCH net-next v2 0/4] net: qualcomm: rmnet: Updates 2018-03-12

From: Subash Abhinov Kasiviswanathan Date: Wed, 14 Mar 2018 13:27:41 -0600 >> Please address Joe's feedback and only update the copyright date on >> files that actually had changes this year. >> Thank you. > > Hi David > > I have fixed that now in v3. > However,

Re: KASAN: use-after-free Read in pfifo_fast_enqueue

On 03/14/2018 05:16 PM, Eric Dumazet wrote: > > typical use after free... > > diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c > index > 190570f21b208d5a17943360a3a6f85e1c2a2187..663e016491773f40f81d9bbfeab3dd68e1c2fc5c > 100644 > --- a/net/sched/sch_generic.c > +++

Re: [PATCH bpf-next v6 0/2] bpf stackmap with build_id+offset

> On Mar 14, 2018, at 5:29 PM, Daniel Borkmann wrote: > > On 03/14/2018 06:23 PM, Song Liu wrote: >> Changes v4 -> v6: >> >> 1. When kernel stack is added to stackmap with build_id, use fallback >> mechanism to store ip (status == BPF_STACK_BUILD_ID_IP). >> >> Changes

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On 3/14/18 4:27 PM, Daniel Borkmann wrote: On 03/14/2018 07:11 PM, Alexei Starovoitov wrote: On Wed, Mar 14, 2018 at 03:37:01PM +0100, Daniel Borkmann wrote: --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -133,6 +133,8 @@ enum bpf_prog_type { BPF_PROG_TYPE_SOCK_OPS,

Re: [PATCH bpf-next v6 0/2] bpf stackmap with build_id+offset

On 03/14/2018 06:23 PM, Song Liu wrote: > Changes v4 -> v6: > > 1. When kernel stack is added to stackmap with build_id, use fallback >mechanism to store ip (status == BPF_STACK_BUILD_ID_IP). > > Changes v4 -> v5: > > 1. Only allow build_id lookup in non-nmi context. Added comment and >

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On 03/14/2018 11:41 AM, Alexei Starovoitov wrote: > On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov > wrote: >> >>> It seems this is exactly the case where a netns would be the correct answer. >> >> Unfortuantely that's not the case. That's what I tried to

Re: KASAN: use-after-free Read in pfifo_fast_enqueue

On 03/14/2018 04:30 PM, syzbot wrote: > syzbot has found reproducer for the following crash on net-next commit > a870a02cc963de35452bbed932560ed69725c4f2 (Tue Mar 13 20:58:39 2018 +) > pktgen: use dynamic allocation for debug print buffer > > So far this crash happened 7 times on mmots,

[PATCH] netns: send uevent messages

This patch adds a receive method to NETLINK_KOBJECT_UEVENT netlink sockets to allow sending uevent messages into the network namespace the socket belongs to. Currently non-initial network namespaces are already isolated and don't receive uevents. There are a number of cases where it is beneficial

Re: [PATCH RFC 5/7] net: phy: make phy_stop synchronous

On 03/14/2018 01:16 PM, Heiner Kallweit wrote: > Currently phy_stop() just sets the state to PHY_HALTED and relies on the > state machine to do the remaining work. It can take up to 1s until the > state machine runs again what causes issues in situations where e.g. > driver / device is brought

Re: [PATCH RFC 0/7] net: phy: patch series aiming to improve few aspects of phylib

On 03/14/2018 01:10 PM, Heiner Kallweit wrote: > This patch series aims to tackle few issues with phylib: > > - address issues with patch series [1] (smsc911x + phylib changes) > - make phy_stop synchronous > - get rid of phy_start/stop_machine and handle it in phy_start/phy_stop > - in

Re: [PATCH RFC 3/7] net: phy: resume PHY only if needed in, mdio_bus_phy_suspend

On 03/14/2018 01:16 PM, Heiner Kallweit wrote: > Currently the PHY is unconditionally resumed in mdio_bus_phy_suspend(). > In cases where the PHY was sleepinh before suspending or if somebody else > takes care of resuming later, this is not needed and wastes energy. > > Also start the state

Re: [PATCH v6 0/6] staging: Introduce DPAA2 Ethernet Switch driver

On Wed, Mar 14, 2018 at 10:55:52AM -0500, Razvan Stefanescu wrote: > This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs > with DPAA2 (DataPath Acceleration Architecture v2). The driver manages > switch objects discovered on the fsl-mc bus. A description of the driver > can

Re: [PATCH net-next v2 0/2] skbuff: Fix applications not being woken for errors

On Wed, Mar 14, 2018 at 02:54:35PM -0700, Vinicius Costa Gomes wrote: > Hi, > > Changes from v1: > - Fixed comments from Willem de Bruijn, about the order of the > options passed to getopt(); > - Added Reviewed-by and Fixes tags to patch (2); > > Changes from the RFC: > - tweaked commit

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On 03/14/2018 07:11 PM, Alexei Starovoitov wrote: > On Wed, Mar 14, 2018 at 03:37:01PM +0100, Daniel Borkmann wrote: >>> --- a/include/uapi/linux/bpf.h >>> +++ b/include/uapi/linux/bpf.h >>> @@ -133,6 +133,8 @@ enum bpf_prog_type { >>> BPF_PROG_TYPE_SOCK_OPS, >>> BPF_PROG_TYPE_SK_SKB, >>>

Re: [PATCH] lan78xx: Connect phy early

> @@ -2082,8 +2082,6 @@ static int lan78xx_phy_init(struct lan78xx_net *dev) > > dev->fc_autoneg = phydev->autoneg; > > - phy_start(phydev); > - > netif_dbg(dev, ifup, dev->net, "phy initialised successfully"); > > return 0; > @@ -2512,9 +2510,7 @@ static int

[PATCH net-next] liquidio: Allow RX descriptors to be consumed before disabling NAPI.

From: Raghu Vatsavayi Signed-off-by: Raghu Vatsavayi Acked-by: Derek Chickles Signed-off-by: Felix Manlunas --- drivers/net/ethernet/cavium/liquidio/lio_core.c| 23

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

Hi Alexander, On 3/14/2018 5:49 PM, Alexander Duyck wrote: > On Wed, Mar 14, 2018 at 5:13 AM, wrote: >> On 2018-03-14 01:08, Timur Tabi wrote: >>> >>> On 3/13/18 10:20 PM, Sinan Kaya wrote: > Actually I would argue this whole patch set is pointless. For starters > why is

Re: regression: ti: cpsw: warning from phy_connect()->sysfs_create_link()-sysfs_warn_dup()

> I've got additional testing data and this actually a *regression*, because > second CPSW Port became broken after above commits due to Net PHY > connection failure. Hi Grygorii I'm not sure this works by design, more by chance. And i think this is the only MAC driver which does this. Can i

Re: [PATCH net] net/sched: act_simple: don't leak 'index' in the error path

hello Cong, thank you for reviewing this. On Wed, 2018-03-14 at 11:41 -0700, Cong Wang wrote: > On Tue, Mar 13, 2018 at 7:13 PM, Davide Caratti wrote: > > Looks like we just need to replace the tcf_idr_cleanup() with > tcf_idr_release()? Which is also simpler. I just tried

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 2018-03-14 16:08, Kalle Valo wrote: Arend van Spriel writes: On 3/14/2018 3:24 PM, Kalle Valo wrote: +config BRCMFMAC_IAPP >+ bool "Partial support for obsoleted Inter-Access Point Protocol" >+ depends on BRCMFMAC >+ ---help--- >+ Most of Broadcom's

[PATCH 1/2] sysfs: symlink: export sysfs_create_link_nowarn()

The sysfs_create_link_nowarn() is going to be used in phylib framework in suseuent patch which can be built as module. Hence, export sysfs_create_link_nowarn() to avoid build errors. Cc: Florian Fainelli Fixes: a3995460491d ("net: phy: Relax error checking on

[PATCH 2/2] net: phy: relax error checking when creating sysfs link netdev->phydev

Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per one netdevice, as result such drivers will produce warning during system boot and fail to connect second phy to netdevice when PHYLIB framework will try to create sysfs link netdev->phydev for second PHY in

[PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per one netdevice, as result such drivers will produce warning during system boot and fail to connect second phy to netdevice when PHYLIB framework will try to create sysfs link netdev->phydev for second PHY in

Re: [Intel-wired-lan] [PATCH 02/15] ice: Add support for control queues

On Mon, 2018-03-12 at 19:05 -0700, Shannon Nelson wrote: > On 3/9/2018 9:21 AM, Anirudh Venkataramanan wrote: > > A control queue is a hardware interface which is used by the driver > > to interact with other subsystems (like firmware, PHY, etc.). It is > > implemented as a producer-consumer ring.

Re: [Intel-wired-lan] [PATCH 03/15] ice: Start hardware initialization

On Mon, 2018-03-12 at 19:05 -0700, Shannon Nelson wrote: > On 3/9/2018 9:21 AM, Anirudh Venkataramanan wrote: > > This patch implements multiple pieces of the initialization flow > > as follows: > > > > 1) A reset is issued to ensure a clean device state, followed > > by initialization of

[PATCH net-next v2 2/2] skbuff: Fix not waking applications when errors are enqueued

When errors are enqueued to the error queue via sock_queue_err_skb() function, it is possible that the waiting application is not notified. Calling 'sk->sk_data_ready()' would not notify applications that selected only POLLERR events in poll() (for example). Fixes: 1da177e4c3f4

[PATCH net-next v2 1/2] selftests/txtimestamp: Add more configurable parameters

Add a way to configure if poll() should wait forever for an event, the number of packets that should be sent for each and if there should be any delay between packets. Signed-off-by: Vinicius Costa Gomes --- .../selftests/networking/timestamping/txtimestamp.c | 21

[PATCH net-next v2 0/2] skbuff: Fix applications not being woken for errors

Hi, Changes from v1: - Fixed comments from Willem de Bruijn, about the order of the options passed to getopt(); - Added Reviewed-by and Fixes tags to patch (2); Changes from the RFC: - tweaked commit messages; Original cover letter: This is actually a "bug report"-RFC instead of the more

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

On Wed, Mar 14, 2018 at 5:13 AM, wrote: > On 2018-03-14 01:08, Timur Tabi wrote: >> >> On 3/13/18 10:20 PM, Sinan Kaya wrote: >>> >>> +/* Assumes caller has executed a write barrier to order memory and >>> device >>> + * requests. >>> + */ >>> static inline void

Re: WARNING in __local_bh_enable_ip (2)

On (03/14/18 14:28), Eric Dumazet wrote: > > > spin_lock_bh(_tcp_conn_lock);/spin_unlock_bh(_tcp_conn_lock); in > rds_tcp_conn_free() > > is in conflict with the spin_lock_irqsave(_conn_lock, flags); > in __rds_conn_create() yes I was going to look into this and fix it later. > Hard to

[PATCH v2] vhost: add vsock compat ioctl

This will allow usage of vsock from 32-bit binaries on a 64-bit kernel. Signed-off-by: Sonny Rao --- drivers/vhost/vsock.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c index 0d14e2ff19f16..ee0c385d9fe54

Re: WARNING in __local_bh_enable_ip (2)

On 03/14/2018 01:11 PM, syzbot wrote: Hello, syzbot hit the following crash on net-next commit be9fc0971a5c27b791608cf9705a04fe96dbd395 (Tue Mar 13 11:44:53 2018 +) net: fix sysctl_fb_tunnels_only_for_init_net link error So far this crash happened 2 times on net-next. Unfortunately, I

[PATCH] net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred

If the optional regulator is deferrred, we must release some resources. They will be re-allocated when the probe function will be called again. Fixes: 6eacf31139bf ("ethernet: arc: Add support for Rockchip SoC layer device tree bindings") Signed-off-by: Christophe JAILLET

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 3/14/2018 5:10 PM, Kalle Valo wrote: Rafał Miłecki writes: + unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN; +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) #ifndef? I followed what is used in the include/linux/etherdevice.h. Is that a good

Re: sctp: use proc_remove_subtree()

On Wed, Mar 14, 2018 at 08:46:21PM +, Al Viro wrote: > use proc_remove_subtree() for subtree removal, both on setup failure > halfway through and on teardown. No need to make simple things > complex... ... and sctp_dbg_objcnt_exit() can be removed as well - remove_proc_subtree() will get

sctp: use proc_remove_subtree()

use proc_remove_subtree() for subtree removal, both on setup failure halfway through and on teardown. No need to make simple things complex... Signed-off-by: Al Viro --- include/net/sctp/sctp.h | 9 + net/sctp/proc.c | 90

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 3/14/2018 4:57 PM, Rafał Miłecki wrote: On 2018-03-14 16:39, Rafał Miłecki wrote: On 2018-03-14 13:58, Arend van Spriel wrote: On 3/14/2018 12:01 PM, Rafał Miłecki wrote: From: Rafał Miłecki Testing brcmfmac with more recent firmwares resulted in AP interfaces not

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 2018-03-14 16:39, Rafał Miłecki wrote: On 2018-03-14 13:58, Arend van Spriel wrote: On 3/14/2018 12:01 PM, Rafał Miłecki wrote: From: Rafał Miłecki Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging

[net-next 2/9] i40evf/i40evf_main: Fix variable assignment in i40evf_parse_cls_flower

From: Gustavo A R Silva It seems this is a copy-paste error and that the proper variable to use in this particular case is _src_ instead of _dst_. Addresses-Coverity-ID: 1465282 ("Copy-paste error") Fixes: 0075fa0fadd0 ("i40evf: Add support to apply cloud filters")

[net-next 5/9] i40e: Fix permission check for VF MAC filters

From: Filip Sadowski When VF requests adding of MAC filters the checking is done against number of already present MAC filters not adding them at the same time. It makes it possible to add a bunch of filters at once possibly exceeding acceptable limit of

[net-next 0/9][pull request] 40GbE Intel Wired LAN Driver Updates 2018-03-14

This series contains updates to i40e and i40evf only. Corentin Labbe cleans up the left over FCoE files in the i40e driver. Gustavo A R Silva fixes a cut and paste error. Paweł fixes a race condition when the VF driver is loaded on a host and virsh is trying to attach it to the virtual machine

[net-next 6/9] i40e: track filter type statistics when deleting invalid filters

From: Jacob Keller When hardware has trouble with a particular filter, we delete it from the list. Unfortunately, we did not properly update the per-filter statistic when doing so. Create a helper function to handle this, and properly reduce the necessary counter so

[net-next 1/9] i40e: remove i40e_fcoe files

From: Corentin Labbe i40e_fcoe support was removed via commit 9eed69a9147c ("i40e: Drop FCoE code from core driver files") But this left files in place but un-compilable. Let's finish the cleaning. Signed-off-by: Corentin Labbe Tested-by: Andrew

[net-next 3/9] i40e: Fix attach VF to VM issue

From: Paweł Jabłoński Fix for "Resource temporarily unavailable" problem when virsh is trying to attach a device to VM. When the VF driver is loaded on host and virsh is trying to attach it to the VM and set a MAC address, it ends with a race condition between

[net-next 7/9] i40e: factor out re-enable functions for ATR and SB

From: Jacob Keller A future patch needs to expand on the logic for re-enabling ATR. Doing so would cause some code to break the 80-character line limit. To reduce the level of indentation, factor out helper functions for re-enabling ATR and SB rules. Signed-off-by:

[net-next 9/9] i40e: restore TCPv4 input set when re-enabling ATR

From: Jacob Keller When we re-enable ATR we need to restore the input set for TCPv4 filters, in order for ATR to function correctly. We already do this for the normal case of re-enabling ATR when disabling ntuple support. However, when re-enabling ATR after the last

[net-next 8/9] i40e: fix for wrong partition id calculation on OCP mezz cards

From: Mariusz Stachura This patch overwrites number of ports for X722 devices with support for OCP PHY mezzanine. The old method with checking if port is disabled in the PRTGEN_CNF register cannot be used in this case. When the OCP is removed, ports were seen as

[net-next 4/9] i40e: Cleanup i40e_vlan_rx_register

From: Jacob Keller We used to use the function i40e_vlan_rx_register as a way to hook into the now defunct .ndo_vlan_rx_register netdev hook. This was removed but we kept the function around because we still used it internally to control enabling or disabling of VLAN

Re: [PATCH] vhost: add vsock compat ioctl

On Wed, Mar 14, 2018 at 12:05 PM, Michael S. Tsirkin wrote: > On Wed, Mar 14, 2018 at 10:26:05AM -0700, Sonny Rao wrote: >> This will allow usage of vsock from 32-bit binaries on a 64-bit >> kernel. >> >> Signed-off-by: Sonny Rao > > I think you need to

[PATCH net] skbuff: Fix not waking applications when errors are enqueued

When errors are enqueued to the error queue via sock_queue_err_skb() function, it is possible that the waiting application is not notified. Calling 'sk->sk_data_ready()' would not notify applications that selected only POLLERR events in poll() (for example). Fixes: 1da177e4c3f4

Re: [PATCH iproute2] Revert "iproute: "list/flush/save default" selected all of the routes"

Hello, For example, it can be fixed in such way (patch is below): - split handling of default and all/any - set needed attributes in get_addr: PREFIXLEN_SPECIFIED flag for default - and AF_UNSPEC for all/any In this case "ip route show default" shows only default route and "ip route show all"

Re: regression: ti: cpsw: warning from phy_connect()->sysfs_create_link()-sysfs_warn_dup()

On 03/14/2018 02:50 PM, Florian Fainelli wrote: > On 03/14/2018 12:40 PM, Grygorii Strashko wrote: >> >> >> On 02/26/2018 02:16 PM, Florian Fainelli wrote: >>> On 02/26/2018 12:08 PM, Grygorii Strashko wrote: Hi Florian, The TI CPSW driver produces warning as below when booted in

Re: [RESEND] rsi: Remove stack VLA usage

On Wed, Mar 14, 2018 at 11:19:53AM +0200, Kalle Valo wrote: > "Tobin C. Harding" writes: > > > Added Konstantin in case he is in charge of administering > > patchwork.kernel.org? > > > > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote: > >> On Tue, Mar 13, 2018 at 7:11

[PATCH RFC 3/7] net: phy: resume PHY only if needed in, mdio_bus_phy_suspend

Currently the PHY is unconditionally resumed in mdio_bus_phy_suspend(). In cases where the PHY was sleepinh before suspending or if somebody else takes care of resuming later, this is not needed and wastes energy. Also start the state machine only if it's used by the driver (indicated by the

[PATCH RFC 2/7] net: phy: improve checking for when PHY is allowed to, suspend

This patch improves and unifies checking for when PHY is allowed to suspend. New is a check for the parent of the MDIO bus being runtime-suspended. In this case the MDIO bus may not be accessible and therefore we don't try to suspend the PHY. Instead we rely on the parent to suspend all devices on

[PATCH RFC 5/7] net: phy: make phy_stop synchronous

Currently phy_stop() just sets the state to PHY_HALTED and relies on the state machine to do the remaining work. It can take up to 1s until the state machine runs again what causes issues in situations where e.g. driver / device is brought down directly after executing phy_stop(). Fix this by

[PATCH RFC 7/7] net: phy: remove phy_stop_machine

Now that the functionality of phy_stop() was integrated to __phy_stop() we can remove phy_stop_machine(). Signed-off-by: Heiner Kallweit --- drivers/net/phy/phy.c| 18 -- drivers/net/phy/phy_device.c | 2 -- include/linux/phy.h | 1 - 3

[PATCH net] netlink: avoid a double skb free in genlmsg_mcast()

nlmsg_multicast() consumes always the skb, thus the original skb must be freed only when this function is called with a clone. Fixes: cb9f7a9a5c96 ("netlink: ensure to loop over all netns in genlmsg_multicast_allns()") Reported-by: Ben Hutchings Signed-off-by:

[PATCH RFC 6/7] net: phy: use new function phy_stop_suspending in, mdio_bus_phy_suspend

Use new function phy_stop_suspending() in mdio_bus_phy_suspend() to also disable interrupts and set link state to down. Signed-off-by: Heiner Kallweit --- drivers/net/phy/phy_device.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

[PATCH RFC 4/7] net: phy: remove phy_start_machine

Now that phy_start() integrated the functionality of phy_start_machine() we can remove it. Signed-off-by: Heiner Kallweit --- drivers/net/phy/phy.c| 16 drivers/net/phy/phy_device.c | 1 - drivers/net/phy/phylink.c| 1 - include/linux/phy.h

[PATCH RFC 1/7] net: phy: unconditionally resume and re-enable interrupts, in phy_start

In subsequent patches of this series interrupts will be disabled during system suspend, also we will have to resume the PHY in states other than PHY_HALTED. To prepare for this unconditionally resume and re-enable interrupts in phy_start(). Signed-off-by: Heiner Kallweit

[PATCH RFC 0/7] net: phy: patch series aiming to improve few aspects of phylib

This patch series aims to tackle few issues with phylib: - address issues with patch series [1] (smsc911x + phylib changes) - make phy_stop synchronous - get rid of phy_start/stop_machine and handle it in phy_start/phy_stop - in mdio_suspend consider runtime pm state of mdio bus parent -

RE: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC address support for ethtool nftuple filters

Hi, "Brown, Aaron F" writes: >> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On >> Behalf Of Vinicius Costa Gomes >> Sent: Wednesday, March 7, 2018 4:37 PM >> To: intel-wired-...@lists.osuosl.org >> Cc: netdev@vger.kernel.org; Sanchez-Palencia,

Re: regression: ti: cpsw: warning from phy_connect()->sysfs_create_link()-sysfs_warn_dup()

On 03/14/2018 12:40 PM, Grygorii Strashko wrote: > > > On 02/26/2018 02:16 PM, Florian Fainelli wrote: >> On 02/26/2018 12:08 PM, Grygorii Strashko wrote: >>> Hi Florian, >>> >>> The TI CPSW driver produces warning as below when booted in switch mode: >>> [8.882295] sysfs: cannot create

Re: [PATCH net-next 1/5] sctp: add refcnt support for sh_key

On Thu, Mar 15, 2018 at 12:12:32AM +0800, Xin Long wrote: > On Wed, Mar 14, 2018 at 9:59 PM, Neil Horman wrote: > > On Wed, Mar 14, 2018 at 07:05:30PM +0800, Xin Long wrote: > >> With refcnt support for sh_key, chunks auth sh_keys can be decided > >> before enqueuing it.

Re: regression: ti: cpsw: warning from phy_connect()->sysfs_create_link()-sysfs_warn_dup()

On 02/26/2018 02:16 PM, Florian Fainelli wrote: > On 02/26/2018 12:08 PM, Grygorii Strashko wrote: >> Hi Florian, >> >> The TI CPSW driver produces warning as below when booted in switch mode: >> [8.882295] sysfs: cannot create duplicate filename >>

Re: [PATCH net-next 0/2] skbuff: Fix applications not being woken for errors

Hi, Willem de Bruijn writes: >> Another interesting fact is that if the POLLIN event is added to the >> poll() .events, poll() no longer becomes stuck, > > The process has registered interest only in POLLIN, which the call to > sk_data_read (sock_def_readable)

Re: [PATCH net-next v2 0/4] net: qualcomm: rmnet: Updates 2018-03-12

Please address Joe's feedback and only update the copyright date on files that actually had changes this year. Thank you. Hi David I have fixed that now in v3. However, patchwork is not showing the entire series. It shows only the first patch for some reason even if I search with me as

[PATCH net-next 2/2] net: Use rtnl_lock_killable() in register_netdev()

This patch adds rtnl_lock_killable() to one of hot path using rtnl_lock(). Signed-off-by: Kirill Tkhai --- net/core/dev.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 12a9aad0b057..d8887cc38e7b 100644 ---

[PATCH net-next 0/2] Introduce rtnl_lock_killable()

rtnl_lock() is widely used mutex in kernel. Some of kernel code does memory allocations under it. In case of memory deficit this may invoke OOM killer, but the problem is a killed task can't exit if it's waiting for the mutex. This may be a reason of deadlock and panic. This patchset adds a new

[PATCH net-next 1/2] net: Add rtnl_lock_killable()

rtnl_lock() is widely used mutex in kernel. Some of kernel code does memory allocations under it. In case of memory deficit this may invoke OOM killer, but the problem is a killed task can't exit if it's waiting for the mutex. This may be a reason of deadlock and panic. This patch adds a new

Re: [PATCH] vhost: add vsock compat ioctl

On Wed, Mar 14, 2018 at 10:26:05AM -0700, Sonny Rao wrote: > This will allow usage of vsock from 32-bit binaries on a 64-bit > kernel. > > Signed-off-by: Sonny Rao I think you need to convert the pointer argument though. Something along the lines of: #ifdef CONFIG_COMPAT

[PATCH net-next v3 4/4] net: qualcomm: rmnet: Implement fill_info

This is needed to query the mux_id and flags of a rmnet device. Signed-off-by: Subash Abhinov Kasiviswanathan --- drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 30 ++ 1 file changed, 30 insertions(+) diff --git

[PATCH net-next v3 2/4] net: qualcomm: rmnet: Update copyright year to 2018

Signed-off-by: Subash Abhinov Kasiviswanathan --- drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +- drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 2 +- drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c| 2 +-

[PATCH net-next v3 1/4] net: qualcomm: rmnet: Fix casting issues

Fix warnings which were reported when running with sparse (make C=1 CF=-D__CHECK_ENDIAN__) drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:81:15: warning: cast to restricted __be16 drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:271:37: warning: incorrect type in assignment (different

[PATCH net-next v3 3/4] net: qualcomm: rmnet: Remove unnecessary device assignment

Device of the de-aggregated skb is correctly assigned after inspecting the mux_id, so remove the assignment in rmnet_map_deaggregate(). Signed-off-by: Subash Abhinov Kasiviswanathan --- drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 1 - 1 file changed, 1

[PATCH net-next v3 0/4] net: qualcomm: rmnet: Updates 2018-03-12

This series contains some minor updates for rmnet driver. Patch 1 contains fixes for sparse warnings. Patch 2 updates the copyright date to 2018. Patch 3 is a cleanup in receive path. Patch 4 has the implementation of the fill_info operation. v1->v2: Remove the force casts since the data type is

  1   2   3   >