* RE: [RFC 01/20] ice: Initialize and register multi-function device to provide RDMA
From: Ertman, David M @ 2019-09-27 18:03 UTC (permalink / raw)
To: gregkh@linuxfoundation.org, Nguyen, Anthony L
Cc: Kirsher, Jeffrey T, jgg@mellanox.com, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, dledford@redhat.com
In-Reply-To: <20190927051320.GA1767635@kroah.com>
> -----Original Message-----
> From: gregkh@linuxfoundation.org [mailto:gregkh@linuxfoundation.org]
> Sent: Thursday, September 26, 2019 10:13 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>
> Cc: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; jgg@mellanox.com;
> netdev@vger.kernel.org; linux-rdma@vger.kernel.org; dledford@redhat.com;
> Ertman, David M <david.m.ertman@intel.com>
> Subject: Re: [RFC 01/20] ice: Initialize and register multi-function device to
> provide RDMA
>
> On Thu, Sep 26, 2019 at 11:39:22PM +0000, Nguyen, Anthony L wrote:
> > On Thu, 2019-09-26 at 20:05 +0200, Greg KH wrote:
> > > On Thu, Sep 26, 2019 at 09:45:00AM -0700, Jeff Kirsher wrote:
> > > > From: Tony Nguyen <anthony.l.nguyen@intel.com>
> > > >
> > > > The RDMA block does not advertise on the PCI bus or any other bus.
> > >
> > > Huh? How do you "know" where it is then? Isn't is usually assigned
> > > to a PCI device?
> >
> > The RDMA block does not have its own PCI function so it must register
> > and interact with the ice driver.
>
> So the "ice driver" is the real thing controlling the pci device? How does it
> "know" about the RDMA block?
>
> thanks,
>
> greg k-h
The ICE driver loads and registers to control the PCI device. It then
creates an MFD device with the name 'ice_rdma'. The device data provided to
the MFD subsystem by the ICE driver is the struct iidc_peer_dev which
contains all of the relevant information that the IRDMA peer will need
to access this PF's IIDC API callbacks
The IRDMA driver loads as a software only driver, and then registers a MFD
function driver that takes ownership of MFD devices named 'ice_rdma'.
This causes the platform bus to perform a matching between ICE's MFD device
and IRDMA's driver. Then the patform bus will call the IRDMA's IIDC probe
function. This probe provides the device data to IRDMA.
Dave E
^ permalink raw reply
* Re: [PATCH net] vrf: Do not attempt to create IPv6 mcast rule if IPv6 is disabled
From: David Miller @ 2019-09-27 18:07 UTC (permalink / raw)
To: dsahern; +Cc: jakub.kicinski, netdev, dsahern, pruddy
In-Reply-To: <20190925145319.26801-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Wed, 25 Sep 2019 07:53:19 -0700
> From: David Ahern <dsahern@gmail.com>
>
> A user reported that vrf create fails when IPv6 is disabled at boot using
> 'ipv6.disable=1':
> https://bugzilla.kernel.org/show_bug.cgi?id=204903
>
> The failure is adding fib rules at create time. Add RTNL_FAMILY_IP6MR to
> the check in vrf_fib_rule if ipv6_mod_enabled is disabled.
>
> Fixes: e4a38c0c4b27 ("ipv6: add vrf table handling code for ipv6 mcast")
> Signed-off-by: David Ahern <dsahern@gmail.com>
> Cc: Patrick Ruddy <pruddy@vyatta.att-mail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v2] net/sched: Set default of CONFIG_NET_TC_SKB_EXT to N
From: David Miller @ 2019-09-27 18:08 UTC (permalink / raw)
To: paulb
Cc: pshelar, daniel, jakub.kicinski, vladbu, netdev, jiri,
xiyou.wangcong, jhs, simon.horman, gerlitz.or
In-Reply-To: <1569423755-1544-1-git-send-email-paulb@mellanox.com>
From: Paul Blakey <paulb@mellanox.com>
Date: Wed, 25 Sep 2019 18:02:35 +0300
> This a new feature, it is preferred that it defaults to N.
> We will probe the feature support from userspace before actually using it.
>
> Fixes: 95a7233c452a ('net: openvswitch: Set OvS recirc_id from tc chain index')
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH] nfp: flower: prevent memory leak in nfp_flower_spawn_phy_reprs
From: David Miller @ 2019-09-27 18:12 UTC (permalink / raw)
To: navid.emamdoost
Cc: emamd001, kjlu, smccaman, jakub.kicinski, john.hurley,
simon.horman, pieter.jansenvanvuuren, frederik.lotter,
oss-drivers, netdev, linux-kernel
In-Reply-To: <20190925182405.31287-1-navid.emamdoost@gmail.com>
From: Navid Emamdoost <navid.emamdoost@gmail.com>
Date: Wed, 25 Sep 2019 13:24:02 -0500
> In nfp_flower_spawn_phy_reprs, in the for loop over eth_tbl if any of
> intermediate allocations or initializations fail memory is leaked.
> requiered releases are added.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] nfp: flower: fix memory leak in nfp_flower_spawn_vnic_reprs
From: David Miller @ 2019-09-27 18:12 UTC (permalink / raw)
To: navid.emamdoost
Cc: emamd001, kjlu, smccaman, jakub.kicinski, john.hurley,
simon.horman, pieter.jansenvanvuuren, frederik.lotter,
oss-drivers, netdev, linux-kernel
In-Reply-To: <20190925190512.3404-1-navid.emamdoost@gmail.com>
From: Navid Emamdoost <navid.emamdoost@gmail.com>
Date: Wed, 25 Sep 2019 14:05:09 -0500
> In nfp_flower_spawn_vnic_reprs in the loop if initialization or the
> allocations fail memory is leaked. Appropriate releases are added.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/5] Netfilter fixes for net
From: David Miller @ 2019-09-27 18:16 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190925203003.20112-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 25 Sep 2019 22:29:58 +0200
> The following patchset contains Netfilter fixes for net:
>
> 1) Add NFT_CHAIN_POLICY_UNSET to replace hardcoded -1 to
> specify that the chain policy is unset. The chain policy
> field is actually defined as an 8-bit unsigned integer.
>
> 2) Remove always true condition reported by smatch in
> chain policy check.
>
> 3) Fix element lookup on dynamic sets, from Florian Westphal.
>
> 4) Use __u8 in ebtables uapi header, from Masahiro Yamada.
>
> 5) Bogus EBUSY when removing flowtable after chain flush,
> from Laura Garcia Liebana.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH bpf] bpf: Fix a race in reuseport_array_free()
From: Martin Lau @ 2019-09-27 18:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Alexei Starovoitov,
Daniel Borkmann, David Miller, Kernel Team
In-Reply-To: <04f683c6-ac49-05fb-6ec9-9f0d698657a2@gmail.com>
On Fri, Sep 27, 2019 at 10:24:49AM -0700, Eric Dumazet wrote:
>
>
> On 9/27/19 9:52 AM, Martin KaFai Lau wrote:
> > In reuseport_array_free(), the rcu_read_lock() cannot ensure sk is still
> > valid. It is because bpf_sk_reuseport_detach() can be called from
> > __sk_destruct() which is invoked through call_rcu(..., __sk_destruct).
>
> We could question why reuseport_detach_sock(sk) is called from __sk_destruct()
> (after the rcu grace period) instead of sk_destruct() ?
Agree. It is another way to fix it.
In this patch, I chose to avoid the need to single out a special treatment for
reuseport_detach_sock() in sk_destruct().
I am happy either way. What do you think?
>
> >
> > This patch takes the reuseport_lock in reuseport_array_free() which
> > is not the fast path. The lock is taken inside the loop in case
> > that the bpf map is big.
> >
> > Signed-off-by: Martin KaFai Lau <kafai@fb.com>
>
> Fixes: 5dc4c4b7d4e8 ("bpf: Introduce BPF_MAP_TYPE_REUSEPORT_SOCKARRAY")
Ah...missed that. Thanks!
^ permalink raw reply
* Re: [PATCH V2] net: dsa: microchip: Always set regmap stride to 1
From: David Miller @ 2019-09-27 18:21 UTC (permalink / raw)
To: marex
Cc: netdev, andrew, f.fainelli, george.mccollister, Tristram.Ha,
vivien.didelot, woojung.huh
In-Reply-To: <20190925220842.4301-1-marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Thu, 26 Sep 2019 00:08:42 +0200
> The regmap stride is set to 1 for regmap describing 8bit registers already.
> However, for 16/32/64bit registers, the stride is 2/4/8 respectively. This
> is not correct, as the switch protocol supports unaligned register reads
> and writes and the KSZ87xx even uses such unaligned register accesses to
> read e.g. MIB counter.
>
> This patch fixes MIB counter access on KSZ87xx.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Fixes: 46558d601cb6 ("net: dsa: microchip: Initial SPI regmap support")
> Fixes: 255b59ad0db2 ("net: dsa: microchip: Factor out regmap config generation into common header")
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: phy: micrel: add Asym Pause workaround for KSZ9021
From: Florian Fainelli @ 2019-09-27 18:22 UTC (permalink / raw)
To: Hans Andersson, andrew
Cc: hkallweit1, davem, netdev, linux-kernel, antoine.tenart,
Hans Andersson
In-Reply-To: <20190927075802.10376-1-haan@cellavision.se>
On 9/27/19 12:58 AM, Hans Andersson wrote:
> From: Hans Andersson <hans.andersson@cellavision.se>
>
> The Micrel KSZ9031 PHY may fail to establish a link when the Asymmetric
> Pause capability is set. This issue is described in a Silicon Errata
> (DS80000691D or DS80000692D), which advises to always disable the
> capability.
>
> Micrel KSZ9021 has no errata, but has the same issue with Asymmetric Pause.
> This patch apply the same workaround as the one for KSZ9031.
>
> Fixes: 3aed3e2a143c ("net: phy: micrel: add Asym Pause workaround")
> Signed-off-by: Hans Andersson <hans.andersson@cellavision.se>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainellI@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH] lib: dimlib: fix help text typos
From: David Miller @ 2019-09-27 18:23 UTC (permalink / raw)
To: rdunlap; +Cc: netdev, uwe, talgi, saeedm
In-Reply-To: <445cadc0-8b22-957f-47f6-2e6250124ae3@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Wed, 25 Sep 2019 17:20:42 -0700
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix help text typos for DIMLIB.
>
> Fixes: 4f75da3666c0 ("linux/dim: Move implementation to .c files")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Applied.
^ permalink raw reply
* Re: [RFC 15/20] RDMA/irdma: Add miscellaneous utility definitions
From: gregkh @ 2019-09-27 18:23 UTC (permalink / raw)
To: Saleem, Shiraz
Cc: Leon Romanovsky, Kirsher, Jeffrey T, dledford@redhat.com,
jgg@mellanox.com, Ismail, Mustafa, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <9DD61F30A802C4429A01CA4200E302A7AC704647@fmsmsx123.amr.corp.intel.com>
On Fri, Sep 27, 2019 at 02:28:20PM +0000, Saleem, Shiraz wrote:
> > Subject: Re: [RFC 15/20] RDMA/irdma: Add miscellaneous utility definitions
> >
> > On Thu, Sep 26, 2019 at 07:49:33PM +0000, Saleem, Shiraz wrote:
> > > > Subject: Re: [RFC 15/20] RDMA/irdma: Add miscellaneous utility
> > > > definitions
> > > >
> > > > On Thu, Sep 26, 2019 at 09:45:14AM -0700, Jeff Kirsher wrote:
> > > > > From: Mustafa Ismail <mustafa.ismail@intel.com>
> > > > >
> > > > > Add miscellaneous utility functions and headers.
> > > > >
> > > > > Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
> > > > > Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
> > > > > ---
> > > > > drivers/infiniband/hw/irdma/osdep.h | 108 ++
> > > > > drivers/infiniband/hw/irdma/protos.h | 96 ++
> > > > > drivers/infiniband/hw/irdma/status.h | 70 +
> > > > > drivers/infiniband/hw/irdma/utils.c | 2333
> > > > > ++++++++++++++++++++++++++
> > > > > 4 files changed, 2607 insertions(+) create mode 100644
> > > > > drivers/infiniband/hw/irdma/osdep.h
> > > > > create mode 100644 drivers/infiniband/hw/irdma/protos.h
> > > > > create mode 100644 drivers/infiniband/hw/irdma/status.h
> > > > > create mode 100644 drivers/infiniband/hw/irdma/utils.c
> > > > >
> > > > > diff --git a/drivers/infiniband/hw/irdma/osdep.h
> > > > > b/drivers/infiniband/hw/irdma/osdep.h
> > > > > new file mode 100644
> > > > > index 000000000000..5885b6fa413d
> > > > > --- /dev/null
> > > > > +++ b/drivers/infiniband/hw/irdma/osdep.h
> > > > > @@ -0,0 +1,108 @@
> > > > > +/* SPDX-License-Identifier: GPL-2.0 or Linux-OpenIB */
> > > > > +/* Copyright (c) 2019, Intel Corporation. */
> > > > > +
> > > > > +#ifndef IRDMA_OSDEP_H
> > > > > +#define IRDMA_OSDEP_H
> > > > > +
> > > > > +#include <linux/version.h>
> > > > > +#include <linux/kernel.h>
> > > > > +#include <linux/vmalloc.h>
> > > > > +#include <linux/string.h>
> > > > > +#include <linux/bitops.h>
> > > > > +#include <linux/pci.h>
> > > > > +#include <net/tcp.h>
> > > > > +#include <crypto/hash.h>
> > > > > +/* get readq/writeq support for 32 bit kernels, use the low-first
> > > > > +version */ #include <linux/io-64-nonatomic-lo-hi.h>
> > > > > +
> > > > > +#define MAKEMASK(m, s) ((m) << (s))
> > > >
> > > > It is a little bit over-macro.
> > > >
> > >
> > > Why is this a problem?
> > > We are not translating any basic kernel construct here.
> >
> > See BIT() definition.
> >
> OK. And?
And you just re-created GENMASK(). Please use in-kernel definitions
instead of creating your own.
thanks,
greg k-h
^ permalink raw reply
* Re: [net-next v2 1/2] ptp: correctly disable flags on old ioctls
From: David Miller @ 2019-09-27 18:25 UTC (permalink / raw)
To: jacob.e.keller
Cc: netdev, intel-wired-lan, jeffrey.t.kirsher, richardcochran,
felipe.balbi, christopher.s.hall
In-Reply-To: <20190926022820.7900-2-jacob.e.keller@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Date: Wed, 25 Sep 2019 19:28:19 -0700
> Commit 415606588c61 ("PTP: introduce new versions of IOCTLs",
> 2019-09-13) introduced new versions of the PTP ioctls which actually
> validate that the flags are acceptable values.
>
> As part of this, it cleared the flags value using a bitwise
> and+negation, in an attempt to prevent the old ioctl from accidentally
> enabling new features.
>
> This is incorrect for a couple of reasons. First, it results in
> accidentally preventing previously working flags on the request ioctl.
> By clearing the "valid" flags, we now no longer allow setting the
> enable, rising edge, or falling edge flags.
>
> Second, if we add new additional flags in the future, they must not be
> set by the old ioctl. (Since the flag wasn't checked before, we could
> potentially break userspace programs which sent garbage flag data.
>
> The correct way to resolve this is to check for and clear all but the
> originally valid flags.
>
> Create defines indicating which flags are correctly checked and
> interpreted by the original ioctls. Use these to clear any bits which
> will not be correctly interpreted by the original ioctls.
>
> In the future, new flags must be added to the VALID_FLAGS macros, but
> *not* to the V1_VALID_FLAGS macros. In this way, new features may be
> exposed over the v2 ioctls, but without breaking previous userspace
> which happened to not clear the flags value properly. The old ioctl will
> continue to behave the same way, while the new ioctl gains the benefit
> of using the flags fields.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Applied to 'net'.
^ permalink raw reply
* Re: [PATCH net] net: socionext: ave: Avoid using netdev_err() before calling register_netdev()
From: David Miller @ 2019-09-27 18:28 UTC (permalink / raw)
To: hayashi.kunihiko; +Cc: netdev, linux-kernel
In-Reply-To: <1569479710-32314-1-git-send-email-hayashi.kunihiko@socionext.com>
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date: Thu, 26 Sep 2019 15:35:10 +0900
> Until calling register_netdev(), ndev->dev_name isn't specified, and
> netdev_err() displays "(unnamed net_device)".
>
> ave 65000000.ethernet (unnamed net_device) (uninitialized): invalid phy-mode setting
> ave: probe of 65000000.ethernet failed with error -22
>
> This replaces netdev_err() with dev_err() before calling register_netdev().
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: add Asym Pause workaround for KSZ9021
From: David Miller @ 2019-09-27 18:29 UTC (permalink / raw)
To: haan
Cc: andrew, f.fainelli, hkallweit1, netdev, linux-kernel,
antoine.tenart, hans.andersson
In-Reply-To: <20190926075437.18088-1-haan@cellavision.se>
From: Hans Andersson <haan@cellavision.se>
Date: Thu, 26 Sep 2019 09:54:37 +0200
> From: Hans Andersson <hans.andersson@cellavision.se>
>
> The Micrel KSZ9031 PHY may fail to establish a link when the Asymmetric
> Pause capability is set. This issue is described in a Silicon Errata
> (DS80000691D or DS80000692D), which advises to always disable the
> capability.
>
> Micrel KSZ9021 has no errata, but has the same issue with Asymmetric Pause.
> This patch apply the same workaround as the one for KSZ9031.
>
> Signed-off-by: Hans Andersson <hans.andersson@cellavision.se>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [net-next v3 0/7] new PTP ioctl fixes
From: David Miller @ 2019-09-27 18:29 UTC (permalink / raw)
To: jacob.e.keller; +Cc: netdev, intel-wired-lan, jeffrey.t.kirsher
In-Reply-To: <20190926181109.4871-1-jacob.e.keller@intel.com>
Bug fixes should target 'net' not 'net-next'
^ permalink raw reply
* Re: [PATCH] NFC: st95hf: clean up indentation issue
From: David Miller @ 2019-09-27 18:31 UTC (permalink / raw)
To: colin.king; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190926111306.17409-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 26 Sep 2019 12:13:06 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The return statement is indented incorrectly, add in a missing
> tab and remove an extraneous space after the return
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ena: clean up indentation issue
From: David Miller @ 2019-09-27 18:32 UTC (permalink / raw)
To: colin.king
Cc: netanel, saeedb, zorik, akiyano, sameehj, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190926112252.21498-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 26 Sep 2019 12:22:52 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> There memset is indented incorrectly, remove the extraneous tabs.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/3] mlxsw: Various fixes
From: David Miller @ 2019-09-27 18:33 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, alexanderk, mlxsw, idosch
In-Reply-To: <20190926114340.9483-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Thu, 26 Sep 2019 14:43:37 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> This patchset includes two small fixes for the mlxsw driver and one
> patch which clarifies recently introduced devlink-trap documentation.
>
> Patch #1 clears the port's VLAN filters during port initialization. This
> ensures that the drop reason reported to the user is consistent. The
> problem is explained in detail in the commit message.
>
> Patch #2 clarifies the description of one of the traps exposed via
> devlink-trap.
>
> Patch #3 from Danielle forbids the installation of a tc filter with
> multiple mirror actions since this is not supported by the device. The
> failure is communicated to the user via extack.
Series applied.
^ permalink raw reply
* Re: [PATCH net] tcp_bbr: fix quantization code to not raise cwnd if not probing bandwidth
From: David Miller @ 2019-09-27 18:39 UTC (permalink / raw)
To: yyd; +Cc: netdev, ncardwell, ycheng, soheil, priyarjha
In-Reply-To: <20190926143005.106045-1-yyd@google.com>
From: "Kevin(Yudong) Yang" <yyd@google.com>
Date: Thu, 26 Sep 2019 10:30:05 -0400
> There was a bug in the previous logic that attempted to ensure gain cycling
> gets inflight above BDP even for small BDPs. This code correctly raised and
> lowered target inflight values during the gain cycle. And this code
> correctly ensured that cwnd was raised when probing bandwidth. However, it
> did not correspondingly ensure that cwnd was *not* raised in this way when
> *not* probing for bandwidth. The result was that small-BDP flows that were
> always cwnd-bound could go for many cycles with a fixed cwnd, and not probe
> or yield bandwidth at all. This meant that multiple small-BDP flows could
> fail to converge in their bandwidth allocations.
>
> Fixes: 383d470 ("tcp_bbr: fix bw probing to raise in-flight data for very small BDPs")
Always use 12 digits of significance for SHA1 IDs, there are already 6 digit conflicts.
> Signed-off-by: Kevin(Yudong) Yang <yyd@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Priyaranjan Jha <priyarjha@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2 net] sk_buff: drop all skb extensions on free and skb scrubbing
From: David Miller @ 2019-09-27 18:40 UTC (permalink / raw)
To: fw; +Cc: netdev, steffen.klassert, paulb, vladbu
In-Reply-To: <20190926183705.16951-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 26 Sep 2019 20:37:05 +0200
> Now that we have a 3rd extension, add a new helper that drops the
> extension space and use it when we need to scrub an sk_buff.
>
> At this time, scrubbing clears secpath and bridge netfilter data, but
> retains the tc skb extension, after this patch all three get cleared.
>
> NAPI reuse/free assumes we can only have a secpath attached to skb, but
> it seems better to clear all extensions there as well.
>
> v2: add unlikely hint (Eric Dumazet)
>
> Fixes: 95a7233c452a ("net: openvswitch: Set OvS recirc_id from tc chain index")
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied.
^ permalink raw reply
* Re: [PATCH net] tcp: better handle TCP_USER_TIMEOUT in SYN_SENT state
From: David Miller @ 2019-09-27 18:42 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, ycheng, marek, jmaxwell37
In-Reply-To: <20190926224251.249797-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 26 Sep 2019 15:42:51 -0700
> Yuchung Cheng and Marek Majkowski independently reported a weird
> behavior of TCP_USER_TIMEOUT option when used at connect() time.
>
> When the TCP_USER_TIMEOUT is reached, tcp_write_timeout()
> believes the flow should live, and the following condition
> in tcp_clamp_rto_to_user_timeout() programs one jiffie timers :
>
> remaining = icsk->icsk_user_timeout - elapsed;
> if (remaining <= 0)
> return 1; /* user timeout has passed; fire ASAP */
>
> This silly situation ends when the max syn rtx count is reached.
>
> This patch makes sure we honor both TCP_SYNCNT and TCP_USER_TIMEOUT,
> avoiding these spurious SYN packets.
>
> Fixes: b701a99e431d ("tcp: Add tcp_clamp_rto_to_user_timeout() helper to improve accuracy")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Yuchung Cheng <ycheng@google.com>
> Reported-by: Marek Majkowski <marek@cloudflare.com>
> Cc: Jon Maxwell <jmaxwell37@gmail.com>
> Link: https://marc.info/?l=linux-netdev&m=156940118307949&w=2
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] tools: bpf: Use !building_out_of_srctree to determine srctree
From: Song Liu @ 2019-09-27 18:44 UTC (permalink / raw)
To: Shuah Khan
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Networking, bpf, open list, linux-kselftest
In-Reply-To: <20190927011344.4695-1-skhan@linuxfoundation.org>
On Thu, Sep 26, 2019 at 6:14 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>
> make TARGETS=bpf kselftest fails with:
>
> Makefile:127: tools/build/Makefile.include: No such file or directory
>
> When the bpf tool make is invoked from tools Makefile, srctree is
> cleared and the current logic check for srctree equals to empty
> string to determine srctree location from CURDIR.
>
> When the build in invoked from selftests/bpf Makefile, the srctree
> is set to "." and the same logic used for srctree equals to empty is
> needed to determine srctree.
>
> Check building_out_of_srctree undefined as the condition for both
> cases to fix "make TARGETS=bpf kselftest" build failure.
>
> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The fix looks reasonable. Thanks!
However, I am still seeing some failure:
make TARGETS=bpf kselftest
[...]
test_verifier.c
/data/users/songliubraving/kernel/linux-git/tools/testing/selftests/bpf/test_stub.o
/data/users/songliubraving/kernel/linux-git/tools/testing/selftests/bpf/libbpf.a
-lcap -lelf -lrt -lpthread -o
/data/users/songliubraving/kernel/linux-git/tools/testing/selftests/bpf/test_verifier
make[3]: test_verifier.c: Command not found
Is this just a problem with my setup?
Thanks,
Song
^ permalink raw reply
* Re: [PATCH net] sch_cbq: validate TCA_CBQ_WRROPT to avoid crash
From: David Miller @ 2019-09-27 18:55 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, syzkaller
In-Reply-To: <20190927012443.129446-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 26 Sep 2019 18:24:43 -0700
> syzbot reported a crash in cbq_normalize_quanta() caused
> by an out of range cl->priority.
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Fixes: tag? -stable?
^ permalink raw reply
* Re: [PATCH v3] nfp: abm: fix memory leak in nfp_abm_u32_knode_replace
From: David Miller @ 2019-09-27 18:56 UTC (permalink / raw)
To: navid.emamdoost
Cc: jakub.kicinski, emamd001, smccaman, kjlu, pablo, john.hurley,
colin.king, oss-drivers, netdev, linux-kernel
In-Reply-To: <20190927015157.20070-1-navid.emamdoost@gmail.com>
From: Navid Emamdoost <navid.emamdoost@gmail.com>
Date: Thu, 26 Sep 2019 20:51:46 -0500
> In nfp_abm_u32_knode_replace if the allocation for match fails it should
> go to the error handling instead of returning. Updated other gotos to
> have correct errno returned, too.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: tap: clean up an indentation issue
From: David Miller @ 2019-09-27 18:58 UTC (permalink / raw)
To: colin.king; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190927094039.23370-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 27 Sep 2019 10:40:39 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a statement that is indented too deeply, remove
> the extraneous tab.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox