[PATCH V2 net-next 00/11] add some new features and fix some bugs

This patchset adds 3 ethtool features: get_channels, get_coalesce and get_coalesce, and fix some bugs. [patch 1/11] adds ethtool_ops.get_channels (ethtool -l) support for VF. [patch 2/11] removes TSO config command from VF driver, as only main PF can config TSO MSS length according to hardware.

[PATCH V2 net-next 09/11] net: hns3: add int_gl_idx setup for TX and RX queues

From: Fuyun Liang If the int_gl_idx does not be set, the default interrupt coalesce index is 0. The TX queues and the RX queues will both use the GL0 as the interrupt coalesce GL switch. But it should be GL1 for TX queues and GL0 for RX queues. This patch adds the

[PATCH V2 net-next 01/11] net: hns3: add ethtool_ops.get_channels support for VF

This patch supports the ethtool's get_channels() for VF. Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 1 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 30 ++ 2 files changed, 31 insertions(+) diff --git

[PATCH V2 net-next 05/11] net: hns3: refactor interrupt coalescing init function

From: Fuyun Liang In the hardware, the coalesce configurable registers include GL0, GL1, GL2. In the driver, the TX queues use the register GL1 and the RX queues use the register GL0. This function initializes the configuration of the interrupt coalescing, but does not

[PATCH V2 net-next 04/11] net: hns3: add ethtool_ops.set_coalesce support to PF

From: Fuyun Liang This patch adds ethtool_ops.set_coalesce support to PF. Signed-off-by: Fuyun Liang Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 34 -

[PATCH V2 net-next 03/11] net: hns3: add ethtool_ops.get_coalesce support to PF

From: Fuyun Liang This patch adds ethtool_ops.get_coalesce support to PF. Whilst our hardware supports per queue values, external interfaces support only a single shared value. As such we use the values for queue 0. Signed-off-by: Fuyun Liang

[PATCH V2 net-next 11/11] net: hns3: check for NULL function pointer in hns3_nic_set_features

From: Jian Shen It's necessary to check hook whether being defined before calling, improve the reliability. Signed-off-by: Jian Shen Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 -- 1

[PATCH V2 net-next 08/11] net: hns3: change the unit of GL value macro

From: Fuyun Liang Previously, driver used 2us as the GL unit. The time unit ethtool command "-c" and "-C" use is 1us, so now the GL unit driver uses actually is 1us. This patch changes the unit of GL value macro from 2us to 1us. Signed-off-by: Fuyun Liang

[PATCH net-next v5 1/4] phy: add 2.5G SGMII mode to the phy_mode enum

This patch adds one more generic PHY mode to the phy_mode enum, to allow configuring generic PHYs to the 2.5G SGMII mode by using the set_mode callback. Signed-off-by: Antoine Tenart --- include/linux/phy/phy.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH net-next v5 4/4] net: mvpp2: 2500baseX support

This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses nearly the same code path. Signed-off-by: Antoine Tenart Reviewed-by: Andrew Lunn ---

[PATCH net-next v5 2/4] phy: cp110-comphy: 2.5G SGMII mode

This patch allow the CP100 comphy to configure some lanes in the 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the same code path. Signed-off-by: Antoine Tenart --- drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++--- 1

[PATCH net-next v5 3/4] net: mvpp2: 1000baseX support

This patch adds the 1000Base-X PHY mode support in the Marvell PPv2 driver. 1000Base-X is quite close the SGMII and uses nearly the same code path. Signed-off-by: Antoine Tenart --- drivers/net/ethernet/marvell/mvpp2.c | 45

[PATCH net-next v5 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

Hi all, This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2 driver. In order to use it, the 2.5 SGMII mode is added in the Marvell common PHY driver (cp110-comphy). This was tested on a mcbin. All patches should probably go through net-next as patch 4/4 depends on patch 1/4 to

[PATCH V2 net-next 02/11] net: hns3: remove TSO config command from VF driver

Only main PF can config TSO MSS length according to hardware. This patch removes TSO config command from VF driver. Signed-off-by: Peng Li --- .../net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 8 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c| 20

Re: [PATCH net-next] net: phy: Have __phy_modify return 0 on success

Hello! On 1/11/2018 11:55 PM, Andrew Lunn wrote: __phy_modify would return the old value of the register before it was modified. Thus on success, it does not return 0, but a positive value. Thus functions using phy_modify, which is a wrapper around __phy_modify, can start returning > 0 on

Re: [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

Hi David, On Thu, Jan 11, 2018 at 11:32:03AM -0500, David Miller wrote: > > Actually, this introduced build warnings, I'm reverting. Please fix this > and repost. The warning points a real issue. I'm sorry about that, seems like I forgot to test this one after the last change... I'll send a

Re: [PATCH 10/18] qla2xxx: prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 02:15:12PM -0800, Dan Williams wrote: > On Sat, Jan 6, 2018 at 1:03 AM, Greg KH wrote: > > On Fri, Jan 05, 2018 at 05:10:48PM -0800, Dan Williams wrote: > >> Static analysis reports that 'handle' may be a user controlled value > >> that is used

[PATCH net] ipv6: ip6_make_skb() needs to clear cork.base.dst

From: Eric Dumazet In my last patch, I missed fact that cork.base.dst was not initialized in ip6_make_skb() : If ip6_setup_cork() returns an error, we might attempt a dst_release() on some random pointer. Fixes: 862c03ee1deb ("ipv6: fix possible mem leaks in

Re: [PATCH v7 7/8] dt-bindings: can: m_can: Document new can transceiver binding

Hi Rob, On Friday 12 January 2018 01:50 AM, Rob Herring wrote: > On Wed, Jan 10, 2018 at 4:55 AM, Faiz Abbas wrote: >> From: Franklin S Cooper Jr >> >> Add information regarding can-transceiver binding. This is especially >> important for MCAN since the IP

[RFC PATCH net-next v2 0/2] Enable virtio to act as a backup for a passthru device

This patch series extends virtio_net to take over VF datapath by simulating a transparent bond without creating any additional netdev. I understand that there are some comments suggesting an alternate model that is based on 3 driver model(virtio_net, VF driver, a new driver virt_bond that acts

[RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

This feature bit can be used by hypervisor to indicate virtio_net device to act as a backup for another device with the same MAC address. Signed-off-by: Sridhar Samudrala --- drivers/net/virtio_net.c| 2 +- include/uapi/linux/virtio_net.h | 3 +++ 2 files

[RFC PATCH 1/1] qemu: Introduce VIRTIO_NET_F_BACKUP feature bit to virtio_net

This feature bit can be used by hypervisor to indicate virtio_net device to act as a backup for another device with the same MAC address. Signed-off-by: Sridhar Samudrala diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c index cd63659140..fa47e723b9 100644

[RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available

This patch enables virtio_net to switch over to a VF datapath when a VF netdev is present with the same MAC address. The VF datapath is only used for unicast traffic. Broadcasts/multicasts go via virtio datapath so that east-west broadcasts don't use the PCI bandwidth. It allows live migration of

[patch iproute2 v10 1/2] lib/libnetlink: Add a new function rtnl_talk_iov

rtnl_talk can only send a single message to kernel. Add a new function rtnl_talk_iov that can send multiple messages to kernel. rtnl_talk_iov takes struct iovec * and iovlen as arguments. Signed-off-by: Chris Mi Signed-off-by: David Ahern ---

[patch iproute2 v10 2/2] tc: Add batchsize feature for filter and actions

Currently in tc batch mode, only one command is read from the batch file and sent to kernel to process. With this support, at most 128 commands can be accumulated before sending to kernel. Now it only works for the following successive commands: 1. filter add/delete/change/replace 2. actions

[patch iproute2 v10 0/2] tc: Add batchsize feature to batch mode

Currently in tc batch mode, only one command is read from the batch file and sent to kernel to process. With this patchset, at most 128 commands can be accumulated before sending to kernel. We introduced a new function in patch 1 to support for sending multiple messages. In patch 2, we add this

[bpf-next PATCH v3 4/7] bpf: sockmap sample, report bytes/sec

Report bytes/sec sent as well as total bytes. Useful to get rough idea how different configurations and usage patterns perform with sockmap. Signed-off-by: John Fastabend --- samples/sockmap/sockmap_user.c | 37 - 1 file changed,

[bpf-next PATCH v3 6/7] bpf: sockmap put client sockets in blocking mode

Put client sockets in blocking mode otherwise with sendmsg tests its easy to overrun the socket buffers which results in the test being aborted. The original non-blocking was added to handle listen/accept with a single thread the client/accepted sockets do not need to be non-blocking.

[bpf-next PATCH v3 7/7] bpf: sockmap set rlimit

Avoid extra step of setting limit from cmdline and do it directly in the program. Signed-off-by: John Fastabend --- samples/sockmap/sockmap_user.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/samples/sockmap/sockmap_user.c

[bpf-next PATCH v3 2/7] bpf: add sendmsg option for testing BPF programs

When testing BPF programs using sockmap I often want to have more control over how sendmsg is exercised. This becomes even more useful as new sockmap program types are added. This adds a test type option to select type of test to run. Currently, only "ping" and "sendmsg" are supported, but more

[bpf-next PATCH v3 5/7] bpf: sockmap sample add base test without any BPF for comparison

Add a base test that does not use BPF hooks to test baseline case. Signed-off-by: John Fastabend --- samples/sockmap/sockmap_user.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/samples/sockmap/sockmap_user.c

[bpf-next PATCH v3 3/7] bpf: sockmap sample, use fork() for send and recv

Currently for SENDMSG tests first send completes then recv runs. This does not work well for large data sizes and/or many iterations. So fork the recv and send handler so that we run both send and recv. In the future we can add a parameter to do more than a single fork of tx/rx. With this we can

[bpf-next PATCH v3 1/7] bpf: refactor sockmap sample program update for arg parsing

sockmap sample program takes arguments from cmd line but it reads them in using offsets into the array. Because we want to add more arguments in the future lets do proper argument handling. Also refactor code to pull apart sock init and ping/pong test. This allows us to add new tests in the

[bpf-next PATCH v3 0/7] sockmap sample update

The sockmap sample is pretty simple at the moment. All it does is open a few sockets attach BPF programs/sockmaps and sends a few packets. However, for testing and debugging I wanted to have more control over the sendmsg format and data than provided by tools like iperf3/netperf, etc. The reason

Re: [bpf-next PATCH v2 1/7] bpf: refactor sockmap sample program update for arg parsing

On 01/11/2018 08:31 PM, John Fastabend wrote: > On 01/10/2018 05:25 PM, Daniel Borkmann wrote: >> On 01/10/2018 07:39 PM, John Fastabend wrote: >>> sockmap sample program takes arguments from cmd line but it reads them >>> in using offsets into the array. Because we want to add more arguments >>>

Re: [bpf-next PATCH v2 3/7] bpf: sockmap sample, use fork() for send and recv

On 01/10/2018 05:31 PM, Daniel Borkmann wrote: > On 01/10/2018 07:39 PM, John Fastabend wrote: >> Currently for SENDMSG tests first send completes then recv runs. This >> does not work well for large data sizes and/or many iterations. So >> fork the recv and send handler so that we run both send

Re: [bpf-next PATCH v2 1/7] bpf: refactor sockmap sample program update for arg parsing

On 01/10/2018 05:25 PM, Daniel Borkmann wrote: > On 01/10/2018 07:39 PM, John Fastabend wrote: >> sockmap sample program takes arguments from cmd line but it reads them >> in using offsets into the array. Because we want to add more arguments >> in the future lets do proper argument handling. >>

[PATCH bpf-next v2 03/15] bpf: hashtab: move checks out of alloc function

Use the new callback to perform allocation checks for hash maps. Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet --- kernel/bpf/hashtab.c | 55 +--- 1 file changed, 39

[PATCH bpf-next v2 07/15] bpf: offload: add map offload infrastructure

BPF map offload follow similar path to program offload. At creation time users may specify ifindex of the device on which they want to create the map. Map will be validated by the kernel's .map_alloc_check callback and device driver will be called for the actual allocation. Map will have an

[PATCH bpf-next v2 04/15] bpf: add helper for copying attrs to struct bpf_map

All map types reimplement the field-by-field copy of union bpf_attr members into struct bpf_map. Add a helper to perform this operation. Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet Acked-by: Alexei Starovoitov

[PATCH bpf-next v2 06/15] bpf: offload: factor out netdev checking at allocation time

Add a helper to check if netdev could be found and whether it has .ndo_bpf callback. There is no need to check the callback every time it's invoked, ndos can't reasonably be swapped for a set without .ndp_bpf while program is loaded. bpf_dev_offload_check() will also be used by map offload.

[PATCH bpf-next v2 15/15] nfp: bpf: implement bpf map offload

Plug in to the stack's map offload callbacks for BPF map offload. Get next call needs some special handling on the FW side, since we can't send a NULL pointer to the FW there is a get first entry FW command. Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet

[PATCH bpf-next v2 01/15] bpf: add map_alloc_check callback

.map_alloc callbacks contain a number of checks validating user- -provided map attributes against constraints of a particular map type. For offloaded maps we will need to check map attributes without actually allocating any memory on the host. Add a new callback for validating attributes before

[PATCH bpf-next v2 09/15] nfp: bpf: add basic control channel communication

For map support we will need to send and receive control messages. Add basic support for sending a message to FW, and waiting for a reply. Control messages are tagged with a 16 bit ID. Add a simple ID allocator and make sure we don't allow too many messages in flight, to avoid request <> reply

[PATCH bpf-next v2 10/15] nfp: bpf: implement helpers for FW map ops

Implement calls for FW map communication. Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet --- drivers/net/ethernet/netronome/nfp/bpf/cmsg.c | 210 +- drivers/net/ethernet/netronome/nfp/bpf/fw.h |

[PATCH bpf-next v2 08/15] nfp: bpf: add map data structure

To be able to split code into reasonable chunks we need to add the map data structures already. Later patches will add code piece by piece. Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet ---

[PATCH bpf-next v2 12/15] nfp: bpf: add helpers for updating immediate instructions

Immediate loads are used to load the return address of a helper. We need to be able to update those loads for relocations. Immediate loads can be slightly more complex and spread over two instructions in general, but here we only care about simple loads of small (< 65k) constants, so complex cases

[PATCH bpf-next v2 11/15] nfp: bpf: parse function call and map capabilities

Parse helper function and supported map FW TLV capabilities. Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet --- drivers/net/ethernet/netronome/nfp/bpf/fw.h | 16 + drivers/net/ethernet/netronome/nfp/bpf/main.c |

[PATCH bpf-next v2 13/15] nfp: bpf: add verification and codegen for map lookups

Verify our current constraints on the location of the key are met and generate the code for calling map lookup on the datapath. New relocation types have to be added - for helpers and return addresses. Signed-off-by: Jakub Kicinski ---

[PATCH bpf-next v2 14/15] nfp: bpf: add support for reading map memory

Map memory needs to use 40 bit addressing. Add handling of such accesses. Since 40 bit addresses are formed by using both 32 bit operands we need to pre-calculate the actual address instead of adding in the offset inside the instruction, like we did in 32 bit mode. Signed-off-by: Jakub Kicinski

[PATCH bpf-next v2 02/15] bpf: hashtab: move attribute validation before allocation

Number of attribute checks are currently performed after hashtab is already allocated. Move them to be able to split them out to the check function later on. Checks have to now be performed on the attr union directly instead of the members of bpf_map, since bpf_map will be allocated later. No

[PATCH bpf-next v2 00/15] bpf: support creating maps on networking devices

Hi! This set adds support for creating maps on networking devices. BPF is programs+maps, the pure program offload has been around for quite some time, this patchset adds the map part of the equation. Maps are allocated on the target device from the start. There is no host copy when map is

[PATCH bpf-next v2 05/15] bpf: rename bpf_dev_offload -> bpf_prog_offload

With map offload coming, we need to call program offload structure something less ambiguous. Pure rename, no functional changes. Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet ---

Re: linux-next: build failure after merge of the net-next tree

On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote: > From: Alexei Starovoitov > Date: Wed, 10 Jan 2018 17:58:54 -0800 > > > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: > >> Hi all, > >> > >> After merging the net-next tree, today's

Re: [bpf-next PATCH v2 5/7] bpf: sockmap sample add base test without any BPF for comparison

On 01/11/2018 01:10 PM, Martin KaFai Lau wrote: > On Wed, Jan 10, 2018 at 10:40:11AM -0800, John Fastabend wrote: >> Add a base test that does not use BPF hooks to test baseline case. >> >> Signed-off-by: John Fastabend >> --- >> samples/sockmap/sockmap_user.c | 26

Re: [bpf-next PATCH v2 3/7] bpf: sockmap sample, use fork() for send and recv

On 01/11/2018 01:08 PM, Martin KaFai Lau wrote: > On Wed, Jan 10, 2018 at 10:39:37AM -0800, John Fastabend wrote: >> Currently for SENDMSG tests first send completes then recv runs. This >> does not work well for large data sizes and/or many iterations. So >> fork the recv and send handler so that

Re: [bpf-next PATCH v2 1/7] bpf: refactor sockmap sample program update for arg parsing

On 01/11/2018 01:05 PM, Martin KaFai Lau wrote: > On Wed, Jan 10, 2018 at 10:39:04AM -0800, John Fastabend wrote: >> sockmap sample program takes arguments from cmd line but it reads them >> in using offsets into the array. Because we want to add more arguments >> in the future lets do proper

[PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

Customer reported memory corruption issue on previous mlx4_en driver version where the order-3 pages and multiple page reference counting were still used. Finally, find out one of the root causes is that the HW may see stale rx_descs due to prod db updating reaches HW before rx_desc. Especially

Re: [PATCH net-next 00/11] add some new features and fix some bugs

On 2018/1/12 1:07, David Miller wrote: From: Peng Li Date: Thu, 11 Jan 2018 19:45:55 +0800 This patchset adds some new features and fixes some bugs: [patch 1/11] adds ethtool_ops.get_channels support for VF. [patch 2/11] removes TSO config command from VF driver.

MERGE net into net-next

Daniel please look at how I resolved the BPF conflicts and build failures. The test_align.c one was pretty simple, but the one that fixes the build failure due to overlap of the BPF call vs. JIT always on changes is bit less trivial. Thanks.

Re: linux-next: build failure after merge of the net-next tree

From: Alexei Starovoitov Date: Wed, 10 Jan 2018 17:58:54 -0800 > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: >> Hi all, >> >> After merging the net-next tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >>

Re:

Did you receive our email ?

[PATCH net-next] i40evf: use GFP_ATOMIC under spin lock

A spin lock is taken here so we should use GFP_ATOMIC. Fixes: 504398f0a78e ("i40evf: use spinlock to protect (mac|vlan)_filter_list") Signed-off-by: Wei Yongjun --- drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c | 8 1 file changed, 4 insertions(+), 4

Re: [RFC bpf-next] bpf: add new jited info fields in bpf_dev_offload and bpf_prog_info

On Thu, 11 Jan 2018 16:47:47 -0800, Jakub Kicinski wrote: > Hi! > > Jiong is working on dumping JITed NFP image via bpftool, Francois will be > submitting support for NFP in binutils soon (whoop! :)). > > We would appreciate if you could weigh in on the uAPI. Is it OK to reuse > the existing

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams > wrote: >> >> This series incorporates Mark Rutland's latest ARM changes and adds >> the x86 specific implementation of

Re: [PATCH net-next] net: phy: Have __phy_modify return 0 on success

On 01/11/2018 12:55 PM, Andrew Lunn wrote: > __phy_modify would return the old value of the register before it was > modified. Thus on success, it does not return 0, but a positive value. > Thus functions using phy_modify, which is a wrapper around > __phy_modify, can start returning > 0 on

Re: [PATCH net-next v2] net: phy: remove parameter new_link from phy_mac_interrupt()

On 01/10/2018 12:21 PM, Heiner Kallweit wrote: > I see two issues with parameter new_link: > > 1. It's not needed. See also phy_interrupt(), works w/o this parameter. >phy_mac_interrupt sets the state to PHY_CHANGELINK and triggers the >state machine which then calls phy_read_status. And

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams wrote: > > This series incorporates Mark Rutland's latest ARM changes and adds > the x86 specific implementation of 'ifence_array_ptr'. That ifence > based approach is provided as an opt-in fallback, but the default >

[PATCH v2 10/19] ipv4: prevent bounds-check bypass via speculative execution

Static analysis reports that 'offset' may be a user controlled value that is used as a data dependency reading from a raw_frag_vec buffer. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based on an

[PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

Static analysis reports that 'queue' may be a user controlled value that is used as a data dependency to read from the 'ar9170_qmap' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an invalid

[PATCH v2 16/19] p54: prevent bounds-check bypass via speculative execution

Static analysis reports that 'queue' may be a user controlled value that is used as a data dependency to read from the 'priv->qos_params' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an

[PATCH v2 18/19] cw1200: prevent bounds-check bypass via speculative execution

Static analysis reports that 'queue' may be a user controlled value that is used as a data dependency to read 'txq_params' from the 'priv->tx_queue_params.params' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could

[PATCH v2 19/19] net: mpls: prevent bounds-check bypass via speculative execution

Static analysis reports that 'index' may be a user controlled value that is used as a data dependency reading 'rt' from the 'platform_label' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based

[PATCH v2 09/19] ipv6: prevent bounds-check bypass via speculative execution

Static analysis reports that 'offset' may be a user controlled value that is used as a data dependency reading from a raw6_frag_vec buffer. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue further reads based on an

[PATCH v2 00/19] prevent bounds-check bypass via speculative execution

Changes since v1 [1]: * fixup the ifence definition to use alternative_2 per recent AMD changes in tip/x86/pti (Tom) * drop 'nospec_ptr' (Linus, Mark) * rename 'nospec_array_ptr' to 'array_ptr' (Alexei) * rename 'nospec_barrier' to 'ifence' (Peter, Ingo) * clean up occasions of 'variable

[RFC bpf-next] bpf: add new jited info fields in bpf_dev_offload and bpf_prog_info

Hi! Jiong is working on dumping JITed NFP image via bpftool, Francois will be submitting support for NFP in binutils soon (whoop! :)). We would appreciate if you could weigh in on the uAPI. Is it OK to reuse the existing jited_prog_len/jited_prog_insns or should we add separate 2 new fields

RE: [patch net-next 5/5] mlxsw: spectrum: qdiscs: Support stats for PRIO qdisc

> > Support basic stats for PRIO qdisc, which includes tx packets and bytes > > count, drops count and backlog size. The rest of the stats are irrelevant > > for this qdisc offload. > > Since backlog is not only incremental but reflecting momentary value, in > > case of a qdisc that stops being

[net 04/11] net/mlx5: Fix mlx5_get_uars_page to return error code

From: Eran Ben Elisha Change mlx5_get_uars_page to return ERR_PTR in case of allocation failure. Change all callers accordingly to check the IS_ERR(ptr) instead of NULL. Fixes: 59211bd3b632 ("net/mlx5: Split the load/unload flow into hardware and software flows")

[net 03/11] net/mlx5: Fix memory leak in bad flow of mlx5_alloc_irq_vectors

From: Alaa Hleihel Fix a memory leak where in case that pci_alloc_irq_vectors failed, priv->irq_info was not released. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Alaa Hleihel Signed-off-by: Saeed Mahameed

[pull request][net 00/11] Mellanox, mlx5 fixes 2018-01-11

Hi Dave, The following series includes fixes to mlx5 core and netdev driver. To highlight we have two critical fixes in this series: 1st patch from Eran to address a fix for Host2BMC Breakage. 2nd patch from Saeed to address the RDMA IRQ vector affinity settings query issue, the patch provides

[net 07/11] net/mlx5e: Add error print in ETS init

From: Tariq Toukan ETS initialization might fail, add a print to indicate such failures. Fixes: 08fb1dacdd76 ("net/mlx5e: Support DCBNL IEEE ETS") Signed-off-by: Tariq Toukan Signed-off-by: Saeed Mahameed ---

[net 11/11] net/mlx5e: Remove timestamp set from netdevice open flow

From: Feras Daoud To avoid configuration override, timestamp set call will be moved from the netdevice open flow to the init flow. By this, a close-open procedure will not override the timestamp configuration. In addition, the change will rename mlx5e_timestamp_set function

[net 05/11] net/mlx5: Fix error handling in load one

From: Maor Gottlieb We didn't store the result of mlx5_init_once, due to that mlx5_load_one returned success on error. Fix that. Fixes: 59211bd3b632 ("net/mlx5: Split the load/unload flow into hardware and software flows") Signed-off-by: Maor Gottlieb

[net 01/11] {net,ib}/mlx5: Don't disable local loopback multicast traffic when needed

From: Eran Ben Elisha There are systems platform information management interfaces (such as HOST2BMC) for which we cannot disable local loopback multicast traffic. Separate disable_local_lb_mc and disable_local_lb_uc capability bits so driver will not disable multicast

[net 10/11] net/mlx5: Update ptp_clock_event foreach PPS event

From: Feras Daoud PPS event did not update ptp_clock_event fields, therefore, timestamp value was not updated correctly. This fix updates the event source and the timestamp value for each PPS event. Fixes: 7c39afb394c7 ("net/mlx5: PTP code migration to driver core

[net 06/11] net/mlx5e: Keep updating ethtool statistics when the interface is down

From: Gal Pressman ethtool statistics should be updated even when the interface is down since it shows more than just netdev counters, which might change while the logical link is down. One useful use case, for example, is when running RoCE traffic over the interface (while

[net 08/11] net/mlx5e: Check support before TC swap in ETS init

From: Tariq Toukan Should not do the following swap between TCs 0 and 1 when max num of TCs is 1: tclass[prio=0]=1, tclass[prio=1]=0, tclass[prio=i]=i (for i>1) Fixes: 08fb1dacdd76 ("net/mlx5e: Support DCBNL IEEE ETS") Signed-off-by: Tariq Toukan

[net 09/11] net/mlx5e: Don't override netdev features field unless in error flow

From: Gal Pressman Set features function sets dev->features in order to keep track of which features were successfully changed and which weren't (in case the user asks for more than one change in a single command). This breaks the logic in __netdev_update_features which

[net 02/11] net/mlx5: Fix get vector affinity helper function

mlx5_get_vector_affinity used to call pci_irq_get_affinity and after reverting the patch that sets the device affinity via PCI_IRQ_AFFINITY API, calling pci_irq_get_affinity becomes useless and it breaks RDMA mlx5 users. To fix this, this patch provides an alternative way to retrieve IRQ vector

Re: [PATCH bpf-next v4 5/5] error-injection: Support fault injection framework

2018-01-12 1:15 GMT+09:00 Masami Hiramatsu : > On Thu, 11 Jan 2018 23:44:57 +0900 > Akinobu Mita wrote: > >> 2018-01-11 9:51 GMT+09:00 Masami Hiramatsu : >> > Support in-kernel fault-injection framework via debugfs. >> > This

Backporting "netfilter: xt_hashlimit: Fix integer divide round to zero." to stable kernels

Hi, A customer of mine has been hitting hashlimits issues in netfilter by switching from Debian 8 (3.16.y) to Debian 9 (4.9.y), making iptables hashlimits unusable for production. This issue has been fixed in mainline with this commit: | commit ad5b55761956427f61ed9c96961bf9c5cd4f92dc | Author:

Re: [patch net-next 5/5] mlxsw: spectrum: qdiscs: Support stats for PRIO qdisc

On Thu, 11 Jan 2018 11:21:02 +0100, Jiri Pirko wrote: > From: Nogah Frankel > > Support basic stats for PRIO qdisc, which includes tx packets and bytes > count, drops count and backlog size. The rest of the stats are irrelevant > for this qdisc offload. > Since backlog is

Re: [patch iproute2 v8 1/2] lib/libnetlink: Add functions rtnl_talk_msg and rtnl_talk_iov

On 1/11/18 8:08 AM, Phil Sutter wrote: > On Wed, Jan 10, 2018 at 09:12:45PM +0100, Phil Sutter wrote: >> On Wed, Jan 10, 2018 at 12:20:36PM -0700, David Ahern wrote: >> [...] >>> 2. I am using a batch file with drop filters: >>> >>> filter add dev eth2 ingress protocol ip pref 273 flower dst_ip

RE: [patch net-next 3/5] net: sch: prio: Add offload ability to PRIO qdisc

> > > > +struct tc_prio_qopt_offload_params { > > > > + int bands; > > > > + u8 priomap[TC_PRIO_MAX + 1]; > > > > + /* In case that a prio qdisc is offloaded and now is changed to > > > > a > > > > +* non-offloadedable config, it needs to update the backlog > > > >

[PATCH v2] bnx2x: disable GSO where gso_size is too big for hardware

If a bnx2x card is passed a GSO packet with a gso_size larger than ~9700 bytes, it will cause a firmware error that will bring the card down: bnx2x: [bnx2x_attn_int_deasserted3:4323(enP24p1s0f0)]MC assert! bnx2x: [bnx2x_mc_assert:720(enP24p1s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2 bnx2x:

Re: [patch net-next 3/5] net: sch: prio: Add offload ability to PRIO qdisc

On Thu, 11 Jan 2018 23:50:27 +, Yuval Mintz wrote: > > > +struct tc_prio_qopt_offload_params { > > > + int bands; > > > + u8 priomap[TC_PRIO_MAX + 1]; > > > + /* In case that a prio qdisc is offloaded and now is changed to a > > > + * non-offloadedable config, it needs to update the backlog

RE: [patch net-next 3/5] net: sch: prio: Add offload ability to PRIO qdisc

> > +struct tc_prio_qopt_offload_params { > > + int bands; > > + u8 priomap[TC_PRIO_MAX + 1]; > > + /* In case that a prio qdisc is offloaded and now is changed to a > > +* non-offloadedable config, it needs to update the backlog value > > +* to negate the HW backlog value. > > +

Re: [patch net-next 3/5] net: sch: prio: Add offload ability to PRIO qdisc

On Thu, 11 Jan 2018 11:21:00 +0100, Jiri Pirko wrote: > +struct tc_prio_qopt_offload_params { > + int bands; > + u8 priomap[TC_PRIO_MAX + 1]; > + /* In case that a prio qdisc is offloaded and now is changed to a > + * non-offloadedable config, it needs to update the backlog value

Re: [PATCH 34/38] arm: Implement thread_struct whitelist for hardened usercopy

On Thu, Jan 11, 2018 at 2:24 AM, Russell King - ARM Linux wrote: > On Wed, Jan 10, 2018 at 06:03:06PM -0800, Kees Cook wrote: >> ARM does not carry FPU state in the thread structure, so it can declare >> no usercopy whitelist at all. > > This comment seems to be misleading.

Re: [PATCH 13/38] ext4: Define usercopy region in ext4_inode_cache slab cache

On Thu, Jan 11, 2018 at 9:01 AM, Theodore Ts'o wrote: > On Wed, Jan 10, 2018 at 06:02:45PM -0800, Kees Cook wrote: >> The ext4 symlink pathnames, stored in struct ext4_inode_info.i_data >> and therefore contained in the ext4_inode_cache slab cache, need >> to be copied to/from

  1   2   3   >