* RE: [PATCH v2 1/2] dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2018-10-18 4:30 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn; +Cc: netdev@vger.kernel.org
In-Reply-To: <cfe986e2-53bc-f514-311a-d35355744687@gmail.com>
Hi Florian
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> Sent: Sunday, October 7, 2018 11:32 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH v2 1/2] dt-bindings: net: add MDIO bus multiplexer driven by
> a regmap device
>
>
>
> On 10/07/18 11:24, Pankaj Bansal wrote:
> > Add support for an MDIO bus multiplexer controlled by a regmap device,
> > like an FPGA.
> >
> > Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA attached
> > to the i2c bus.
> >
> > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > ---
> >
> > Notes:
> > V2:
> > - Fixed formatting error caused by using space instead of tab
> > - Add newline between property list and subnode
> > - Add newline between two subnodes
> >
> > .../bindings/net/mdio-mux-regmap.txt | 95 ++++++++++++++++++
> > 1 file changed, 95 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
> > b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
> > new file mode 100644
> > index 000000000000..88ebac26c1c5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
> > @@ -0,0 +1,95 @@
> > +Properties for an MDIO bus multiplexer controlled by a regmap
> > +
> > +This is a special case of a MDIO bus multiplexer. A regmap device,
> > +like an FPGA, is used to control which child bus is connected. The
> > +mdio-mux node must be a child of the device that is controlled by a regmap.
> > +The driver currently only supports devices with upto 32-bit registers.
>
> I would omit any sort of details about Linux constructs designed to support
> specific needs (e.g: regmap) as well as putting driver limitations into a binding
> document because it really ought to be restricted to describing hardware.
>
Actually the platform driver mdio-mux-regmap.c, is generalization of mdio-mux-mmioreg.c
As such, it doesn't describe any new hardware, so no new properties are described by it.
The only new property is compatible field.
I don't know how to describe this driver otherwise. Can you please help?
> > +
> > +Required properties in addition to the generic multiplexer properties:
> > +
> > +- compatible : string, must contain "mdio-mux-regmap"
> > +
> > +- reg : integer, contains the offset of the register that controls the bus
> > + multiplexer. it can be 32 bit number.
>
> Technically it could be any "reg" property size, the only requirement is that it
> must be of the appropriate size with respect to what the parent node of this
> "mdio-mux-regmap" node has, determined by #address-cells/#size-cells width.
We are reading only single cell of this property using "of_propert_read_u32".
That is why I put the size in this.
>
> > +
> > +- mux-mask : integer, contains an 32 bit mask that specifies which
> > + bits in the register control the actual bus multiplexer. The
> > + 'reg' property of each child mdio-mux node must be constrained by
> > + this mask.
>
> Same thing here.
We are reading only single cell of this property using "of_propert_read_u32".
That is why I put the size in this.
>
> Since this is a MDIO mux, I would invite you to specify what the correct
> #address-cells/#size-cells values should be (1, and 0 respectively as your
> example correctly shows).
>
I will mention #address-cells/#size-cells values
> > +
> > +Example:
> > +
> > +The FPGA node defines a i2c connected FPGA with a register space of 0x30
> bytes.
> > +For the "EMI2" MDIO bus, register 0x54 (BRDCFG4) controls the mux on that
> bus.
> > +A bitmask of 0x07 means that bits 0, 1 and 2 (bit 0 is lsb) are the
> > +bits on
> > +BRDCFG4 that control the actual mux.
> > +
> > +i2c@2000000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2000000 0x0 0x10000>;
> > + interrupts = <0 34 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + fsl-scl-gpio = <&gpio2 15 0>;
> > + status = "okay";
> > +
> > + /* The FPGA node */
> > + fpga@66 {
> > + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> > + reg = <0x66>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + mdio1_mux@54 {
> > + compatible = "mdio-mux-regmap", "mdio-mux";
> > + mdio-parent-bus = <&emdio2>; /* MDIO bus */
> > + reg = <0x54>; /* BRDCFG4 */
> > + mux-mask = <0x07>; /* EMI2_MDIO */
> > + #address-cells=<1>;
> > + #size-cells = <0>;
> > +
> > + mdio1_ioslot1@0 { // Slot 1
> > + reg = <0x00>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + phy1@1 {
> > + reg = <1>;
> > + compatible = "ethernet-phy-
> id0210.7441";
> > + };
> > +
> > + phy1@0 {
> > + reg = <0>;
> > + compatible = "ethernet-phy-
> id0210.7441";
> > + };
> > + };
> > +
> > + mdio1_ioslot2@1 { // Slot 2
> > + reg = <0x01>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + };
> > +
> > + mdio1_ioslot3@2 { // Slot 3
> > + reg = <0x02>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + };
> > + };
> > + };
> > +};
> > +
> > + /* The parent MDIO bus. */
> > + emdio2: mdio@0x8B97000 {
> > + compatible = "fsl,fman-memac-mdio";
> > + reg = <0x0 0x8B97000 0x0 0x1000>;
> > + device_type = "mdio";
> > + little-endian;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> >
>
> --
> Florian
^ permalink raw reply
* Re: [PATCH 00/16] octeontx2-af: NPA and NIX blocks initialization
From: David Miller @ 2018-10-18 4:34 UTC (permalink / raw)
To: sunil.kovvuri; +Cc: netdev, arnd, linux-soc, sgoutham
In-Reply-To: <1539689240-11526-1-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Tue, 16 Oct 2018 16:57:04 +0530
> This patchset is a continuation to earlier submitted patch series
> to add a new driver for Marvell's OcteonTX2 SOC's
> Resource virtualization unit (RVU) admin function driver.
Series applied.
^ permalink raw reply
* RE: [PATCH v2 2/2] netdev/phy: add MDIO bus multiplexer driven by a regmap
From: Pankaj Bansal @ 2018-10-18 4:35 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn; +Cc: netdev@vger.kernel.org
In-Reply-To: <dffc2112-110b-be61-b90d-5806b6420bb0@gmail.com>
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> Sent: Sunday, October 7, 2018 11:39 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH v2 2/2] netdev/phy: add MDIO bus multiplexer driven by a
> regmap
>
>
>
> On 10/07/18 11:24, Pankaj Bansal wrote:
> > Add support for an MDIO bus multiplexer controlled by a regmap device,
> > like an FPGA.
> >
> > Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA attached
> > to the i2c bus.
> >
> > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > ---
> >
> > Notes:
> > V2:
> > - replaced be32_to_cpup with of_property_read_u32
> > - incorporated Andrew's comments
> >
> > drivers/net/phy/Kconfig | 13 +++
> > drivers/net/phy/Makefile | 1 +
> > drivers/net/phy/mdio-mux-regmap.c | 171 ++++++++++++++++++++++++++++
> > 3 files changed, 185 insertions(+)
> >
> > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index
> > 82070792edbb..d1ac9e70cbb2 100644
> > --- a/drivers/net/phy/Kconfig
> > +++ b/drivers/net/phy/Kconfig
> > @@ -87,6 +87,19 @@ config MDIO_BUS_MUX_MMIOREG
> >
> > Currently, only 8/16/32 bits registers are supported.
> >
> > +config MDIO_BUS_MUX_REGMAP
> > + tristate "REGMAP controlled MDIO bus multiplexers"
> > + depends on OF_MDIO && REGMAP
> > + select MDIO_BUS_MUX
> > + help
> > + This module provides a driver for MDIO bus multiplexers that
> > + are controlled via a regmap device, like an FPGA connected to i2c.
> > + The multiplexer connects one of several child MDIO busses to a
> > + parent bus.Child bus selection is under the control of one of
> > + the FPGA's registers.
> > +
> > + Currently, only upto 32 bits registers are supported.
> > +
> > config MDIO_CAVIUM
> > tristate
> >
> > diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile index
> > 5805c0b7d60e..33053f9f320d 100644
> > --- a/drivers/net/phy/Makefile
> > +++ b/drivers/net/phy/Makefile
> > @@ -29,6 +29,7 @@ obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
> > obj-$(CONFIG_MDIO_BUS_MUX_BCM_IPROC) += mdio-mux-bcm-iproc.o
> > obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
> > obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
> > +obj-$(CONFIG_MDIO_BUS_MUX_REGMAP) += mdio-mux-regmap.o
> > obj-$(CONFIG_MDIO_CAVIUM) += mdio-cavium.o
> > obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
> > obj-$(CONFIG_MDIO_HISI_FEMAC) += mdio-hisi-femac.o
> > diff --git a/drivers/net/phy/mdio-mux-regmap.c
> > b/drivers/net/phy/mdio-mux-regmap.c
> > new file mode 100644
> > index 000000000000..6068d05a728a
> > --- /dev/null
> > +++ b/drivers/net/phy/mdio-mux-regmap.c
> > @@ -0,0 +1,171 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +/* Simple regmap based MDIO MUX driver
> > + *
> > + * Copyright 2018 NXP
> > + *
> > + * Based on mdio-mux-mmioreg.c by Timur Tabi
> > + *
> > + * Author:
> > + * Pankaj Bansal <pankaj.bansal@nxp.com>
> > + */
> > +
> > +#include <linux/platform_device.h>
> > +#include <linux/device.h>
> > +#include <linux/of_mdio.h>
> > +#include <linux/module.h>
> > +#include <linux/phy.h>
> > +#include <linux/mdio-mux.h>
> > +#include <linux/regmap.h>
> > +
> > +struct mdio_mux_regmap_state {
> > + void *mux_handle;
> > + struct regmap *regmap;
> > + u32 mux_reg;
> > + u32 mask;
> > +};
> > +
> > +/* MDIO multiplexing switch function
> > + *
> > + * This function is called by the mdio-mux layer when it thinks the
> > +mdio bus
> > + * multiplexer needs to switch.
> > + *
> > + * 'current_child' is the current value of the mux register (masked
> > +via
> > + * s->mask).
> > + *
> > + * 'desired_child' is the value of the 'reg' property of the target
> > +child MDIO
> > + * node.
> > + *
> > + * The first time this function is called, current_child == -1.
> > + *
> > + * If current_child == desired_child, then the mux is already set to
> > +the
> > + * correct bus.
> > + */
> > +static int mdio_mux_regmap_switch_fn(int current_child, int desired_child,
> > + void *data)
> > +{
> > + struct mdio_mux_regmap_state *s = data;
> > + bool change;
> > + int ret;
> > +
> > + ret = regmap_update_bits_check(s->regmap,
> > + s->mux_reg,
> > + s->mask,
> > + desired_child,
> > + &change);
> > +
> > + if (ret)
> > + return ret;
> > + if (change)
> > + pr_debug("%s %d -> %d\n", __func__, current_child,
> > + desired_child);
>
> If you add a struct platform_device or struct device reference to struct
> mdio_mux_regmap_state, the you can use dev_dbg() here with the correct
> device, which would be helpful if you are debugging problems, and there are
> more than once instance of them in the system.
Ok, I will add platform_device reference to struct.
>
> > + return ret;
> > +}
> > +
> > +static int mdio_mux_regmap_probe(struct platform_device *pdev) {
> > + struct device_node *np2, *np = pdev->dev.of_node;
>
> How about naming "np2", "child" instead?
Ok. I will rename this variable
>
> Everything else looks fine to me, thanks!
> --
> Florian
^ permalink raw reply
* Re: [net-next PATCH] net: sched: cls_flower: Classify packets using port ranges
From: David Miller @ 2018-10-18 4:42 UTC (permalink / raw)
To: amritha.nambiar
Cc: netdev, jakub.kicinski, sridhar.samudrala, jhs, xiyou.wangcong,
jiri
In-Reply-To: <153935241037.11051.5334451030083154425.stgit@anamhost.jf.intel.com>
From: Amritha Nambiar <amritha.nambiar@intel.com>
Date: Fri, 12 Oct 2018 06:53:30 -0700
> Added support in tc flower for filtering based on port ranges.
> This is a rework of the RFC patch at:
> https://patchwork.ozlabs.org/patch/969595/
You never addressed Cong's feedback asking you to explain why this
can't be simply built using existing generic filtering facilities that
exist already.
I appreciate that you addressed Jiri's feedback, but Cong's feedback is
just as, if not more, important.
Thank you.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/2] bpf: add cg_skb_is_valid_access for BPF_PROG_TYPE_CGROUP_SKB
From: Alexei Starovoitov @ 2018-10-18 4:44 UTC (permalink / raw)
To: Song Liu; +Cc: netdev, ast, daniel, kernel-team
In-Reply-To: <20181017233616.3130909-2-songliubraving@fb.com>
On Wed, Oct 17, 2018 at 04:36:15PM -0700, Song Liu wrote:
> BPF programs of BPF_PROG_TYPE_CGROUP_SKB need to access headers in the
> skb. This patch enables direct access of skb for these programs.
>
> In __cgroup_bpf_run_filter_skb(), bpf_compute_data_pointers() is called
> to compute proper data_end for the BPF program.
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
> kernel/bpf/cgroup.c | 4 ++++
> net/core/filter.c | 36 +++++++++++++++++++++++++++++++++++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 00f6ed2e4f9a..340d496f35bd 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -566,6 +566,10 @@ int __cgroup_bpf_run_filter_skb(struct sock *sk,
> save_sk = skb->sk;
> skb->sk = sk;
> __skb_push(skb, offset);
> +
> + /* compute pointers for the bpf prog */
> + bpf_compute_data_pointers(skb);
cg_skb_is_valid_access() below looks good to me now,
but I just realized that above change is not safe for all sockets.
After sk_filter_trim_cap() is called in udp_queue_rcv_skb()
it needs to see valid UDP_SKB_CB.
But sizeof(struct udp_skb_cb)==28, so bpf_compute_data_pointers()
would mangle the end of it.
So we have to save/restore data_end/data_meta pointers as well.
I'm thinking that new helper like:
bpf_compute_and_save_data_pointers(skb, &buffer_of_16_bytes);
BPF_PROG_RUN_ARRAY();
bpf_restore_data_pointers(skb, &buffer_of_16_bytes);
would be decent interface.
^ permalink raw reply
* Re: [PATCH net-next] netpoll: allow cleanup to be synchronous
From: David Miller @ 2018-10-18 4:47 UTC (permalink / raw)
To: dbanerje; +Cc: netdev, nhorman
In-Reply-To: <20181012165929.20098-1-dbanerje@akamai.com>
From: Debabrata Banerjee <dbanerje@akamai.com>
Date: Fri, 12 Oct 2018 12:59:29 -0400
> @@ -826,7 +826,10 @@ static void netpoll_async_cleanup(struct work_struct *work)
>
> void __netpoll_free_async(struct netpoll *np)
> {
> - schedule_work(&np->cleanup_work);
> + if (rtnl_is_locked())
> + __netpoll_cleanup(np);
> + else
> + schedule_work(&np->cleanup_work);
> }
rtnl_is_locked() says only that the RTNL mutex is held by someone.
It does not necessarily say that it is held by the current execution
context.
Which means you could erronesly run this synchronously when another
thread has the RTNL mutex held, not you.
I'm not applying this, sorry.
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix doc of bpf_skb_adjust_room() in uapi
From: Alexei Starovoitov @ 2018-10-18 4:49 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: ast, daniel, davem, netdev, Quentin Monnet
In-Reply-To: <20181017142448.15071-1-nicolas.dichtel@6wind.com>
On Wed, Oct 17, 2018 at 04:24:48PM +0200, Nicolas Dichtel wrote:
> len_diff is signed.
>
> Fixes: fa15601ab31e ("bpf: add documentation for eBPF helpers (33-41)")
> CC: Quentin Monnet <quentin.monnet@netronome.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> include/uapi/linux/bpf.h | 2 +-
> tools/include/uapi/linux/bpf.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 66917a4eba27..c4ffe91d5598 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -1430,7 +1430,7 @@ union bpf_attr {
> * Return
> * 0 on success, or a negative error in case of failure.
> *
> - * int bpf_skb_adjust_room(struct sk_buff *skb, u32 len_diff, u32 mode, u64 flags)
> + * int bpf_skb_adjust_room(struct sk_buff *skb, s32 len_diff, u32 mode, u64 flags)
Thanks. Applied to bpf-next, since we're very late into release cycle.
^ permalink raw reply
* Re: [PATCH net 0/2] geneve, vxlan: Don't set exceptions if skb->len < mtu
From: David Miller @ 2018-10-18 4:51 UTC (permalink / raw)
To: sbrivio; +Cc: lucien.xin, sd, netdev
In-Reply-To: <cover.1539381018.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Fri, 12 Oct 2018 23:53:57 +0200
> This series fixes the exception abuse described in 2/2, and 1/2
> is just a preparatory change to make 2/2 less ugly.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next v2] net: dsa: mv88e6xxx: Fix 88E6141/6341 2500mbps SERDES speed
From: David Miller @ 2018-10-18 4:56 UTC (permalink / raw)
To: marek.behun; +Cc: netdev, andrew
In-Reply-To: <20181013124031.4080-1-marek.behun@nic.cz>
From: Marek Behún <marek.behun@nic.cz>
Date: Sat, 13 Oct 2018 14:40:31 +0200
> This is a fix for the port_set_speed method for the Topaz family.
> Currently the same method is used as for the Peridot family, but
> this is wrong for the SERDES port.
>
> On Topaz, the SERDES port is port 5, not 9 and 10 as in Peridot.
> Moreover setting alt_bit on Topaz only makes sense for port 0 (for
> (differentiating 100mbps vs 200mbps). The SERDES port does not
> support more than 2500mbps, so alt_bit does not make any difference.
>
> Signed-off-by: Marek Behún <marek.behun@nic.cz>
Applied, thank you.
^ permalink raw reply
* [iproute2-next v3] tipc: support interface name when activating UDP bearer
From: Hoang Le @ 2018-10-18 5:03 UTC (permalink / raw)
To: dsahern, jon.maloy, maloy, ying.xue, netdev, tipc-discussion
Support for indicating interface name has an ip address in parallel
with specifying ip address when activating UDP bearer.
This liberates the user from keeping track of the current ip address
for each device.
Old command syntax:
$tipc bearer enable media udp name NAME localip IP
New command syntax:
$tipc bearer enable media udp name NAME [localip IP|dev DEVICE]
v2:
- Removed initial value for fd
- Fixed the returning value for cmd_bearer_validate_and_get_addr
to make its consistent with using: zero or non-zero
v3:
- Switch to use helper 'get_ifname' to retrieve interface name
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
---
tipc/bearer.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 57 insertions(+), 5 deletions(-)
diff --git a/tipc/bearer.c b/tipc/bearer.c
index 05dc84aa8ded..ea971516d3f4 100644
--- a/tipc/bearer.c
+++ b/tipc/bearer.c
@@ -19,10 +19,13 @@
#include <linux/tipc_netlink.h>
#include <linux/tipc.h>
#include <linux/genetlink.h>
+#include <linux/if.h>
+#include <sys/ioctl.h>
#include <libmnl/libmnl.h>
#include <sys/socket.h>
+#include "utils.h"
#include "cmdl.h"
#include "msg.h"
#include "bearer.h"
@@ -68,7 +71,7 @@ static void cmd_bearer_enable_l2_help(struct cmdl *cmdl, char *media)
static void cmd_bearer_enable_udp_help(struct cmdl *cmdl, char *media)
{
fprintf(stderr,
- "Usage: %s bearer enable [OPTIONS] media %s name NAME localip IP [UDP OPTIONS]\n\n",
+ "Usage: %s bearer enable [OPTIONS] media %s name NAME [localip IP|device DEVICE] [UDP OPTIONS]\n\n",
cmdl->argv[0], media);
fprintf(stderr,
"OPTIONS\n"
@@ -121,6 +124,43 @@ static int generate_multicast(short af, char *buf, int bufsize)
return 0;
}
+static int cmd_bearer_validate_and_get_addr(const char *name, char *straddr)
+{
+ struct ifreq ifc = {};
+ struct sockaddr_in *ip4addr;
+ struct sockaddr_in6 *ip6addr;
+ int fd;
+
+ if (!name || !straddr || get_ifname(ifc.ifr_name, name))
+ return 0;
+
+ fd = socket(PF_INET, SOCK_DGRAM, 0);
+ if (fd <= 0) {
+ fprintf(stderr, "Failed to create socket\n");
+ return 0;
+ }
+
+ if (ioctl(fd, SIOCGIFADDR, &ifc) < 0) {
+ fprintf(stderr, "ioctl failed: %s\n", strerror(errno));
+ close(fd);
+ return 0;
+ }
+
+ ip4addr = (struct sockaddr_in *)&ifc.ifr_addr;
+ if (inet_ntop(AF_INET, &ip4addr->sin_addr, straddr,
+ INET_ADDRSTRLEN) == NULL) {
+ ip6addr = (struct sockaddr_in6 *)&ifc.ifr_addr;
+ if (inet_ntop(AF_INET6, &ip6addr->sin6_addr, straddr,
+ INET6_ADDRSTRLEN) == NULL) {
+ fprintf(stderr, "UDP local address error\n");
+ close(fd);
+ return 0;
+ }
+ }
+ close(fd);
+ return 1;
+}
+
static int nl_add_udp_enable_opts(struct nlmsghdr *nlh, struct opt *opts,
struct cmdl *cmdl)
{
@@ -138,13 +178,25 @@ static int nl_add_udp_enable_opts(struct nlmsghdr *nlh, struct opt *opts,
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_DGRAM
};
+ char addr[INET6_ADDRSTRLEN] = {0};
- if (!(opt = get_opt(opts, "localip"))) {
- fprintf(stderr, "error, udp bearer localip missing\n");
- cmd_bearer_enable_udp_help(cmdl, "udp");
+ opt = get_opt(opts, "device");
+ if (opt && !cmd_bearer_validate_and_get_addr(opt->val, addr)) {
+ fprintf(stderr, "error, no device name available\n");
return -EINVAL;
}
- locip = opt->val;
+
+ if (strlen(addr) > 0) {
+ locip = addr;
+ } else {
+ opt = get_opt(opts, "localip");
+ if (!opt) {
+ fprintf(stderr, "error, udp bearer localip/device missing\n");
+ cmd_bearer_enable_udp_help(cmdl, "udp");
+ return -EINVAL;
+ }
+ locip = opt->val;
+ }
if ((opt = get_opt(opts, "remoteip")))
remip = opt->val;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] net: bpfilter: use get_pid_task instead of pid_task
From: David Miller @ 2018-10-18 5:04 UTC (permalink / raw)
To: ap420073; +Cc: netdev, daniel, ast
In-Reply-To: <20181016153510.16962-1-ap420073@gmail.com>
From: Taehee Yoo <ap420073@gmail.com>
Date: Wed, 17 Oct 2018 00:35:10 +0900
> pid_task() dereferences rcu protected tasks array.
> But there is no rcu_read_lock() in shutdown_umh() routine so that
> rcu_read_lock() is needed.
> get_pid_task() is wrapper function of pid_task. it holds rcu_read_lock()
> then calls pid_task(). if task isn't NULL, it increases reference count
> of task.
>
> test commands:
> %modprobe bpfilter
> %modprobe -rv bpfilter
...
> Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/2] bpf: add cg_skb_is_valid_access for BPF_PROG_TYPE_CGROUP_SKB
From: Song Liu @ 2018-10-18 5:06 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
Kernel Team
In-Reply-To: <20181018044407.rj3xgdrweobcvcbn@ast-mbp.dhcp.thefacebook.com>
> On Oct 17, 2018, at 9:44 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Oct 17, 2018 at 04:36:15PM -0700, Song Liu wrote:
>> BPF programs of BPF_PROG_TYPE_CGROUP_SKB need to access headers in the
>> skb. This patch enables direct access of skb for these programs.
>>
>> In __cgroup_bpf_run_filter_skb(), bpf_compute_data_pointers() is called
>> to compute proper data_end for the BPF program.
>>
>> Signed-off-by: Song Liu <songliubraving@fb.com>
>> ---
>> kernel/bpf/cgroup.c | 4 ++++
>> net/core/filter.c | 36 +++++++++++++++++++++++++++++++++++-
>> 2 files changed, 39 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
>> index 00f6ed2e4f9a..340d496f35bd 100644
>> --- a/kernel/bpf/cgroup.c
>> +++ b/kernel/bpf/cgroup.c
>> @@ -566,6 +566,10 @@ int __cgroup_bpf_run_filter_skb(struct sock *sk,
>> save_sk = skb->sk;
>> skb->sk = sk;
>> __skb_push(skb, offset);
>> +
>> + /* compute pointers for the bpf prog */
>> + bpf_compute_data_pointers(skb);
>
> cg_skb_is_valid_access() below looks good to me now,
> but I just realized that above change is not safe for all sockets.
> After sk_filter_trim_cap() is called in udp_queue_rcv_skb()
> it needs to see valid UDP_SKB_CB.
> But sizeof(struct udp_skb_cb)==28, so bpf_compute_data_pointers()
> would mangle the end of it.
> So we have to save/restore data_end/data_meta pointers as well.
>
> I'm thinking that new helper like:
> bpf_compute_and_save_data_pointers(skb, &buffer_of_16_bytes);
> BPF_PROG_RUN_ARRAY();
> bpf_restore_data_pointers(skb, &buffer_of_16_bytes);
> would be decent interface.
Thanks Alexei!
Will send v3 shortly.
Song
^ permalink raw reply
* Re: [PATCH net] r8169: re-enable MSI-X on RTL8168g
From: David Miller @ 2018-10-18 5:10 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <59357029-d025-2180-2c7a-a1fdc4c366b3@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 16 Oct 2018 19:35:17 +0200
> Similar to d49c88d7677b ("r8169: Enable MSI-X on RTL8106e") after
> e9d0ba506ea8 ("PCI: Reprogram bridge prefetch registers on resume")
> we can safely assume that this also fixes the root cause of
> the issue worked around by 7c53a722459c ("r8169: don't use MSI-X on
> RTL8168g"). So let's revert it.
>
> Fixes: 7c53a722459c ("r8169: don't use MSI-X on RTL8168g")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] sctp: fix race on sctp_id2asoc
From: David Miller @ 2018-10-18 5:12 UTC (permalink / raw)
To: marcelo.leitner; +Cc: netdev, linux-sctp, vyasevich, nhorman, dvyukov
In-Reply-To: <081e1546a92f5bde8bdef0366561ff0b8ddd9eb2.1539707812.git.mleitner@redhat.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Tue, 16 Oct 2018 15:18:17 -0300
> syzbot reported an use-after-free involving sctp_id2asoc. Dmitry Vyukov
> helped to root cause it and it is because of reading the asoc after it
> was freed:
>
> CPU 1 CPU 2
> (working on socket 1) (working on socket 2)
> sctp_association_destroy
> sctp_id2asoc
> spin lock
> grab the asoc from idr
> spin unlock
> spin lock
> remove asoc from idr
> spin unlock
> free(asoc)
> if asoc->base.sk != sk ... [*]
>
> This can only be hit if trying to fetch asocs from different sockets. As
> we have a single IDR for all asocs, in all SCTP sockets, their id is
> unique on the system. An application can try to send stuff on an id
> that matches on another socket, and the if in [*] will protect from such
> usage. But it didn't consider that as that asoc may belong to another
> socket, it may be freed in parallel (read: under another socket lock).
>
> We fix it by moving the checks in [*] into the protected region. This
> fixes it because the asoc cannot be freed while the lock is held.
>
> Reported-by: syzbot+c7dd55d7aec49d48e49a@syzkaller.appspotmail.com
> Acked-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] sctp: not free the new asoc when sctp_wait_for_connect returns err
From: David Miller @ 2018-10-18 5:13 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <6ee31cce8c2e36a7e189de11c13c257e8c45b42f.1539716772.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 17 Oct 2018 03:06:12 +0800
> When sctp_wait_for_connect is called to wait for connect ready
> for sp->strm_interleave in sctp_sendmsg_to_asoc, a panic could
> be triggered if cpu is scheduled out and the new asoc is freed
> elsewhere, as it will return err and later the asoc gets freed
> again in sctp_sendmsg.
...
> This is a similar issue with the one fixed in Commit ca3af4dd28cf
> ("sctp: do not free asoc when it is already dead in sctp_sendmsg").
> But this one can't be fixed by returning -ESRCH for the dead asoc
> in sctp_wait_for_connect, as it will break sctp_connect's return
> value to users.
>
> This patch is to simply set err to -ESRCH before it returns to
> sctp_sendmsg when any err is returned by sctp_wait_for_connect
> for sp->strm_interleave, so that no asoc would be freed due to
> this.
>
> When users see this error, they will know the packet hasn't been
> sent. And it also makes sense to not free asoc because waiting
> connect fails, like the second call for sctp_wait_for_connect in
> sctp_sendmsg_to_asoc.
>
> Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* [bpf-next v2 0/2] Fix kcm + sockmap by checking psock type
From: John Fastabend @ 2018-10-18 5:20 UTC (permalink / raw)
To: ast, daniel; +Cc: john.fastabend, netdev, eric.dumazet
We check if the sk_user_data (the psock in skmsg) is in fact a sockmap
type to late, after we read the refcnt which is an error. This
series moves the check up before reading refcnt and also adds a test
to test_maps to test trying to add a KCM socket into a sockmap.
While reviewig this code I also found an issue with KCM and kTLS
where each uses sk_data_ready hooks and associated stream parser
breaking expectations in kcm, ktls or both. But that fix will need
to go to net.
Thanks to Eric for reporting.
v2: Fix up file +/- my scripts lost track of them
John Fastabend (2):
bpf: skmsg, fix psock create on existing kcm/tls port
bpf: test_maps add a test to catch kcm + sockmap
include/linux/skmsg.h | 25 +++++++++---
net/core/sock_map.c | 11 +++---
tools/testing/selftests/bpf/Makefile | 2 +-
tools/testing/selftests/bpf/sockmap_kcm.c | 14 +++++++
tools/testing/selftests/bpf/test_maps.c | 64 ++++++++++++++++++++++++++++++-
5 files changed, 103 insertions(+), 13 deletions(-)
create mode 100644 tools/testing/selftests/bpf/sockmap_kcm.c
--
1.9.1
^ permalink raw reply
* [bpf-next v2 1/2] bpf: skmsg, fix psock create on existing kcm/tls port
From: John Fastabend @ 2018-10-18 5:20 UTC (permalink / raw)
To: ast, daniel; +Cc: john.fastabend, netdev, eric.dumazet
In-Reply-To: <1539840004-26433-1-git-send-email-john.fastabend@gmail.com>
Before using the psock returned by sk_psock_get() when adding it to a
sockmap we need to ensure it is actually a sockmap based psock.
Previously we were only checking this after incrementing the reference
counter which was an error. This resulted in a slab-out-of-bounds
error when the psock was not actually a sockmap type.
This moves the check up so the reference counter is only used
if it is a sockmap psock.
Eric reported the following KASAN BUG,
BUG: KASAN: slab-out-of-bounds in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: slab-out-of-bounds in refcount_inc_not_zero_checked+0x97/0x2f0 lib/refcount.c:120
Read of size 4 at addr ffff88019548be58 by task syz-executor4/22387
CPU: 1 PID: 22387 Comm: syz-executor4 Not tainted 4.19.0-rc7+ #264
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
refcount_inc_not_zero_checked+0x97/0x2f0 lib/refcount.c:120
sk_psock_get include/linux/skmsg.h:379 [inline]
sock_map_link.isra.6+0x41f/0xe30 net/core/sock_map.c:178
sock_hash_update_common+0x19b/0x11e0 net/core/sock_map.c:669
sock_hash_update_elem+0x306/0x470 net/core/sock_map.c:738
map_update_elem+0x819/0xdf0 kernel/bpf/syscall.c:818
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
---
include/linux/skmsg.h | 25 ++++++++++++++++++++-----
net/core/sock_map.c | 11 ++++++-----
2 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h
index 677b673..f44ca6b 100644
--- a/include/linux/skmsg.h
+++ b/include/linux/skmsg.h
@@ -275,11 +275,6 @@ static inline struct sk_psock *sk_psock(const struct sock *sk)
return rcu_dereference_sk_user_data(sk);
}
-static inline bool sk_has_psock(struct sock *sk)
-{
- return sk_psock(sk) != NULL && sk->sk_prot->recvmsg == tcp_bpf_recvmsg;
-}
-
static inline void sk_psock_queue_msg(struct sk_psock *psock,
struct sk_msg *msg)
{
@@ -379,6 +374,26 @@ static inline bool sk_psock_test_state(const struct sk_psock *psock,
return test_bit(bit, &psock->state);
}
+static inline struct sk_psock *sk_psock_get_checked(struct sock *sk)
+{
+ struct sk_psock *psock;
+
+ rcu_read_lock();
+ psock = sk_psock(sk);
+ if (psock) {
+ if (sk->sk_prot->recvmsg != tcp_bpf_recvmsg) {
+ psock = ERR_PTR(-EBUSY);
+ goto out;
+ }
+
+ if (!refcount_inc_not_zero(&psock->refcnt))
+ psock = NULL;
+ }
+out:
+ rcu_read_unlock();
+ return psock;
+}
+
static inline struct sk_psock *sk_psock_get(struct sock *sk)
{
struct sk_psock *psock;
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 3c0e44c..be6092a 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -175,12 +175,13 @@ static int sock_map_link(struct bpf_map *map, struct sk_psock_progs *progs,
}
}
- psock = sk_psock_get(sk);
+ psock = sk_psock_get_checked(sk);
+ if (IS_ERR(psock)) {
+ ret = PTR_ERR(psock);
+ goto out_progs;
+ }
+
if (psock) {
- if (!sk_has_psock(sk)) {
- ret = -EBUSY;
- goto out_progs;
- }
if ((msg_parser && READ_ONCE(psock->progs.msg_parser)) ||
(skb_progs && READ_ONCE(psock->progs.skb_parser))) {
sk_psock_put(sk, psock);
--
1.9.1
^ permalink raw reply related
* [bpf-next v2 2/2] bpf: test_maps add a test to catch kcm + sockmap
From: John Fastabend @ 2018-10-18 5:20 UTC (permalink / raw)
To: ast, daniel; +Cc: john.fastabend, netdev, eric.dumazet
In-Reply-To: <1539840004-26433-1-git-send-email-john.fastabend@gmail.com>
Adding a socket to both sockmap and kcm is not supported due to
collision on sk_user_data usage.
If selftests is run without KCM support we will issue a warning
and continue with the tests.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
tools/testing/selftests/bpf/Makefile | 2 +-
tools/testing/selftests/bpf/sockmap_kcm.c | 14 +++++++
tools/testing/selftests/bpf/test_maps.c | 64 ++++++++++++++++++++++++++++++-
3 files changed, 77 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/bpf/sockmap_kcm.c
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index d99dd6f..f290554 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -28,7 +28,7 @@ TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test
TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test_obj_id.o \
test_pkt_md_access.o test_xdp_redirect.o test_xdp_meta.o sockmap_parse_prog.o \
- sockmap_verdict_prog.o dev_cgroup.o sample_ret0.o test_tracepoint.o \
+ sockmap_verdict_prog.o sockmap_kcm.o dev_cgroup.o sample_ret0.o test_tracepoint.o \
test_l4lb_noinline.o test_xdp_noinline.o test_stacktrace_map.o \
sample_map_ret0.o test_tcpbpf_kern.o test_stacktrace_build_id.o \
sockmap_tcp_msg_prog.o connect4_prog.o connect6_prog.o test_adjust_tail.o \
diff --git a/tools/testing/selftests/bpf/sockmap_kcm.c b/tools/testing/selftests/bpf/sockmap_kcm.c
new file mode 100644
index 0000000..4377adc
--- /dev/null
+++ b/tools/testing/selftests/bpf/sockmap_kcm.c
@@ -0,0 +1,14 @@
+#include <linux/bpf.h>
+#include "bpf_helpers.h"
+#include "bpf_util.h"
+#include "bpf_endian.h"
+
+int _version SEC("version") = 1;
+
+SEC("socket_kcm")
+int bpf_prog1(struct __sk_buff *skb)
+{
+ return skb->len;
+}
+
+char _license[] SEC("license") = "GPL";
diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
index 9b552c0..be20f1d 100644
--- a/tools/testing/selftests/bpf/test_maps.c
+++ b/tools/testing/selftests/bpf/test_maps.c
@@ -20,6 +20,7 @@
#include <sys/socket.h>
#include <netinet/in.h>
#include <linux/bpf.h>
+#include <linux/kcm.h>
#include <bpf/bpf.h>
#include <bpf/libbpf.h>
@@ -479,14 +480,16 @@ static void test_devmap(int task, void *data)
#define SOCKMAP_PARSE_PROG "./sockmap_parse_prog.o"
#define SOCKMAP_VERDICT_PROG "./sockmap_verdict_prog.o"
#define SOCKMAP_TCP_MSG_PROG "./sockmap_tcp_msg_prog.o"
+#define KCM_PROG "./sockmap_kcm.o"
static void test_sockmap(int tasks, void *data)
{
struct bpf_map *bpf_map_rx, *bpf_map_tx, *bpf_map_msg, *bpf_map_break;
- int map_fd_msg = 0, map_fd_rx = 0, map_fd_tx = 0, map_fd_break;
+ int map_fd_msg = 0, map_fd_rx = 0, map_fd_tx = 0, map_fd_break, kcm;
int ports[] = {50200, 50201, 50202, 50204};
int err, i, fd, udp, sfd[6] = {0xdeadbeef};
u8 buf[20] = {0x0, 0x5, 0x3, 0x2, 0x1, 0x0};
- int parse_prog, verdict_prog, msg_prog;
+ int parse_prog, verdict_prog, msg_prog, kcm_prog;
+ struct kcm_attach attach_info;
struct sockaddr_in addr;
int one = 1, s, sc, rc;
struct bpf_object *obj;
@@ -744,6 +747,62 @@ static void test_sockmap(int tasks, void *data)
goto out_sockmap;
}
+ /* Test adding a KCM socket into map */
+#define AF_KCM 41
+ kcm = socket(AF_KCM, SOCK_DGRAM, KCMPROTO_CONNECTED);
+ if (kcm == -1) {
+ printf("Warning, KCM+Sockmap could not be tested.\n");
+ goto skip_kcm;
+ }
+
+ err = bpf_prog_load(KCM_PROG,
+ BPF_PROG_TYPE_SOCKET_FILTER,
+ &obj, &kcm_prog);
+ if (err) {
+ printf("Failed to load SK_SKB parse prog\n");
+ goto out_sockmap;
+ }
+
+ i = 2;
+ memset(&attach_info, 0, sizeof(attach_info));
+ attach_info.fd = sfd[i];
+ attach_info.bpf_fd = kcm_prog;
+ err = ioctl(kcm, SIOCKCMATTACH, &attach_info);
+ if (!err) {
+ perror("Failed KCM attached to sockmap fd: ");
+ goto out_sockmap;
+ }
+
+ err = bpf_map_delete_elem(fd, &i);
+ if (err) {
+ printf("Failed delete sockmap from empty map %i %i\n", err, errno);
+ goto out_sockmap;
+ }
+
+ err = ioctl(kcm, SIOCKCMATTACH, &attach_info);
+ if (err) {
+ perror("Failed KCM attach");
+ goto out_sockmap;
+ }
+
+ err = bpf_map_update_elem(fd, &i, &sfd[i], BPF_ANY);
+ if (!err) {
+ printf("Failed sockmap attached KCM sock!\n");
+ goto out_sockmap;
+ }
+ err = ioctl(kcm, SIOCKCMUNATTACH, &attach_info);
+ if (err) {
+ printf("Failed detach KCM sock!\n");
+ goto out_sockmap;
+ }
+
+ err = bpf_map_update_elem(fd, &i, &sfd[i], BPF_ANY);
+ if (err) {
+ printf("Failed post-kcm update sockmap '%i:%i'\n",
+ i, sfd[i]);
+ goto out_sockmap;
+ }
+
/* Test map update elem afterwards fd lives in fd and map_fd */
for (i = 2; i < 6; i++) {
err = bpf_map_update_elem(map_fd_rx, &i, &sfd[i], BPF_ANY);
@@ -776,6 +835,7 @@ static void test_sockmap(int tasks, void *data)
}
}
+skip_kcm:
/* Put sfd[2] (sending fd below) into msg map to test sendmsg bpf */
i = 0;
err = bpf_map_update_elem(map_fd_msg, &i, &sfd[2], BPF_ANY);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net] r8169: fix NAPI handling under high load
From: David Miller @ 2018-10-18 5:21 UTC (permalink / raw)
To: romieu; +Cc: hkallweit1, nic_swsd, netdev
In-Reply-To: <20181017233044.GA8478@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 18 Oct 2018 01:30:45 +0200
> Heiner Kallweit <hkallweit1@gmail.com> :
> [...]
>> This issue has been there more or less forever (at least it exists in
>> 3.16 already), so I can't provide a "Fixes" tag.
>
> Hardly forever. It fixes da78dbff2e05630921c551dbbc70a4b7981a8fff.
I don't see exactly how that can be true.
That commit didn't change the parts of the NAPI poll processing which
are relevant here, mainly the guarding of the RX and TX work using
the status bits which are cleared.
Maybe I'm missing something? If so, indeed it would be nice to add
a proper Fixes: tag here.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 0/2] tcp_bbr: TCP BBR changes for EDT pacing model
From: David Miller @ 2018-10-18 5:24 UTC (permalink / raw)
To: ncardwell; +Cc: netdev
In-Reply-To: <20181017001645.261770-1-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Tue, 16 Oct 2018 20:16:43 -0400
> Two small patches for TCP BBR to follow up with Eric's recent work to change
> the TCP and fq pacing machinery to an "earliest departure time" (EDT) model:
>
> - The first patch adjusts the TCP BBR logic to work with the new
> "earliest departure time" (EDT) pacing model.
>
> - The second patch adjusts the TCP BBR logic to centralize the setting
> of gain values, to simplify the code and prepare for future changes.
Series applied, thanks Neal.
^ permalink raw reply
* Re: [PATCH net] mlxsw: core: Fix use-after-free when flashing firmware during init
From: David Miller @ 2018-10-18 5:27 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, alexpe, mlxsw
In-Reply-To: <20181017080525.21856-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Wed, 17 Oct 2018 08:05:45 +0000
> When the switch driver (e.g., mlxsw_spectrum) determines it needs to
> flash a new firmware version it resets the ASIC after the flashing
> process. The bus driver (e.g., mlxsw_pci) then registers itself again
> with mlxsw_core which means (among other things) that the device
> registers itself again with the hwmon subsystem again.
>
> Since the device was registered with the hwmon subsystem using
> devm_hwmon_device_register_with_groups(), then the old hwmon device
> (registered before the flashing) was never unregistered and was
> referencing stale data, resulting in a use-after free.
>
> Fix by removing reliance on device managed APIs in mlxsw_hwmon_init().
>
> Fixes: c86d62cc410c ("mlxsw: spectrum: Reset FW after flash")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Reported-by: Alexander Petrovskiy <alexpe@mellanox.com>
> Tested-by: Alexander Petrovskiy <alexpe@mellanox.com>
> Reviewed-by: Petr Machata <petrm@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] udp6: fix encap return code for resubmitting
From: David Miller @ 2018-10-18 5:27 UTC (permalink / raw)
To: pabeni; +Cc: netdev
In-Reply-To: <1e792b80ae514e944f868c904c30e797e02b418c.1539769397.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 17 Oct 2018 11:44:04 +0200
> The commit eb63f2964dbe ("udp6: add missing checks on edumux packet
> processing") used the same return code convention of the ipv4 counterpart,
> but ipv6 uses the opposite one: positive values means resubmit.
>
> This change addresses the issue, using positive return value for
> resubmitting. Also update the related comment, which was broken, too.
>
> Fixes: eb63f2964dbe ("udp6: add missing checks on edumux packet processing")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> Note: I could not find any in kernel udp6 encap using the above
> feature, that would explain why nobody complained so far...
Applied.
^ permalink raw reply
* Re: [PATCH V2 net-next] net: ena: Fix Kconfig dependency on X86
From: David Miller @ 2018-10-18 5:28 UTC (permalink / raw)
To: netanel
Cc: netdev, akiyano, alisaidi, dwmw, zorik, matua, saeedb, msw,
aliguori, nafea, gtzalik
In-Reply-To: <20181017100421.56045-1-netanel@amazon.com>
From: <netanel@amazon.com>
Date: Wed, 17 Oct 2018 10:04:21 +0000
> From: Netanel Belgazal <netanel@amazon.com>
>
> The Kconfig limitation of X86 is to too wide.
> The ENA driver only requires a little endian dependency.
>
> Change the dependency to be on little endian CPU.
>
> Signed-off-by: Netanel Belgazal <netanel@amazon.com>
Applied.
^ permalink raw reply
* Re: [PATCH V1 net-next] net: ena: enable Low Latency Queues
From: David Miller @ 2018-10-18 5:31 UTC (permalink / raw)
To: akiyano
Cc: netdev, dwmw, zorik, matua, saeedb, msw, aliguori, nafea, gtzalik,
netanel, alisaidi
In-Reply-To: <1539779603-17895-1-git-send-email-akiyano@amazon.com>
From: <akiyano@amazon.com>
Date: Wed, 17 Oct 2018 15:33:23 +0300
> From: Arthur Kiyanovski <akiyano@amazon.com>
>
> Use the new API to enable usage of LLQ.
>
> Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] sctp: fix the data size calculation in sctp_data_size
From: David Miller @ 2018-10-18 5:33 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <c407b682a424f0441d9b9a29ef6296c8e9824b64.1539781887.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 17 Oct 2018 21:11:27 +0800
> sctp data size should be calculated by subtracting data chunk header's
> length from chunk_hdr->length, not just data header.
>
> Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable.
^ 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