* Re: [PATCH net-next 0/5] net: Consolidate metrics handling for ipv4 and ipv6
From: David Miller @ 2018-10-05 4:55 UTC (permalink / raw)
To: dsahern; +Cc: netdev, weiwan, sd, xiyou.wangcong, dsahern
In-Reply-To: <20181005030755.31217-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Thu, 4 Oct 2018 20:07:50 -0700
> From: David Ahern <dsahern@gmail.com>
>
> As part of the IPv6 fib info refactoring, the intent was to make metrics
> handling for ipv6 identical to ipv4. One oversight in ip6_dst_destroy
> led to confusion and a couple of incomplete attempts at finding and
> fixing the resulting memory leak which was ultimately resolved by
> ce7ea4af0838 ("ipv6: fix memory leak on dst->_metrics").
>
> Refactor metrics hanlding make the code really identical for v4 and v6,
> and add a few test cases.
Looks nice, series applied, thanks David.
^ permalink raw reply
* RE: [PATCH 2/2] netdev/phy: add MDIO bus multiplexer driven by a regmap
From: Pankaj Bansal @ 2018-10-05 4:31 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, netdev@vger.kernel.org, Alexandru Marginean
In-Reply-To: <20181005035142.GC7715@lunn.ch>
Hi Andrew
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, October 5, 2018 9:22 AM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org;
> Alexandru Marginean <alexandru.marginean@nxp.com>
> Subject: Re: [PATCH 2/2] netdev/phy: add MDIO bus multiplexer driven by a
> regmap
>
> On Fri, Oct 05, 2018 at 01:59:26PM +0530, 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>
> > ---
> > drivers/net/phy/Kconfig | 13 ++
> > drivers/net/phy/Makefile | 1 +
> > drivers/net/phy/mdio-mux-regmap.c | 177
> ++++++++++++++++++++++++++++
> > 3 files changed, 191 insertions(+)
> >
> > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index
> > 82070792edbb..bb894ede7464 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 && HAS_IOMEM
>
> Hi Pankaj
>
> Doesn't it also depend on REGMAP?
I will add
>
> > + select MDIO_BUS_MUX
> > + help
> > + This module provides a driver for MDIO bus multiplexers that
> > + are controlled via a regmap, like an FPGA.
> > + 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..b0882273fd47
> > --- /dev/null
> > +++ b/drivers/net/phy/mdio-mux-regmap.c
> > @@ -0,0 +1,177 @@
> > +// 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 = 0;
> > +
>
> No need to initialise ret.
Ok
>
> > + ret = regmap_update_bits_check(s->regmap,
> > + s->mux_reg,
> > + s->mask,
> > + desired_child,
> > + &change);
>
> When getting the mask from DT, you use be32_to_cpup().
> When testing the reg value against the mask, you use be32_to_cpup().
> Here you do not use be32_to_cpup()?
Can you please tell me for which variable you mean I should use be32_to_cpup?
I use be32_to_cpup when reading device tree entries.
After being read, their values are stored in structure. After that no need to do be32_to_cpup
>
> > +
> > + if (ret)
> > + goto out;
>
> Just do the return here.
Ok
>
> > + if (change)
> > + pr_debug("%s %d -> %d\n", __func__, current_child,
> > + desired_child);
> > +
> > +out:
> > + return ret;
> > +}
> > +
> > +static int mdio_mux_regmap_probe(struct platform_device *pdev) {
> > + struct device_node *np2, *np = pdev->dev.of_node;
> > + struct mdio_mux_regmap_state *s;
> > + const __be32 *iprop;
> > + int len, ret;
> > + u32 val;
> > +
> > + dev_dbg(&pdev->dev, "probing node %pOF\n", np);
> > +
> > + s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
> > + if (!s)
> > + return -ENOMEM;
> > +
> > + s->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> > + if (IS_ERR(s->regmap)) {
> > + dev_err(&pdev->dev, "Failed to get parent regmap\n");
> > + ret = PTR_ERR(s->regmap);
> > + return ret;
>
> return PTR_ERR(s->regmap);
Ok
>
> > + }
> > +
> > + iprop = of_get_property(np, "reg", &len);
> > + if (!iprop || len != sizeof(u32)) {
> > + dev_err(&pdev->dev, "missing or invalid reg property\n");
> > + return -ENODEV;
> > + }
> > + s->mux_reg = (u32)be32_to_cpup(iprop);
> > +
> > + /* Test Register read write */
> > + ret = regmap_read(s->regmap, s->mux_reg, &val);
> > + if (ret) {
> > + dev_err(&pdev->dev, "error while reading reg\n");
> > + return ret;
> > + }
> > +
> > + ret = regmap_write(s->regmap, s->mux_reg, val);
> > + if (ret) {
> > + dev_err(&pdev->dev, "error while writing reg\n");
> > + return ret;
> > + }
> > +
> > + iprop = of_get_property(np, "mux-mask", &len);
> > + if (!iprop || len != sizeof(u32)) {
> > + dev_err(&pdev->dev, "missing or invalid mux-mask
> property\n");
> > + return -ENODEV;
> > + }
> > + s->mask = (uint32_t)be32_to_cpup(iprop);
>
> Is this cast needed?
I will remove the typecasts.
>
> > +
> > + /* Verify that the 'reg' property of each child MDIO bus does not
> > + * set any bits outside of the 'mask'.
> > + */
> > + for_each_available_child_of_node(np, np2) {
> > + iprop = of_get_property(np2, "reg", &len);
> > + if (!iprop || len != sizeof(u32)) {
> > + dev_err(&pdev->dev, "mdio-mux child node %pOF is
> missing a 'reg' property\n", np2);
> > + of_node_put(np2);
> > + return -ENODEV;
> > + }
> > + if (be32_to_cpup(iprop) & ~s->mask) {
> > + dev_err(&pdev->dev, "mdio-mux child node %pOF
> has a 'reg' value with unmasked bits\n", np2);
> > + of_node_put(np2);
> > + return -ENODEV;
> > + }
> > + }
> > +
> > + ret = mdio_mux_init(&pdev->dev, pdev->dev.of_node,
> > + mdio_mux_regmap_switch_fn,
> > + &s->mux_handle, s, NULL);
> > + if (ret) {
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(&pdev->dev,
> > + "failed to register mdio-mux bus %pOF\n",
> np);
> > + return ret;
> > + }
> > +
> > + pdev->dev.platform_data = s;
> > + return 0;
> > +}
> > +
> > +static int mdio_mux_regmap_remove(struct platform_device *pdev) {
> > + struct mdio_mux_regmap_state *s = dev_get_platdata(&pdev-
> >dev);
> > +
> > + mdio_mux_uninit(s->mux_handle);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id mdio_mux_regmap_match[] = {
> > + {
> > + .compatible = "mdio-mux-regmap",
> > + },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, mdio_mux_regmap_match);
> > +
> > +static struct platform_driver mdio_mux_regmap_driver = {
> > + .driver = {
> > + .name = "mdio-mux-regmap",
> > + .of_match_table = mdio_mux_regmap_match,
> > + },
> > + .probe = mdio_mux_regmap_probe,
> > + .remove = mdio_mux_regmap_remove,
> > +};
> > +
> > +module_platform_driver(mdio_mux_regmap_driver);
> > +
> > +MODULE_AUTHOR("Pankaj Bansal <pankaj.bansal@nxp.com>");
> > +MODULE_DESCRIPTION("I2c device MDIO MUX driver");
>
> I2C should be replaced by regmap.
Nice catch. I will replace it.
>
> Andrew
^ permalink raw reply
* Re: [PATCH 2/2] can: tcan4x5x: Add tcan4x5x driver to the kernel
From: Dan Murphy @ 2018-10-05 11:45 UTC (permalink / raw)
To: Wolfgang Grandegger, mkl, davem
Cc: linux-can, netdev, linux-kernel, Mario.Huettel
In-Reply-To: <6f055cd9-9452-0b4c-2df2-3d0cc06f9e68@grandegger.com>
Wolfgang
On 10/05/2018 12:56 AM, Wolfgang Grandegger wrote:
> Hello Dan,
>
> Am 04.10.2018 um 22:26 schrieb Dan Murphy:
>> Wolfgang
>>
>> On 09/26/2018 12:54 PM, Wolfgang Grandegger wrote:
>>> Hello,
>>>
>>> I wonder why you do not extend the existing MCAN driver by implementing
>>> an interface to access the hardware. Would that be feasible?
>>>
>>
>> I have created a m_can_core code base that can be used by other hardware that
>> have special needs.
>>
>> So I have created the m_can_core, m_can and the tcan4x5x drivers.
>
> Great, I still think it's a good idea to have just one "m_can" driver.
The m_can and tcan4x5x provide the device level implementations. The m_can_core
deals specifically with handling of the m_can IP and protocol.
>
>> I can RFC the code to see if this is what is expected.
>> It is not 100% working but it is close enough for a directional call.
>
> That would be nice! Most of the SPI accesses are pure register accesses.
> A few read/write more bytes at a time (for data, etc.) but that could be
> handled by appropriate interface functions. One general problem is that
> SPI accesses are not possible from interrupt context requiring threads
> or work queues. Also NAPI is usually not used.
>
> Other opinions?
agreed. Is there any issue with moving the request_irq to a threaded_irq?
Not sure how that would affect the timing.
>
> Wolfgang.
>
> PS: I have added Mario to the CC. Maybe he could test a common driver on
> his M_CAN hardware.
>
I found that our am5/dra76 EVM also uses this IP stack. So I am working with
our experts there to test and review the code as well.
Dan
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH v3] net/ncsi: Add NCSI OEM command support
From: Samuel Mendoza-Jonas @ 2018-10-05 4:47 UTC (permalink / raw)
To: Vijay Khemka, Justin . Lee1 @ Dell . com, joel @ jms . id . au,
linux-aspeed @ lists . ozlabs . org,
openbmc @ lists . ozlabs . org, Sai Dasari,
netdev @ vger . kernel . org, christian @ cmd . nu
In-Reply-To: <20181003233222.3909359-1-vijaykhemka@fb.com>
On Wed, 2018-10-03 at 16:32 -0700, Vijay Khemka wrote:
> This patch adds OEM commands and response handling. It also defines OEM
> command and response structure as per NCSI specification along with its
> handlers.
>
> ncsi_cmd_handler_oem: This is a generic command request handler for OEM
> commands
> ncsi_rsp_handler_oem: This is a generic response handler for OEM commands
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Technically this patch should also be marked [PATCH net-next] to target
David's next tree.
> ---
> net/ncsi/internal.h | 5 +++++
> net/ncsi/ncsi-cmd.c | 30 +++++++++++++++++++++++++++---
> net/ncsi/ncsi-pkt.h | 14 ++++++++++++++
> net/ncsi/ncsi-rsp.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 88 insertions(+), 4 deletions(-)
>
> diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h
> index 8055e3965cef..3d0a33b874f5 100644
> --- a/net/ncsi/internal.h
> +++ b/net/ncsi/internal.h
> @@ -68,6 +68,10 @@ enum {
> NCSI_MODE_MAX
> };
>
> +/* OEM Vendor Manufacture ID */
> +#define NCSI_OEM_MFR_MLX_ID 0x8119
> +#define NCSI_OEM_MFR_BCM_ID 0x113d
> +
> struct ncsi_channel_version {
> u32 version; /* Supported BCD encoded NCSI version */
> u32 alpha2; /* Supported BCD encoded NCSI version */
> @@ -305,6 +309,7 @@ struct ncsi_cmd_arg {
> unsigned short words[8];
> unsigned int dwords[4];
> };
> + unsigned char *data; /* NCSI OEM data */
> };
>
> extern struct list_head ncsi_dev_list;
> diff --git a/net/ncsi/ncsi-cmd.c b/net/ncsi/ncsi-cmd.c
> index 7567ca63aae2..82b7d9201db8 100644
> --- a/net/ncsi/ncsi-cmd.c
> +++ b/net/ncsi/ncsi-cmd.c
> @@ -211,6 +211,25 @@ static int ncsi_cmd_handler_snfc(struct sk_buff *skb,
> return 0;
> }
>
> +static int ncsi_cmd_handler_oem(struct sk_buff *skb,
> + struct ncsi_cmd_arg *nca)
> +{
> + struct ncsi_cmd_oem_pkt *cmd;
> + unsigned int len;
> +
> + len = sizeof(struct ncsi_cmd_pkt_hdr) + 4;
> + if (nca->payload < 26)
> + len += 26;
> + else
> + len += nca->payload;
> +
> + cmd = skb_put_zero(skb, len);
> + memcpy(&cmd->mfr_id, nca->data, nca->payload);
> + ncsi_cmd_build_header(&cmd->cmd.common, nca);
> +
> + return 0;
> +}
> +
> static struct ncsi_cmd_handler {
> unsigned char type;
> int payload;
> @@ -244,7 +263,7 @@ static struct ncsi_cmd_handler {
> { NCSI_PKT_CMD_GNS, 0, ncsi_cmd_handler_default },
> { NCSI_PKT_CMD_GNPTS, 0, ncsi_cmd_handler_default },
> { NCSI_PKT_CMD_GPS, 0, ncsi_cmd_handler_default },
> - { NCSI_PKT_CMD_OEM, 0, NULL },
> + { NCSI_PKT_CMD_OEM, -1, ncsi_cmd_handler_oem },
> { NCSI_PKT_CMD_PLDM, 0, NULL },
> { NCSI_PKT_CMD_GPUUID, 0, ncsi_cmd_handler_default }
> };
> @@ -316,8 +335,13 @@ int ncsi_xmit_cmd(struct ncsi_cmd_arg *nca)
> return -ENOENT;
> }
>
> - /* Get packet payload length and allocate the request */
> - nca->payload = nch->payload;
> + /* Get packet payload length and allocate the request
> + * It is expected that if length set as negative in
> + * handler structure means caller is initializing it
> + * and setting length in nca before calling xmit function
> + */
> + if (nch->payload >= 0)
> + nca->payload = nch->payload;
> nr = ncsi_alloc_command(nca);
> if (!nr)
> return -ENOMEM;
> diff --git a/net/ncsi/ncsi-pkt.h b/net/ncsi/ncsi-pkt.h
> index 91b4b66438df..0f2087c8d42a 100644
> --- a/net/ncsi/ncsi-pkt.h
> +++ b/net/ncsi/ncsi-pkt.h
> @@ -151,6 +151,20 @@ struct ncsi_cmd_snfc_pkt {
> unsigned char pad[22];
> };
>
> +/* OEM Request Command as per NCSI Specification */
> +struct ncsi_cmd_oem_pkt {
> + struct ncsi_cmd_pkt_hdr cmd; /* Command header */
> + __be32 mfr_id; /* Manufacture ID */
> + unsigned char data[]; /* OEM Payload Data */
> +};
> +
> +/* OEM Response Packet as per NCSI Specification */
> +struct ncsi_rsp_oem_pkt {
> + struct ncsi_rsp_pkt_hdr rsp; /* Command header */
> + __be32 mfr_id; /* Manufacture ID */
> + unsigned char data[]; /* Payload data */
> +};
> +
> /* Get Link Status */
> struct ncsi_rsp_gls_pkt {
> struct ncsi_rsp_pkt_hdr rsp; /* Response header */
> diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
> index 930c1d3796f0..d66b34749027 100644
> --- a/net/ncsi/ncsi-rsp.c
> +++ b/net/ncsi/ncsi-rsp.c
> @@ -596,6 +596,47 @@ static int ncsi_rsp_handler_snfc(struct ncsi_request *nr)
> return 0;
> }
>
> +static struct ncsi_rsp_oem_handler {
> + unsigned int mfr_id;
> + int (*handler)(struct ncsi_request *nr);
> +} ncsi_rsp_oem_handlers[] = {
> + { NCSI_OEM_MFR_MLX_ID, NULL },
> + { NCSI_OEM_MFR_BCM_ID, NULL }
> +};
> +
> +/* Response handler for OEM command */
> +static int ncsi_rsp_handler_oem(struct ncsi_request *nr)
> +{
> + struct ncsi_rsp_oem_pkt *rsp;
> + struct ncsi_rsp_oem_handler *nrh = NULL;
> + unsigned int mfr_id, i;
> +
> + /* Get the response header */
> + rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
> + mfr_id = ntohl(rsp->mfr_id);
> +
> + /* Check for manufacturer id and Find the handler */
> + for (i = 0; i < ARRAY_SIZE(ncsi_rsp_oem_handlers); i++) {
> + if (ncsi_rsp_oem_handlers[i].mfr_id == mfr_id) {
> + if (ncsi_rsp_oem_handlers[i].handler)
> + nrh = &ncsi_rsp_oem_handlers[i];
> + else
> + nrh = NULL;
> +
> + break;
> + }
> + }
> +
> + if (!nrh) {
> + netdev_err(nr->ndp->ndev.dev, "Received unrecognized OEM packet with MFR-ID (0x%x)\n",
> + mfr_id);
> + return -ENOENT;
> + }
> +
> + /* Process the packet */
> + return nrh->handler(nr);
> +}
> +
> static int ncsi_rsp_handler_gvi(struct ncsi_request *nr)
> {
> struct ncsi_rsp_gvi_pkt *rsp;
> @@ -932,7 +973,7 @@ static struct ncsi_rsp_handler {
> { NCSI_PKT_RSP_GNS, 172, ncsi_rsp_handler_gns },
> { NCSI_PKT_RSP_GNPTS, 172, ncsi_rsp_handler_gnpts },
> { NCSI_PKT_RSP_GPS, 8, ncsi_rsp_handler_gps },
> - { NCSI_PKT_RSP_OEM, 0, NULL },
> + { NCSI_PKT_RSP_OEM, -1, ncsi_rsp_handler_oem },
> { NCSI_PKT_RSP_PLDM, 0, NULL },
> { NCSI_PKT_RSP_GPUUID, 20, ncsi_rsp_handler_gpuuid }
> };
^ permalink raw reply
* Re: [PATCH net-next] net: sched: remove unused helpers
From: David Miller @ 2018-10-05 4:42 UTC (permalink / raw)
To: jakub.kicinski; +Cc: jiri, netdev, oss-drivers
In-Reply-To: <20181005000751.24150-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 4 Oct 2018 17:07:51 -0700
> tcf_block_dev() doesn't seem to be used anywhere in the tree.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/4] bnxt_en: Misc. bug fixes.
From: David Miller @ 2018-10-05 4:42 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Fri, 5 Oct 2018 00:25:59 -0400
> 4 small bug fixes related to setting firmware message enables bits, possible
> memory leak when probe fails, and ring accouting when RDMA driver is loaded.
>
> Please queue these for -stable as well. Thanks.
Series applied and queued up for -stable.
^ permalink raw reply
* RE: [PATCH 1/2] dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2018-10-05 4:32 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, netdev@vger.kernel.org, Alexandru Marginean
In-Reply-To: <20181005030818.GB7715@lunn.ch>
Hi Andrew
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, October 5, 2018 8:38 AM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org;
> Alexandru Marginean <alexandru.marginean@nxp.com>
> Subject: Re: [PATCH 1/2] dt-bindings: net: add MDIO bus multiplexer driven
> by a regmap device
>
> > +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 {
>
> Hi Pankaj
>
> It looks like you have tab vs space issues.
I will fix the formatting error in V2
>
> > + reg = <1>;
> > + compatible = "ethernet-phy-id0210.7441";
> > + };
>
> A blank line after here please.
OK
> > + phy1@0 {
> > + reg = <0>;
> > + compatible = "ethernet-phy-id0210.7441";
> > + };
> > + };
>
> And here
Ok
>
> > + mdio1_ioslot2@1 { // Slot 2
> > + reg = <0x01>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + };
>
> and here.
Ok
>
> Andrew
^ permalink raw reply
* [PATCH net 4/4] bnxt_en: get the reduced max_irqs by the ones used by RDMA
From: Michael Chan @ 2018-10-05 4:26 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
When getting the max rings supported, get the reduced max_irqs
by the ones used by RDMA.
If the number MSIX is the limiting factor, this bug may cause the
max ring count to be higher than it should be when RDMA driver is
loaded and may result in ring allocation failures.
Fixes: 30f529473ec9 ("bnxt_en: Do not modify max IRQ count after RDMA driver requests/frees IRQs.")
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 3718984..e2d9254 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8622,7 +8622,7 @@ static void _bnxt_get_max_rings(struct bnxt *bp, int *max_rx, int *max_tx,
*max_tx = hw_resc->max_tx_rings;
*max_rx = hw_resc->max_rx_rings;
*max_cp = min_t(int, bnxt_get_max_func_cp_rings_for_en(bp),
- hw_resc->max_irqs);
+ hw_resc->max_irqs - bnxt_get_ulp_msix_num(bp));
*max_cp = min_t(int, *max_cp, hw_resc->max_stat_ctxs);
max_ring_grps = hw_resc->max_hw_ring_grps;
if (BNXT_CHIP_TYPE_NITRO_A0(bp) && BNXT_PF(bp)) {
--
2.5.1
^ permalink raw reply related
* [PATCH net 3/4] bnxt_en: free hwrm resources, if driver probe fails.
From: Michael Chan @ 2018-10-05 4:26 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
From: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
When the driver probe fails, all the resources that were allocated prior
to the failure must be freed. However, hwrm dma response memory is not
getting freed.
This patch fixes the problem described above.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 2564a92..3718984 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3017,10 +3017,11 @@ static void bnxt_free_hwrm_resources(struct bnxt *bp)
{
struct pci_dev *pdev = bp->pdev;
- dma_free_coherent(&pdev->dev, PAGE_SIZE, bp->hwrm_cmd_resp_addr,
- bp->hwrm_cmd_resp_dma_addr);
-
- bp->hwrm_cmd_resp_addr = NULL;
+ if (bp->hwrm_cmd_resp_addr) {
+ dma_free_coherent(&pdev->dev, PAGE_SIZE, bp->hwrm_cmd_resp_addr,
+ bp->hwrm_cmd_resp_dma_addr);
+ bp->hwrm_cmd_resp_addr = NULL;
+ }
}
static int bnxt_alloc_hwrm_resources(struct bnxt *bp)
@@ -9057,6 +9058,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
bnxt_clear_int_mode(bp);
init_err_pci_clean:
+ bnxt_free_hwrm_resources(bp);
bnxt_cleanup_pci(bp);
init_err_free:
--
2.5.1
^ permalink raw reply related
* [PATCH net 2/4] bnxt_en: Fix enables field in HWRM_QUEUE_COS2BW_CFG request
From: Michael Chan @ 2018-10-05 4:26 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
In HWRM_QUEUE_COS2BW_CFG request, enables field should have the bits
set only for the queue ids which are having the valid parameters.
This causes firmware to return error when the TC to hardware CoS queue
mapping is not 1:1 during DCBNL ETS setup.
Fixes: 2e8ef77ee0ff ("bnxt_en: Add TC to hardware QoS queue mapping logic.")
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
index ddc98c3..a85d2be 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
@@ -98,13 +98,13 @@ static int bnxt_hwrm_queue_cos2bw_cfg(struct bnxt *bp, struct ieee_ets *ets,
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_QUEUE_COS2BW_CFG, -1, -1);
for (i = 0; i < max_tc; i++) {
- u8 qidx;
+ u8 qidx = bp->tc_to_qidx[i];
req.enables |= cpu_to_le32(
- QUEUE_COS2BW_CFG_REQ_ENABLES_COS_QUEUE_ID0_VALID << i);
+ QUEUE_COS2BW_CFG_REQ_ENABLES_COS_QUEUE_ID0_VALID <<
+ qidx);
memset(&cos2bw, 0, sizeof(cos2bw));
- qidx = bp->tc_to_qidx[i];
cos2bw.queue_id = bp->q_info[qidx].queue_id;
if (ets->tc_tsa[i] == IEEE_8021QAZ_TSA_STRICT) {
cos2bw.tsa =
--
2.5.1
^ permalink raw reply related
* [PATCH net 1/4] bnxt_en: Fix VNIC reservations on the PF.
From: Michael Chan @ 2018-10-05 4:26 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
The enables bit for VNIC was set wrong when calling the HWRM_FUNC_CFG
firmware call to reserve VNICs. This has the effect that the firmware
will keep a large number of VNICs for the PF, and having very few for
VFs. DPDK driver running on the VFs, which requires more VNICs, may not
work properly as a result.
Fixes: 674f50a5b026 ("bnxt_en: Implement new method to reserve rings.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 0478e56..2564a92 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4650,7 +4650,7 @@ __bnxt_hwrm_reserve_pf_rings(struct bnxt *bp, struct hwrm_func_cfg_input *req,
FUNC_CFG_REQ_ENABLES_NUM_STAT_CTXS : 0;
enables |= ring_grps ?
FUNC_CFG_REQ_ENABLES_NUM_HW_RING_GRPS : 0;
- enables |= vnics ? FUNC_VF_CFG_REQ_ENABLES_NUM_VNICS : 0;
+ enables |= vnics ? FUNC_CFG_REQ_ENABLES_NUM_VNICS : 0;
req->num_rx_rings = cpu_to_le16(rx_rings);
req->num_hw_ring_grps = cpu_to_le16(ring_grps);
--
2.5.1
^ permalink raw reply related
* [PATCH net 0/4] bnxt_en: Misc. bug fixes.
From: Michael Chan @ 2018-10-05 4:25 UTC (permalink / raw)
To: davem; +Cc: netdev
4 small bug fixes related to setting firmware message enables bits, possible
memory leak when probe fails, and ring accouting when RDMA driver is loaded.
Please queue these for -stable as well. Thanks.
Michael Chan (1):
bnxt_en: Fix VNIC reservations on the PF.
Vasundhara Volam (2):
bnxt_en: Fix enables field in HWRM_QUEUE_COS2BW_CFG request
bnxt_en: get the reduced max_irqs by the ones used by RDMA
Venkat Duvvuru (1):
bnxt_en: free hwrm resources, if driver probe fails.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 14 ++++++++------
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 +++---
2 files changed, 11 insertions(+), 9 deletions(-)
--
2.5.1
^ permalink raw reply
* Re:заявка за оферта
From: Dimitar Hristov @ 2018-10-05 3:46 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
Добро утро,
Дайте ни най-добрите цени за тази поръчка. Нуждаем се от 1000 бр., Ако
имаме добри цени. Някои образци също са приложени
Димитър Христов
NugradTradings Eood
София, България
37214 Pojate
Тел. +35137805277
Моб. +351648670356
[-- Attachment #2: SKG_Поръчайте мостри_6744510.r11 --]
[-- Type: application/x-rar, Size: 184685 bytes --]
^ permalink raw reply
* [PATCH] wil6210: fix debugfs_simple_attr.cocci warnings
From: YueHaibing @ 2018-10-05 11:07 UTC (permalink / raw)
To: Maya Erez, Kalle Valo
Cc: YueHaibing, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
wil6210-Rm6X0d1/PG5y9aJCnZT0Uw,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
for debugfs files.
Semantic patch information:
Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
imposes some significant overhead as compared to
DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Signed-off-by: YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
drivers/net/wireless/ath/wil6210/debugfs.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c b/drivers/net/wireless/ath/wil6210/debugfs.c
index 66ffae2..aa50813 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -416,8 +416,8 @@ static int wil_debugfs_iomem_x32_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(fops_iomem_x32, wil_debugfs_iomem_x32_get,
- wil_debugfs_iomem_x32_set, "0x%08llx\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_iomem_x32, wil_debugfs_iomem_x32_get,
+ wil_debugfs_iomem_x32_set, "0x%08llx\n");
static struct dentry *wil_debugfs_create_iomem_x32(const char *name,
umode_t mode,
@@ -432,7 +432,8 @@ static struct dentry *wil_debugfs_create_iomem_x32(const char *name,
data->wil = wil;
data->offset = value;
- file = debugfs_create_file(name, mode, parent, data, &fops_iomem_x32);
+ file = debugfs_create_file_unsafe(name, mode, parent, data,
+ &fops_iomem_x32);
if (!IS_ERR_OR_NULL(file))
wil->dbg_data.iomem_data_count++;
@@ -451,14 +452,15 @@ static int wil_debugfs_ulong_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(wil_fops_ulong, wil_debugfs_ulong_get,
- wil_debugfs_ulong_set, "0x%llx\n");
+DEFINE_DEBUGFS_ATTRIBUTE(wil_fops_ulong, wil_debugfs_ulong_get,
+ wil_debugfs_ulong_set, "0x%llx\n");
static struct dentry *wil_debugfs_create_ulong(const char *name, umode_t mode,
struct dentry *parent,
ulong *value)
{
- return debugfs_create_file(name, mode, parent, value, &wil_fops_ulong);
+ return debugfs_create_file_unsafe(name, mode, parent, value,
+ &wil_fops_ulong);
}
/**
^ permalink raw reply related
* Re: [PATCH] wil6210: fix debugfs_simple_attr.cocci warnings
From: Kalle Valo @ 2018-10-05 11:04 UTC (permalink / raw)
To: YueHaibing
Cc: Maya Erez, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
wil6210-Rm6X0d1/PG5y9aJCnZT0Uw,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1538737646-118337-1-git-send-email-yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> writes:
> Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
> for debugfs files.
>
> Semantic patch information:
> Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
> imposes some significant overhead as compared to
> DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
>
> Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Just out of curiosity, what kind of overhead are we talking about here?
--
Kalle Valo
^ permalink raw reply
* Re: [RFC v2 bpf-next 5/5] selftests/bpf: verifier, check bpf_map_lookup_elem access in bpf prog
From: Prashant Bhole @ 2018-10-05 2:07 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, Daniel Borkmann, Jakub Kicinski,
David S . Miller, Quentin Monnet, netdev
In-Reply-To: <20181005015144.ct3vsjol53ndveeh@ast-mbp.dhcp.thefacebook.com>
On 10/5/2018 10:51 AM, Alexei Starovoitov wrote:
> On Tue, Oct 02, 2018 at 02:35:19PM +0900, Prashant Bhole wrote:
>> map_lookup_elem isn't supported by certain map types like:
>> - BPF_MAP_TYPE_PROG_ARRAY
>> - BPF_MAP_TYPE_STACK_TRACE
>> - BPF_MAP_TYPE_XSKMAP
>> - BPF_MAP_TYPE_SOCKMAP/BPF_MAP_TYPE_SOCKHASH
>> Let's add verfier tests to check whether verifier prevents
>> bpf_map_lookup_elem call on above programs from bpf program.
>>
>> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
>> ---
>> tools/testing/selftests/bpf/test_verifier.c | 121 +++++++++++++++++++-
>> 1 file changed, 120 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
>> index c7d25f23baf9..afa7e67f66e4 100644
>> --- a/tools/testing/selftests/bpf/test_verifier.c
>> +++ b/tools/testing/selftests/bpf/test_verifier.c
>> @@ -47,7 +47,7 @@
>>
>> #define MAX_INSNS BPF_MAXINSNS
>> #define MAX_FIXUPS 8
>> -#define MAX_NR_MAPS 8
>> +#define MAX_NR_MAPS 13
>> #define POINTER_VALUE 0xcafe4all
>> #define TEST_DATA_LEN 64
>>
>> @@ -64,6 +64,10 @@ struct bpf_test {
>> int fixup_map2[MAX_FIXUPS];
>> int fixup_map3[MAX_FIXUPS];
>> int fixup_map4[MAX_FIXUPS];
>> + int fixup_map5[MAX_FIXUPS];
>> + int fixup_map6[MAX_FIXUPS];
>> + int fixup_map7[MAX_FIXUPS];
>> + int fixup_map8[MAX_FIXUPS];
>> int fixup_prog1[MAX_FIXUPS];
>> int fixup_prog2[MAX_FIXUPS];
>> int fixup_map_in_map[MAX_FIXUPS];
>> @@ -4391,6 +4395,85 @@ static struct bpf_test tests[] = {
>> .errstr = "invalid access to packet",
>> .prog_type = BPF_PROG_TYPE_SCHED_CLS,
>> },
>> + {
>> + "prevent map lookup in sockmap",
>> + .insns = {
>> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
>> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
>> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
>> + BPF_LD_MAP_FD(BPF_REG_1, 0),
>> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
>> + BPF_FUNC_map_lookup_elem),
>> + BPF_EXIT_INSN(),
>> + },
>> + .fixup_map5 = { 3 },
>> + .result = REJECT,
>> + .errstr = "cannot pass map_type 15 into func bpf_map_lookup_elem",
>> + .prog_type = BPF_PROG_TYPE_SOCK_OPS,
>> + },
>> + {
>> + "prevent map lookup in sockhash",
>> + .insns = {
>> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
>> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
>> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
>> + BPF_LD_MAP_FD(BPF_REG_1, 0),
>> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
>> + BPF_FUNC_map_lookup_elem),
>> + BPF_EXIT_INSN(),
>> + },
>> + .fixup_map6 = { 3 },
>> + .result = REJECT,
>> + .errstr = "cannot pass map_type 18 into func bpf_map_lookup_elem",
>> + .prog_type = BPF_PROG_TYPE_SOCK_OPS,
>> + },
>> + {
>> + "prevent map lookup in xskmap",
>> + .insns = {
>> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
>> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
>> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
>> + BPF_LD_MAP_FD(BPF_REG_1, 0),
>> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
>> + BPF_FUNC_map_lookup_elem),
>> + BPF_EXIT_INSN(),
>> + },
>> + .fixup_map7 = { 3 },
>> + .result = REJECT,
>> + .errstr = "cannot pass map_type 17 into func bpf_map_lookup_elem",
>> + .prog_type = BPF_PROG_TYPE_XDP,
>> + },
>> + {
>> + "prevent map lookup in stack trace",
>> + .insns = {
>> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
>> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
>> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
>> + BPF_LD_MAP_FD(BPF_REG_1, 0),
>> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
>> + BPF_FUNC_map_lookup_elem),
>> + BPF_EXIT_INSN(),
>> + },
>> + .fixup_map8 = { 3 },
>> + .result = REJECT,
>> + .errstr = "cannot pass map_type 7 into func bpf_map_lookup_elem",
>> + .prog_type = BPF_PROG_TYPE_PERF_EVENT,
>> + },
>> + {
>> + "prevent map lookup in prog array",
>> + .insns = {
>> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
>> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
>> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
>> + BPF_LD_MAP_FD(BPF_REG_1, 0),
>> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
>> + BPF_FUNC_map_lookup_elem),
>> + BPF_EXIT_INSN(),
>> + },
>> + .fixup_prog2 = { 3 },
>> + .result = REJECT,
>> + .errstr = "cannot pass map_type 3 into func bpf_map_lookup_elem",
>
> excellent tests. exactly what I was hoping to see.
>
>> + },
>> {
>> "valid map access into an array with a constant",
>> .insns = {
>> @@ -12755,6 +12838,10 @@ static void do_test_fixup(struct bpf_test *test, struct bpf_insn *prog,
>> int *fixup_map2 = test->fixup_map2;
>> int *fixup_map3 = test->fixup_map3;
>> int *fixup_map4 = test->fixup_map4;
>> + int *fixup_map5 = test->fixup_map5;
>> + int *fixup_map6 = test->fixup_map6;
>> + int *fixup_map7 = test->fixup_map7;
>> + int *fixup_map8 = test->fixup_map8;
>> int *fixup_prog1 = test->fixup_prog1;
>> int *fixup_prog2 = test->fixup_prog2;
>> int *fixup_map_in_map = test->fixup_map_in_map;
>> @@ -12843,6 +12930,38 @@ static void do_test_fixup(struct bpf_test *test, struct bpf_insn *prog,
>> fixup_percpu_cgroup_storage++;
>> } while (*fixup_percpu_cgroup_storage);
>> }
>> + if (*fixup_map5) {
>> + map_fds[9] = create_map(BPF_MAP_TYPE_SOCKMAP, sizeof(int),
>> + sizeof(int), 1);
>> + do {
>> + prog[*fixup_map5].imm = map_fds[9];
>> + fixup_map5++;
>> + } while (*fixup_map5);
>> + }
>> + if (*fixup_map6) {
>> + map_fds[10] = create_map(BPF_MAP_TYPE_SOCKHASH, sizeof(int),
>> + sizeof(int), 1);
>> + do {
>> + prog[*fixup_map6].imm = map_fds[10];
>> + fixup_map6++;
>> + } while (*fixup_map6);
>> + }
>> + if (*fixup_map7) {
>> + map_fds[11] = create_map(BPF_MAP_TYPE_XSKMAP, sizeof(int),
>> + sizeof(int), 1);
>> + do {
>> + prog[*fixup_map7].imm = map_fds[11];
>> + fixup_map7++;
>> + } while (*fixup_map7);
>> + }
>> + if (*fixup_map8) {
>> + map_fds[12] = create_map(BPF_MAP_TYPE_STACK_TRACE, sizeof(u32),
>> + sizeof(u64), 1);
>> + do {
>> + prog[*fixup_map8].imm = map_fds[12];
>> + fixup_map8++;
>> + } while (fixup_map8);
>
> I understand that you're following the existing naming convention
> with fixup_mapN, but it was ugly before and these 4 additions
> make it completely unreadable.
>
> Could you please refactor the old names:
> fixup_map1 -> fixup_map_hash_8b
> fixup_map2 -> fixup_map_hash_48b (pls double check my math)
> fixup_map3 -> fixup_map_hash_16b
> fixup_map4 -> fixup_map_array_48b
>
> then your new diff will use
> fixup_map5 -> fixup_map_sockmap
> fixup_map6 -> fixup_map_sockhash
> ...
>
> and please drop rfc tag from the next respin.
> Thanks!
>
Thanks for reviewing. I will fix the naming convention in the next patch
series.
-Prashant
^ permalink raw reply
* Re: [RFC v2 bpf-next 5/5] selftests/bpf: verifier, check bpf_map_lookup_elem access in bpf prog
From: Alexei Starovoitov @ 2018-10-05 1:51 UTC (permalink / raw)
To: Prashant Bhole
Cc: Alexei Starovoitov, Daniel Borkmann, Jakub Kicinski,
David S . Miller, Quentin Monnet, netdev
In-Reply-To: <20181002053519.8000-6-bhole_prashant_q7@lab.ntt.co.jp>
On Tue, Oct 02, 2018 at 02:35:19PM +0900, Prashant Bhole wrote:
> map_lookup_elem isn't supported by certain map types like:
> - BPF_MAP_TYPE_PROG_ARRAY
> - BPF_MAP_TYPE_STACK_TRACE
> - BPF_MAP_TYPE_XSKMAP
> - BPF_MAP_TYPE_SOCKMAP/BPF_MAP_TYPE_SOCKHASH
> Let's add verfier tests to check whether verifier prevents
> bpf_map_lookup_elem call on above programs from bpf program.
>
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
> ---
> tools/testing/selftests/bpf/test_verifier.c | 121 +++++++++++++++++++-
> 1 file changed, 120 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> index c7d25f23baf9..afa7e67f66e4 100644
> --- a/tools/testing/selftests/bpf/test_verifier.c
> +++ b/tools/testing/selftests/bpf/test_verifier.c
> @@ -47,7 +47,7 @@
>
> #define MAX_INSNS BPF_MAXINSNS
> #define MAX_FIXUPS 8
> -#define MAX_NR_MAPS 8
> +#define MAX_NR_MAPS 13
> #define POINTER_VALUE 0xcafe4all
> #define TEST_DATA_LEN 64
>
> @@ -64,6 +64,10 @@ struct bpf_test {
> int fixup_map2[MAX_FIXUPS];
> int fixup_map3[MAX_FIXUPS];
> int fixup_map4[MAX_FIXUPS];
> + int fixup_map5[MAX_FIXUPS];
> + int fixup_map6[MAX_FIXUPS];
> + int fixup_map7[MAX_FIXUPS];
> + int fixup_map8[MAX_FIXUPS];
> int fixup_prog1[MAX_FIXUPS];
> int fixup_prog2[MAX_FIXUPS];
> int fixup_map_in_map[MAX_FIXUPS];
> @@ -4391,6 +4395,85 @@ static struct bpf_test tests[] = {
> .errstr = "invalid access to packet",
> .prog_type = BPF_PROG_TYPE_SCHED_CLS,
> },
> + {
> + "prevent map lookup in sockmap",
> + .insns = {
> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
> + BPF_FUNC_map_lookup_elem),
> + BPF_EXIT_INSN(),
> + },
> + .fixup_map5 = { 3 },
> + .result = REJECT,
> + .errstr = "cannot pass map_type 15 into func bpf_map_lookup_elem",
> + .prog_type = BPF_PROG_TYPE_SOCK_OPS,
> + },
> + {
> + "prevent map lookup in sockhash",
> + .insns = {
> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
> + BPF_FUNC_map_lookup_elem),
> + BPF_EXIT_INSN(),
> + },
> + .fixup_map6 = { 3 },
> + .result = REJECT,
> + .errstr = "cannot pass map_type 18 into func bpf_map_lookup_elem",
> + .prog_type = BPF_PROG_TYPE_SOCK_OPS,
> + },
> + {
> + "prevent map lookup in xskmap",
> + .insns = {
> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
> + BPF_FUNC_map_lookup_elem),
> + BPF_EXIT_INSN(),
> + },
> + .fixup_map7 = { 3 },
> + .result = REJECT,
> + .errstr = "cannot pass map_type 17 into func bpf_map_lookup_elem",
> + .prog_type = BPF_PROG_TYPE_XDP,
> + },
> + {
> + "prevent map lookup in stack trace",
> + .insns = {
> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
> + BPF_FUNC_map_lookup_elem),
> + BPF_EXIT_INSN(),
> + },
> + .fixup_map8 = { 3 },
> + .result = REJECT,
> + .errstr = "cannot pass map_type 7 into func bpf_map_lookup_elem",
> + .prog_type = BPF_PROG_TYPE_PERF_EVENT,
> + },
> + {
> + "prevent map lookup in prog array",
> + .insns = {
> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
> + BPF_FUNC_map_lookup_elem),
> + BPF_EXIT_INSN(),
> + },
> + .fixup_prog2 = { 3 },
> + .result = REJECT,
> + .errstr = "cannot pass map_type 3 into func bpf_map_lookup_elem",
excellent tests. exactly what I was hoping to see.
> + },
> {
> "valid map access into an array with a constant",
> .insns = {
> @@ -12755,6 +12838,10 @@ static void do_test_fixup(struct bpf_test *test, struct bpf_insn *prog,
> int *fixup_map2 = test->fixup_map2;
> int *fixup_map3 = test->fixup_map3;
> int *fixup_map4 = test->fixup_map4;
> + int *fixup_map5 = test->fixup_map5;
> + int *fixup_map6 = test->fixup_map6;
> + int *fixup_map7 = test->fixup_map7;
> + int *fixup_map8 = test->fixup_map8;
> int *fixup_prog1 = test->fixup_prog1;
> int *fixup_prog2 = test->fixup_prog2;
> int *fixup_map_in_map = test->fixup_map_in_map;
> @@ -12843,6 +12930,38 @@ static void do_test_fixup(struct bpf_test *test, struct bpf_insn *prog,
> fixup_percpu_cgroup_storage++;
> } while (*fixup_percpu_cgroup_storage);
> }
> + if (*fixup_map5) {
> + map_fds[9] = create_map(BPF_MAP_TYPE_SOCKMAP, sizeof(int),
> + sizeof(int), 1);
> + do {
> + prog[*fixup_map5].imm = map_fds[9];
> + fixup_map5++;
> + } while (*fixup_map5);
> + }
> + if (*fixup_map6) {
> + map_fds[10] = create_map(BPF_MAP_TYPE_SOCKHASH, sizeof(int),
> + sizeof(int), 1);
> + do {
> + prog[*fixup_map6].imm = map_fds[10];
> + fixup_map6++;
> + } while (*fixup_map6);
> + }
> + if (*fixup_map7) {
> + map_fds[11] = create_map(BPF_MAP_TYPE_XSKMAP, sizeof(int),
> + sizeof(int), 1);
> + do {
> + prog[*fixup_map7].imm = map_fds[11];
> + fixup_map7++;
> + } while (*fixup_map7);
> + }
> + if (*fixup_map8) {
> + map_fds[12] = create_map(BPF_MAP_TYPE_STACK_TRACE, sizeof(u32),
> + sizeof(u64), 1);
> + do {
> + prog[*fixup_map8].imm = map_fds[12];
> + fixup_map8++;
> + } while (fixup_map8);
I understand that you're following the existing naming convention
with fixup_mapN, but it was ugly before and these 4 additions
make it completely unreadable.
Could you please refactor the old names:
fixup_map1 -> fixup_map_hash_8b
fixup_map2 -> fixup_map_hash_48b (pls double check my math)
fixup_map3 -> fixup_map_hash_16b
fixup_map4 -> fixup_map_array_48b
then your new diff will use
fixup_map5 -> fixup_map_sockmap
fixup_map6 -> fixup_map_sockhash
...
and please drop rfc tag from the next respin.
Thanks!
^ permalink raw reply
* Re: [RFC v2 bpf-next 2/5] bpf: return EOPNOTSUPP when map lookup isn't supported
From: Alexei Starovoitov @ 2018-10-05 1:45 UTC (permalink / raw)
To: Prashant Bhole
Cc: Alexei Starovoitov, Daniel Borkmann, Jakub Kicinski,
David S . Miller, Quentin Monnet, netdev
In-Reply-To: <14f9b4ae-b1f8-d50c-fdc8-d357199cabc0@lab.ntt.co.jp>
On Fri, Oct 05, 2018 at 09:16:04AM +0900, Prashant Bhole wrote:
>
>
> On 10/5/2018 9:10 AM, Alexei Starovoitov wrote:
> > On Tue, Oct 02, 2018 at 02:35:16PM +0900, Prashant Bhole wrote:
> > > Return ERR_PTR(-EOPNOTSUPP) from map_lookup_elem() methods of below
> > > map types:
> > > - BPF_MAP_TYPE_PROG_ARRAY
> > > - BPF_MAP_TYPE_STACK_TRACE
> > > - BPF_MAP_TYPE_XSKMAP
> > > - BPF_MAP_TYPE_SOCKMAP/BPF_MAP_TYPE_SOCKHASH
> > >
> > > Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
> > > ---
> > > kernel/bpf/arraymap.c | 2 +-
> > > kernel/bpf/sockmap.c | 2 +-
> > > kernel/bpf/stackmap.c | 2 +-
> > > kernel/bpf/xskmap.c | 2 +-
> > > 4 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> > > index dded84cbe814..24583da9ffd1 100644
> > > --- a/kernel/bpf/arraymap.c
> > > +++ b/kernel/bpf/arraymap.c
> > > @@ -449,7 +449,7 @@ static void fd_array_map_free(struct bpf_map *map)
> > > static void *fd_array_map_lookup_elem(struct bpf_map *map, void *key)
> > > {
> > > - return NULL;
> > > + return ERR_PTR(-EOPNOTSUPP);
> >
> > last time we discussed that the verifier should make sure that
> > lookup is not called from bpf program for these map types.
> > I'd like to see test cases in test_verifier.c for these map types
> > to make sure we don't introduce crashes.
>
> Hi Alexei,
> Patch 05/05 adds such tests in test_verifier.c. Please review those changes.
ahh. missed it. sorry about that. looking...
^ permalink raw reply
* Re: [PATCH 08/16] zd1211rw: Replace spin_is_locked() with lockdep
From: Kalle Valo @ 2018-10-05 8:35 UTC (permalink / raw)
To: Lance Roy
Cc: linux-kernel, Paul E. McKenney, Lance Roy, Daniel Drake,
Ulrich Kunitz, David S. Miller, linux-wireless, netdev
In-Reply-To: <20181003053902.6910-9-ldr709@gmail.com>
Lance Roy <ldr709@gmail.com> wrote:
> lockdep_assert_held() is better suited to checking locking requirements,
> since it won't get confused when someone else holds the lock. This is
> also a step towards possibly removing spin_is_locked().
>
> Signed-off-by: Lance Roy <ldr709@gmail.com>
> Cc: Daniel Drake <dsd@gentoo.org>
> Cc: Ulrich Kunitz <kune@deine-taler.de>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: <linux-wireless@vger.kernel.org>
> Cc: <netdev@vger.kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
209e957b467b zd1211rw: Replace spin_is_locked() with lockdep
--
https://patchwork.kernel.org/patch/10624325/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] net: wireless: iwlegacy: Fix possible data races in il4965_send_rxon_assoc()
From: Stanislaw Gruszka @ 2018-10-05 7:54 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: kvalo, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <988494cb-c121-697e-b502-ea4e7c601f47@gmail.com>
On Thu, Oct 04, 2018 at 04:52:19PM +0800, Jia-Ju Bai wrote:
> On 2018/10/4 15:59, Stanislaw Gruszka wrote:
> >On Wed, Oct 03, 2018 at 10:07:45PM +0800, Jia-Ju Bai wrote:
> >>These possible races are detected by a runtime testing.
> >>To fix these races, the mutex lock is used in il4965_send_rxon_assoc()
> >>to protect the data.
> >Really ? I'm surprised by that, see below.
>
> My runtime testing shows that il4965_send_rxon_assoc() and
> il4965_configure_filter() are concurrently executed.
> But after seeing your reply, I need to carefully check whether my
> runtime testing is right, because I think you are right.
> In fact, I only monitored the iwl4965 driver, but did not monitor
> the iwlegacy driver, so I will do the testing again with monitoring
> the lwlegacy driver.
<snip>
> >So I wonder how this patch did not cause the deadlock ?
>
> Oh, sorry, anyway, my patch will cause double locks...
So how those runtime test were performend such you didn't
notice this ?
> >Anyway what can be done is adding:
> >
> >lockdep_assert_held(&il->mutex);
> >
> >il4965_commit_rxon() to check if we hold the mutex.
>
> I agree.
Care to post a patch ?
Thanks
Stanislaw
^ permalink raw reply
* Re: [PATCH iproute2-next] tc: jsonify output of q_fifo
From: Jakub Kicinski @ 2018-10-05 0:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dsahern, netdev, oss-drivers
In-Reply-To: <20181004171058.0bd85fdb@xeon-e3>
On Thu, 4 Oct 2018 17:10:58 -0700, Stephen Hemminger wrote:
> On Thu, 4 Oct 2018 17:08:34 -0700
> Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
>
> > Print limits correctly in JSON context.
> >
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > ---
> > tc/q_fifo.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/tc/q_fifo.c b/tc/q_fifo.c
> > index cb86a404d4de..61493fbbc5bc 100644
> > --- a/tc/q_fifo.c
> > +++ b/tc/q_fifo.c
> > @@ -69,9 +69,12 @@ static int fifo_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
> > qopt = RTA_DATA(opt);
> > if (strcmp(qu->id, "bfifo") == 0) {
> > SPRINT_BUF(b1);
> > - fprintf(f, "limit %s", sprint_size(qopt->limit, b1));
> > - } else
> > - fprintf(f, "limit %up", qopt->limit);
> > + print_uint(PRINT_JSON, "limit", NULL, qopt->limit);
> > + print_string(PRINT_FP, NULL, "limit %s",
> > + sprint_size(qopt->limit, b1));
> > + } else {
> > + print_uint(PRINT_ANY, "limit", "limit %up", qopt->limit);
> > + }
> > return 0;
> > }
> >
>
> This can go to current not net-next, since it is a bug fix really.
No preference on my side, should I resend?
(Apologies for not CCing you!)
^ permalink raw reply
* Re: [RFC v2 bpf-next 2/5] bpf: return EOPNOTSUPP when map lookup isn't supported
From: Prashant Bhole @ 2018-10-05 0:16 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, Daniel Borkmann, Jakub Kicinski,
David S . Miller, Quentin Monnet, netdev
In-Reply-To: <20181005001043.btwv2k7fbp7gfcbv@ast-mbp.dhcp.thefacebook.com>
On 10/5/2018 9:10 AM, Alexei Starovoitov wrote:
> On Tue, Oct 02, 2018 at 02:35:16PM +0900, Prashant Bhole wrote:
>> Return ERR_PTR(-EOPNOTSUPP) from map_lookup_elem() methods of below
>> map types:
>> - BPF_MAP_TYPE_PROG_ARRAY
>> - BPF_MAP_TYPE_STACK_TRACE
>> - BPF_MAP_TYPE_XSKMAP
>> - BPF_MAP_TYPE_SOCKMAP/BPF_MAP_TYPE_SOCKHASH
>>
>> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
>> ---
>> kernel/bpf/arraymap.c | 2 +-
>> kernel/bpf/sockmap.c | 2 +-
>> kernel/bpf/stackmap.c | 2 +-
>> kernel/bpf/xskmap.c | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
>> index dded84cbe814..24583da9ffd1 100644
>> --- a/kernel/bpf/arraymap.c
>> +++ b/kernel/bpf/arraymap.c
>> @@ -449,7 +449,7 @@ static void fd_array_map_free(struct bpf_map *map)
>>
>> static void *fd_array_map_lookup_elem(struct bpf_map *map, void *key)
>> {
>> - return NULL;
>> + return ERR_PTR(-EOPNOTSUPP);
>
> last time we discussed that the verifier should make sure that
> lookup is not called from bpf program for these map types.
> I'd like to see test cases in test_verifier.c for these map types
> to make sure we don't introduce crashes.
Hi Alexei,
Patch 05/05 adds such tests in test_verifier.c. Please review those
changes. Thank you.
-Prashant
^ permalink raw reply
* Re: [PATCH iproute2-next] tc: jsonify output of q_fifo
From: Stephen Hemminger @ 2018-10-05 0:10 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: dsahern, netdev, oss-drivers
In-Reply-To: <20181005000834.24364-1-jakub.kicinski@netronome.com>
On Thu, 4 Oct 2018 17:08:34 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> Print limits correctly in JSON context.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> tc/q_fifo.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tc/q_fifo.c b/tc/q_fifo.c
> index cb86a404d4de..61493fbbc5bc 100644
> --- a/tc/q_fifo.c
> +++ b/tc/q_fifo.c
> @@ -69,9 +69,12 @@ static int fifo_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
> qopt = RTA_DATA(opt);
> if (strcmp(qu->id, "bfifo") == 0) {
> SPRINT_BUF(b1);
> - fprintf(f, "limit %s", sprint_size(qopt->limit, b1));
> - } else
> - fprintf(f, "limit %up", qopt->limit);
> + print_uint(PRINT_JSON, "limit", NULL, qopt->limit);
> + print_string(PRINT_FP, NULL, "limit %s",
> + sprint_size(qopt->limit, b1));
> + } else {
> + print_uint(PRINT_ANY, "limit", "limit %up", qopt->limit);
> + }
> return 0;
> }
>
This can go to current not net-next, since it is a bug fix really.
^ permalink raw reply
* Re: [RFC v2 bpf-next 2/5] bpf: return EOPNOTSUPP when map lookup isn't supported
From: Alexei Starovoitov @ 2018-10-05 0:10 UTC (permalink / raw)
To: Prashant Bhole
Cc: Alexei Starovoitov, Daniel Borkmann, Jakub Kicinski,
David S . Miller, Quentin Monnet, netdev
In-Reply-To: <20181002053519.8000-3-bhole_prashant_q7@lab.ntt.co.jp>
On Tue, Oct 02, 2018 at 02:35:16PM +0900, Prashant Bhole wrote:
> Return ERR_PTR(-EOPNOTSUPP) from map_lookup_elem() methods of below
> map types:
> - BPF_MAP_TYPE_PROG_ARRAY
> - BPF_MAP_TYPE_STACK_TRACE
> - BPF_MAP_TYPE_XSKMAP
> - BPF_MAP_TYPE_SOCKMAP/BPF_MAP_TYPE_SOCKHASH
>
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
> ---
> kernel/bpf/arraymap.c | 2 +-
> kernel/bpf/sockmap.c | 2 +-
> kernel/bpf/stackmap.c | 2 +-
> kernel/bpf/xskmap.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index dded84cbe814..24583da9ffd1 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
> @@ -449,7 +449,7 @@ static void fd_array_map_free(struct bpf_map *map)
>
> static void *fd_array_map_lookup_elem(struct bpf_map *map, void *key)
> {
> - return NULL;
> + return ERR_PTR(-EOPNOTSUPP);
last time we discussed that the verifier should make sure that
lookup is not called from bpf program for these map types.
I'd like to see test cases in test_verifier.c for these map types
to make sure we don't introduce crashes.
^ permalink raw reply
* [PATCH iproute2-next] tc: jsonify output of q_fifo
From: Jakub Kicinski @ 2018-10-05 0:08 UTC (permalink / raw)
To: dsahern; +Cc: netdev, oss-drivers, Jakub Kicinski
Print limits correctly in JSON context.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
tc/q_fifo.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tc/q_fifo.c b/tc/q_fifo.c
index cb86a404d4de..61493fbbc5bc 100644
--- a/tc/q_fifo.c
+++ b/tc/q_fifo.c
@@ -69,9 +69,12 @@ static int fifo_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
qopt = RTA_DATA(opt);
if (strcmp(qu->id, "bfifo") == 0) {
SPRINT_BUF(b1);
- fprintf(f, "limit %s", sprint_size(qopt->limit, b1));
- } else
- fprintf(f, "limit %up", qopt->limit);
+ print_uint(PRINT_JSON, "limit", NULL, qopt->limit);
+ print_string(PRINT_FP, NULL, "limit %s",
+ sprint_size(qopt->limit, b1));
+ } else {
+ print_uint(PRINT_ANY, "limit", "limit %up", qopt->limit);
+ }
return 0;
}
--
2.17.1
^ permalink raw reply related
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