Re: net: hang in unregister_netdevice: waiting for lo to become free

On 19.02.2018 20:59, Dmitry Vyukov wrote: On Sat, Feb 3, 2018 at 1:15 PM, Xin Long wrote: On 1/30/18 1:57 PM, David Ahern wrote: On 1/30/18 1:08 PM, Daniel Borkmann wrote: On 01/30/2018 07:32 PM, Cong Wang wrote: On Tue, Jan 30, 2018 at 4:09 AM, Dmitry Vyukov

Re: [PATCH v3 2/2] net: ethernet: nixge: Add support for National Instruments XGE netdev

Hi Moritz, On Fri, Feb 16, 2018 at 6:00 PM, Moritz Fischer wrote: > Add support for the National Instruments XGE 1/10G network device. > > It uses the EEPROM on the board via NVMEM. > > Signed-off-by: Moritz Fischer > --- /dev/null > +++

[patch net-next] mlxsw: spectrum_switchdev: Allow port enslavement to a VLAN-unaware bridge

From: Ido Schimmel Up until now we only allowed VLAN devices to be put in a VLAN-unaware bridge, but some users need the ability to enslave physical ports as well. This is achieved by mapping the port and VID 1 to the bridge's vFID, instead of the port and the VID used by

[patch net-next v2 1/5] devlink: Move size validation to core

From: Arkadi Sharshevsky Currently the size validation is done via a cb, which is unneeded. The size validation can be moved to core. The next patch will perform cleanup. Signed-off-by: Arkadi Sharshevsky Signed-off-by: Jiri Pirko

[patch net-next v2 3/5] mlxsw: spectrum_kvdl: Add support for linear division resources

From: Arkadi Sharshevsky The linear part of the KVD memory is sub-divided into multiple parts. This patch exposes this internal partitions via the resource interface. Signed-off-by: Arkadi Sharshevsky Signed-off-by: Jiri Pirko ---

[patch net-next v2 0/5] mlxsw: Expose KVD linear parts as resources

From: Jiri Pirko Arkadi says: Expose the KVD linear partitions via the devlink resource interface. This will give the user the ability to control the linear memory division. --- v1->v2: - patch1: - fixed u64 division error reported by kbuildbot Arkadi Sharshevsky (5):

[patch net-next v2 5/5] mlxsw: spectrum_kvdl: Add support for per part occupancy

From: Arkadi Sharshevsky Add support for calculating occupancy for separate kvdl parts. Signed-off-by: Arkadi Sharshevsky Signed-off-by: Jiri Pirko --- .../net/ethernet/mellanox/mlxsw/spectrum_kvdl.c| 58

[patch net-next v2 2/5] devlink: Perform cleanup of resource_set cb

From: Arkadi Sharshevsky After adding size validation logic into core cleanup is required. Signed-off-by: Arkadi Sharshevsky Signed-off-by: Jiri Pirko --- drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 83

[patch net-next v2 4/5] mlxsw: spectrum_kvdl: Add support for dynamic partition set

From: Arkadi Sharshevsky Add support for dynamic partition set via the resource interface. Signed-off-by: Arkadi Sharshevsky Signed-off-by: Jiri Pirko --- .../net/ethernet/mellanox/mlxsw/spectrum_kvdl.c| 58

Re: [PATCH net-next 1/7] net: stmmac: set MSS for each tx DMA channel

Hi Niklas I had a look at this series that looks ok for me. Acked-by: Giuseppe Cavallaro On 2/19/2018 6:11 PM, Niklas Cassel wrote: The DMA engine in dwmac4 can segment a large TSO packet to several smaller packets of (max) size Maximum Segment Size (MSS). The DMA

Re: [PATCH net] xfrm: do not call rcu_read_unlock when afinfo is NULL in xfrm_get_tos

On Sat, Feb 17, 2018 at 03:16:22PM +0800, Xin Long wrote: > When xfrm_policy_get_afinfo returns NULL, it will not hold rcu > read lock. In this case, rcu_read_unlock should not be called > in xfrm_get_tos, just like other places where it's calling > xfrm_policy_get_afinfo. > > Fixes: f5e2bb4f5b22

[PATCH net-next] r8169: remove not needed PHY soft reset in rtl8168e_2_hw_phy_config

rtl8169_init_phy() resets the PHY anyway after applying the chip-specific PHY configuration. So we don't need to soft-reset the PHY as part of the chip-specific configuration. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 2 -- 1 file changed, 2

[PATCH net-next] r8169: remove some WOL-related dead code

Commit bde135a672bf "r8169: only enable PCI wakeups when WOL is active" removed the only user of flag RTL_FEATURE_WOL. So let's remove some now dead code. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 39 ++-- 1

[PATCH net-queue] e1000e: Fix check_for_link return value with autoneg off.

When autoneg is off, the .check_for_link callback functions clear the get_link_status flag and systematically return a "pseudo-error". This means that the link is not detected as up until the next execution of the e1000_watchdog_task() 2 seconds later. Fixes: 19110cfbb34d ("e1000e: Separate

Re: [PATCH net 2/4] net/8390: Fix msg_enable patch snafu

From: Finn Thain Date: Tue, 20 Feb 2018 11:42:26 +1100 (AEDT) > If there was an unused variables I would happily remove that too but the > 'version' string is not unused. The etherh.c and mac8390.c files both > include "lib8390.c" and in there you'll find the

Re: [PATCH iproute2-next] ip link: add support to display extended tun attributes

On 2/19/18 3:19 PM, Serhey Popovych wrote: > I get following checkpatch.pl warnings: > > WARNING: Missing a blank line after declarations > #73: FILE: ip/iptuntap.c:497: > + __u8 mq = rta_getattr_u8(tb[IFLA_TUN_MULTI_QUEUE]); > + if (!mq) > > WARNING: Missing a blank

[PATCH net-next RFC 2/2] net: ethernet: pch_gbe: Convert to mdiobus and phylib

Convert this driver to use the mdio bus and phylib infrastructure. It will then use the common AT803X PHY driver, rather than use its own code. Have the shared code also handle the GPIO used to reset the PHY. To implement disabling PHY hibernation, which appears to cause issues on the minnow

[PATCH net-next RFC 0/2] Convert OKI PCH GBE to mdiobus and phylib

Hi Paul Here is my stab at converting the OKI PCH GBE to use the common MDIO bus and phylib drivers. This is compile tested only, and pretty much guaranteed to be broken. But hopefully it will help you. Feel free to pick it up and make it work. Without hardware, there is not much more i can do,

[PATCH net-next RFC 1/2] net: phy: at803x: Export at803x_debug_reg_mask()

On some boards, this PHY has a problem when it hibernates. Export this function to a board can register a PHY fixup to disable hibernation. Signed-off-by: Andrew Lunn --- drivers/net/phy/at803x.c | 5 +++-- include/linux/at803x_phy.h | 16 2 files changed, 19

[PATCH net v2] ibmvnic: Check for NULL skb's in NAPI poll routine

After introduction of commit d0869c0071e4, there were some instances of RX queue entries from a previous session (before the device was closed and reopened) returned to the NAPI polling routine. Since the corresponding socket buffers were freed, this resulted in a panic on reopen. Include a check

Re: [PATCH net-next 0/6] tcp: remove non GSO code

On Mon, Feb 19, 2018 at 2:56 PM Eric Dumazet wrote: > Switching TCP to GSO mode, relying on core networking layers > to perform eventual adaptation for dumb devices was overdue. > 1) Most TCP developments are done with TSO in mind. > 2) Less high-resolution timers needs to

Re: [PATCH net-next 1/6] tcp: switch to GSO being always on

Hi Eric, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Eric-Dumazet/tcp-remove-non-GSO-code/20180220-064839 reproduce: make htmldocs All warnings (new ones prefixed by >>):

[PATCH] tools/libbpf: Avoid possibly using uninitialized variable

Fixes a GCC maybe-uninitialized warning introduced by 48cca7e44f9f. "text" is only initialized inside the if statement so only print debug info there. Signed-off-by: Jeremy Cline --- tools/lib/bpf/libbpf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

Re: [PATCH net 2/4] net/8390: Fix msg_enable patch snafu

On Mon, 19 Feb 2018, David Miller wrote: > > On Mon, 19 Feb 2018, David Miller wrote: > > > >> > The lib8390 module parameter 'msg_enable' doesn't do anything > >> > useful: it causes an ancient version string to be logged. > >> > >> Since you are removing the last reference to this 'version'

Re: [net-next v2 1/2] bpf, seccomp: Add eBPF filter capabilities

On 02/19/2018 05:22 PM, Sargun Dhillon wrote: > This introduces the BPF_PROG_TYPE_SECCOMP bpf program type. It is meant > to be used for seccomp filters as an alternative to cBPF filters. The > program type has relatively limited capabilities in terms of helpers, > but that can be extended later

Re: [PATCH net 2/4] net/8390: Fix msg_enable patch snafu

From: Finn Thain Date: Tue, 20 Feb 2018 09:01:11 +1100 (AEDT) > On Mon, 19 Feb 2018, David Miller wrote: > >> From: Finn Thain >> Date: Sun, 18 Feb 2018 21:39:17 -0500 (EST) >> >> > The lib8390 module parameter 'msg_enable' doesn't do

Re: [PATCH iproute2-next 1/4] bridge: implement json pretty print flag

Stephen Hemminger wrote: > Make bridge work like other iproute2 commands with standard -j and -p > flags. > > Signed-off-by: Stephen Hemminger > --- > bridge/br_common.h | 3 ++- > bridge/bridge.c| 9 ++--- > bridge/fdb.c | 10 ++ >

Re: [PATCH iproute2-next] ip link: add support to display extended tun attributes

Sabrina Dubroca wrote: > Signed-off-by: Sabrina Dubroca > Reviewed-by: Stefano Brivio > --- > > I included the uapi changes from the kernel patch. Let me know if I > need to resend without the header changes. > > include/uapi/linux/if_link.h | 18

Re: [PATCH net 2/4] net/8390: Fix msg_enable patch snafu

On Mon, 19 Feb 2018, David Miller wrote: > From: Finn Thain > Date: Sun, 18 Feb 2018 21:39:17 -0500 (EST) > > > The lib8390 module parameter 'msg_enable' doesn't do anything useful: > > it causes an ancient version string to be logged. > > Since you are removing the

Re: [PATCH RFC 0/4] net: add bpfilter

> I see several possible areas of contention: > > 1) If you aim for a non-feature-complete support of iptables rules, it >will create confusion to the users. Right, you need full feature parity to be avoid ending up having to maintain two implementations. It seems uncontroversial that BPF

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, 19 Feb 2018, Florian Westphal wrote: > David Miller wrote: > > > > Florian, first of all, the whole "change the iptables binary" idea is > > a non-starter. For the many reasons I have described in the various > > postings I have made today. > > > > It

Re: [PATCH RFC 0/4] net: add bpfilter

David Miller wrote: > From: Phil Sutter > Date: Mon, 19 Feb 2018 18:14:11 +0100 > > > OK, so reading between the lines you're saying that nftables project > > has failed to provide an adequate successor to iptables? > > Whilst it is great that the atomic table

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 01:41:29PM -0500, David Miller wrote: > From: Phil Sutter > Date: Mon, 19 Feb 2018 19:05:51 +0100 > > > On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote: > >> From: Phil Sutter > >> Date: Mon, 19 Feb 2018 18:14:11 +0100 >

Re: WARNING in check_flush_dependency

On Mon, 2018-02-19 at 19:58 +0100, Dmitry Vyukov wrote: > > > Yeah, we clearly shouldn't have WQ_RECLAIM set on this workqueue... > > Hi Johannes, > > Do you mind to send a patch to fix this? Yeah, sorry, I've been behind on patches a bit. I just applied it today, and once I've let it sit for

[PATCH v2] sched: report if filter is too large to dump

So far, if the filter was too large to fit in the allocated skb, the kernel did not return any error and stopped dumping. Modify the dumper so that it returns -EMSGSIZE when a filter fails to dump and it is the first filter in the skb. If we are not first, we will get a next chance with more room.

Re: [PATCH v3 1/2] dt-bindings: net: Add bindings for National Instruments XGE netdev

On Fri, Feb 16, 2018 at 09:00:32AM -0800, Moritz Fischer wrote: > This adds bindings for the NI XGE 1G/10G network device. > > Signed-off-by: Moritz Fischer > --- > > Changes from v2: > - Addressed Rob's comments w.r.t to IRQ names and typo > > Changes from v1: > - Corrected

[PATCH RFC iproute-next 3/5] rdma: Add CQ resource tracking information

Sample output: # rdma resource show cq link cxgb4_0/- cqe 46 usecnt 2 pid 30503 comm rping link cxgb4_0/- cqe 46 usecnt 2 pid 30498 comm rping link mlx4_0/- cqe 63 usecnt 2 pid 30494 comm rping link mlx4_0/- cqe 63 usecnt 2 pid 30489 comm rping link mlx4_0/- cqe 1023 usecnt 2 poll_ctx WORKQUEUE

[PATCH RFC iproute-next 5/5] rdma: Add PD resource tracking information

Sample output: # rdma resource show pd link cxgb4_0/- local_dma_lkey 0x0 usecnt 4 flags 0x0 pid 30503 comm rping link cxgb4_0/- local_dma_lkey 0x0 usecnt 0 flags 0x0 pid 30488 comm rping link cxgb4_0/- local_dma_lkey 0x0 usecnt 5 flags 0x0 pid 30498 comm rping link cxgb4_0/- local_dma_lkey 0x0

[PATCH RFC iproute-next 4/5] rdma: Add MR resource tracking information

Sample output: # rdma resource show mr link cxgb4_0/- rkey 0x5e0e lkey 0x5e0e iova 0x7f9b60001c80 mrlen 64 pgsize 4096 pid 30503 comm rping link cxgb4_0/- rkey 0x510d lkey 0x510d iova 0x17c7ee0 mrlen 16 pgsize 4096 pid 30503 comm rping link cxgb4_0/- rkey 0x4a0c lkey 0x4a0c iova 0x17c7e38 mrlen

[PATCH RFC iproute-next 2/5] rdma: Add CM_ID resource tracking information

Sample output: # rdma resource 2: cxgb4_0: pd 5 cq 2 qp 2 cm_id 3 mr 7 3: mlx4_0: pd 7 cq 3 qp 3 cm_id 3 mr 7 # rdma resource show cm_id [root@stevo1 iproute2]# /root/stevo/iproute2/rdma/rdma resource show cm_id link cxgb4_0/- lqpn 0 qp-type RC state LISTEN ps TCP dev-type --- transport-type

[PATCH RFC iproute-next 1/5] rdma: update rdma_netlink.h

From: Steve Wise Pull in the latest rdma_netlink.h which has support for the rdma nldev resource tracking objects being added with this patch series. Signed-off-by: Steve Wise --- include/uapi/rdma/rdma_netlink.h | 62

[PATCH RFC iproute-next 0/5] cm_id, cq, mr, and pd resource tracking

Hello, This series enhances the iproute2 rdma tool to include dumping of connection manager id (cm_id), completion queue (cq), memory region (mr), and protection domain (pd) rdma resources. It is the user-space part of the resource tracking series under review now on the linux-rdma list [1].

Re: [PATCH] rds: send: mark expected switch fall-through in rds_rm_size

On (02/19/18 12:10), Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. Acked-by: Sowmini Varadhan

[PATCH net-next 6/6] tcp: remove dead code after CHECKSUM_PARTIAL adoption

Since all skbs in write/rtx queues have CHECKSUM_PARTIAL, we can remove dead code. Signed-off-by: Eric Dumazet --- net/ipv4/tcp_ipv4.c | 13 +++-- net/ipv4/tcp_output.c | 38 +- 2 files changed, 8 insertions(+), 43 deletions(-)

Re: [PATCH net] ibmvnic: Clean RX pools only during a hard reset

On 02/19/2018 01:30 PM, David Miller wrote: > From: Thomas Falcon > Date: Mon, 19 Feb 2018 13:24:52 -0600 > >> Sorry, I should explain it better. It's not there is a double free. >> It's that the driver is receiving RX descriptors from the previous >> session for

[PATCH net-next 0/6] tcp: remove non GSO code

Switching TCP to GSO mode, relying on core networking layers to perform eventual adaptation for dumb devices was overdue. 1) Most TCP developments are done with TSO in mind. 2) Less high-resolution timers needs to be armed for TCP-pacing 3) GSO can benefit of xmit_more hint 4) Receiver GRO is

[PATCH net-next 1/6] tcp: switch to GSO being always on

Oleksandr Natalenko reported performance issues with BBR without FQ packet scheduler that were root caused to lack of SG and GSO/TSO on his configuration. In this mode, TCP internal pacing has to setup a high resolution timer for each MSS sent. We could implement in TCP a strategy similar to the

[PATCH net-next 2/6] tcp: remove sk_can_gso() use

After previous commit, sk_can_gso() is always true. Signed-off-by: Eric Dumazet --- net/ipv4/tcp.c | 34 -- net/ipv4/tcp_input.c | 3 --- 2 files changed, 8 insertions(+), 29 deletions(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c

Re: [PATCH RFC PoC 0/3] nftables meets bpf

On 02/19/2018 05:37 PM, Pablo Neira Ayuso wrote: [...] > * Simplified infrastructure: We don't need the ebpf verifier complexity > either given we trust the code we generate from the kernel. We don't > need any complex userspace tooling either, just libnftnl and nft > userspace binaries. >

[PATCH net-next 3/6] tcp: remove sk_check_csum_caps()

Since TCP relies on GSO, we do not need this helper anymore. Signed-off-by: Eric Dumazet --- include/net/sock.h | 9 - net/ipv4/tcp.c | 11 +++ 2 files changed, 3 insertions(+), 17 deletions(-) diff --git a/include/net/sock.h b/include/net/sock.h index

[PATCH net-next 5/6] tcp: remove dead code from tcp_set_skb_tso_segs()

We no longer have skbs with skb->ip_summed == CHECKSUM_NONE in TCP write queues. Signed-off-by: Eric Dumazet --- net/ipv4/tcp_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index

[PATCH net-next 4/6] tcp: tcp_sendmsg() only deals with CHECKSUM_PARTIAL

We no longer have skbs with skb->ip_summed == CHECKSUM_NONE in TCP write queues. We can remove dead code in tcp_sendmsg(). Signed-off-by: Eric Dumazet --- net/ipv4/tcp.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/net/ipv4/tcp.c

[PATCH V3 net-next 5/5] ibmvnic: Allocate max queues stats buffers

To avoid losing any stats when the number of sub-crqs change, allocate the max number of stats buffers so a stats buffer exists all possible sub-crqs. Signed-off-by: Nathan Fontenot --- drivers/net/ethernet/ibm/ibmvnic.c |4 ++-- 1 file changed, 2 insertions(+), 2

Re: [PATCH V2 net-next 3/5] ibmvnic: Free and re-allocate scrqs when tx/rx scrqs change

On 02/19/2018 01:16 PM, David Miller wrote: > From: Nathan Fontenot > Date: Sun, 18 Feb 2018 19:34:47 -0600 > >> @@ -2241,24 +2241,27 @@ static int reset_sub_crq_queues(struct >> ibmvnic_adapter *adapter) >> } >> >> static void release_sub_crq_queue(struct

[PATCH V3 net-next 2/5] ibmvnic: Move active sub-crq count settings

Inpreparation for using the active scrq count to track more active resources, move the setting of the active count to after initialization occurs in initial driver init and during driver reset. Signed-off-by: Nathan Fontenot --- drivers/net/ethernet/ibm/ibmvnic.c |

[PATCH V3 net-next 1/5] ibmvnic: Rename active queue count variables

Rename the tx/rx active pool variables to be tx/rx active scrq counts. The tx/rx pools are per sub-crq so this is a more appropriate name. This also is a preparatory step for using thiese variables for handling updates to sub-crqs and napi based on the active count. Signed-off-by: Nathan Fontenot

[PATCH V3 net-next 3/5] ibmvnic: Free and re-allocate scrqs when tx/rx scrqs change

When the driver resets it is possible that the number of tx/rx sub-crqs can change. This patch handles this so that the driver does not try to access non-existent sub-crqs. The count for releasing sub crqs depends on the adapter state. The active queue count is not set in probe, so if we are

[PATCH V3 net-next 4/5] ibmvnic: Make napi usage dynamic

In order to handle the number of rx sub crqs changing during a driver reset, the ibmvnic driver also needs to update the number of napi. To do this the code to init and free napi's is moved to their own routines so they can be called during the reset process. Signed-off-by: Nathan Fontenot

[GIT] Networking

1) Prevent index integer overflow in ptr_ring, from Jason Wang. 2) Program mvpp2 multicast filter properly, from Mikulas Patocka. 3) The bridge brport attribute file is write only and doesn't have a ->show() method, don't blindly invoke it. From Xin Long. 4) Inverted mask used in

[PATCH V3 net-next 0/5] ibmvnic: Make driver resources dynamic

The ibmvnic driver needs to be able to handle the number of tx/rx sub-crqs changing during a reset of the driver. To do this several changes need to be made. First the num_active_[tx|rx]_pools counters need to be re-named to num_active_[tc|rx]_scrqs, and updated after resource initialization.

Re: [net-next 1/1] tipc: fix bug on error path in tipc_topsrv_kern_subscr()

From: Jon Maloy Date: Mon, 19 Feb 2018 12:48:21 +0100 > In commit cc1ea9ffadf7 ("tipc: eliminate struct tipc_subscriber") we > re-introduced an old bug on the error path in the function > tipc_topsrv_kern_subscr(). We now re-introduce the correction too. > > Reported-by:

Re: [PATCH net-next] tipc: don't call sock_release() in atomic context

From: Paolo Abeni Date: Mon, 19 Feb 2018 19:02:24 +0100 > syzbot reported a scheduling while atomic issue at netns > destruction time: ... > This is caused by tipc_topsrv_stop() releasing the listener socket > with the idr lock held. This changeset addresses the issue moving

Re: [PATCH net] ibmvnic: Clean RX pools only during a hard reset

From: Thomas Falcon Date: Mon, 19 Feb 2018 13:24:52 -0600 > Sorry, I should explain it better. It's not there is a double free. > It's that the driver is receiving RX descriptors from the previous > session for which socket buffers have been freed. The driver's >

Re: [PATCH net] ibmvnic: Clean RX pools only during a hard reset

On 02/19/2018 10:37 AM, David Miller wrote: > From: Thomas Falcon > Date: Sun, 18 Feb 2018 10:08:40 -0600 > >> Sorry, this fixes a bug in commit d0869c0071e4. The cause of the >> bug is that "stale" RX buffers containing packet data are returned >> to the driver after

Re: [PATCH 00/16] Converting pernet_operations (part #2)

From: Kirill Tkhai Date: Mon, 19 Feb 2018 11:47:55 +0300 > This patchset continues to review and to convert pernet_operations > to async. There are mostly ipv6, also some regular used netfilter > pernet_operations are involved. One more converted is cfg80211_pernet_ops.

Re: [PATCH net] tg3: APE heartbeat changes

From: Satish Baddipadige Date: Mon, 19 Feb 2018 12:27:04 +0530 > From: Prashant Sreedharan > > In ungraceful host shutdown or driver crash case BMC connectivity is > lost. APE firmware is missing the driver state in this > case

Re: [PATCH V2 net-next 3/5] ibmvnic: Free and re-allocate scrqs when tx/rx scrqs change

From: Nathan Fontenot Date: Sun, 18 Feb 2018 19:34:47 -0600 > @@ -2241,24 +2241,27 @@ static int reset_sub_crq_queues(struct > ibmvnic_adapter *adapter) > } > > static void release_sub_crq_queue(struct ibmvnic_adapter *adapter, > -

Re: [PATCH net 2/4] net/8390: Fix msg_enable patch snafu

From: Finn Thain Date: Sun, 18 Feb 2018 21:39:17 -0500 (EST) > The lib8390 module parameter 'msg_enable' doesn't do anything useful: > it causes an ancient version string to be logged. Since you are removing the last reference to this 'version' string you should

Re: [PATCH] net: sched: report if filter is too large to dump

From: Roman Kapl Date: Sun, 18 Feb 2018 23:10:47 +0100 > So far, if the filter was too large to fit in the allocated skb, the > kernel did not return any error and stopped dumping. Modify the dumper > so that it returns -ENOMSG when a filter fails to dump and it is the > first

Re: [PATCH net-next] dpaa_eth: fix pause capability advertisement logic

From: Jake Moroni Date: Sun, 18 Feb 2018 15:26:04 -0500 > The ADVERTISED_Asym_Pause bit was being improperly set when both > rx and tx pause were enabled. When rx and tx are both enabled, only > the ADVERTISED_Pause bit is supposed to be set. > > Signed-off-by: Jake Moroni

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Sat, Feb 3, 2018 at 1:15 PM, Xin Long wrote: >>> On 1/30/18 1:57 PM, David Ahern wrote: On 1/30/18 1:08 PM, Daniel Borkmann wrote: > On 01/30/2018 07:32 PM, Cong Wang wrote: >> On Tue, Jan 30, 2018 at 4:09 AM, Dmitry Vyukov >> wrote:

Re: WARNING in check_flush_dependency

On Wed, Jan 24, 2018 at 8:39 AM, Johannes Berg wrote: > On Mon, 2018-01-22 at 23:39 -0800, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on upstream commit >> 0d665e7b109d512b7cae3ccef6e8654714887844 (Fri Jan 19 12:49:24 2018 +) >> mm,

RE: [PATCH net-next] tipc: don't call sock_release() in atomic context

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Paolo Abeni > Sent: Monday, February 19, 2018 19:02 > To: netdev@vger.kernel.org > Cc: Jon Maloy ; Ying Xue > ; David S. Miller

Re: [PATCH RFC 3/3] netfilter: nf_tables: add BPF-based jit infrastructure

From: Pablo Neira Ayuso Date: Mon, 19 Feb 2018 17:37:06 +0100 > From nf_tables_newrule(), this calls nft_jit_rule() that transforms > our internal expression structure layout to abstract syntax tree, then > we walk over this syntax tree to generate the BPF instructions that

Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte Date: Mon, 19 Feb 2018 19:37:30 +0100 > I was speaking of actual *users* as in indiiduals running their own > systems, companies running their own servers/datacenter. The fact that > some ISP (or its supplier) decisdes that one of my IP packets is routed

Re: [PATCH RFC 0/4] net: add bpfilter

From: Arturo Borrero Gonzalez Date: Mon, 19 Feb 2018 19:06:12 +0100 > Yes, probably major datacenters (google? facebook?, amazon?) they > don't even care about what Debian is doing, since they are crafting > their own distro anyway. But there are *a lot* of other people

Re: [PATCH RFC 0/4] net: add bpfilter

From: Phil Sutter Date: Mon, 19 Feb 2018 19:05:51 +0100 > Hi David, > > On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote: >> From: Phil Sutter >> Date: Mon, 19 Feb 2018 18:14:11 +0100 >> >> > OK, so reading between the lines you're saying that nftables

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 12:29:08PM -0500, David Miller wrote: > People with an Android phone in their pocket is using iptables, and > the overhead and performance of those rules really does matter. It > determines how long your battery life is, etc. I am not the android expert.

[PATCH] rds: send: mark expected switch fall-through in rds_rm_size

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1465362 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva --- net/rds/send.c | 2 ++ 1 file changed, 2 insertions(+) diff

Re: [PATCH net-next 0/7] stmmac multi-queue fixes and cleanups

Hi Niklas, On 19-02-2018 17:11, Niklas Cassel wrote: > stmmac multi-queue fixes and cleanups > > Niklas Cassel (7): > net: stmmac: set MSS for each tx DMA channel > net: stmmac: do not clear tx_skbuff entries in > stmmac_xmit()/stmmac_tso_xmit() > net: stmmac: WARN if tx_skbuff entries

Re: [PATCH RFC 0/4] net: add bpfilter

On 19 February 2018 at 16:36, David Miller wrote: > > In my opinion, any resistence to integration with eBPF and XDP will > lead to even less adoption of netfilter as a technology. > > Therefore my plan is to move everything to be integrated around these > important core

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote: > From: Phil Sutter > Date: Mon, 19 Feb 2018 18:14:11 +0100 > > > OK, so reading between the lines you're saying that nftables project > > has failed to provide an adequate successor to iptables? > > Whilst it

Re: [PATCH net] tcp: restrict F-RTO to work-around broken middle-boxes

On Mon, Feb 19, 2018 at 11:17 AM, Teodor Milkov wrote: > On 19.02.2018 15:38, Neal Cardwell wrote: >> >> On Sun, Feb 18, 2018 at 4:02 PM, Teodor Milkov wrote: >>> >>> Hello, >>> >>> I've numerous reports from Windows users that after kernel upgrade from >>> 4.9 >>> to

[PATCH net-next] tipc: don't call sock_release() in atomic context

syzbot reported a scheduling while atomic issue at netns destruction time: BUG: sleeping function called from invalid context at net/core/sock.c:2769 in_atomic(): 1, irqs_disabled(): 0, pid: 85, name: kworker/u4:3 5 locks held by kworker/u4:3/85: #0: ((wq_completion)"%s""netns"){+.+.}, at:

Re: [PATCH RFC 0/4] net: add bpfilter

On 19 February 2018 at 16:27, David Miller wrote: > From: Florian Westphal > Date: Mon, 19 Feb 2018 16:15:55 +0100 > >> Would you be willing to merge nftables into kernel tools directory >> then? > > Did you miss the part where I explained that people

Re: [PATCH RFC 0/4] net: add bpfilter

On 19 February 2018 at 16:36, David Miller wrote: > > I think netfilter is at a real crossroads right now. > I don't think so. The Netfilter Project and the Netfilter Community already "agreed" on nftables and we are working on it. But this isn't a secret, right? We have

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 10:31:39AM -0500, David Miller wrote: > > Why is it practical to replace your kernel but not practical to replace > > a small userspace tool running on top of it? > > The container is just userspace components. Those are really baked in > and are never

Re: [PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

On Mon, Feb 19, 2018 at 12:19:16PM +, David Laight wrote: > This seems to be somewhat excessive 64bit maths on a 32bit system. > It is more than enough to make timelo/timehi 'unsigned int'. Do you see a difference in the generated code? Thanks, Richard

Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte Date: Mon, 19 Feb 2018 18:20:40 +0100 > It's like with any migration. People were using ipchains for a long > time even after iptables existed. Many people simply don't care > about packet filter performance. It's only a small fraction of their >

Re: [PATCH nf] netfilter: IDLETIMER: be syzkaller friendly

On Fri, Feb 16, 2018 at 07:36:28PM -0800, Eric Dumazet wrote: > From: Eric Dumazet > > We had one report from syzkaller [1] > > First issue is that INIT_WORK() should be done before mod_timer() > or we risk timer being fired too soon, even with a 1 second timer. > > Second

Re: [PATCH RFC 0/4] net: add bpfilter

From: Phil Sutter Date: Mon, 19 Feb 2018 18:14:11 +0100 > OK, so reading between the lines you're saying that nftables project > has failed to provide an adequate successor to iptables? Whilst it is great that the atomic table update problem was solved, I think the emphasis on

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 10:36:51AM -0500, David Miller wrote: > nftables has been proported as "better" for years, yet large > institutions did not migrate to it. In fact, they explicitly > disabled NFTABLES in their kernel config. It's like with any migration. People were using

RE: [net-next v2 1/1] tipc: avoid unnecessary copying of bundled messages

> -Original Message- > From: David Laight [mailto:david.lai...@aculab.com] > Sent: Monday, February 19, 2018 14:30 > To: Jon Maloy > Cc: netdev@vger.kernel.org; Mohan Krishna Ghanta Krishnamurthy > ; Tung Quang

Re: [PATCH RFC 0/4] net: add bpfilter

From: Phil Sutter Date: Mon, 19 Feb 2018 18:09:39 +0100 > What puzzles me about your argumentation is that you seem to propose for > the kernel to cover up flaws in userspace. Spinning this concept further > would mean that if there would be an old bug in iproute2 we should think >

[PATCH net-next 0/7] stmmac multi-queue fixes and cleanups

stmmac multi-queue fixes and cleanups Niklas Cassel (7): net: stmmac: set MSS for each tx DMA channel net: stmmac: do not clear tx_skbuff entries in stmmac_xmit()/stmmac_tso_xmit() net: stmmac: WARN if tx_skbuff entries are reused before cleared net: stmmac: rename

[PATCH net-next 1/7] net: stmmac: set MSS for each tx DMA channel

The DMA engine in dwmac4 can segment a large TSO packet to several smaller packets of (max) size Maximum Segment Size (MSS). The DMA engine fetches and saves the MSS via a context descriptor. This context decriptor has to be provided to each tx DMA channel. To ensure that this is done, move

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 10:44:59AM -0500, David Miller wrote: > From: Harald Welte > Date: Mon, 19 Feb 2018 16:38:08 +0100 > > > On Mon, Feb 19, 2018 at 10:27:27AM -0500, David Miller wrote: > >> > Would you be willing to merge nftables into kernel tools

[PATCH net-next 2/7] net: stmmac: do not clear tx_skbuff entries in stmmac_xmit()/stmmac_tso_xmit()

tx_skbuff is initialized to NULL in init_dma_tx_desc_rings(), which is called from ndo_open(). stmmac_tx_clean() frees any non-NULL skb, and sets the tx_skbuff entry to NULL. Hence, there is no need to set skbuff entries to NULL in stmmac_xmit()/stmmac_tso_xmit(), and doing so falsely gives the

[PATCH net-next 3/7] net: stmmac: WARN if tx_skbuff entries are reused before cleared

The current code assumes that a tx_skbuff entry has been cleared by stmmac_tx_clean() before stmmac_xmit()/stmmac_tso_xmit() assigns a new skb to that entry. However, since we never check the current value before overwriting it, it is theoretically possible that a non-NULL value is overwritten.

[PATCH net-next 4/7] net: stmmac: rename dwmac4_tx_queue_routing() to match reality

Looking at dwmac4_tx_queue_routing(), it is obvious that it sets up rx queue routing. Rename dwmac4_tx_queue_routing() to dwmac4_rx_queue_routing() to better match reality. Fixes: abe80fdc6ee6 ("net: stmmac: RX queue routing configuration") Signed-off-by: Niklas Cassel

  1   2   3   >