[PATCH net-next v7] net/tls: Use socket data_ready callback on record availability

On receipt of a complete tls record, use socket's saved data_ready callback instead of state_change callback. In function tls_queue(), the TLS record is queued in encrypted state. But the decryption happen inline when tls_sw_recvmsg() or tls_sw_splice_read() get invoked. So it should be ok to

Re: [PATCH PATCH net-next 10/18] 9p: fix whitespace issues

(removed tons of Cc to make v9fs-developer@ happy - please do include linux-ker...@vger.kernel.org next time though, I only saw this patch by chance snooping at netdev) Stephen Hemminger wrote on Tue, Jul 24, 2018: > Remove trailing whitespace and blank lines at EOF > > Signed-off-by: Stephen

Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink

On Sun, Jul 29, 2018 at 2:23 AM, Moshe Shemesh wrote: > > > On Sat, Jul 28, 2018 at 7:06 PM, Bjorn Helgaas wrote: >> >> On Thu, Jul 26, 2018 at 07:00:20AM -0700, Alexander Duyck wrote: >> > On Thu, Jul 26, 2018 at 12:14 AM, Jiri Pirko wrote: >> > > Thu, Jul 26, 2018 at 02:43:59AM CEST,

Re: [PATCH net-next] virtio_net: force_napi_tx module param.

On Sun, Jul 29, 2018 at 12:01 PM David Miller wrote: > > From: Caleb Raitto > Date: Mon, 23 Jul 2018 16:11:19 -0700 > > > From: Caleb Raitto > > > > The driver disables tx napi if it's not certain that completions will > > be processed affine with tx service. > > > > Its heuristic doesn't

Re: [PATCH net-next] virtio_net: force_napi_tx module param.

On Sun, Jul 29, 2018 at 4:48 PM Michael S. Tsirkin wrote: > > On Sun, Jul 29, 2018 at 09:00:27AM -0700, David Miller wrote: > > From: Caleb Raitto > > Date: Mon, 23 Jul 2018 16:11:19 -0700 > > > > > From: Caleb Raitto > > > > > > The driver disables tx napi if it's not certain that completions

Re: [PATCH net-next] virtio_net: force_napi_tx module param.

From: "Michael S. Tsirkin" Date: Sun, 29 Jul 2018 23:33:20 +0300 > The point really is that tx irq handler needs a lock on the tx queue to > free up skbs, so processing it on another CPU while tx is active causes > cache line bounces. So we want affinity to CPUs that submit to this > queue on

Re: [PATCH net-next] virtio_net: force_napi_tx module param.

On Sun, Jul 29, 2018 at 09:00:27AM -0700, David Miller wrote: > From: Caleb Raitto > Date: Mon, 23 Jul 2018 16:11:19 -0700 > > > From: Caleb Raitto > > > > The driver disables tx napi if it's not certain that completions will > > be processed affine with tx service. > > > > Its heuristic

Re: [pull request][net-next V2 00/12] Mellanox, mlx5 updates 2018-07-27 (Vxlan updates)

From: Saeed Mahameed Date: Fri, 27 Jul 2018 17:06:10 -0700 > This series from Gal and Saeed provides updates to mlx5 vxlan implementation. > > For more information please see tag log below. > > Please pull and let me know if there's any problem. > > V1->V2: > - Drop the rw lock patch. Looks

Re: [PATCH 1/5] net: remove bogus RCU annotations on socket.wq

From: Christoph Hellwig Date: Fri, 27 Jul 2018 16:02:10 +0200 > We never use RCU protection for it, just a lot of cargo-cult > rcu_deference_protects calls. > > Note that we do keep the kfree_rcu call for it, as the references through > struct sock are RCU protected and thus might require a

Re: [PATCH net-next] selftests: mlxsw: qos_dscp_bridge: Fix

From: Petr Machata Date: Sat, 28 Jul 2018 00:48:13 +0200 > There are two problems in this test case: > > - When indexing in bash associative array, the subscript is interpreted as > string, not as a variable name to be expanded. > > - The keys stored to t0s and t1s are not DSCP values, but

Re: [PATCH net-next 0/3] mtu related changes

From: Stephen Hemminger Date: Fri, 27 Jul 2018 13:43:20 -0700 > While looking at other MTU issues, noticed a couple oppurtunties > for improving user experience. Series applied, thanks.

Re: [PATCH net-next] net: dcb: add DSCP to comment about priority selector types

From: Jakub Kicinski Date: Fri, 27 Jul 2018 13:11:00 -0700 > Commit ee2059819450 ("net/dcb: Add dscp to priority selector type") > added a define for the new DSCP selector type created by > IEEE 802.1Qcd, but missed the comment enumerating all selector types. > Update the comment. > >

Re: [PATCHv4 net-next 0/2] route: add support and selftests for directed broadcast forwarding

From: Xin Long Date: Fri, 27 Jul 2018 16:37:27 +0800 > Patch 1/2 is the feature and 2/2 is the selftest. Check the changelog > on each of them to know the details. > > v1->v2: > - fix a typo in changelog. > - fix an uapi break that Davide noticed. > - flush route cache when bc_forwarding

Re: [net-next v1] net/ipv6: allow any source address for sendmsg pktinfo with ip_nonlocal_bind

From: Vincent Bernat Date: Wed, 25 Jul 2018 13:19:13 +0200 > When freebind feature is set of an IPv6 socket, any source address can > be used when sending UDP datagrams using IPv6 PKTINFO ancillary > message. Global non-local bind feature was added in commit > 35a256fee52c ("ipv6: Nonlocal

Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver

> The embedded PHYs are only connected to the switch in this SoC and on > all other SoCs from this line I am aware of. Hi Hauke O.K, then it makes sense to have it part of the switch driver. > The firmware is 64KBytes big and we have to load that into continuous > memory which is then used by

Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver

On 07/29/2018 06:40 PM, Andrew Lunn wrote: >> I am thinking about merging this into the switch driver, then we do not >> have to configure the dependency any more. > > Hi Hauke > > Are there any PHYs which are not part of the switch? The embedded PHYs are only connected to the switch in this

[PATCH bpf v2] tools/bpftool: fix a percpu_array map dump problem

I hit the following problem when I tried to use bpftool to dump a percpu array. $ sudo ./bpftool map show 61: percpu_array name stub flags 0x0 key 4B value 4B max_entries 1 memlock 4096B ... $ sudo ./bpftool map dump id 61 bpftool: malloc.c:2406: sysmalloc: Assertion

Re: [PATCH bpf] tools/bpftool: fix a percpu_array map dump problem

On 7/28/18 12:14 PM, Daniel Borkmann wrote: On 07/28/2018 01:11 AM, Yonghong Song wrote: I hit the following problem when I tried to use bpftool to dump a percpu array. $ sudo ./bpftool map show 61: percpu_array name stub flags 0x0 key 4B value 4B max_entries 1 memlock

Re: [PATCH 4/4] net: dsa: Add Lantiq / Intel DSA driver for vrx200

> >> +static const struct gswip_rmon_cnt_desc gswip_rmon_cnt[] = { > >> + /** Receive Packet Count (only packets that are accepted and not > >> discarded). */ > >> + MIB_DESC(1, 0x1F, "RxGoodPkts"), > >> + /** Receive Size 1024-1522 (or more, if configured) Packet Count. */ > >> + MIB_DESC(1,

Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver

> I am thinking about merging this into the switch driver, then we do not > have to configure the dependency any more. Hi Hauke Are there any PHYs which are not part of the switch? Making it part of the switch driver would make sense. Are there any backwards compatibility issues? I don't

Re: [PATCH 4/4] net: dsa: Add Lantiq / Intel DSA driver for vrx200

On 07/25/2018 06:12 PM, Andrew Lunn wrote: >> LANTIQ MIPS ARCHITECTURE >> M: John Crispin >> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig >> index 2b81b97e994f..f1280aa3f9bd 100644 >> --- a/drivers/net/dsa/Kconfig >> +++ b/drivers/net/dsa/Kconfig >> @@ -23,6 +23,14 @@ config

Re: [PATCH net-next] virtio_net: force_napi_tx module param.

From: Caleb Raitto Date: Mon, 23 Jul 2018 16:11:19 -0700 > From: Caleb Raitto > > The driver disables tx napi if it's not certain that completions will > be processed affine with tx service. > > Its heuristic doesn't account for some scenarios where it is, such as > when the queue pair count

Re: [PATCH] bpf: verifier: BPF_MOV don't mark dst reg if src == dst

On Thu, Jul 26, 2018 at 1:08 AM, Arthur Fabre wrote: > When check_alu_op() handles a BPF_MOV between two registers, > it calls check_reg_arg() on the dst register, marking it as unbounded. > If the src and dst register are the same, this marks the src as > unbounded, which can lead to unexpected

Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver

On 07/29/2018 05:51 PM, Andrew Lunn wrote: > On Sun, Jul 29, 2018 at 04:03:10PM +0200, Hauke Mehrtens wrote: >> On 07/25/2018 05:28 PM, Andrew Lunn wrote: + /* Make sure the firmware of the embedded GPHY is loaded before, + * otherwise they will not be detectable on the MDIO bus.

Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver

On Sun, Jul 29, 2018 at 04:03:10PM +0200, Hauke Mehrtens wrote: > On 07/25/2018 05:28 PM, Andrew Lunn wrote: > >> + /* Make sure the firmware of the embedded GPHY is loaded before, > >> + * otherwise they will not be detectable on the MDIO bus. > >> + */ > >> + of_for_each_phandle(, err, np,

Re: [PATCH bpf] bpf: fix bpf_skb_load_bytes_relative pkt length check

On Sat, Jul 28, 2018 at 10:04 PM, Daniel Borkmann wrote: > The len > skb_headlen(skb) cannot be used as a maximum upper bound > for the packet length since it does not have any relation to the full > linear packet length when filtering is used from upper layers (e.g. > in case of reuseport BPF

Re: pull-request: can-next 2018-01-16,pull-request: can-next 2018-01-16

From: Marc Kleine-Budde Date: Fri, 27 Jul 2018 11:40:10 +0200 > this is a pull request for net-next/master consisting of 38 patches. ... > The following changes since commit ecbcd689d74a394b711d2360aef7e5d007ec9d98: > > Merge tag 'mlx5e-updates-2018-07-26' of >

RE: Done

$ 3million donated to you, E-mail tsouam...@gmail.com for funds confirmation.

Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver

On 07/25/2018 05:28 PM, Andrew Lunn wrote: >> +/* Make sure the firmware of the embedded GPHY is loaded before, >> + * otherwise they will not be detectable on the MDIO bus. >> + */ >> +of_for_each_phandle(, err, np, "lantiq,phys", NULL, 0) { >> +phy_np = it.node; >> +

Re: [PATCH 2/4] net: dsa: Add Lantiq / Intel GSWIP tag support

On 07/25/2018 04:20 PM, Andrew Lunn wrote: > On Sat, Jul 21, 2018 at 09:13:56PM +0200, Hauke Mehrtens wrote: >> This handles the tag added by the PMAC on the VRX200 SoC line. >> >> The GSWIP uses internally a GSWIP special tag which is located after the >> Ethernet header. The PMAC which connects

partnership offer

I want us to join hands as partners because i have a deal for you

[PATCH rdma-next 26/27] RDMA/mlx5: Add NIC TX namespace when getting a flow table

From: Mark Bloch Add the ability to get a NIC TX flow table when using _get_flow_table(). This will allow to create a matcher and a flow rule on the NIC TX path. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/flow.c| 1 +

[PATCH rdma-next 27/27] RDMA/mlx5: Allow creating a matcher for a NIC TX flow table

From: Mark Bloch Currently a matcher can only be created and attached to a NIC RX flow table. Extend it to allow it on NIC TX flow tables as well. In order to achieve that, We: 1) Expose a new attribute: MLX5_IB_ATTR_FLOW_MATCHER_FLOW_FLAGS. enum ib_flow_flags is used as valid flags. Only

[PATCH rdma-next 17/27] RDMA/mlx5: Add new flow action verb, packet reformat

From: Mark Bloch For now, only add L2_TUNNEL_TO_L2 option, for example this can be used to decap VXLAN packets. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/flow.c | 76 ++- drivers/infiniband/hw/mlx5/mlx5_ib.h

[PATCH rdma-next 25/27] RDMA/mlx5: Add flow actions support to DEVX create flow

From: Mark Bloch Support attaching flow actions to a flow rule via DEVX. For now only NIC RX path is supported. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/flow.c| 21 - include/uapi/rdma/mlx5_user_ioctl_cmds.h | 1 + 2

[PATCH rdma-next 23/27] RDMA/mlx5: Refactor flow action parsing to be more generic

From: Mark Bloch Make the parsing of flow actions more generic so it could be used by DEVX create flow. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/main.c| 13 +++-- drivers/infiniband/hw/mlx5/mlx5_ib.h | 3 +++ 2 files changed, 10

[PATCH rdma-next 24/27] RDMA/mlx5: Refactor DEVX flow creation

From: Mark Bloch Move struct mlx5_flow_act to be passed from the METHOD entry point, this will allow to add support for flow action for the DEVX path. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/flow.c| 4 +++-

[PATCH rdma-next 18/27] RDMA/mlx5: Enable attaching DECAP action to steering flows

From: Mark Bloch Any matching flow will be stripped of it's VXLAN tunnel, only the inner L2 onward is left. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/main.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH rdma-next 21/27] RDMA/mlx5: Enable attaching packet reformat action to steering flows

From: Mark Bloch Any matching rules will be mutated based on the packet reformat context which is attached to that given flow rule. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/main.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH rdma-next 16/27] RDMA/uverbs: Add generic function to fill in flow action object

From: Mark Bloch Refactor the initialization of a flow action object to a common function. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/core/uverbs_std_types_flow_action.c | 7 ++- drivers/infiniband/hw/mlx5/flow.c | 8 +++-

[PATCH rdma-next 22/27] IB/uverbs: Add IDRs array attribute type to ioctl() interface

From: Guy Levi Methods sometimes need to get a flexible set of idrs and not a strict set as can be achieved today by the conventional idr attribute. This is an idrs-array-like behavior. Since this may be popular used, we add a new IDRS_ARRAY attribute to the generic uverbs ioctl layer. This

[PATCH mlx5-next 08/27] net/mlx5: Expose new packet reformat capabilities

From: Mark Bloch Expose new abilities when creating a packet reformat context. The new types which can be created are: MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL: Ability to create generic encap operation to be done by the HW. MLX5_REFORMAT_TYPE_L3_TUNNEL_TO_L2: Ability to create generic decap

[PATCH rdma-next 14/27] RDMA/mlx5: Enable attaching modify header to steering flows

From: Mark Bloch When creating a flow steering rule, allow the user to attach a modify header action. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/main.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/infiniband/hw/mlx5/main.c

[PATCH rdma-next 15/27] RDMA/mlx5: Enable decap and packet reformat on flow tables

From: Mark Bloch If NIC RX flow tables support decap operation, enable it on creation. If NIC TX flow tables support reformat operation, enable it on creation. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/main.c | 17 + 1 file

[PATCH rdma-next 20/27] RDMA/mlx5: Enable reformat on NIC RX if supported

From: Mark Bloch A L3_TUNNEL_TO_L2 decap flow action requires to enable the encap bit on the Flow table, enable it if supported. This will allow to attach those flow actions to NIC RX steering. We don't enable if running on a representor. Signed-off-by: Mark Bloch Signed-off-by: Leon

[PATCH rdma-next 19/27] RDMA/mlx5: Extend packet reformat verbs

From: Mark Bloch We expose new actions: L2_TO_L2_TUNNEL - A generic encap from L2 to L2, the data passed should be the encapsulating headers. L3_TUNNEL_TO_L2 - Will do decap where the inner packet starts from L3, the data should be mac or mac + vlan (14 or 18 bytes). L2_TO_L3_TUNNEL - Will do

[PATCH rdma-next 11/27] RDMA/mlx5: Add NIC TX steering support

From: Mark Bloch Add support for proper NIC TX (egress) steering with multiple priorities. We expose the same number of priorities as the bypass (NIC RX) steering. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/main.c| 28

[PATCH rdma-next 13/27] RDMA/mlx5: Add a new flow action verb, modify header

From: Mark Bloch Expose the ability to create a flow action which mutates packet headers. The data passed from userspace should be modify header actions as defined by Mellanox's PRM. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/infiniband/hw/mlx5/flow.c | 128

[PATCH rdma-next 12/27] RDMA/uverbs: Add UVERBS_ATTR_CONST_IN to the specs language

From: Mark Bloch This makes it clear and safe to access constants past in from user space. We define a consistent ABI of u64 for all constants, and verify that the data passed in can be represented by the type the user supplies. The expectation is this will always be used with an enum declaring

[PATCH mlx5-next 10/27] net/mlx5: Export packet reformat alloc/dealloc functions

From: Mark Bloch This will allow for the RDMA side to allocate packet reformat context. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c| 2 ++ drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h | 8

[PATCH mlx5-next 04/27] net/mlx5: Add support for more namespaces when allocating modify header

From: Mark Bloch There are RX and TX flow steering namespaces with different number of actions. Initialize them accordingly. Signed-off-by: Mark Bloch Reviewed-by: Or Gerlitz Signed-off-by: Leon Romanovsky --- drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c | 5 + 1 file changed, 5

[PATCH mlx5-next 06/27] net/mlx5: Move header encap type to IFC header file

From: Mark Bloch Those bits are hardware specification and should be defined at the IFC header file. Signed-off-by: Mark Bloch Reviewed-by: Or Gerlitz Signed-off-by: Leon Romanovsky --- drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 5 - include/linux/mlx5/mlx5_ifc.h

[PATCH mlx5-next 09/27] net/mlx5: Pass a namespace for packet reformat ID allocation

From: Mark Bloch Currently we attach packet reformat actions only to the FDB namespace. In preparation to be able to use that for NIC steering, pass the actual namespace as a parameter. Signed-off-by: Mark Bloch Reviewed-by: Or Gerlitz Signed-off-by: Leon Romanovsky ---

[PATCH mlx5-next 07/27] {net, RDMA}/mlx5: Rename encap to reformat packet

From: Mark Bloch Renames all encap mlx5_{core,ib} code to use the new naming of packet reformat. No functional change is introduced. This is done because the original naming didn't reflect correctly the operation being done by this action. For example not only can we encapsulate a packet, but

[PATCH mlx5-next 05/27] net/mlx5: Break encap/decap into two separated flow table creation flags

From: Mark Bloch Today we are able to attach encap and decap actions only to the FDB. In preparation to enable those actions on the NIC flow tables, break the single flag into two. Those flags control whatever a decap or encap operations can be attached to the flow table created. For FDB, if

[PATCH rdma-next 00/27] Flow actions to mutate packets

From: Leon Romanovsky Hi, This is PATCH variant of RFC posted in previous week to the ML. https://patchwork.ozlabs.org/cover/944184/ Changelog: RFC -> v0: * Patch 1 a new patch which refactors the logic when getting a flow namespace. * Patch 2 was split into two. * Patch 3: Fixed a

[PATCH mlx5-next 02/27] net/mlx5: Add proper NIC TX steering flow tables support

From: Mark Bloch Expose the ability to add steering rules to NIC TX flow tables. For now, we are only adding TX bypass (egress) which is used by the RDMA side. This will allow an administrator to control outgoing traffic and tweak it if needed, for example preforming encapsulation or rewriting

[PATCH mlx5-next 01/27] net/mlx5: Cleanup flow namespace getter switch logic

From: Mark Bloch Refactor the switch logic so it's simpler to follow and understand. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 22 +- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git

[PATCH mlx5-next 03/27] net/mlx5: Export modify header alloc/dealloc functions

From: Mark Bloch Those functions will be used by the RDMA side to create modify header actions to be attached to flow steering rules via verbs. Signed-off-by: Mark Bloch Signed-off-by: Leon Romanovsky --- drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c| 2 ++

[no subject]

-- Did you receive our representative email ?

Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink

On Sat, Jul 28, 2018 at 7:06 PM, Bjorn Helgaas wrote: > On Thu, Jul 26, 2018 at 07:00:20AM -0700, Alexander Duyck wrote: > > On Thu, Jul 26, 2018 at 12:14 AM, Jiri Pirko wrote: > > > Thu, Jul 26, 2018 at 02:43:59AM CEST, jakub.kicin...@netronome.com > wrote: > > >>On Wed, 25 Jul 2018 08:23:26

[PATCH rdma-next 10/10] IB/ipoib: Consolidate checking of the proposed child interface

From: Jason Gunthorpe Move all the checking for pkey and other validity to the __ipoib_vlan_add function. This removes the last difference from the control flow of the __ipoib_vlan_add to make the overall design simpler to understand. Signed-off-by: Jason Gunthorpe Signed-off-by: Erez Shitrit

[PATCH rdma-next 06/10] RDMA/netdev: Use priv_destructor for netdev cleanup

From: Jason Gunthorpe Now that the unregister_netdev flow for IPoIB no longer relies on external code we can now introduce the use of priv_destructor and needs_free_netdev. The rdma_netdev flow is switched to use the netdev common priv_destructor instead of the special free_rdma_netdev and the

[PATCH rdma-next 09/10] IB/ipoib: Maintain the child_intfs list from ndo_init/uninit

From: Jason Gunthorpe This fixes a bug in the netlink path where the vlan_rwsem was not held around __ipoib_vlan_add causing the child_intfs to be manipulated unsafely. In the process this greatly simplifies the vlan_rwsem write side locking to only cover a single non-sleeping statement. This

[PATCH rdma-next 00/10] IPoIB uninit

From: Leon Romanovsky IP link was broken due to the changes in IPoIB for the rdma_netdev support after commit cd565b4b51e5 ("IB/IPoIB: Support acceleration options callbacks"). This patchset restores IPoIB pkey creation and removal using rtnetlink. It is completely rewritten variant of

[PATCH rdma-next 07/10] IB/ipoib: Get rid of the sysfs_mutex

From: Jason Gunthorpe This mutex was introduced to deal with the deadlock formed by calling unregister_netdev from within the sysfs callback of a netdev. Now that we have priv_destructor and needs_free_netdev we can switch to the more targeted solution of running the unregister from a work

[PATCH rdma-next 05/10] IB/ipoib: Move init code to ndo_init

From: Jason Gunthorpe Now that we have a proper ndo_uninit, move code that naturally pairs with the ndo_uninit into ndo_init. This allows the netdev core to natually handle ordering. This fixes the situation where register_netdev can fail before calling ndo_init, in which case it wouldn't call

[PATCH rdma-next 01/10] IB/ipoib: Get rid of IPOIB_FLAG_GOING_DOWN

From: Jason Gunthorpe This essentially duplicates the netdev's reg_state, so just use that directly. The reg_state is updated under the rntl_lock, and all places using GOING_DOWN already acquire the rtnl_lock so checking is safe. Since the only place we use GOING_DOWN is for the parent device

[PATCH rdma-next 03/10] IB/ipoib: Move all uninit code into ndo_uninit

From: Jason Gunthorpe Currently uninit is sometimes done twice in error flows, and is sprinkled a bit all over the place. Improve the clarity of the design by moving all uninit only into ndo_uinit. Some duplication is removed: - Sometimes IPOIB_STOP_NEIGH_GC was done before unregister, but

[PATCH rdma-next 04/10] IB/ipoib: Make ipoib_neigh_hash_uninit fully fence its work

From: Erez Shitrit The neigh_reap_task is self restarting, but so long as we call cancel_delayed_work_sync() it will be guaranteed to not be running and never start again. Thus there is no longer any purpose to IPOIB_STOP_NEIGH_GC (which was racy/buggy anyhow), so remove it too. This fixes a

[PATCH rdma-next 08/10] IB/ipoib: Do not remove child devices from within the ndo_uninit

From: Jason Gunthorpe Switching to priv_destructor and needs_free_netdev created a subtle ordering problem in ipoib_remove_one. Now that unregister_netdev frees the netdev and priv we must ensure that the children are unregistered before trying to unregister the parent, or child unregister will

[PATCH rdma-next 02/10] IB/ipoib: Use cancel_delayed_work_sync for neigh-clean task

From: Erez Shitrit The neigh_reap_task is self restarting, but so long as we call cancel_delayed_work_sync() it will be guaranteed to not be running and never start again. Thus we don't need to have the racy IPOIB_STOP_NEIGH_GC bit, or the confusing mismatch of places sometimes calling

Re: [patch net-next] net: sched: don't dump chains only held by actions

Sat, Jul 28, 2018 at 07:39:36PM CEST, xiyou.wangc...@gmail.com wrote: >On Sat, Jul 28, 2018 at 10:20 AM Cong Wang wrote: >> >> On Fri, Jul 27, 2018 at 12:47 AM Jiri Pirko wrote: >> > >> > From: Jiri Pirko >> > >> > In case a chain is empty and not explicitly created by a user, >> > such chain

Re: [PATCH v5 bpf-next 6/9] bpf: Make redirect_info accessible from modules

Hi Toshiaki, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on bpf-next/master] url: https://github.com/0day-ci/linux/commits/Toshiaki-Makita/net-Export-skb_headers_offset_update/20180729-094722 base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf

RE: [net-next v6 1/2] net/tls: Use socket data_ready callback on record availability

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Sunday, July 29, 2018 11:48 AM > To: Vakul Garg > Cc: netdev@vger.kernel.org; bor...@mellanox.com; > avia...@mellanox.com; davejwat...@fb.com > Subject: Re: [net-next v6 1/2] net/tls: Use socket data_ready

Re: [net-next v6 1/2] net/tls: Use socket data_ready callback on record availability

From: Vakul Garg Date: Sun, 29 Jul 2018 06:01:29 + > Could you please correct me if my counter-reasoning behind changing > the socket callback is wrong? Ok, after stufying the code a bit I agree with your analysis.

Re: [PATCH][net-next] openvswitch: eliminate cpu_used_mask from sw_flow

From: Li RongQing Date: Fri, 27 Jul 2018 16:03:57 +0800 > The size of struct cpumask varies with CONFIG_NR_CPUS, some config > CONFIG_NR_CPUS is very larger, like 5120, struct cpumask will take > 640 bytes, if there is thousands of flows, it will take lots of > memory > > cpu_used_mask has two

RE: [net-next v6 1/2] net/tls: Use socket data_ready callback on record availability

Hi David Could you please correct me if my counter-reasoning behind changing the socket callback is wrong? Thanks & Regards Vakul > -Original Message- > From: Vakul Garg > Sent: Wednesday, July 25, 2018 11:22 AM > To: David Miller > Cc: netdev@vger.kernel.org; bor...@mellanox.com; >