* Re: [PATCH] fm10k: Use dev_get_drvdata
From: David Miller @ 2019-07-23 20:03 UTC (permalink / raw)
To: hslester96; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190723141533.5803-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 22:15:33 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* [PATCH v1] net: thunderx: Use fwnode_get_mac_address()
From: Andy Shevchenko @ 2019-07-23 20:03 UTC (permalink / raw)
To: Sunil Goutham, Robert Richter, linux-arm-kernel, David S. Miller,
netdev
Cc: Andy Shevchenko
Replace the custom implementation with fwnode_get_mac_address,
which works on both DT and ACPI platforms.
While here, replace memcpy() by ether_addr_copy().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
.../net/ethernet/cavium/thunder/thunder_bgx.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index ad22554857bf..acb016834f04 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -1381,24 +1381,18 @@ static int acpi_get_mac_address(struct device *dev, struct acpi_device *adev,
u8 *dst)
{
u8 mac[ETH_ALEN];
- int ret;
+ u8 *addr;
- ret = fwnode_property_read_u8_array(acpi_fwnode_handle(adev),
- "mac-address", mac, ETH_ALEN);
- if (ret)
- goto out;
-
- if (!is_valid_ether_addr(mac)) {
+ addr = fwnode_get_mac_address(acpi_fwnode_handle(adev), mac, ETH_ALEN);
+ if (!addr) {
dev_err(dev, "MAC address invalid: %pM\n", mac);
- ret = -EINVAL;
- goto out;
+ return -EINVAL;
}
dev_info(dev, "MAC address set to: %pM\n", mac);
- memcpy(dst, mac, ETH_ALEN);
-out:
- return ret;
+ ether_addr_copy(dst, mac);
+ return 0;
}
/* Currently only sets the MAC address. */
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net 0/2] selftests: forwarding: GRE multipath fixes
From: David Miller @ 2019-07-23 20:07 UTC (permalink / raw)
To: idosch; +Cc: netdev, ssuryaextr, mlxsw, idosch
In-Reply-To: <20190723081926.30647-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Tue, 23 Jul 2019 11:19:24 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Patch #1 ensures IPv4 forwarding is enabled during the test.
>
> Patch #2 fixes the flower filters used to measure the distribution of
> the traffic between the two nexthops, so that the test will pass
> regardless if traffic is offloaded or not.
Series applied.
^ permalink raw reply
* Re: [PATCH mlx5-next] net/mlx5: Fix modify_cq_in alignment
From: Saeed Mahameed @ 2019-07-23 20:25 UTC (permalink / raw)
To: davem@davemloft.net, leon@kernel.org
Cc: Jason Gunthorpe, Yishai Hadas, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, dledford@redhat.com, Edward Srouji
In-Reply-To: <20190723190414.GU5125@mtr-leonro.mtl.com>
On Tue, 2019-07-23 at 22:04 +0300, Leon Romanovsky wrote:
> On Tue, Jul 23, 2019 at 11:28:50AM -0700, David Miller wrote:
> > From: Leon Romanovsky <leon@kernel.org>
> > Date: Tue, 23 Jul 2019 10:12:55 +0300
> >
> > > From: Edward Srouji <edwards@mellanox.com>
> > >
> > > Fix modify_cq_in alignment to match the device specification.
> > > After this fix the 'cq_umem_valid' field will be in the right
> > > offset.
> > >
> > > Cc: <stable@vger.kernel.org> # 4.19
> > > Fixes: bd37197554eb ("net/mlx5: Update mlx5_ifc with DEVX UID
> > > bits")
> > > Signed-off-by: Edward Srouji <edwards@mellanox.com>
> > > Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> >
> > Very confusing submission on many levels.
> >
> > Coming from a Mellanox developer using a kernel.org email address.
>
> It works for us and was proven internally as the best way to have
> setup which always works.
>
> > Targetting the mlx5-next tree, yet CC:'ing stable.
>
> This patch was found by RDMA team, needed by RDMA but changes are
> located
> in code accessible by mlx5_core part. This is why mlx5-next.
>
Leon,
mlx5-next "hence the -next" is NOT meant for fixes, it is indeed
confusing what you are trying to do here, Dave's system works perfectly
for us.
> > A networking change, for which stable submissions are handled by me
> > by
> > hand and not via CC:'ing stable.
>
> The intention was to have this patch in shared mlx5 branch, which is
> picked by RDMA too. This "Cc: stable@..." together with merge through
> RDMA will ensure that such patch will be part of stable
> automatically.
>
> I can remove "Cc: ..." line if you think that it is inappropriate to
> have such line in patch in mlx5-next.
No, if this was meant to land in -stable then it should go to -rc via
net branch not to mlx5-next, let's save everybody's time and energy
here. no point in arguing..
I will take this to my net queue and submit to Dave's net branch, as we
always do for mlx5 fixes.
for next time, mlx5 fixes should always go to net branch first, then it
is just a matter of days to see the fix in -rc and queued up to
-stable.
>
> Thanks
^ permalink raw reply
* Re: [PATCH mlx5-next] net/mlx5: Fix modify_cq_in alignment
From: Saeed Mahameed @ 2019-07-23 20:34 UTC (permalink / raw)
To: davem@davemloft.net, leon@kernel.org
Cc: Jason Gunthorpe, Yishai Hadas, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, dledford@redhat.com, Edward Srouji
In-Reply-To: <20190723.130211.1967999203654051483.davem@davemloft.net>
On Tue, 2019-07-23 at 13:02 -0700, David Miller wrote:
> From: Leon Romanovsky <leon@kernel.org>
> Date: Tue, 23 Jul 2019 22:04:14 +0300
>
> > The intention was to have this patch in shared mlx5 branch, which
> > is
> > picked by RDMA too. This "Cc: stable@..." together with merge
> > through
> > RDMA will ensure that such patch will be part of stable
> > automatically.
>
> Why wouldn't it come via Saeed's usual mlx5 bug fix pull requests to
> me?
That should have been the plan in first place, i will handle this,
thanks Dave and sorry for any inconvenience.
I will apply this patch to my (mlx5) net queue, will submit to net
shortly.
Leon can merge the next -rc when this patch lands there.
meanwhile, Leon can also merge my (mlx5) net queue which is always
based on latest -rc.
https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git/log/?h=net-mlx5
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: chip: Add of_node_put() before return
From: David Miller @ 2019-07-23 20:38 UTC (permalink / raw)
To: nishkadg.linux; +Cc: andrew, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20190723104307.8068-1-nishkadg.linux@gmail.com>
From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Tue, 23 Jul 2019 16:13:07 +0530
> Each iteration of for_each_available_child_of_node puts the previous
> node, but in the case of a return from the middle of the loop, there is
> no put, thus causing a memory leak. Hence add an of_node_put before the
> return.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Applied, but as I've repeatedly stated these OF node looping constructs
are EXTREMELY ERROR PRONE.
We must fix these kinds of interfaces so that they are easier to use
correctly.
^ permalink raw reply
* Re: [PATCH] net: dsa: sja1105: sja1105_main: Add of_node_put()
From: David Miller @ 2019-07-23 20:38 UTC (permalink / raw)
To: nishkadg.linux
Cc: olteanv, andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20190723104448.8125-1-nishkadg.linux@gmail.com>
From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Tue, 23 Jul 2019 16:14:48 +0530
> Each iteration of for_each_child_of_node puts the previous node, but in
> the case of a return from the middle of the loop, there is no put, thus
> causing a memory leak. Hence add an of_node_put before the return.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Applied.
Again, the semantics of these looping constructs are terrible.
^ permalink raw reply
* Re: [PATCH net-next v2] net/mlx5e: xsk: dynamically allocate mlx5e_channel_param
From: David Miller @ 2019-07-23 20:39 UTC (permalink / raw)
To: maximmi
Cc: arnd, ast, daniel, bpf, netdev, saeedm, leon, jakub.kicinski,
hawk, john.fastabend, tariqt
In-Reply-To: <20190723120208.27423-1-maximmi@mellanox.com>
From: Maxim Mikityanskiy <maximmi@mellanox.com>
Date: Tue, 23 Jul 2019 12:02:26 +0000
> From: Arnd Bergmann <arnd@arndb.de>
>
> The structure is too large to put on the stack, resulting in a
> warning on 32-bit ARM:
>
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:59:5: error: stack frame size of 1344 bytes in function
> 'mlx5e_open_xsk' [-Werror,-Wframe-larger-than=]
>
> Use kvzalloc() instead.
>
> Fixes: a038e9794541 ("net/mlx5e: Add XSK zero-copy support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> ---
> v2 changes: use kvzalloc/kvfree and fix a memory leak.
I'll apply this directly to net-next.
Thanks Maxim.
^ permalink raw reply
* Re: [bpf-next 6/6] selftests/bpf: add test for bpf_tcp_gen_syncookie
From: Alexei Starovoitov @ 2019-07-23 20:46 UTC (permalink / raw)
To: Lorenz Bauer
Cc: Petar Penkov, Networking, bpf, davem, Alexei Starovoitov,
Daniel Borkmann, Eric Dumazet, Stanislav Fomichev, Petar Penkov,
yhs
In-Reply-To: <CACAyw9-qQ8KbQk6Q6dg0+A337ZbSpot-sHpH_tSxFaQmUfhLyQ@mail.gmail.com>
On Tue, Jul 23, 2019 at 10:37:29AM +0100, Lorenz Bauer wrote:
> On Tue, 23 Jul 2019 at 01:20, Petar Penkov <ppenkov.kernel@gmail.com> wrote:
> > +static __always_inline __s64 gen_syncookie(void *data_end, struct bpf_sock *sk,
> > + void *iph, __u32 ip_size,
> > + struct tcphdr *tcph)
> > +{
> > + __u32 thlen = tcph->doff * 4;
> > +
> > + if (tcph->syn && !tcph->ack) {
> > + // packet should only have an MSS option
> > + if (thlen != 24)
> > + return 0;
>
> Just for my own understanding: without this the verifier complains since
> thlen is not a known value, even though it is in bounds due to the check below?
the verifier understands only constant part of the packet pointer.
Without additional 'if' above the statement:
if ((void *)tcph + thlen > data_end)
will add variables length 'thlen' to pkt pointer which will become
another pkt pointer (with different id).
That pointer would need 'pkt + const_range > data_end' to have valid access.
We hit this issue in the past when folks wanted to use bpf_csum_diff() helper
with variable size.
It's possible to extend the verifier to support that but it's intrusive,
since variable part would need to passed around to a bunch of check* functions.
I think it's tricky, but doable. Looking forward to patches :)
> > +
> > + if ((void *)tcph + thlen > data_end)
> > + return 0;
> > +
> > + return bpf_tcp_gen_syncookie(sk, iph, ip_size, tcph, thlen);
> > + }
> > + return 0;
> > +}
> > +
>
> --
> Lorenz Bauer | Systems Engineer
> 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
>
> www.cloudflare.com
^ permalink raw reply
* Re: [PATCH net-next 1/3] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Saeed Mahameed @ 2019-07-23 20:49 UTC (permalink / raw)
To: claudiu.manoil@nxp.com, davem@davemloft.net
Cc: linux-arm-kernel@lists.infradead.org, leoyang.li@nxp.com,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
alexandru.marginean@nxp.com, robh+dt@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1563894955-545-2-git-send-email-claudiu.manoil@nxp.com>
On Tue, 2019-07-23 at 18:15 +0300, Claudiu Manoil wrote:
> ENETC ports can manage the MDIO bus via local register
> interface. However there's also a centralized way
> to manage the MDIO bus, via the MDIO PCIe endpoint
> device integrated by the same root complex that also
> integrates the ENETC ports (eth controllers).
>
> Depending on board design and use case, centralized
> access to MDIO may be better than using local ENETC
> port registers. For instance, on the LS1028A QDS board
> where MDIO muxing is requiered. Also, the LS1028A on-chip
> switch doesn't have a local MDIO register interface.
>
> The current patch registers the above PCIe enpoint as a
> separate MDIO bus and provides a driver for it by re-using
> the code used for local MDIO access. It also allows the
> ENETC port PHYs to be managed by this driver if the local
> "mdio" node is missing from the ENETC port node.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
> .../net/ethernet/freescale/enetc/enetc_mdio.c | 90
> +++++++++++++++++++
> .../net/ethernet/freescale/enetc/enetc_pf.c | 5 +-
> 2 files changed, 94 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> index 77b9cd10ba2b..efa8a29f463d 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> @@ -197,3 +197,93 @@ void enetc_mdio_remove(struct enetc_pf *pf)
> mdiobus_free(pf->mdio);
> }
> }
> +
> +#define ENETC_MDIO_DEV_ID 0xee01
> +#define ENETC_MDIO_DEV_NAME "FSL PCIe IE Central MDIO"
> +#define ENETC_MDIO_BUS_NAME ENETC_MDIO_DEV_NAME " Bus"
> +#define ENETC_MDIO_DRV_NAME ENETC_MDIO_DEV_NAME " driver"
> +#define ENETC_MDIO_DRV_ID "fsl_enetc_mdio"
> +
> +static int enetc_pci_mdio_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + struct device *dev = &pdev->dev;
> + struct mii_bus *bus;
> + int err;
> +
> + bus = mdiobus_alloc_size(sizeof(u32 *));
> + if (!bus)
> + return -ENOMEM;
> +
> + bus->name = ENETC_MDIO_BUS_NAME;
> + bus->read = enetc_mdio_read;
> + bus->write = enetc_mdio_write;
> + bus->parent = dev;
> + snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
> +
> + pcie_flr(pdev);
> + err = pci_enable_device_mem(pdev);
> + if (err) {
> + dev_err(dev, "device enable failed\n");
mdiobus_free(bus) is missing here and in every error path.
> + return err;
> + }
> +
> + err = pci_request_mem_regions(pdev, ENETC_MDIO_DRV_ID);
> + if (err) {
> + dev_err(dev, "pci_request_regions failed\n");
> + goto err_pci_mem_reg;
> + }
> +
> + bus->priv = pci_iomap_range(pdev, 0, ENETC_MDIO_REG_OFFSET, 0);
> + if (!bus->priv) {
> + err = -ENXIO;
> + dev_err(dev, "ioremap failed\n");
> + goto err_ioremap;
> + }
> +
> + err = of_mdiobus_register(bus, dev->of_node);
> + if (err)
> + goto err_mdiobus_reg;
> +
> + pci_set_drvdata(pdev, bus);
> +
> + return 0;
> +
> +err_mdiobus_reg:
> + iounmap(bus->priv);
> +err_ioremap:
> + pci_release_mem_regions(pdev);
> +err_pci_mem_reg:
> + pci_disable_device(pdev);
> +
> + return err;
> +}
> +
> +static void enetc_pci_mdio_remove(struct pci_dev *pdev)
> +{
> + struct mii_bus *bus = pci_get_drvdata(pdev);
> +
> + mdiobus_unregister(bus);
> + iounmap(bus->priv);
> + mdiobus_free(bus);
> +
this should come last to be symmetrical with probe flow.
> + pci_release_mem_regions(pdev);
> + pci_disable_device(pdev);
> +}
> +
> +static const struct pci_device_id enetc_pci_mdio_id_table[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, ENETC_MDIO_DEV_ID) },
> + { 0, } /* End of table. */
> +};
> +MODULE_DEVICE_TABLE(pci, enetc_mdio_id_table);
> +
> +static struct pci_driver enetc_pci_mdio_driver = {
> + .name = ENETC_MDIO_DRV_ID,
> + .id_table = enetc_pci_mdio_id_table,
> + .probe = enetc_pci_mdio_probe,
> + .remove = enetc_pci_mdio_remove,
> +};
> +module_pci_driver(enetc_pci_mdio_driver);
> +
> +MODULE_DESCRIPTION(ENETC_MDIO_DRV_NAME);
> +MODULE_LICENSE("Dual BSD/GPL");
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> index 258b3cb38a6f..7d6513ff8507 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> @@ -750,6 +750,7 @@ static int enetc_of_get_phy(struct
> enetc_ndev_priv *priv)
> {
> struct enetc_pf *pf = enetc_si_priv(priv->si);
> struct device_node *np = priv->dev->of_node;
> + struct device_node *mdio_np;
> int err;
>
> if (!np) {
> @@ -773,7 +774,9 @@ static int enetc_of_get_phy(struct
> enetc_ndev_priv *priv)
> priv->phy_node = of_node_get(np);
> }
>
> - if (!of_phy_is_fixed_link(np)) {
> + mdio_np = of_get_child_by_name(np, "mdio");
> + if (mdio_np) {
> + of_node_put(mdio_np);
> err = enetc_mdio_probe(pf);
> if (err) {
> of_node_put(priv->phy_node);
^ permalink raw reply
* Re: [PATCH net-next 0/4] nfp: Offload MPLS actions
From: David Miller @ 2019-07-23 20:53 UTC (permalink / raw)
To: john.hurley; +Cc: netdev, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1563892442-4654-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Tue, 23 Jul 2019 15:33:58 +0100
> The module act_mpls has recently been added to the kernel. This allows the
> manipulation of MPLS headers on packets including push, pop and modify.
> Add these new actions and parameters to the intermediate representation
> API for hardware offload. Follow this by implementing the offload of these
> MPLS actions in the NFP driver.
Looks nice, clean, and straightforward.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sky2: Disable MSI on ASUS P6T
From: David Miller @ 2019-07-23 20:55 UTC (permalink / raw)
To: tiwai; +Cc: netdev, mlindner, stephen, m.seyfarth
In-Reply-To: <20190723151525.6526-1-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 23 Jul 2019 17:15:25 +0200
> The onboard sky2 NIC on ASUS P6T WS PRO doesn't work after PM resume
> due to the infamous IRQ problem. Disabling MSI works around it, so
> let's add it to the blacklist.
>
> Unfortunately the BIOS on the machine doesn't fill the standard
> DMI_SYS_* entry, so we pick up DMI_BOARD_* entries instead.
>
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1142496
> Reported-and-tested-by: Marcus Seyfarth <m.seyfarth@gmail.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v1] hv_sock: Use consistent types for UUIDs
From: David Miller @ 2019-07-23 20:58 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: haiyangz, kys, sthemmin, sashal, linux-hyperv, netdev
In-Reply-To: <20190723163943.65991-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 23 Jul 2019 19:39:43 +0300
> The rest of Hyper-V code is using new types for UUID handling.
> Convert hv_sock as well.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next] dpaa2-eth: Don't use netif_receive_skb_list for TCP frames
From: David Miller @ 2019-07-23 21:02 UTC (permalink / raw)
To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei, vladimir.oltean
In-Reply-To: <1563902923-26178-1-git-send-email-ruxandra.radulescu@nxp.com>
From: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Date: Tue, 23 Jul 2019 20:28:43 +0300
> Using Rx skb bulking for all frames may negatively impact the
> performance in some TCP termination scenarios, as it effectively
> bypasses GRO.
"may"?
Please provide numbers so that we know exactly whether it actually
hurts performance one way or another.
Thank you.
^ permalink raw reply
* Re: [net-next 6/6] e1000e: disable force K1-off feature
From: David Miller @ 2019-07-23 21:04 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: kai.heng.feng, netdev, nhorman, sassmann, aaron.f.brown
In-Reply-To: <20190723173650.23276-7-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 23 Jul 2019 10:36:50 -0700
> diff --git a/drivers/net/ethernet/intel/e1000e/hw.h b/drivers/net/ethernet/intel/e1000e/hw.h
> index eff75bd8a8f0..e3c71fd093ee 100644
> --- a/drivers/net/ethernet/intel/e1000e/hw.h
> +++ b/drivers/net/ethernet/intel/e1000e/hw.h
> @@ -662,6 +662,7 @@ struct e1000_dev_spec_ich8lan {
> bool kmrn_lock_loss_workaround_enabled;
> struct e1000_shadow_ram shadow_ram[E1000_ICH8_SHADOW_RAM_WORDS];
> bool nvm_k1_enabled;
> + bool disable_k1_off;
> bool eee_disable;
I don't see any code actually setting this boolean, how does it work?
^ permalink raw reply
* Re: [PATCH bpf v3] bpf: fix narrower loads on s390
From: Alexei Starovoitov @ 2019-07-23 21:04 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, Network Development, Y Song, gor, Heiko Carstens
In-Reply-To: <20190719091815.92181-1-iii@linux.ibm.com>
On Fri, Jul 19, 2019 at 2:18 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> The very first check in test_pkt_md_access is failing on s390, which
> happens because loading a part of a struct __sk_buff field produces
> an incorrect result.
>
> The preprocessed code of the check is:
>
> {
> __u8 tmp = *((volatile __u8 *)&skb->len +
> ((sizeof(skb->len) - sizeof(__u8)) / sizeof(__u8)));
> if (tmp != ((*(volatile __u32 *)&skb->len) & 0xFF)) return 2;
> };
>
> clang generates the following code for it:
>
> 0: 71 21 00 03 00 00 00 00 r2 = *(u8 *)(r1 + 3)
> 1: 61 31 00 00 00 00 00 00 r3 = *(u32 *)(r1 + 0)
> 2: 57 30 00 00 00 00 00 ff r3 &= 255
> 3: 5d 23 00 1d 00 00 00 00 if r2 != r3 goto +29 <LBB0_10>
>
> Finally, verifier transforms it to:
>
> 0: (61) r2 = *(u32 *)(r1 +104)
> 1: (bc) w2 = w2
> 2: (74) w2 >>= 24
> 3: (bc) w2 = w2
> 4: (54) w2 &= 255
> 5: (bc) w2 = w2
>
> The problem is that when verifier emits the code to replace a partial
> load of a struct __sk_buff field (*(u8 *)(r1 + 3)) with a full load of
> struct sk_buff field (*(u32 *)(r1 + 104)), an optional shift and a
> bitwise AND, it assumes that the machine is little endian and
> incorrectly decides to use a shift.
>
> Adjust shift count calculation to account for endianness.
>
> Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Applied to bpf tree. Thanks
^ permalink raw reply
* Re: [PATCH v2] drivers: net: xgene: Remove acpi_has_method() calls
From: David Miller @ 2019-07-23 21:06 UTC (permalink / raw)
To: skunberg.kelsey
Cc: iyappan, keyur, quan, netdev, linux-kernel, bjorn, skhan,
linux-kernel-mentees
In-Reply-To: <20190723185811.8548-1-skunberg.kelsey@gmail.com>
From: Kelsey Skunberg <skunberg.kelsey@gmail.com>
Date: Tue, 23 Jul 2019 12:58:11 -0600
> acpi_evaluate_object will already return an error if the needed method
> does not exist. Remove unnecessary acpi_has_method() calls and check the
> returned acpi_status for failure instead.
>
> Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
> ---
> Changes in v2:
> - Fixed white space warnings and errors
Applied to net-next.
^ permalink raw reply
* Re: [PATCH v2] drivers: net: xgene: Remove acpi_has_method() calls
From: David Miller @ 2019-07-23 21:07 UTC (permalink / raw)
To: skunberg.kelsey
Cc: iyappan, keyur, quan, netdev, linux-kernel, bjorn, skhan,
linux-kernel-mentees
In-Reply-To: <20190723.140646.505566792140054611.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 23 Jul 2019 14:06:46 -0700 (PDT)
> From: Kelsey Skunberg <skunberg.kelsey@gmail.com>
> Date: Tue, 23 Jul 2019 12:58:11 -0600
>
>> acpi_evaluate_object will already return an error if the needed method
>> does not exist. Remove unnecessary acpi_has_method() calls and check the
>> returned acpi_status for failure instead.
>>
>> Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
>> ---
>> Changes in v2:
>> - Fixed white space warnings and errors
>
> Applied to net-next.
Wow did you even build test this? Reverted...
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function ‘xgene_enet_reset’:
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:480:13: error: invalid storage class for function ‘xgene_enet_cle_bypass’
static void xgene_enet_cle_bypass(struct xgene_enet_pdata *p,
^~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:480:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
static void xgene_enet_cle_bypass(struct xgene_enet_pdata *p,
^~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:506:13: error: invalid storage class for function ‘xgene_enet_clear’
static void xgene_enet_clear(struct xgene_enet_pdata *pdata,
^~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:522:13: error: invalid storage class for function ‘xgene_enet_shutdown’
static void xgene_enet_shutdown(struct xgene_enet_pdata *p)
^~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:532:13: error: invalid storage class for function ‘xgene_enet_link_state’
static void xgene_enet_link_state(struct work_struct *work)
^~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:563:13: error: invalid storage class for function ‘xgene_sgmac_enable_tx_pause’
static void xgene_sgmac_enable_tx_pause(struct xgene_enet_pdata *p, bool enable)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:604:1: error: expected declaration or statement at end of input
};
^
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:599:29: warning: unused variable ‘xgene_sgport_ops’ [-Wunused-variable]
const struct xgene_port_ops xgene_sgport_ops = {
^~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:582:28: warning: unused variable ‘xgene_sgmac_ops’ [-Wunused-variable]
const struct xgene_mac_ops xgene_sgmac_ops = {
^~~~~~~~~~~~~~~
At top level:
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:437:12: warning: ‘xgene_enet_reset’ defined but not used [-Wunused-function]
static int xgene_enet_reset(struct xgene_enet_pdata *p)
^~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH v2 00/10] XDP unaligned chunk placement support
From: Alexei Starovoitov @ 2019-07-23 21:08 UTC (permalink / raw)
To: Kevin Laatz
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Björn Töpel, Karlsson, Magnus, Jakub Kicinski,
Jonathan Lemon, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190716030637.5634-1-kevin.laatz@intel.com>
Johnathan, Bjorn, Jakub,
Please review!
The patch set has been pending for a week.
On Tue, Jul 16, 2019 at 4:21 AM Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> This patch set adds the ability to use unaligned chunks in the XDP umem.
>
> Currently, all chunk addresses passed to the umem are masked to be chunk
> size aligned (default is 2k, max is PAGE_SIZE). This limits where we can
> place chunks within the umem as well as limiting the packet sizes that are
> supported.
>
> The changes in this patch set removes these restrictions, allowing XDP to
> be more flexible in where it can place a chunk within a umem. By relaxing
> where the chunks can be placed, it allows us to use an arbitrary buffer
> size and place that wherever we have a free address in the umem. These
> changes add the ability to support arbitrary frame sizes up to 4k
> (PAGE_SIZE) and make it easy to integrate with other existing frameworks
> that have their own memory management systems, such as DPDK.
>
> Since we are now dealing with arbitrary frame sizes, we need also need to
> update how we pass around addresses. Currently, the addresses can simply be
> masked to 2k to get back to the original address. This becomes less trivial
> when using frame sizes that are not a 'power of 2' size. This patch set
> modifies the Rx/Tx descriptor format to use the upper 16-bits of the addr
> field for an offset value, leaving the lower 48-bits for the address (this
> leaves us with 256 Terabytes, which should be enough!). We only need to use
> the upper 16-bits to store the offset when running in unaligned mode.
> Rather than adding the offset (headroom etc) to the address, we will store
> it in the upper 16-bits of the address field. This way, we can easily add
> the offset to the address where we need it, using some bit manipulation and
> addition, and we can also easily get the original address wherever we need
> it (for example in i40e_zca_free) by simply masking to get the lower
> 48-bits of the address field.
>
> The numbers below were recorded with the following set up:
> - Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
> - Intel Corporation Ethernet Controller XXV710 for 25GbE SFP28 (rev 02)
> - Driver: i40e
> - Application: xdpsock with l2fwd (single interface)
>
> These are solely for comparing performance with and without the patches.
> The largest drop was ~1% (in zero-copy mode).
>
> +-------------------------+------------+-----------------+-------------+
> | Buffer size: 2048 | SKB mode | Zero-copy | Copy |
> +-------------------------+------------+-----------------+-------------+
> | Aligned (baseline) | 1.7 Mpps | 15.3 Mpps | 2.08 Mpps |
> +-------------------------+------------+-----------------+-------------+
> | Aligned (with patches) | 1.7 Mpps | 15.1 Mpps | 2.08 Mpps |
> +-------------------------+------------+-----------------+-------------+
> | Unaligned | 1.7 Mpps | 14.5 Mpps | 2.08 Mpps |
> +-------------------------+------------+-----------------+-------------+
>
> NOTE: We are currently working on the changes required in the Mellanox
> driver. We will include these in the v3.
>
> Structure of the patchset:
> Patch 1:
> - Remove unnecessary masking and headroom addition during zero-copy Rx
> buffer recycling in i40e. This change is required in order for the
> buffer recycling to work in the unaligned chunk mode.
>
> Patch 2:
> - Remove unnecessary masking and headroom addition during
> zero-copy Rx buffer recycling in ixgbe. This change is required in
> order for the buffer recycling to work in the unaligned chunk mode.
>
> Patch 3:
> - Add infrastructure for unaligned chunks. Since we are dealing with
> unaligned chunks that could potentially cross a physical page boundary,
> we add checks to keep track of that information. We can later use this
> information to correctly handle buffers that are placed at an address
> where they cross a page boundary. This patch also modifies the
> existing Rx and Tx functions to use the new descriptor format. To
> handle addresses correctly, we need to mask appropriately based on
> whether we are in aligned or unaligned mode.
>
> Patch 4:
> - This patch updates the i40e driver to make use of the new descriptor
> format. The new format is particularly useful here since we can now
> retrieve the original address in places like i40e_zca_free with ease.
> This saves us doing various calculations to get the original address
> back.
>
> Patch 5:
> - This patch updates the ixgbe driver to make use of the new descriptor
> format. The new format is particularly useful here since we can now
> retrieve the original address in places like ixgbe_zca_free with ease.
> This saves us doing various calculations to get the original address
> back.
>
> Patch 6:
> - Add flags for umem configuration to libbpf
>
> Patch 7:
> - Modify xdpsock application to add a command line option for
> unaligned chunks
>
> Patch 8:
> - Since we can now run the application in unaligned chunk mode, we need
> to make sure we recycle the buffers appropriately.
>
> Patch 9:
> - Adds hugepage support to the xdpsock application
>
> Patch 10:
> - Documentation update to include the unaligned chunk scenario. We need
> to explicitly state that the incoming addresses are only masked in the
> aligned chunk mode and not the unaligned chunk mode.
>
> ---
> v2:
> - fixed checkpatch issues
> - fixed Rx buffer recycling for unaligned chunks in xdpsock
> - removed unused defines
> - fixed how chunk_size is calculated in xsk_diag.c
> - added some performance numbers to cover letter
> - modified descriptor format to make it easier to retrieve original
> address
> - removed patch adding off_t off to the zero copy allocator. This is no
> longer needed with the new descriptor format.
>
> Kevin Laatz (10):
> i40e: simplify Rx buffer recycle
> ixgbe: simplify Rx buffer recycle
> xsk: add support to allow unaligned chunk placement
> i40e: modify driver for handling offsets
> ixgbe: modify driver for handling offsets
> libbpf: add flags to umem config
> samples/bpf: add unaligned chunks mode support to xdpsock
> samples/bpf: add buffer recycling for unaligned chunks to xdpsock
> samples/bpf: use hugepages in xdpsock app
> doc/af_xdp: include unaligned chunk case
>
> Documentation/networking/af_xdp.rst | 10 ++-
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 39 +++++----
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 39 +++++----
> include/net/xdp_sock.h | 2 +
> include/uapi/linux/if_xdp.h | 9 ++
> net/xdp/xdp_umem.c | 17 ++--
> net/xdp/xsk.c | 89 ++++++++++++++++----
> net/xdp/xsk_diag.c | 2 +-
> net/xdp/xsk_queue.h | 70 +++++++++++++--
> samples/bpf/xdpsock_user.c | 61 ++++++++++----
> tools/include/uapi/linux/if_xdp.h | 4 +
> tools/lib/bpf/xsk.c | 3 +
> tools/lib/bpf/xsk.h | 2 +
> 13 files changed, 266 insertions(+), 81 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-testing: added tdc tests for [b|p]fifo qdisc
From: David Miller @ 2019-07-23 21:08 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1563908519-30111-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Tue, 23 Jul 2019 15:01:59 -0400
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Always love to see new tests... Applied.
^ permalink raw reply
* Re: [PATCH v1] net: thunderx: Use fwnode_get_mac_address()
From: David Miller @ 2019-07-23 21:09 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: sgoutham, rric, linux-arm-kernel, netdev
In-Reply-To: <20190723200344.69864-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 23 Jul 2019 23:03:43 +0300
> Replace the custom implementation with fwnode_get_mac_address,
> which works on both DT and ACPI platforms.
>
> While here, replace memcpy() by ether_addr_copy().
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied.
^ permalink raw reply
* [PATCH v2 bpf-next] libbpf: provide more helpful message on uninitialized global var
From: Andrii Nakryiko @ 2019-07-23 21:11 UTC (permalink / raw)
To: bpf, netdev, ast, daniel, songliubraving
Cc: andrii.nakryiko, kernel-team, Andrii Nakryiko
When BPF program defines uninitialized global variable, it's put into
a special COMMON section. Libbpf will reject such programs, but will
provide very unhelpful message with garbage-looking section index.
This patch detects special section cases and gives more explicit error
message.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
---
tools/lib/bpf/libbpf.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 794dd5064ae8..8741c39adb1c 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1760,15 +1760,22 @@ bpf_program__collect_reloc(struct bpf_program *prog, GElf_Shdr *shdr,
(long long) sym.st_value, sym.st_name, name);
shdr_idx = sym.st_shndx;
+ insn_idx = rel.r_offset / sizeof(struct bpf_insn);
+ pr_debug("relocation: insn_idx=%u, shdr_idx=%u\n",
+ insn_idx, shdr_idx);
+
+ if (shdr_idx >= SHN_LORESERVE) {
+ pr_warning("relocation: not yet supported relo for non-static global \'%s\' variable in special section (0x%x) found in insns[%d].code 0x%x\n",
+ name, shdr_idx, insn_idx,
+ insns[insn_idx].code);
+ return -LIBBPF_ERRNO__RELOC;
+ }
if (!bpf_object__relo_in_known_section(obj, shdr_idx)) {
pr_warning("Program '%s' contains unrecognized relo data pointing to section %u\n",
prog->section_name, shdr_idx);
return -LIBBPF_ERRNO__RELOC;
}
- insn_idx = rel.r_offset / sizeof(struct bpf_insn);
- pr_debug("relocation: insn_idx=%u\n", insn_idx);
-
if (insns[insn_idx].code == (BPF_JMP | BPF_CALL)) {
if (insns[insn_idx].src_reg != BPF_PSEUDO_CALL) {
pr_warning("incorrect bpf_call opcode\n");
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf 0/2] bpf: gso_segs fixes
From: Alexei Starovoitov @ 2019-07-23 21:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexei Starovoitov, Daniel Borkmann, David S . Miller, netdev,
Eric Dumazet, Stanislav Fomichev, bpf
In-Reply-To: <20190723101538.136328-1-edumazet@google.com>
On Tue, Jul 23, 2019 at 3:15 AM Eric Dumazet <edumazet@google.com> wrote:
>
> First patch changes the kernel, second patch
> adds a new test.
>
> Note that other patches might be needed to take
> care of similar issues in sock_ops_convert_ctx_access()
> and SOCK_OPS_GET_FIELD()
Nice catch!
Applied to bpf tree. Thanks
^ permalink raw reply
* Re: [net-next 0/6][pull request] 1GbE Intel Wired LAN Driver Updates 2019-07-23
From: Saeed Mahameed @ 2019-07-23 21:16 UTC (permalink / raw)
To: jeffrey.t.kirsher@intel.com, davem@davemloft.net
Cc: nhorman@redhat.com, sassmann@redhat.com, netdev@vger.kernel.org
In-Reply-To: <20190723173650.23276-1-jeffrey.t.kirsher@intel.com>
On Tue, 2019-07-23 at 10:36 -0700, Jeff Kirsher wrote:
> This series contains updates to igc and e1000e client drivers only.
>
> Sasha provides a couple of cleanups to remove code that is not needed
> and reduce structure sizes. Updated the MAC reset flow to use the
> device reset flow instead of a port reset flow. Added addition
> device
> id's that will be supported.
>
> Kai-Heng Feng provides a workaround for a possible stalled packet
> issue
> in our ICH devices due to a clock recovery from the PCH being too
> slow.
> Also provided a fix where the MAC & PHY may become de-sync'd causing
> a
> miss detection of link up events.
For what it's worth, Series LGTM.
^ permalink raw reply
* Re: [PATCH v4 net-next 02/19] ionic: Add hardware init and device commands
From: David Miller @ 2019-07-23 21:18 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20190722214023.9513-3-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 22 Jul 2019 14:40:06 -0700
> +void ionic_init_devinfo(struct ionic_dev *idev)
> +{
> + idev->dev_info.asic_type = ioread8(&idev->dev_info_regs->asic_type);
> + idev->dev_info.asic_rev = ioread8(&idev->dev_info_regs->asic_rev);
> +
> + memcpy_fromio(idev->dev_info.fw_version,
> + idev->dev_info_regs->fw_version,
> + IONIC_DEVINFO_FWVERS_BUFLEN);
> +
> + memcpy_fromio(idev->dev_info.serial_num,
> + idev->dev_info_regs->serial_num,
> + IONIC_DEVINFO_SERIAL_BUFLEN);
...
> + sig = ioread32(&idev->dev_info_regs->signature);
I think if you are going to use the io{read,write}{8,16,32,64}()
interfaces then you should use io{read,write}{8,16,32,64}_rep()
instead of memcpy_{to,from}io().
^ 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