Re: [PATCH net-next] nfp: flower: prioritize stats updates

On Sun, Jan 21, 2018 at 3:10 PM, David Miller wrote: > From: Jakub Kicinski > Date: Fri, 19 Jan 2018 17:54:08 -0800 > >> From: Pieter Jansen van Vuuren >> >> Previously it was possible to interrupt

[RFC PATCH net-next] net: aquantia: aq_fw2x_get_mac_permanent() can be static

Fixes: a57d3929b838 ("net: aquantia: Introduce support for new firmware on AQC cards") Signed-off-by: Fengguang Wu --- hw_atl_utils_fw2x.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

On 2018/01/20 09:21, Alexander Duyck wrote: > On Fri, Jan 19, 2018 at 2:55 PM, Benjamin Poirier > wrote: > > On 2018/01/20 07:45, Benjamin Poirier wrote: > > [...] > >> > > >> > I'm of the mind that we need to cut down on the code thrash. This > >> > driver is

[RFC PATCH net-next] net: aquantia: hw_atl_utils_mpi_set_speed() can be static

Fixes: 0c58c35f02c2 ("net: aquantia: Introduce firmware ops callbacks") Signed-off-by: Fengguang Wu --- hw_atl_utils.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c

Re: [PATCHv3] 3c59x: fix missing dma_mapping_error check and bad ring refill logic

On Wed, Jan 3, 2018 at 1:44 PM, David Miller wrote: > From: Neil Horman > Date: Wed, 3 Jan 2018 13:09:23 -0500 > >> A few spots in 3c59x missed calls to dma_mapping_error checks, casuing >> WARN_ONS to trigger. Clean those up. While we're at it,

Re: wcn36xx: release resources in case of error

Ramon Fried wrote: > wcn36xx_dxe_init() doesn't check for the return value > of wcn36xx_dxe_init_descs(). > This patch releases the resources in case an error ocurred. > > Signed-off-by: Ramon Fried This is a duplicate. Patch set to Superseded.

Re: wcn36xx: release resources in case of error

Ramon Fried wrote: > wcn36xx_dxe_init() doesn't check for the return value > of wcn36xx_dxe_init_descs(). > This patch releases the resources in case an error ocurred. > > Signed-off-by: Ramon Fried This is a duplicate. Patch set to Superseded.

Re: wcn36xx: release resources in case of error

Ramon Fried wrote: > wcn36xx_dxe_init() doesn't check for the return value > of wcn36xx_dxe_init_descs(). > This patch releases the resources in case an error ocurred. > > Signed-off-by: Ramon Fried Doesn't compile:

[PATCH net-next] net: link_watch: mark bonding link events urgent

From: Roopa Prabhu It takes 1sec for bond link down notification to hit user-space when all slaves of the bond go down. 1sec is too long for protocol daemons in user-space relying on bond link notification to failover/recover (eg: multichassis lag implementations in

Re: [v3, 3/6] dt: booting-without-of: DT fix s/#interrupt-cell/#interrupt-cells/

On Fri, 2017-06-02 at 12:38:46 UTC, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > Acked-by: Rob Herring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/4be4119d1fbd93c44d5c639735c312 cheers

[PATCH net-next] tun: add missing rcu annotation

This patch fixes the following sparse warnings: drivers/net/tun.c:2241:15: error: incompatible types in comparison expression (different address spaces) Fixes: cd5681d7d890 ("tuntap: rename struct tun_steering_prog to struct tun_prog") Cc: Daniel Borkmann Signed-off-by:

Re: net merged into net-next

On 2018年01月21日 04:17, Cong Wang wrote: On Fri, Jan 19, 2018 at 8:02 PM, David Miller wrote: Cong, please check my conflict resolution of drivers/net/tun.c, thank you. It looks good to me except I am not sure about the xdp_rxq_info_unreg() inside tun_cleanup_tx_ring().

Re: [PATCH net] net: validate untrusted gso packets

On 2018年01月19日 22:39, Willem de Bruijn wrote: On Fri, Jan 19, 2018 at 3:19 AM, Jason Wang wrote: On 2018年01月19日 08:53, Willem de Bruijn wrote: And what you propose here is just a very small subset of the necessary checking, more comes at gso header checking. So even if

Re: [PATCH net v3] gso: validate gso_type in GSO handlers

On 2018年01月19日 22:29, Willem de Bruijn wrote: From: Willem de Bruijn Validate gso_type during segmentation as SKB_GSO_DODGY sources may pass packets where the gso_type does not match the contents. Syzkaller was able to enter the SCTP gso handler with a packet of gso_type

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

Hi Eric On 01/22/2018 12:43 AM, Eric Dumazet wrote: > On Sun, 2018-01-21 at 18:24 +0200, Tariq Toukan wrote: >> >> On 21/01/2018 11:31 AM, Tariq Toukan wrote: >>> >>> >>> On 19/01/2018 5:49 PM, Eric Dumazet wrote: On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote: > Hi Tariq >

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

Hi Tariq and all Many thanks for your kindly and detailed response and comment. On 01/22/2018 12:24 AM, Tariq Toukan wrote: > > > On 21/01/2018 11:31 AM, Tariq Toukan wrote: >> >> >> On 19/01/2018 5:49 PM, Eric Dumazet wrote: >>> On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote: Hi

Re: Memory corruption with r8169 across several device revisions and kernels

Am 22.01.2018 um 01:09 schrieb Francois Romieu: > You said: > > Oliver Freyermuth : > [...] >> The values found in overwritten memory match those contained in >> /proc/self/net/dev for the realtek ethernet device. > > Are you able to retrieve the layout ? That is,

Re: Memory corruption with r8169 across several device revisions and kernels

Oliver Freyermuth : > Am 21.01.2018 um 21:48 schrieb Francois Romieu: > > Oliver Freyermuth : [...] > > Is it an AMD based system ? > > > > No, all the systems on which I have observed this up to now are Intel-based. > Two Haswell and

Re: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit queue

On Sun, Jan 21, 2018 at 12:52 PM, Tal Gilboa wrote: > Hi Eric, > We have noticed a degradation on both of our drivers (mlx4 and mlx5) when > running TCP. Exact scenario is single stream TCP with 1KB packets. The > degradation is a steady 50% drop. > We tracked the offending

Re: [patch net-next 0/7] mlxsw: Add support for mirror action with flower

From: Jiri Pirko Date: Fri, 19 Jan 2018 09:24:45 +0100 > From: Jiri Pirko > > Arkadi says: > > Add support for mirror action with flower classifier. The first 3 patches > introduce a generic per-block resource infra. The last 4 patches add > support for

Re: [PATCH net-next 00/11] Aquantia atlantic driver new devices support

From: Igor Russkikh Date: Fri, 19 Jan 2018 17:03:17 +0300 > This patchset introduces a support for new Aquantia hardware: > AQC11x family with updated hardware (B1) and firmware (2.x and 3.x branches). > > For that, a number of improvements in overall driver model

Re: [pull request][net-next 00/15] Mellanox, mlx5 updates 2018-01-19

From: Saeed Mahameed Date: Fri, 19 Jan 2018 23:34:42 +0200 > The following series includes updates for mlx5e netdev driver, > for more information please see tag log below. > > Please pull and let me know if there's any problem. Pulled, thanks Saeed.

Re: [PATCH net-next] nfp: flower: prioritize stats updates

From: Jakub Kicinski Date: Fri, 19 Jan 2018 17:54:08 -0800 > From: Pieter Jansen van Vuuren > > Previously it was possible to interrupt processing stats updates because > they were handled in a work queue. Interrupting the

Re: [PATCH net V2] net/mlx5e: Fix fixpoint divide exception in mlx5e_am_stats_compare

From: Saeed Mahameed Date: Sun, 21 Jan 2018 05:30:42 +0200 > From: Talat Batheesh > > Helmut reported a bug about division by zero while > running traffic and doing physical cable pull test. > > When the cable unplugged the ppms become zero, so when >

Re: [PATCH] net: gemini: Depend on HAS_IOMEM

From: Linus Walleij Date: Sun, 21 Jan 2018 14:15:41 +0100 > The zeroday builder notices that since Usermode Linux does not > have IO memory, the build fails for them when selecting everything > it can enable. > > As the driver is clearly using memory-mapped registers

Re: [RFC crypto v3 0/9] Chelsio Inline TLS

2017-12-20, 17:03:02 +0530, Atul Gupta wrote: > RFC series for Chelsio Inline TLS driver (chtls.ko) > > Driver use the ULP infrastructure to register chtls as Inline TLS ULP. I don't think drivers should be registering their own ULP. TLS offloading should be transparent to userspace, whatever HW

Re: [Patch net-next 2/3] net_sched: plug in qdisc ops change_tx_queue_len

On 01/19/2018 03:09 PM, Cong Wang wrote: > Introduce a new qdisc ops ->change_tx_queue_len() so that > each qdisc could decide how to implement this if it wants. > Previously we simply read dev->tx_queue_len, after pfifo_fast > switches to skb array, we need this API to resize the skb array > when

Re: [Patch net-next 1/3] net: introduce helper dev_change_tx_queue_len()

On 01/19/2018 03:09 PM, Cong Wang wrote: > This patch promotes the local change_tx_queue_len() to a core > helper function, dev_change_tx_queue_len(), so that rtnetlink > and net-sysfs could share the code. This also prepares for the > following patch. > > Note, the -EFAULT in the original code

Re: [PATCH] rtl8xxxu: Fix trailing semicolon

On 01/17/2018 05:56 AM, Luis de Bethencourt wrote: > The trailing semicolon is an empty statement that does no operation. > Removing it since it doesn't do anything. > > Signed-off-by: Luis de Bethencourt > --- > > Hi, > > After fixing the same thing in

Re: ipv6_addrconf: WARNING about suspicious RCU usage

Am 20.01.2018 um 20:19 schrieb Ido Schimmel: > On Sat, Jan 20, 2018 at 10:49:03AM -0800, Eric Dumazet wrote: >> On Sat, 2018-01-20 at 15:37 +0200, Ido Schimmel wrote: >>> On Sat, Jan 20, 2018 at 12:57:01PM +0100, Heiner Kallweit wrote: Since some time (didn't bisect it yet) I get the

Darlehen

Benötigen Sie Privat- oder Geschäftskredite ohne Stress und schnelle Zustimmung? Wenn ja, kontaktieren Sie uns bitte alexgr...@gmail.com

Re: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit queue

Hi Eric, We have noticed a degradation on both of our drivers (mlx4 and mlx5) when running TCP. Exact scenario is single stream TCP with 1KB packets. The degradation is a steady 50% drop. We tracked the offending commit to be: 75c119a ("tcp: implement rb-tree based retransmit queue") Since

Re: Memory corruption with r8169 across several device revisions and kernels

Hi, Am 21.01.2018 um 21:48 schrieb Francois Romieu: > Oliver Freyermuth : > [...] > > Is it an AMD based system ? > No, all the systems on which I have observed this up to now are Intel-based. Two Haswell and one Sandy Bridge system. Cheers, Oliver

Re: Memory corruption with r8169 across several device revisions and kernels

Oliver Freyermuth : [...] Is it an AMD based system ? -- Ueimor

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

> Hmm, this is actually consistent with the example below [1]. > > AIU from the example, it seems that the dma_wmb/dma_rmb barriers are good > for synchronizing cpu/device accesses to the "Streaming DMA mapped" buffers > (the descriptors, went through the dma_map_page() API), but not for the >

Re: [Patch net-next 1/3] net: introduce helper dev_change_tx_queue_len()

On Sat, Jan 20, 2018 at 8:52 PM, John Fastabend wrote: > On 01/19/2018 03:09 PM, Cong Wang wrote: >> This patch promotes the local change_tx_queue_len() to a core >> helper function, dev_change_tx_queue_len(), so that rtnetlink >> and net-sysfs could share the code. This

Re: [PATCH net-next v2 2/2] net/sched: act_csum: don't use spinlock in the fast path

On Fri, Jan 19, 2018 at 6:12 AM, Davide Caratti wrote: > static int tcf_csum_dump(struct sk_buff *skb, struct tc_action *a, int bind, > @@ -575,15 +594,18 @@ static int tcf_csum_dump(struct sk_buff *skb, struct > tc_action *a, int bind, > { > unsigned char *b =

Re: [patch iproute2 net-next v12 0/3] tc: shared block support

On 1/20/18 3:00 AM, Jiri Pirko wrote: > From: Jiri Pirko > > Kernel allows to share all filters between qdiscs with use > of shared block. > > Example: > > block number 22. "22" is just an identification: > $ tc qdisc add dev ens7 ingress_block 22 ingress >

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

> However interesting as an example, I'm not convinced this is what we > should aim for. > > ACPI is not a replacement for DT, and it is unlikely that people would > be interested in running ACPI-only distros such as RHEL on their > Ethernet switch. DT is excellent at describing this, and there

Re: [PATCH iproute2 0/6] utils: Get rid of inet_get_addr()

On 1/18/18 11:13 AM, Serhey Popovych wrote: > It looks confusing to have multiple independent > routines to get internet address from it's string > representation: get_addr() and inet_get_addr(). > > Most complicated users of inet_get_addr() is > iplink_geneve.c and iplink_vxlan.c because they >

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

On 21 January 2018 at 16:13, Andrew Lunn wrote: >> Right. So if you need to have some additional "parameters" with the >> connection, then I suppose you may want to go with the GenericSerialBus >> route. However, looking at the sample device tree description: >> >>

Re: [PATCH 00/32] Netfilter/IPVS updates for net-next

From: Pablo Neira Ayuso Date: Fri, 19 Jan 2018 20:10:09 +0100 > The following patchset contains Netfilter/IPVS updates for your net-next > tree. Basically, a new extension for ip6tables, simplification work of > nf_tables that saves us 500 LoC, allow raw table registration

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

On Sun, 2018-01-21 at 18:24 +0200, Tariq Toukan wrote: > > On 21/01/2018 11:31 AM, Tariq Toukan wrote: > > > > > > On 19/01/2018 5:49 PM, Eric Dumazet wrote: > > > On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote: > > > > Hi Tariq > > > > > > > > Very sad that the crash was reproduced

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

On 21/01/2018 11:31 AM, Tariq Toukan wrote: On 19/01/2018 5:49 PM, Eric Dumazet wrote: On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote: Hi Tariq Very sad that the crash was reproduced again after applied the patch. Memory barriers vary for different Archs, can you please share

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

> Right. So if you need to have some additional "parameters" with the > connection, then I suppose you may want to go with the GenericSerialBus > route. However, looking at the sample device tree description: > > davinci_mdio: ethernet@5c03 { > compatible =

[PATCH] r8169: improve multicast hash filter handling

The multicast hash filter is a 64 bit value and the code can be simplified by using a u64 variable. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 24 ++-- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git

[PATCH] net: gemini: Depend on HAS_IOMEM

The zeroday builder notices that since Usermode Linux does not have IO memory, the build fails for them when selecting everything it can enable. As the driver is clearly using memory-mapped registers to access the network adapter, we add depends on HAS_IOMEM to solve this problem. Reported-by:

Re: [net-next:master 308/357] gemini.c:undefined reference to `devm_ioremap_resource'

On Sat, Jan 20, 2018 at 12:33 PM, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git > master > head: 8565d26bcb2ff6df646e946d2913fcf706d46b66 > commit: 4d5ae32f5e1e13f7f36d6439ec3257993b9f5b88 [308/357] net: ethernet:

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

On Sun, Jan 21, 2018 at 02:08:40AM +0100, Andrew Lunn wrote: > > I'm not familiar with MDIO bus but an alternative to GeneriSerialBus > > would be to follow what SDIO is doing, e.g have the PHY devices listed > > below the MDIO controller and use _ADR to describe their "address" on > > that bus.

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

On 19/01/2018 5:49 PM, Eric Dumazet wrote: On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote: Hi Tariq Very sad that the crash was reproduced again after applied the patch. --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c @@ -252,6