[PATCH] RDS: Simplify code

Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to 'list_splice_init'. This has been spotted with the following coccinelle script: / @@ expression y,z; @@ - list_splice(y,z); - INIT_LIST_HEAD(y); + list_splice_init(y,z); Signed-off-by: Christophe JAILLET

Re: [BUG] af_packet FANOUT and device dismantle

From: Eric Dumazet Date: Thu, 01 Sep 2016 17:04:43 -0700 > When you added fanout in commit dc99f600698dcac, > it seems a device dismantle is not properly handled. > > packet_notifier() does properly finds all sockets attached to the > device and we call

Re: [PATCH v3 0/4] net: smsc911x: Move phy and interrupt config

From: Jeremy Linton Date: Thu, 1 Sep 2016 15:15:05 -0500 > v2-v3: Move error handing into separate patch, replace a couple cases > of fixed errors with the errors being returned from the failing functions. > Hoist irq handler. > > The smsc911x driver is doing a number

Re: [PATCH net-next V5 0/8] liquidio CN23XX support

From: Raghu Vatsavayi Date: Thu, 1 Sep 2016 11:16:03 -0700 > I am posting the remaining half of patchset after the > acceptance of first half. With this patchset I am able > to completely submit the code of V3 patchset which you > earlier advised me to split into

Re: [PATCH net-next 0/3] tipc: improve broadcast NACK mechanism

From: Jon Maloy Date: Thu, 1 Sep 2016 13:52:48 -0400 > The broadcast protocol has turned out to not scale well beyond 70-80 > nodes, while it is now possible to build TIPC clusters of at least ten > times that size. This commit series improves the NACK/retransmission >

Re: [PATCH v4 0/6] Support the rk3399 gmac and pd function

From: Caesar Wang Date: Fri, 2 Sep 2016 01:49:58 +0800 > This patch have the following changes: > > 7edf13e net: stmmac: dwmac-rk: add rk3366 & rk3399 specific data > 26e004e net: stmmac: dwmac-rk: fixes the gmac resume after PD on/off > b216c2f net: stmmac: dwmac-rk: add

[PATCH 0/2] hso: neatening

This seems to be the only code in the kernel that uses macro defines with a trailing underscore. Fix that. Joe Perches (2): hso: Use a more common logging style hso: Convert printk to pr_ drivers/net/usb/hso.c | 118 +++--- 1 file changed, 55

[PATCH 2/2] hso: Convert printk to pr_

Use a more common logging style Miscellanea: o Add pr_fmt to prefix each output message o Realign arguments Signed-off-by: Joe Perches --- drivers/net/usb/hso.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/net/usb/hso.c

[PATCH 1/2] hso: Use a more common logging style

Macros that end in an underscore are just odd. Add hso_dbg(level, fmt, ...) and use it everwhere instead. Several uses had additional unnecessary newlines as the macro added a newline. Remove the newline from the macro and add newlines to each use as appropriate. Remove now unused D macros.

Re: [ovs-dev] [PATCH net-next v21 3/4] openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes

On Fri, Sep 2, 2016 at 2:42 PM, pravin shelar wrote: > On Thu, Sep 1, 2016 at 1:45 PM, Eric Garver wrote: >> Add support for 802.1ad including the ability to push and pop double >> tagged vlans. Add support for 802.1ad to netlink parsing and flow >> conversion.

Re: [ovs-dev] [PATCH net-next v21 4/4] openvswitch: report error on VLAN nlattr in ovs_key_from_nlattrs()

On Thu, Sep 1, 2016 at 1:45 PM, Eric Garver wrote: > With 802.1ad support these are parsed and set upfront by > parse_vlan_from_nlattrs() before ovs_key_from_nlattrs() is ever called. > As such we should never see a VLAN attribute in ovs_key_from_nlattrs(). > > Signed-off-by: Eric

Re: [ovs-dev] [PATCH net-next v21 1/4] openvswitch: 802.1ad uapi changes.

On Thu, Sep 1, 2016 at 1:45 PM, Eric Garver wrote: > From: Thomas F Herbert > > openvswitch: Add support for 8021.AD > > Change the description of the VLAN tpid field. > > Signed-off-by: Thomas F Herbert Acked-by: Pravin B

Re: [ovs-dev] [PATCH net-next v21 2/4] vlan: Check for vlan ethernet types for 8021.q or 802.1ad

On Thu, Sep 1, 2016 at 1:45 PM, Eric Garver wrote: > This is to simplify using double tagged vlans. This function allows all > valid vlan ethertypes to be checked in a single function call. > Also replace some instances that check for both ETH_P_8021Q and > ETH_P_8021AD. > > Patch

Re: [ovs-dev] [PATCH net-next v21 3/4] openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes

On Thu, Sep 1, 2016 at 1:45 PM, Eric Garver wrote: > Add support for 802.1ad including the ability to push and pop double > tagged vlans. Add support for 802.1ad to netlink parsing and flow > conversion. Uses double nested encap attributes to represent double > tagged vlan. Inner

Re: [PATCH net-next 2/3] smsc95xx: Add register define

On Fri, 2016-09-02 at 20:34 +, woojung@microchip.com wrote: > From: Woojung Huh > > Add STRAP_STATUS defines. [] > diff --git a/drivers/net/usb/smsc95xx.h b/drivers/net/usb/smsc95xx.h [] > @@ -144,6 +144,14 @@ >   >  #define BURST_CAP(0x38)

[PATCH net-next 3/3] smsc95xx: Add mdix control via ethtool

From: Woojung Huh Add mdix control through ethtool. Signed-off-by: Woojung Huh --- drivers/net/usb/smsc95xx.c | 109 +++-- 1 file changed, 106 insertions(+), 3 deletions(-) diff --git

[PATCH net-next 1/3] smsc95xx: Add maintainer

From: Woojung Huh Add Microchip Linux Driver Support as maintainer because this driver is maintaining by Microchip. Signed-off-by: Woojung Huh --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index

[PATCH net-next 2/3] smsc95xx: Add register define

From: Woojung Huh Add STRAP_STATUS defines. Signed-off-by: Woojung Huh --- drivers/net/usb/smsc95xx.h | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/usb/smsc95xx.h b/drivers/net/usb/smsc95xx.h index 526faa0..29a4d9e

[PATCH net-next 0/3] smsc95xx: patch serises

From: Woojung Huh Woojung Huh (3): Smsc95xx: Add maintainer smsc95xx: Add register define smsc95xx: Add mdix control via ethtool MAINTAINERS| 1 + drivers/net/usb/smsc95xx.c | 109 +++--

Re: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock'

On 02.09.2016 20:13, Linus Torvalds wrote: > > From: Linus Torvalds > Date: Thu, 1 Sep 2016 14:43:53 -0700 > Subject: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and > 'bindlock' > > Right now we use the 'readlock' both for protecting some of the

Re: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock'

On 02.09.2016 21:15, David Miller wrote: > From: Linus Torvalds > Date: Fri, 2 Sep 2016 11:17:18 -0700 > >> Oh, this was missing a >> >> Reported-and-tested-by: CAI Qian >> >> who found the new deadlock. >> >> There's now *another* lockdep

Re: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock'

On Fri, Sep 2, 2016 at 12:15 PM, David Miller wrote: > > The main thing I was concerned about was an I/O path that really > expects the socket's hash not to change for whatever reason, but even > all of the unix_find_other() calls are done outside of the mutex > already.

Re: [PATCH iproute2 net-next] nstat: add sctp snmp support

On Fri, 2 Sep 2016 12:46:49 -0700 Stephen Hemminger wrote: > On Fri, 2 Sep 2016 15:12:38 +0800 > Hangbin Liu wrote: > > > SCTP module was not load by default. But this should be OK since we will not > > load table if fdopen() failed. > > > >

Re: [PATCH iproute2 net-next] nstat: add sctp snmp support

On Fri, 2 Sep 2016 15:12:38 +0800 Hangbin Liu wrote: > SCTP module was not load by default. But this should be OK since we will not > load table if fdopen() failed. > > Signed-off-by: Hangbin Liu This seems like a bad idea for the normal distro

Re: [RFC Patch net-next 0/6] net_sched: really switch to RCU for tc actions

On Fri, Sep 2, 2016 at 12:09 AM, Jiri Pirko wrote: > > I wonder, do you happen to have a very tiny narrow screen? LOL, yeah, I should fix the indentation... ;)

Re: [net-next PATCH =v2] e1000: add initial XDP support

On 16-09-01 11:50 PM, Jesper Dangaard Brouer wrote: > On Thu, 01 Sep 2016 14:39:44 -0700 > John Fastabend wrote: > >> From: Alexei Starovoitov >> >> This patch adds initial support for XDP on e1000 driver. Note e1000 >> driver does not support page

Re: [PATCH net 0/2] net: thunderx: Fixes for TSO offload issues

From: sunil.kovv...@gmail.com Date: Tue, 30 Aug 2016 11:36:25 +0530 > This patch series fixes couple of issues w.r.t HW TSO offload Series applied, thanks.

Re: [PATCH] net/mlx4_en: protect ring->xdp_prog with rcu_read_lock

On Fri, Sep 2, 2016 at 11:13 AM, Brenden Blanco wrote: > On Mon, Aug 29, 2016 at 10:46:38AM -0700, Tom Herbert wrote: > [...] >> Brenden, tracking down how the structure is freed needed a few steps, >> please make sure the RCU requirements are well documented. Also, I'm >

Re: [PATCH net v2 1/2] ipv6: add missing netconf notif when 'all' is updated

From: Nicolas Dichtel Date: Tue, 30 Aug 2016 10:09:21 +0200 > The 'default' value was not advertised. > > Fixes: f3a1bfb11ccb ("rtnl/ipv6: use netconf msg to advertise forwarding > status") > Signed-off-by: Nicolas Dichtel Applied.

Re: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock'

From: Linus Torvalds Date: Fri, 2 Sep 2016 11:17:18 -0700 > Oh, this was missing a > > Reported-and-tested-by: CAI Qian > > who found the new deadlock. > > There's now *another* lockdep deadlock report by him, but that one has > nothing to

Re: [PATCH net v2 2/2] netconf: add a notif when settings are created

From: Nicolas Dichtel Date: Tue, 30 Aug 2016 10:09:22 +0200 > All changes are notified, but the initial state was missing. > > Signed-off-by: Nicolas Dichtel Applied.

Re: Centralizing support for TCAM?

> I need to get reasonable operations per second on the TCAM tables. > Reasonable for me being somewhere in the 50k to 100k add/del/update > commands per second. I'm hesitant to create more abstractions then > are actually needed. Hi John That is an interesting requirement. Could you explain

Re: [PATCH 0/4] SA11x0 Clocks and removal of Neponset SMC91x hack

On Thu, Sep 01, 2016 at 04:32:41PM -0700, David Miller wrote: > From: Russell King - ARM Linux > Date: Tue, 30 Aug 2016 11:51:17 +0100 > > > Please ack these changes; due to the dependencies, I wish to merge > > them through my tree. Thanks. > > Acked-by: David S. Miller

Re: Centralizing support for TCAM?

On 16-09-02 10:18 AM, Florian Fainelli wrote: > Hi all, > Hi Florian, > (apologies for the long CC list and the fact that I can't type correctly > email addresses) > My favorite topic ;) > While working on adding support for the Broadcom Ethernet switches > Compact Field Processor (which is

[PATCH net-next v2 1/3] net: dsa: mv88e6xxx: fix module naming

Since the mv88e6xxx.c file has been renamed, the driver compiled as a module is called chip.ko instead of mv88e6xxx.ko. Fix this. Fixes: fad09c73c270 ("net: dsa: mv88e6xxx: rename single-chip support") Signed-off-by: Vivien Didelot ---

[PATCH net-next v2 0/3] net: dsa: mv88e6xxx: isolate Global2 support

Registers of Marvell chips are organized in internal SMI devices. One of them at address 0x1C is called Global2. It provides an extended set of registers, used for interrupt control, EEPROM access, indirect PHY access (to bypass the PHY Polling Unit) and cross-chip setup. Most chips have it, but

[PATCH net-next v2 3/3] net: dsa: mv88e6xxx: make global2 code optional

Since not every chip has a Global2 set of registers, make its support optional, in which case the related functions will return -EOPNOTSUPP. This also allows to reduce the size of the mv88e6xxx driver for devices such as home routers embedding Ethernet chips without Global2 support. It is

[PATCH net-next v2 2/3] net: dsa: mv88e6xxx: move Global2 code

Marvell chips are composed of multiple SMI devices. One of them at address 0x1C is called Global2. It provides an extended set of registers, used for interrupt control, EEPROM access, indirect PHY access (to bypass the PHY Polling Unit) and cross-chip related setup. Most chips have it, but some

Re: [PATCH net v2] l2tp: fix use-after-free during module unload

From: Sabrina Dubroca Date: Fri, 2 Sep 2016 10:22:54 +0200 > Tunnel deletion is delayed by both a workqueue (l2tp_tunnel_delete -> wq > -> l2tp_tunnel_del_work) and RCU (sk_destruct -> RCU -> > l2tp_tunnel_destruct). > > By the time l2tp_tunnel_destruct() runs to destroy

ipv6: release dst in ping_v6_sendmsg

Neither the failure or success paths of ping_v6_sendmsg release the dst it acquires. This leads to a flood of warnings from "net/core/dst.c:288 dst_release" on older kernels that don't have 8bf4ada2e21378816b28205427ee6b0e1ca4c5f1 backported. That patch optimistically hoped this had been fixed

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

Bjorn Andersson writes: > On Fri 02 Sep 09:24 PDT 2016, Kalle Valo wrote: > >> Bjorn Andersson writes: >> >> > --- a/drivers/net/wireless/ath/wcn36xx/Kconfig >> > +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig >> > @@ -1,6 +1,6 @@ >> >

Re: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock'

On Fri, Sep 2, 2016 at 11:13 AM, Linus Torvalds wrote: > > From: Linus Torvalds > Date: Thu, 1 Sep 2016 14:43:53 -0700 > Subject: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and > 'bindlock' > > Right now we use the

Re: [PATCH] net/mlx4_en: protect ring->xdp_prog with rcu_read_lock

On Mon, Aug 29, 2016 at 10:46:38AM -0700, Tom Herbert wrote: [...] > Brenden, tracking down how the structure is freed needed a few steps, > please make sure the RCU requirements are well documented. Also, I'm Really? It's just bpf_prog_put->call_rcu(__bpf_prog_put_rcu). I suppose what's missing

[PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock'

From: Linus Torvalds Date: Thu, 1 Sep 2016 14:43:53 -0700 Subject: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock' Right now we use the 'readlock' both for protecting some of the af_unix IO path and for making the bind be

[PATCH 1/2] Revert "af_unix: Fix splice-bind deadlock"

From: Linus Torvalds Date: Thu, 1 Sep 2016 14:56:49 -0700 Subject: [PATCH 1/2] Revert "af_unix: Fix splice-bind deadlock" This reverts commit c845acb324aa85a39650a14e7696982ceea75dc1. It turns out that it just replaces one deadlock with another one: we can still

Re: [PATCH] net/mlx4_en: protect ring->xdp_prog with rcu_read_lock

On Fri, Sep 02, 2016 at 01:59:40AM +0300, Saeed Mahameed wrote: > On Wed, Aug 31, 2016 at 4:50 AM, Brenden Blanco wrote: > > On Tue, Aug 30, 2016 at 12:35:58PM +0300, Saeed Mahameed wrote: [...] > >> Sorry folks I am with Tariq on this, you can't just add a single > >>

Re: [PATCH net-next] switchdev: Fix return value of switchdev_port_fdb_dump().

From: Rami Rosen Date: Fri, 2 Sep 2016 14:11:57 +0300 > This patch fixes the retun value of switchdev_port_fdb_dump() when > CONFIG_NET_SWITCHDEV is not set. This avoids getting "warning: return makes > integer from pointer without a cast [-Wint-conversion]" when building

Re: [PATCH RESEND net-next 13/15] smc: receive data from RMBE

From: Ursula Braun Date: Fri, 2 Sep 2016 15:05:01 +0200 > Understood, I wrongly used xchg() for atomicity. I now realize that I > would need cursor locking for 32-bit architectures - something I would > like to defer. Thus I would like to come up with V2 of SMC-R with

Re: [PATCH v3 net-next 0/6] perf, bpf: add support for bpf in sw/hw perf_events

From: Alexei Starovoitov Date: Thu, 1 Sep 2016 18:37:20 -0700 > Hi Peter, Dave, > > this patch set is a follow up to the discussion: > https://lkml.kernel.org/r/20160804142853.GO6862%20()%20twins%20!%20programming%20!%20kicks-ass%20!%20net > It turned out to be simpler than what we

Re: possible circular locking dependency detected

Linus Torvalds writes: > On Fri, Sep 2, 2016 at 10:02 AM, Al Viro wrote: >> >> It's very much _not_ just overlayfs being pathological - that it certainly >> is, >> but the problem is much wider. > > Al, can you take a look at my two

Re: possible circular locking dependency detected

On Fri, Sep 02, 2016 at 06:40:59PM +0100, Rainer Weikusat wrote: > The original deadlock occurred because of some code path locking the > superblock followed by trying to acquire the af_unix readlock while Not even that - one code path takes ->readlock under pipe lock, while another takes pipe

Re: possible circular locking dependency detected

On Fri, Sep 02, 2016 at 10:12:08AM -0700, Linus Torvalds wrote: > On Fri, Sep 2, 2016 at 10:02 AM, Al Viro wrote: > > > > It's very much _not_ just overlayfs being pathological - that it certainly > > is, > > but the problem is much wider. > > Al, can you take a look at

Re: [PATCH] net/mlx4_en: protect ring->xdp_prog with rcu_read_lock

On Thu, Sep 01, 2016 at 04:30:28PM -0700, Tom Herbert wrote: [...] > > Yep, but this is an unlikely condition and the critical code here is > > much smaller and it is more clear that the rcu_read_lock here meant to > > protect the ring->xdp_prog under this small xdp critical section in > >

[PATCH] qed: Remove OOM messages

These messages are unnecessary as OOM allocation failures already do a dump_stack() giving more or less the same information. $ size drivers/net/ethernet/qlogic/qed/built-in.o* (defconfig x86-64) textdata bss dec hex filename 126849 27968 32800 187617 2dce1

Re: [PATCH] qed: fix kzalloc-simple.cocci warnings

On Thu, 2016-09-01 at 07:37 +, Yuval Mintz wrote: > > drivers/net/ethernet/qlogic/qed/qed_dcbx.c:1230:13-20: WARNING: kzalloc > > should be used for dcbx_info, instead of kmalloc/memset > > drivers/net/ethernet/qlogic/qed/qed_dcbx.c:1192:13-20: WARNING: kzalloc > > should be used for

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

Hi Andrew, Andrew Lunn writes: >> I agree. Does the following snippet looks OK? >> >> >> #ifndef CONFIG_NET_DSA_MV88E6XXX_GLOBAL2 >> if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_GLOBAL2)) { >> dev_err(chip->dev, "Missing support for Global 2 >>

Re: [Patch net-next 2/2] netns: avoid disabling irq for netns id

On Fri, Sep 2, 2016 at 9:39 AM, Cong Wang wrote: > On Fri, Sep 2, 2016 at 1:12 AM, Nicolas Dichtel > wrote: >> Le 02/09/2016 à 06:53, Cong Wang a écrit : >>> We never read or change netns id in hardirq context, >>> the only place we read netns

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

> I agree. Does the following snippet looks OK? > > > #ifndef CONFIG_NET_DSA_MV88E6XXX_GLOBAL2 > if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_GLOBAL2)) { > dev_err(chip->dev, "Missing support for Global 2 > registers\n"); I would include the name of the option

Centralizing support for TCAM?

Hi all, (apologies for the long CC list and the fact that I can't type correctly email addresses) While working on adding support for the Broadcom Ethernet switches Compact Field Processor (which is essentially a TCAM, action/policer/rate meter RAMs, 256 entries), I started working with the

Re: [PATCH net] bonding: Fix bonding crash

Fri, Sep 02, 2016 at 07:08:54PM CEST, mahe...@google.com wrote: >On Fri, Sep 2, 2016 at 9:37 AM, Eric Dumazet wrote: >> On Fri, 2016-09-02 at 18:25 +0200, Jiri Pirko wrote: >> >>> Understand the reason. All I say is we tried hard (I surely did) in >>> the past to remove

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

Hi Andrew, Andrew Lunn writes: >> What do you think? > > I think the probe() needs to fail with a very obvious error message > saying you need to recompile your kernel with option XYZ enabled in > order to support this switch, when the optional stuff is not > optional... I

Re: possible circular locking dependency detected

On Fri, Sep 2, 2016 at 10:02 AM, Al Viro wrote: > > It's very much _not_ just overlayfs being pathological - that it certainly is, > but the problem is much wider. Al, can you take a look at my two patches, and see if you agree that they fix it, though? Of course, we

Re: possible circular locking dependency detected

On Fri, Sep 2, 2016 at 8:51 AM, CAI Qian wrote: > > Actually, I took it back, and now spice seems start to deadlock using the > reproducer, > > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/splice/splice01.c This is a different deadlock,

Re: [PATCH net] bonding: Fix bonding crash

On Fri, Sep 2, 2016 at 9:37 AM, Eric Dumazet wrote: > On Fri, 2016-09-02 at 18:25 +0200, Jiri Pirko wrote: > >> Understand the reason. All I say is we tried hard (I surely did) in >> the past to remove bonding specific quirks and now we are adding one. >> And the simple

Minimum MTU Mess

So... I had a bug reported, about a NIC that ceased to work, if it's MTU was set to 0, then back to it's original value (1500). This got me thinking... What does an MTU of 0 even mean? Why should it be allowed? As it turns out, most (but not all) network drivers have a check in their

Re: possible circular locking dependency detected

On Fri, Sep 02, 2016 at 05:10:13PM +0100, Rainer Weikusat wrote: > > Bullshit. kern_path_create() *does* mean the same thing in all cases. > > Namely, find the parent, lock it and leave the final name component for > > the create-type operation. It sure as hell is not guaranteed to take > >

Re: e1000e on Thinkpad x60: gigabit not available due to "SmartSpeed"

On Thu, Sep 01, 2016 at 02:58:13PM -0700, Greg wrote: > On Thu, 2016-09-01 at 22:14 +0200, Pavel Machek wrote: > > Hi! > > > > I have trouble getting 1000mbit out of my ethernet card. > > > > I tried direct connection between two PCs with different cables, and > > no luck. > > > > Today I tried

[PATCH net-next v4 1/2] net: ethernet: mediatek: enhance RX path by reducing the frequency of the memory barrier used

From: Sean Wang The patch makes move wmb() to outside the loop that could help RX path handling more faster although that RX descriptors aren't freed for DMA to use as soon as possible, but based on my experiment and the result shows it still can reach about 943Mbpis

[PATCH net-next v4 2/2] net: ethernet: mediatek: enhance RX path by aggregating more SKBs into NAPI

From: Sean Wang The patch adds support for aggregating more SKBs feed into NAPI in order to get more benefits from generic receive offload (GRO) by peeking at the RX ring status and moving more packets right before returning from NAPI RX polling handler if NAPI budgets

[PATCH net-next v4 0/2] net: ethernet: mediatek: add enhancements to RX path

From: Sean Wang Changes since v1: - fix message typos and add coverletter Changes since v2: - split from the previous series for submitting add enhancements as a series targeting 'net-next' and add indents before comments. Changes since v3: - merge the patch using

Re: [PATCH 4/4] net: smsc911x: Move interrupt allocation to open/stop

On Thu, Sep 01, 2016 at 03:15:09PM -0500, Jeremy Linton wrote: > The /proc/irq/xx information is incorrect for smsc911x because > the request_irq is happening before the register_netdev has the > proper device name. Moving it to the open also fixes the case > of when the device is renamed. > >

Re: possible circular locking dependency detected

Linus Torvalds writes: > On Thu, Sep 1, 2016 at 2:43 PM, Linus Torvalds > wrote: >> On Thu, Sep 1, 2016 at 2:01 PM, Al Viro wrote: >>> >>> Outside as in "all fs activity in bind happens under it". Along with

Re: possible circular locking dependency detected

- Original Message - > From: "CAI Qian" > To: "Linus Torvalds" > Cc: "Al Viro" , "Miklos Szeredi" > , "Rainer Weikusat" > , "Hannes Frederic Sowa" >

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

On Fri 02 Sep 09:24 PDT 2016, Kalle Valo wrote: > Bjorn Andersson writes: > > > The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD > > channel, as such it should be a SMD client. This patch makes this > > transition, now that we have the necessary

Re: [PATCH net 0/2] vxlan: fix error reporting

On Fri, 2 Sep 2016 09:03:11 -0700, Stephen Hemminger wrote: > On Fri, 2 Sep 2016 13:37:10 +0200 > Jiri Benc wrote: > > > This patchset improves checking for invalid configuration in VXLAN and fixes > > problems with duplicated and inappropriate error messages. > > > > Jiri

Re: [Patch net-next 2/2] netns: avoid disabling irq for netns id

On Fri, Sep 2, 2016 at 1:12 AM, Nicolas Dichtel wrote: > Le 02/09/2016 à 06:53, Cong Wang a écrit : >> We never read or change netns id in hardirq context, >> the only place we read netns id in softirq context >> is in vxlan_xmit(). So, it should be enough to just >>

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

Hi Kalle, >> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD >> channel, as such it should be a SMD client. This patch makes this >> transition, now that we have the necessary frameworks available. >> >> Signed-off-by: Bjorn Andersson > > [...] >

Re: [PATCH net] bonding: Fix bonding crash

On Fri, 2016-09-02 at 18:25 +0200, Jiri Pirko wrote: > Understand the reason. All I say is we tried hard (I surely did) in > the past to remove bonding specific quirks and now we are adding one. > And the simple reason is that the code is such a mess. > > Just use team instead and you'll be

Re: [PATCH net] bonding: Fix bonding crash

Fri, Sep 02, 2016 at 03:33:20PM CEST, eric.duma...@gmail.com wrote: >On Fri, 2016-09-02 at 09:52 +0200, Jiri Pirko wrote: > >> >> No, please, don't make bonding a spacial citizen introducing this. >> Please handle the issue inside the bonding code, like we do for the rest >> of master devices

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

Bjorn Andersson writes: > The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD > channel, as such it should be a SMD client. This patch makes this > transition, now that we have the necessary frameworks available. > > Signed-off-by: Bjorn Andersson

Re: possible circular locking dependency detected

Al Viro writes: > On Fri, Sep 02, 2016 at 04:18:04PM +0100, Rainer Weikusat wrote: > >> As far as I can tell, this should work as I can't currently imagine >> why a fs operation might end up binding a unix socket despite the >> idea to make af_unix.c yet more complicated

[PATCH net-next v3 0/2] net: ethernet: mediatek: add enhancements to RX path

From: Sean Wang Changes since v1: - fix message typos and add coverletter Changes since v2: - split from the previous series for submitting add enhancements as a series targeting 'net-next' and add indents before comments. Changes since v3: - merge the patch using

[PATCH net-next v3 1/2] net: ethernet: mediatek: enhance RX path by reducing the frequency of the memory barrier used

From: Sean Wang The patch makes move wmb() to outside the loop that could help RX path handling more faster although that RX descriptors aren't freed for DMA to use as soon as possible, but based on my experiment and the result shows it still can reach about 943Mbpis

[PATCH net-next v3 2/2] net: ethernet: mediatek: enhance RX path by aggregating more SKBs into NAPI

From: Sean Wang The patch adds support for aggregating more SKBs feed into NAPI in order to get more benefits from generic receive offload (GRO) by peeking at the RX ring status and moving more packets right before returning from NAPI RX polling handler if NAPI budgets

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

Hi Vivien > What do you think? I think the probe() needs to fail with a very obvious error message saying you need to recompile your kernel with option XYZ enabled in order to support this switch, when the optional stuff is not optional... Andrew

Re: [v2] ath9k: mark ath_fill_led_pin() static

Baoyou Xie wrote: > We get 1 warning about global functions without a declaration > in the ath9k gpio driver when building with W=1: > drivers/net/wireless/ath/ath9k/gpio.c:25:6: warning: no previous prototype > for 'ath_fill_led_pin' [-Wmissing-prototypes] > > In fact,

Re: [PATCH] net: Don't delete routes in different VRFs

On 9/1/16 11:26 PM, Mark Tomlinson wrote: > When deleting an IP address from an interface, there is a clean-up of > routes which refer to this local address. However, there was no check to > see that the VRF matched. This meant that deletion wasn't confined to > the VRF it should have been. > >

Re: ath10k: fix spelling mistake "montior" -> "monitor"

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in ath10k_warn message. > > Signed-off-by: Colin Ian King > Reviewed-by: Julian Calaby Thanks, 1 patch

Re: possible circular locking dependency detected

On Fri, Sep 02, 2016 at 04:18:04PM +0100, Rainer Weikusat wrote: > As far as I can tell, this should work as I can't currently imagine why > a fs operation might end up binding a unix socket despite the idea to > make af_unix.c yet more complicated in order to work around irregular > behaviour of

Re: ath10k: replace config_enabled() with IS_REACHABLE()

Masahiro Yamada wrote: > Commit 97f2645f358b ("tree-wide: replace config_enabled() with > IS_ENABLED()") mostly did away with config_enabled(). > > This is one of the postponed TODO items as config_enabled() is used > for a tristate option here. Theoretically,

Re: [PATCH net 0/2] vxlan: fix error reporting

On Fri, 2 Sep 2016 13:37:10 +0200 Jiri Benc wrote: > This patchset improves checking for invalid configuration in VXLAN and fixes > problems with duplicated and inappropriate error messages. > > Jiri Benc (2): > vxlan: reject multicast destination without an interface >

Re: possible circular locking dependency detected

- Original Message - > From: "CAI Qian" > To: "Linus Torvalds" > Cc: "Al Viro" , "Miklos Szeredi" > , "Rainer Weikusat" > , "Hannes Frederic Sowa" >

Re: [2/2] ath10k: use complete() instead complete_all()

Daniel Wagner wrote: > From: Daniel Wagner > > There is only one waiter for the completion, therefore there > is no need to use complete_all(). Let's make that clear by > using complete() instead of complete_all(). > > The usage pattern of the

Re: [PATCH] ath10k: fix memory leak on caldata on error exit path

Colin King writes: > From: Colin Ian King > > caldata is not being free'd on the error exit path, causing > a memory leak. kfree it to fix the leak. > > Signed-off-by: Colin Ian King > --- >

Re: [PATCH net] bonding: Fix bonding crash

On Fri, 2016-09-02 at 08:21 -0700, Eric Dumazet wrote: > Ideally the netdev_rx_handler_register() should be called only when no > further errors can be detected in the 'enslaving' process, otherwise > some live packets could come and be incorrectly processed/dropped by a > not fully initialized

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

Hi Andrew, Andrew Lunn writes: > On Fri, Sep 02, 2016 at 08:08:19AM -0400, Vivien Didelot wrote: >> Since not every chip has a Global2 set of registers, make its support >> optional, in which case the related functions will return -EOPNOTSUPP. >> >> This also allows to reduce

Re: [PATCH net] bonding: Fix bonding crash

On Fri, 2016-09-02 at 08:57 -0600, David Ahern wrote: > I hit this same problem yesterday but with the bridge. I forgot I had > a macvlan device on an interface and tried to enslave it to a bridge. > It failed with EBUSY without crashing the kernel so it is one example > that handles the

Re: [PATCH net] bonding: Fix bonding crash

On 9/2/16 8:45 AM, Eric Dumazet wrote: > On Fri, 2016-09-02 at 08:30 -0600, David Ahern wrote: > >> This check duplicates what netdev_rx_handler_register does. Why not >> move the call to netdev_rx_handler_register here and then call >> unregister on failure paths? > > As soon as you call

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

On Fri, Sep 02, 2016 at 08:08:19AM -0400, Vivien Didelot wrote: > Since not every chip has a Global2 set of registers, make its support > optional, in which case the related functions will return -EOPNOTSUPP. > > This also allows to reduce the size of the mv88e6xxx driver for devices > such as

Re: [PATCH net] bonding: Fix bonding crash

On Fri, 2016-09-02 at 08:30 -0600, David Ahern wrote: > This check duplicates what netdev_rx_handler_register does. Why not > move the call to netdev_rx_handler_register here and then call > unregister on failure paths? As soon as you call netdev_rx_handler_register(), incoming packets will hit

  1   2   >