* Re: [PATCH net-next] ravb: Disable Pause Advertisement
From: Simon Horman @ 2018-09-25 7:38 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David Miller, Florian Fainelli, netdev
In-Reply-To: <1537537946-24786-1-git-send-email-andrew@lunn.ch>
On Fri, Sep 21, 2018 at 03:52:26PM +0200, Andrew Lunn wrote:
> The previous commit to ravb had the side effect of making the PHY
> advertise Pause and Asym Pause, which previously did not happen. By
> default, phydev->supported has both forms of pause enabled, but
> phydev->advertising does not. The new phy_remove_link_mode() copies
> phydev->supported to phydev->advertising after removing the requested
> link mode. These Pause configuration bits appears it stops the PHY
> from completing Auto-Neg and the link remains down. Be explicit and
> remove the Pause and Asym Pause modes, so restoring the old behavior.
>
> Reported-by: Simon Horman <horms@verge.net.au>
> Fixes: 41124fa64d4b ("net: ethernet: Add helper to remove a supported link mode")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> I reworded the commit message from what Simon tested.
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index fb2a1125780d..b0f2612ad226 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1073,9 +1073,11 @@ static int ravb_phy_init(struct net_device *ndev)
> netdev_info(ndev, "limited PHY to 100Mbit/s\n");
> }
>
> - /* 10BASE is not supported */
> + /* 10BASE, Pause and Asym Pause is not supported */
> phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_10baseT_Half_BIT);
> phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_10baseT_Full_BIT);
> + phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Pause_BIT);
> + phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
>
> phy_attached_info(phydev);
>
> --
> 2.19.0.rc1
>
^ permalink raw reply
* Re: [PATCH rdma-next v1 0/7] Preparation to DevX extension series
From: Leon Romanovsky @ 2018-09-25 7:33 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180922170207.GA13493@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]
On Sat, Sep 22, 2018 at 11:02:07AM -0600, Jason Gunthorpe wrote:
> On Thu, Sep 20, 2018 at 09:35:19PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Changelog v0->v1:
> > * Update commit messages
> > * Split DevX series to small sub-series.
> > * Change static initialization from {0} to be {}
> >
> >
> > Set uid as part of various IB commands so that the firmware can manage
> > the IB object in a secured way.
> >
> > The firmware should mark this IB object with the given uid so that it
> > can be used later on only by objects with the same uid.
> >
> > Upon DEVX flows that use this objec, the pointed object must have
> > the same uid as of the issuer uid command.
> >
> > When a command is issued with uid=0 it means that the issuer of the
> > command is trusted (i.e. kernel), in that case any pointed object
> > can be used regardless of its uid.
> >
> > Thanks
> >
> > Leon Romanovsky (1):
> > net/mlx5: Update mlx5_ifc with DEVX UID bits
> >
> > Yishai Hadas (6):
> > net/mlx5: Set uid as part of CQ commands
> > net/mlx5: Set uid as part of QP commands
> > net/mlx5: Set uid as part of RQ commands
> > net/mlx5: Set uid as part of SQ commands
> > net/mlx5: Set uid as part of SRQ commands
> > net/mlx5: Set uid as part of DCT commands
>
> This and the next series look OK to me. Let me know when it is applied
> to the mlx branch
Applied after fixing Or's comments (typo and extra description in last patch).
bd37197554eb net/mlx5: Update mlx5_ifc with DEVX UID bits
774ea6eea290 net/mlx5: Set uid as part of DCT commands
a0d8c0543189 net/mlx5: Set uid as part of SRQ commands
430ae0d5a3ce net/mlx5: Set uid as part of SQ commands
d269b3afffcb net/mlx5: Set uid as part of RQ commands
4ac63ec72587 net/mlx5: Set uid as part of QP commands
9ba481e2eb3b net/mlx5: Set uid as part of CQ commands
Thanks
>
> Thanks,
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next] flow_dissector: lookup netns by skb->sk if skb->dev is NULL
From: Song Liu @ 2018-09-25 6:13 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Networking, Alexei Starovoitov, Daniel Borkmann, David S . Miller,
Willem de Bruijn
In-Reply-To: <20180924204956.83718-1-willemdebruijn.kernel@gmail.com>
On Mon, Sep 24, 2018 at 1:52 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> From: Willem de Bruijn <willemb@google.com>
>
> BPF flow dissectors are configured per network namespace.
> __skb_flow_dissect looks up the netns through dev_net(skb->dev).
>
> In some dissector paths skb->dev is NULL, such as for Unix sockets.
> In these cases fall back to looking up the netns by socket.
>
> Analyzing the codepaths leading to __skb_flow_dissect I did not find
> a case where both skb->dev and skb->sk are NULL. Warn and fall back to
> standard flow dissector if one is found.
>
> Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
> Reported-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> net/core/flow_dissector.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 5c5dd74b5b3b..738c7562e1e0 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -714,7 +714,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> struct flow_dissector_key_vlan *key_vlan;
> enum flow_dissect_ret fdret;
> enum flow_dissector_key_id dissector_vlan = FLOW_DISSECTOR_KEY_MAX;
> - struct bpf_prog *attached;
> + struct bpf_prog *attached = NULL;
> int num_hdrs = 0;
> u8 ip_proto = 0;
> bool ret;
> @@ -755,8 +755,14 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> target_container);
>
> rcu_read_lock();
> - attached = skb ? rcu_dereference(dev_net(skb->dev)->flow_dissector_prog)
> - : NULL;
> + if (skb) {
> + if (skb->dev)
> + attached = rcu_dereference(dev_net(skb->dev)->flow_dissector_prog);
> + else if (skb->sk)
> + attached = rcu_dereference(sock_net(skb->sk)->flow_dissector_prog);
> + else
> + WARN_ON_ONCE(1);
> + }
> if (attached) {
> /* Note that even though the const qualifier is discarded
> * throughout the execution of the BPF program, all changes(the
> --
> 2.19.0.444.g18242da7ef-goog
>
^ permalink raw reply
* [PATCH net-next 3/3] r8169: improve a check in rtl_init_one
From: Heiner Kallweit @ 2018-09-25 5:59 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <2dcf188b-852a-f785-c6e4-e63041b76c86@gmail.com>
The check for pci_is_pcie() is redundant here because all
chip versions >=18 are PCIe only anyway. In addition use
dma_set_mask_and_coherent() instead of separate calls to
pci_set_dma_mask() and pci_set_consistent_dma_mask().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 2d9e6c186..f882be49f 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7346,11 +7346,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->cp_cmd = RTL_R16(tp, CPlusCmd);
- if ((sizeof(dma_addr_t) > 4) &&
- (use_dac == 1 || (use_dac == -1 && pci_is_pcie(pdev) &&
- tp->mac_version >= RTL_GIGA_MAC_VER_18)) &&
- !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
- !pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
+ if (sizeof(dma_addr_t) > 4 && (use_dac == 1 || (use_dac == -1 &&
+ tp->mac_version >= RTL_GIGA_MAC_VER_18)) &&
+ !dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
/* CPlusCmd Dual Access Cycle is only needed for non-PCIe */
if (!pci_is_pcie(pdev))
--
2.19.0
^ permalink raw reply related
* [PATCH net-next 2/3] r8169: improve rtl8169_irq_mask_and_ack
From: Heiner Kallweit @ 2018-09-25 5:58 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <2dcf188b-852a-f785-c6e4-e63041b76c86@gmail.com>
Code can be slightly simplified by acking even events we're not
interested in. In addition add a comment making clear that the
read has no functional purpose and is just a PCI commit.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index dd5822673..2d9e6c186 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1352,7 +1352,8 @@ static void rtl_irq_enable_all(struct rtl8169_private *tp)
static void rtl8169_irq_mask_and_ack(struct rtl8169_private *tp)
{
rtl_irq_disable(tp);
- rtl_ack_events(tp, RTL_EVENT_NAPI | tp->event_slow);
+ rtl_ack_events(tp, 0xffff);
+ /* PCI commit */
RTL_R8(tp, ChipCmd);
}
@@ -7365,14 +7366,12 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
rtl_init_rxcfg(tp);
- rtl_irq_disable(tp);
+ rtl8169_irq_mask_and_ack(tp);
rtl_hw_initialize(tp);
rtl_hw_reset(tp);
- rtl_ack_events(tp, 0xffff);
-
pci_set_master(pdev);
rtl_init_mdio_ops(tp);
--
2.19.0
^ permalink raw reply related
* [PATCH net-next 1/3] r8169: use default watchdog timeout
From: Heiner Kallweit @ 2018-09-25 5:56 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <2dcf188b-852a-f785-c6e4-e63041b76c86@gmail.com>
The networking core has a default watchdog timeout of 5s. I see no
need to define an own timeout of 6s which is basically the same.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 1843fafb6..dd5822673 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -77,8 +77,6 @@ static const int multicast_filter_limit = 32;
#define R8169_TX_RING_BYTES (NUM_TX_DESC * sizeof(struct TxDesc))
#define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc))
-#define RTL8169_TX_TIMEOUT (6*HZ)
-
/* write/read MMIO register */
#define RTL_W8(tp, reg, val8) writeb((val8), tp->mmio_addr + (reg))
#define RTL_W16(tp, reg, val16) writew((val16), tp->mmio_addr + (reg))
@@ -7414,7 +7412,6 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->dev_addr[i] = RTL_R8(tp, MAC0 + i);
dev->ethtool_ops = &rtl8169_ethtool_ops;
- dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
netif_napi_add(dev, &tp->napi, rtl8169_poll, NAPI_POLL_WEIGHT);
--
2.19.0
^ permalink raw reply related
* [PATCH net-next 0/3] r8169: series with smaller improvements
From: Heiner Kallweit @ 2018-09-25 5:55 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
This series includes smaller improvements, nothing exciting.
Heiner Kallweit (3):
r8169: use default watchdog timeout
r8169: improve rtl8169_irq_mask_and_ack
r8169: improve a check in rtl_init_one
drivers/net/ethernet/realtek/r8169.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
--
2.19.0
^ permalink raw reply
* Re: [PATCH v2 2/7] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 in linux/setbits.h
From: Christophe LEROY @ 2018-09-25 5:05 UTC (permalink / raw)
To: Corentin Labbe, Gilles.Muller, Julia.Lawall, agust, airlied,
alexandre.torgue, alistair, benh, carlo, davem, galak, joabreu,
khilman, maxime.ripard, michal.lkml, mpe, mporter, narmstrong,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens
Cc: netdev, linux-kernel, dri-devel, linux-ide, linux-amlogic,
linuxppc-dev, cocci, linux-arm-kernel
In-Reply-To: <1537815856-31728-3-git-send-email-clabbe@baylibre.com>
Le 24/09/2018 à 21:04, Corentin Labbe a écrit :
> This patch adds setbits32/clrbits32/clrsetbits32 and
> setbits64/clrbits64/clrsetbits64 in linux/setbits.h header.
Fix the patch subject and description.
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
> include/linux/setbits.h | 88 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 88 insertions(+)
> create mode 100644 include/linux/setbits.h
>
> diff --git a/include/linux/setbits.h b/include/linux/setbits.h
> new file mode 100644
> index 000000000000..6e7e257134ae
> --- /dev/null
> +++ b/include/linux/setbits.h
> @@ -0,0 +1,88 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __LINUX_SETBITS_H
> +#define __LINUX_SETBITS_H
> +
> +#include <linux/io.h>
> +
> +#define __setbits(readfunction, writefunction, addr, set) \
> + writefunction((readfunction(addr) | (set)), addr)
You don't need so long names for parameters in a 2 lines macro (See
Linux Kernel Codying style §4 Naming).
A single line macro would be feasible with only 3 chars names:
#define __setbits(rfn, wfn, addr, set) wfn((rfn(addr) | (set)), addr)
> +#define __clrbits(readfunction, writefunction, addr, mask) \
> + writefunction((readfunction(addr) & ~(mask)), addr)
> +#define __clrsetbits(readfunction, writefunction, addr, mask, set) \
> + writefunction(((readfunction(addr) & ~(mask)) | (set)), addr)
> +#define __setclrbits(readfunction, writefunction, addr, mask, set) \
> + writefunction(((readfunction(addr) | (set)) & ~(mask)), addr)
> +
> +#ifndef setbits_le32
> +#define setbits_le32(addr, set) __setbits(readl, writel, addr, set)
> +#endif
> +#ifndef setbits_le32_relaxed
> +#define setbits_le32_relaxed(addr, set) __setbits(readl_relaxed, writel_relaxed, \
> + addr, set)
> +#endif
> +
> +#ifndef clrbits_le32
> +#define clrbits_le32(addr, mask) __clrbits(readl, writel, addr, mask)
> +#endif
> +#ifndef clrbits_le32_relaxed
> +#define clrbits_le32_relaxed(addr, mask) __clrbits(readl_relaxed, writel_relaxed, \
> + addr, mask)
> +#endif
> +
> +#ifndef clrsetbits_le32
> +#define clrsetbits_le32(addr, mask, set) __clrsetbits(readl, writel, addr, mask, set)
> +#endif
> +#ifndef clrsetbits_le32_relaxed
> +#define clrsetbits_le32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, \
> + writel_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +#ifndef setclrbits_le32
> +#define setclrbits_le32(addr, mask, set) __setclrbits(readl, writel, addr, mask, set)
> +#endif
> +#ifndef setclrbits_le32_relaxed
> +#define setclrbits_le32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, \
> + writel_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +/* We cannot use CONFIG_64BIT as some x86 drivers use non-atomicwriteq() */
> +#if defined(writeq) && defined(readq)
Take care. At least Alpha Arch defines it as a static inline without
redefining it as a #define. (see arch/alpha/kernel/io.c)
Christophe
> +#ifndef setbits_le64
> +#define setbits_le64(addr, set) __setbits(readq, writeq, addr, set)
> +#endif
> +#ifndef setbits_le64_relaxed
> +#define setbits_le64_relaxed(addr, set) __setbits(readq_relaxed, writeq_relaxed, \
> + addr, set)
> +#endif
> +
> +#ifndef clrbits_le64
> +#define clrbits_le64(addr, mask) __clrbits(readq, writeq, addr, mask)
> +#endif
> +#ifndef clrbits_le64_relaxed
> +#define clrbits_le64_relaxed(addr, mask) __clrbits(readq_relaxed, writeq_relaxed, \
> + addr, mask)
> +#endif
> +
> +#ifndef clrsetbits_le64
> +#define clrsetbits_le64(addr, mask, set) __clrsetbits(readq, writeq, addr, mask, set)
> +#endif
> +#ifndef clrsetbits_le64_relaxed
> +#define clrsetbits_le64_relaxed(addr, mask, set) __clrsetbits(readq_relaxed, \
> + writeq_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +#ifndef setclrbits_le64
> +#define setclrbits_le64(addr, mask, set) __setclrbits(readq, writeq, addr, mask, set)
> +#endif
> +#ifndef setclrbits_le64_relaxed
> +#define setclrbits_le64_relaxed(addr, mask, set) __setclrbits(readq_relaxed, \
> + writeq_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +#endif /* writeq/readq */
> +
> +#endif /* __LINUX_SETBITS_H */
>
^ permalink raw reply
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Ard Biesheuvel @ 2018-09-25 10:25 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Linux Kernel Mailing List, <netdev@vger.kernel.org>,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, David S. Miller,
Greg Kroah-Hartman, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <20180918161646.19105-3-Jason@zx2c4.com>
Hi Jason,
I have another couple of questions which are unrelated to the below,
so I will just respond again to the top message.
On Tue, 18 Sep 2018 at 18:18, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Zinc stands for "Zinc Is Neat Crypto" or "Zinc as IN Crypto" or maybe
> just "Zx2c4's INsane Cryptolib." It's also short, easy to type, and
> plays nicely with the recent trend of naming crypto libraries after
> elements. The guiding principle is "don't overdo it". It's less of a
> library and more of a directory tree for organizing well-curated direct
> implementations of cryptography primitives.
>
Kees is currently dealing with VLA uses in crypto API skcipher
invocations [0] that don't benefit from its async capabilities nor
from the runtime resolution of cipher name strings, given that they
always select the same one.
drivers/net/ppp/ppp_mppe.c: "ecb(arc4)"
drivers/usb/wusbcore/crypto.c: "cbc(aes)"
net/ceph/crypto.c: "cbc(aes)"
net/mac802154/llsec.c: "ctr(aes)"
net/rxrpc/rxkad.c: "pcbc(fcrypt)"
net/rxrpc/rxkad.c: "pcbc(fcrypt)"
net/sunrpc/auth_gss/gss_krb5_mech.c: "cbc(des)"
net/sunrpc/auth_gss/gss_krb5_mech.c: "ecb(arc4)"
net/sunrpc/auth_gss/gss_krb5_mech.c: "cbc(des3_ede)"
net/sunrpc/auth_gss/gss_krb5_mech.c: "cts(cbc(aes))"
net/sunrpc/auth_gss/gss_krb5_mech.c: "cts(cbc(aes))"
net/wireless/lib80211_crypt_tkip.c: "ecb(arc4)"
net/wireless/lib80211_crypt_wep.c: "ecb(arc4)"
To me, these are prime candidates for moving into your library [at
some point]. I guess AES should be non-controversial, but moving the
others is actually more important in my view, since we will be able to
stop exposing them via the crypto API in that case. Any thoughts?
> [From 00/20] ..., WireGuard patches will go through
> DaveM's net-next tree, while Zinc patches will go through Greg KH's tree.
>
Given the cross dependencies, I'd prefer it if we take these through
Herbert's tree [which feeds into DaveM's tree as well].
Also, you haven't yet responded to my question about WireGuard's
limitation to synchronous encryption, or whether and how you expect to
support asynchronous accelerators for ChaCha20/Poly1305 in the future.
This shouldn't impede adoption of this series, but this is something
that is going to come up sooner than you think, and so I would like to
understand whether this means your library will grow asynchronous
interfaces as well, or whether it will be moved to the crypto API.
(Also, I'd like to know whether the RFC7539 construction of ChaCha20
and Poly1305 is compatible with WireGuard's)
Thanks,
Ard.
[0] https://marc.info/?l=linux-kernel&m=153732317132090&w=2
> Zinc is a new cryptography API that is much more minimal and lower-level
> than the current one. It intends to complement it and provide a basis
> upon which the current crypto API might build, as the provider of
> software implementations of cryptographic primitives. It is motivated by
> three primary observations in crypto API design:
>
> * Highly composable "cipher modes" and related abstractions from
> 90s cryptographers did not turn out to be as terrific an idea as
> hoped, leading to a host of API misuse problems.
>
> * Most programmers are afraid of crypto code, and so prefer to
> integrate it into libraries in a highly abstracted manner, so as to
> shield themselves from implementation details. Cryptographers, on
> the other hand, prefer simple direct implementations, which they're
> able to verify for high assurance and optimize in accordance with
> their expertise.
>
> * Overly abstracted and flexible cryptography APIs lead to a host of
> dangerous problems and performance issues. The kernel is in the
> business usually not of coming up with new uses of crypto, but
> rather implementing various constructions, which means it essentially
> needs a library of primitives, not a highly abstracted enterprise-ready
> pluggable system, with a few particular exceptions.
>
> This last observation has seen itself play out several times over and
> over again within the kernel:
>
> * The perennial move of actual primitives away from crypto/ and into
> lib/, so that users can actually call these functions directly with
> no overhead and without lots of allocations, function pointers,
> string specifier parsing, and general clunkiness. For example:
> sha256, chacha20, siphash, sha1, and so forth live in lib/ rather
> than in crypto/. Zinc intends to stop the cluttering of lib/ and
> introduce these direct primitives into their proper place, lib/zinc/.
>
> * An abundance of misuse bugs with the present crypto API that have
> been very unpleasant to clean up.
>
> * A hesitance to even use cryptography, because of the overhead and
> headaches involved in accessing the routines.
>
> Zinc goes in a rather different direction. Rather than providing a
> thoroughly designed and abstracted API, Zinc gives you simple functions,
> which implement some primitive, or some particular and specific
> construction of primitives. It is not dynamic in the least, though one
> could imagine implementing a complex dynamic dispatch mechanism (such as
> the current crypto API) on top of these basic functions. After all,
> dynamic dispatch is usually needed for applications with cipher agility,
> such as IPsec, dm-crypt, AF_ALG, and so forth, and the existing crypto
> API will continue to play that role. However, Zinc will provide a non-
> haphazard way of directly utilizing crypto routines in applications
> that do have neither the need nor desire for abstraction and dynamic
> dispatch.
>
> It also organizes the implementations in a simple, straight-forward,
> and direct manner, making it enjoyable and intuitive to work on.
> Rather than moving optimized assembly implementations into arch/, it
> keeps them all together in lib/zinc/, making it simple and obvious to
> compare and contrast what's happening. This is, notably, exactly what
> the lib/raid6/ tree does, and that seems to work out rather well. It's
> also the pattern of most successful crypto libraries. The architecture-
> specific glue-code is made a part of each translation unit, rather than
> being in a separate one, so that generic and architecture-optimized code
> are combined at compile-time, and incompatibility branches compiled out by
> the optimizer.
>
> All implementations have been extensively tested and fuzzed, and are
> selected for their quality, trustworthiness, and performance. Wherever
> possible and performant, formally verified implementations are used,
> such as those from HACL* [1] and Fiat-Crypto [2]. The routines also take
> special care to zero out secrets using memzero_explicit (and future work
> is planned to have gcc do this more reliably and performantly with
> compiler plugins). The performance of the selected implementations is
> state-of-the-art and unrivaled on a broad array of hardware, though of
> course we will continue to fine tune these to the hardware demands
> needed by kernel contributors. Each implementation also comes with
> extensive self-tests and crafted test vectors, pulled from various
> places such as Wycheproof [9].
>
> Regularity of function signatures is important, so that users can easily
> "guess" the name of the function they want. Though, individual
> primitives are oftentimes not trivially interchangeable, having been
> designed for different things and requiring different parameters and
> semantics, and so the function signatures they provide will directly
> reflect the realities of the primitives' usages, rather than hiding it
> behind (inevitably leaky) abstractions. Also, in contrast to the current
> crypto API, Zinc functions can work on stack buffers, and can be called
> with different keys, without requiring allocations or locking.
>
> SIMD is used automatically when available, though some routines may
> benefit from either having their SIMD disabled for particular
> invocations, or to have the SIMD initialization calls amortized over
> several invocations of the function, and so Zinc utilizes function
> signatures enabling that in conjunction with the recently introduced
> simd_context_t.
>
> More generally, Zinc provides function signatures that allow just what
> is required by the various callers. This isn't to say that users of the
> functions will be permitted to pollute the function semantics with weird
> particular needs, but we are trying very hard not to overdo it, and that
> means looking carefully at what's actually necessary, and doing just that,
> and not much more than that. Remember: practicality and cleanliness rather
> than over-zealous infrastructure.
>
> Zinc provides also an opening for the best implementers in academia to
> contribute their time and effort to the kernel, by being sufficiently
> simple and inviting. In discussing this commit with some of the best and
> brightest over the last few years, there are many who are eager to
> devote rare talent and energy to this effort.
>
> Following the merging of this, I expect for the primitives that
> currently exist in lib/ to work their way into lib/zinc/, after intense
> scrutiny of each implementation, potentially replacing them with either
> formally-verified implementations, or better studied and faster
> state-of-the-art implementations.
>
> Also following the merging of this, I expect for the old crypto API
> implementations to be ported over to use Zinc for their software-based
> implementations.
>
> As Zinc is simply library code, its config options are un-menued, with
> the exception of CONFIG_ZINC_DEBUG, which enables various selftests and
> BUG_ONs.
>
> [1] https://github.com/project-everest/hacl-star
> [2] https://github.com/mit-plv/fiat-crypto
> [3] https://cr.yp.to/ecdh.html
> [4] https://cr.yp.to/chacha.html
> [5] https://cr.yp.to/snuffle/xsalsa-20081128.pdf
> [6] https://cr.yp.to/mac.html
> [7] https://blake2.net/
> [8] https://tools.ietf.org/html/rfc8439
> [9] https://github.com/google/wycheproof
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: Samuel Neves <sneves@dei.uc.pt>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
> ---
> MAINTAINERS | 8 ++++++++
> lib/Kconfig | 2 ++
> lib/Makefile | 2 ++
> lib/zinc/Kconfig | 32 ++++++++++++++++++++++++++++++++
> lib/zinc/Makefile | 4 ++++
> 5 files changed, 48 insertions(+)
> create mode 100644 lib/zinc/Kconfig
> create mode 100644 lib/zinc/Makefile
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4327777dce57..5967c737f3ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16170,6 +16170,14 @@ Q: https://patchwork.linuxtv.org/project/linux-media/list/
> S: Maintained
> F: drivers/media/dvb-frontends/zd1301_demod*
>
> +ZINC CRYPTOGRAPHY LIBRARY
> +M: Jason A. Donenfeld <Jason@zx2c4.com>
> +M: Samuel Neves <sneves@dei.uc.pt>
> +S: Maintained
> +F: lib/zinc/
> +F: include/zinc/
> +L: linux-crypto@vger.kernel.org
> +
> ZPOOL COMPRESSED PAGE STORAGE API
> M: Dan Streetman <ddstreet@ieee.org>
> L: linux-mm@kvack.org
> diff --git a/lib/Kconfig b/lib/Kconfig
> index a3928d4438b5..3e6848269c66 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -485,6 +485,8 @@ config GLOB_SELFTEST
> module load) by a small amount, so you're welcome to play with
> it, but you probably don't need it.
>
> +source "lib/zinc/Kconfig"
> +
> #
> # Netlink attribute parsing support is select'ed if needed
> #
> diff --git a/lib/Makefile b/lib/Makefile
> index ca3f7ebb900d..571d28d3f143 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -214,6 +214,8 @@ obj-$(CONFIG_PERCPU_TEST) += percpu_test.o
>
> obj-$(CONFIG_ASN1) += asn1_decoder.o
>
> +obj-y += zinc/
> +
> obj-$(CONFIG_FONT_SUPPORT) += fonts/
>
> obj-$(CONFIG_PRIME_NUMBERS) += prime_numbers.o
> diff --git a/lib/zinc/Kconfig b/lib/zinc/Kconfig
> new file mode 100644
> index 000000000000..4e2e59126a67
> --- /dev/null
> +++ b/lib/zinc/Kconfig
> @@ -0,0 +1,32 @@
> +config ZINC_DEBUG
> + bool "Zinc cryptography library debugging and self-tests"
> + help
> + This builds a series of self-tests for the Zinc crypto library, which
> + help diagnose any cryptographic algorithm implementation issues that
> + might be at the root cause of potential bugs. It also adds various
> + debugging traps.
> +
> + Unless you're developing and testing cryptographic routines, or are
> + especially paranoid about correctness on your hardware, you may say
> + N here.
> +
> +config ZINC_ARCH_ARM
> + def_bool y
> + depends on ARM && !64BIT
> +
> +config ZINC_ARCH_ARM64
> + def_bool y
> + depends on ARM64 && 64BIT
> +
> +config ZINC_ARCH_X86_64
> + def_bool y
> + depends on X86_64 && 64BIT
> + depends on !UML
> +
> +config ZINC_ARCH_MIPS
> + def_bool y
> + depends on MIPS && CPU_MIPS32_R2 && !64BIT
> +
> +config ZINC_ARCH_MIPS64
> + def_bool y
> + depends on MIPS && 64BIT
> diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
> new file mode 100644
> index 000000000000..83dfd63988c0
> --- /dev/null
> +++ b/lib/zinc/Makefile
> @@ -0,0 +1,4 @@
> +ccflags-y := -O3
> +ccflags-y += -Wframe-larger-than=$(if (CONFIG_KASAN),16384,8192)
> +ccflags-y += -D'pr_fmt(fmt)="zinc: " fmt'
> +ccflags-$(CONFIG_ZINC_DEBUG) += -DDEBUG
> --
> 2.19.0
>
^ permalink raw reply
* Re: [PATCH v2 net-next 0/9] bnxt_en: devlink param updates
From: Vasundhara Volam @ 2018-09-25 4:14 UTC (permalink / raw)
To: jakub.kicinski; +Cc: David Miller, michael.chan@broadcom.com, Netdev
In-Reply-To: <20180924093908.157f3ea2@cakuba.netronome.com>
On Mon, Sep 24, 2018 at 10:11 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Mon, 24 Sep 2018 10:46:12 +0530, Vasundhara Volam wrote:
> > This patchset adds support for 3 generic and 1 driver-specific devlink
> > parameters. Add documentation for these configuration parameters.
> >
> > Also, this patchset adds support to return proper error code if
> > HWRM_NVM_GET/SET_VARIABLE commands return error code
> > HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED.
> >
> > v1->v2:
> > -Remove hw_tc_offload parameter.
> > -Update all patches with Cc of MAINTAINERS.
> > -Add more description in commit message for device specific parameter.
> > -Add a new Documentation/networking/devlink-params.txt with some
> > generic devlink parameters information.
> > -Add a new Documentation/networking/devlink-params-bnxt_en.txt with devlink
> > parameters information that are supported by bnxt_en driver.
> >
> > Vasundhara Volam (9):
> > devlink: Add generic parameter ignore_ari
> > devlink: Add generic parameter msix_vec_per_pf_max
> > devlink: Add generic parameter msix_vec_per_pf_min
>
> Nobody agreed with me that we need structure the PCIe bits better so
> I'll let go...
>
> > bnxt_en: Use ignore_ari devlink parameter
> > bnxt_en: return proper error when FW returns
> > HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
> > bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink
> > params.
> > bnxt_en: Add a driver specific gre_ver_check devlink parameter.
>
> This looks like configuring forwarding rules with devlink, but again,
Do you think, this parameter should be made generic?
> I won't object if I'm the only one who finds this inappropriate.
>
> You should CC people who gave you feedback on the previous version.
Sorry, I will add in the next version of the patchset. Thanks.
>
> > devlink: Add Documentation/networking/devlink-params.txt
> > devlink: Add Documentation/networking/devlink-params-bnxt.txt
^ permalink raw reply
* Re: [PATCH v2 net-next 9/9] devlink: Add Documentation/networking/devlink-params-bnxt.txt
From: Vasundhara Volam @ 2018-09-25 4:07 UTC (permalink / raw)
To: jakub.kicinski; +Cc: David Miller, michael.chan@broadcom.com, Netdev
In-Reply-To: <20180924092406.539fc54f@cakuba.netronome.com>
On Mon, Sep 24, 2018 at 9:54 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Mon, 24 Sep 2018 10:46:21 +0530, Vasundhara Volam wrote:
> > This patch adds a new file to add information about configuration
> > parameters that are supported by bnxt_en driver via devlink.
> >
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: linux-doc@vger.kernel.org
> > Cc: Jiri Pirko <jiri@mellanox.com>
> > Cc: Michael Chan <michael.chan@broadcom.com>
> >
> > Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
> > ---
> > Documentation/networking/devlink-params-bnxt.txt | 35 ++++++++++++++++++++++++
> > 1 file changed, 35 insertions(+)
> > create mode 100644 Documentation/networking/devlink-params-bnxt.txt
> >
> > diff --git a/Documentation/networking/devlink-params-bnxt.txt b/Documentation/networking/devlink-params-bnxt.txt
> > new file mode 100644
> > index 0000000..ca7c457
> > --- /dev/null
> > +++ b/Documentation/networking/devlink-params-bnxt.txt
> > @@ -0,0 +1,35 @@
> > +enable_sriov [DEVICE, GENERIC]
> > + Enable Single Root I/O Virtualisation (SRIOV) in
> > + the device.
> > + Type: Boolean
> > + Configuration mode: Permanent
> > +
> > +ignore_ari [DEVICE, GENERIC]
> > + Ignore Alternative Routing-ID Interpretation (ARI)
> > + capability. If enabled, adapter will ignore ARI
> > + capability even when platforms has the support
> > + enabled and creates same number of partitions when
> > + platform does not support ARI.
> > + Type: Boolean
> > + Configuration mode: Permanent
> > +
> > +msix_vec_per_pf_max [DEVICE, GENERIC]
> > + Provides the maximum number of MSIX interrupts that
> > + a device can create. Value is same across all
> > + physical functions (PFs) in the device.
> > + Type: u32
> > + Configuration mode: Permanent
> > +
> > +msix_vec_per_pf_min [DEVICE, GENERIC]
> > + Provides the minimum number of MSIX interrupts required
> > + or the device initialization. Value is same across all
> > + physical functions (PFs) in the device.
> > + Type: u32
> > + Configuration mode: Permanent
>
> Why duplicate the description of the generic parameters?
Not all generic parameters are used by all drivers. So, I want to add
information about
type and configuration mode about generic parameters used by bnxt_en driver.
I can remove description part keeping type and configuration mode, if
it looks duplication.
>
> > +gre_ver_check [DEVICE, DRIVER-SPECIFIC]
> > + Generic Routing Encapsulation (GRE) version check will
> > + be enabled in the device. If disabled, device skips
> > + version checking for incoming packets.
> > + Type: Boolean
> > + Configuration mode: Permanent
>
^ permalink raw reply
* Re: r8169 hang on 4.18
From: Ortwin Glück @ 2018-09-25 9:53 UTC (permalink / raw)
To: Heiner Kallweit, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <680acec6-f610-7f9d-5aa2-a03e878354d1@gmail.com>
On 24.09.18 22:21, Heiner Kallweit wrote:
> Thanks for the report. Here come a few inquiries:
>
> You say the box has one on-board network port and four network ports on
> an extension card, all five driven by r8169. The on-board chip is a
> RTL8168h, what's the type of the chips on the extension card?
This is the card:
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller [10ec:0123]
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at d000 [size=256]
Memory at f7300000 (64-bit, non-prefetchable) [size=4K]
Memory at f0300000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller [10ec:0123]
Flags: bus master, fast devsel, latency 0, IRQ 18
I/O ports at c000 [size=256]
Memory at f7200000 (64-bit, non-prefetchable) [size=4K]
Memory at f0200000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller [10ec:0123]
Flags: bus master, fast devsel, latency 0, IRQ 19
I/O ports at b000 [size=256]
Memory at f7100000 (64-bit, non-prefetchable) [size=4K]
Memory at f0100000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
06:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller [10ec:0123]
Flags: bus master, fast devsel, latency 0, IRQ 16
I/O ports at a000 [size=256]
Memory at f7000000 (64-bit, non-prefetchable) [size=4K]
Memory at f0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
> I'm asking because r8169 supports ~ 50 chip variants of the RTL8169/8
> family.
> Are the problems the same on all five ports?
Yes, I see the WARN_ON also on the other ports. Here is one from the separate card:
[Mon Sep 24 15:47:21 2018] ------------[ cut here ]------------
[Mon Sep 24 15:47:21 2018] NETDEV WATCHDOG: lan (r8169): transmit queue 0 timed out
[Mon Sep 24 15:47:21 2018] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:461
dev_watchdog+0x215/0x220
[Mon Sep 24 15:47:21 2018] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.18.8 #70
[Mon Sep 24 15:47:21 2018] Hardware name: Dell Inc. OptiPlex 3050/0W0CHX, BIOS 1.6.5 09/09/2017
[Mon Sep 24 15:47:21 2018] RIP: 0010:dev_watchdog+0x215/0x220
[Mon Sep 24 15:47:21 2018] Code: 49 63 4c 24 e8 eb 8c 4c 89 ef c6 05 1a 19 ca 00 01 e8 5f 52 fd ff
89 d9 4c 89 ee 48 c7 c7 78 ab 67 af 48 89 c2 e8 1b 2b 49 ff <0f> 0b eb be 0f 1f 80 00 00 00 00 41 57
45 89 cf 41 56 49 89 d6 41
[Mon Sep 24 15:47:21 2018] RSP: 0018:ffff8a205dd03e98 EFLAGS: 00010282
[Mon Sep 24 15:47:21 2018] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
[Mon Sep 24 15:47:21 2018] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff8a205dd15350
[Mon Sep 24 15:47:21 2018] RBP: ffff8a2045de041c R08: 0000000000000001 R09: 0000000000000763
[Mon Sep 24 15:47:21 2018] R10: 0000000000000082 R11: 0000000000000000 R12: ffff8a2045de0438
[Mon Sep 24 15:47:21 2018] R13: ffff8a2045de0000 R14: 0000000000000001 R15: ffff8a20455e1480
[Mon Sep 24 15:47:21 2018] FS: 0000000000000000(0000) GS:ffff8a205dd00000(0000) knlGS:0000000000000000
[Mon Sep 24 15:47:21 2018] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[Mon Sep 24 15:47:21 2018] CR2: 00007ff598642c38 CR3: 000000001f80a004 CR4: 00000000003606e0
[Mon Sep 24 15:47:21 2018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[Mon Sep 24 15:47:21 2018] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[Mon Sep 24 15:47:21 2018] Call Trace:
[Mon Sep 24 15:47:21 2018] <IRQ>
[Mon Sep 24 15:47:21 2018] ? pfifo_fast_reset+0x130/0x130
[Mon Sep 24 15:47:21 2018] ? pfifo_fast_reset+0x130/0x130
[Mon Sep 24 15:47:21 2018] call_timer_fn+0x11/0x70
[Mon Sep 24 15:47:21 2018] expire_timers+0x8e/0xa0
[Mon Sep 24 15:47:21 2018] run_timer_softirq+0xb9/0x160
[Mon Sep 24 15:47:21 2018] ? __hrtimer_run_queues+0x135/0x1a0
[Mon Sep 24 15:47:21 2018] ? hw_breakpoint_pmu_read+0x10/0x10
[Mon Sep 24 15:47:21 2018] ? ktime_get+0x39/0x90
[Mon Sep 24 15:47:21 2018] ? lapic_next_event+0x20/0x20
[Mon Sep 24 15:47:21 2018] __do_softirq+0xcb/0x1f8
[Mon Sep 24 15:47:21 2018] irq_exit+0xa9/0xb0
[Mon Sep 24 15:47:21 2018] smp_apic_timer_interrupt+0x59/0x90
[Mon Sep 24 15:47:21 2018] apic_timer_interrupt+0xf/0x20
[Mon Sep 24 15:47:21 2018] </IRQ>
[Mon Sep 24 15:47:21 2018] RIP: 0010:cpuidle_enter_state+0x129/0x200
[Mon Sep 24 15:47:21 2018] Code: 45 00 89 c3 e8 d8 3b 55 ff 65 8b 3d b1 eb 45 51 e8 8c 3a 55 ff 31
ff 49 89 c4 e8 72 43 55 ff fb 48 ba cf f7 53 e3 a5 9b c4 20 <4c> 89 e1 4c 29 e9 48 89 c8 48 c1 f9 3f
48 f7 ea b8 ff ff ff 7f 48
[Mon Sep 24 15:47:21 2018] RSP: 0018:ffff9f46806e7ea8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
[Mon Sep 24 15:47:21 2018] RAX: ffff8a205dd1f800 RBX: 0000000000000004 RCX: 000000000000001f
[Mon Sep 24 15:47:21 2018] RDX: 20c49ba5e353f7cf RSI: 00000000258f0602 RDI: 0000000000000000
[Mon Sep 24 15:47:21 2018] RBP: ffff8a205dd25ee0 R08: 00000000000003ee R09: 00000000ffffffff
[Mon Sep 24 15:47:21 2018] R10: ffff9f46806e7e90 R11: 00000000000003d5 R12: 00000752028ec2d0
[Mon Sep 24 15:47:21 2018] R13: 000007520282ea18 R14: 0000000000000004 R15: 0000000000000000
[Mon Sep 24 15:47:21 2018] ? cpuidle_enter_state+0x11e/0x200
[Mon Sep 24 15:47:21 2018] do_idle+0x1c0/0x200
[Mon Sep 24 15:47:21 2018] cpu_startup_entry+0x6a/0x70
[Mon Sep 24 15:47:21 2018] start_secondary+0x18a/0x1c0
[Mon Sep 24 15:47:21 2018] secondary_startup_64+0xa5/0xb0
[Mon Sep 24 15:47:21 2018] ---[ end trace 7ea59db719c41930 ]---
[Mon Sep 24 15:47:21 2018] r8169 0000:06:00.0 lan: link up
> Can you reproduce the problem (how)? Any specific network usage
> triggering the problem?
Actually the WARN_ON seems not to be causing the hang but to be rather a side effect of an
"unstable" port. The WARN_ON occurs every few days but the port works fine most of the time. But
when the port hangs (no more traffic) only a reboot fixes it.
These looks suspicious:
[ 8048.829832] r8169 0000:06:00.0 lan: link up
[64114.535455] r8169 0000:07:00.0 wan: link up
[74726.396319] r8169 0000:07:00.0 wan: link up
The ports seem to go up at random times (without "link down" message). This is also what we saw with
MSI enabled: links thrashing in down/up cycles.
> The root cause of the problem not necessarily is in r8169, some other
> change could have broken it too. Can you test using r8169 from 4.18
> on top of 4.17?
Unfortunately I am not able to do that.
> When stating "behaves erratic" you refer to the network hangs
> mentioned before? Or to some other issue?
please see above: links thrashing in down/up cycles.
I see that MSI/MSI-X has been disabled on quite a few chip versions (e.g. lately commit 72a579b8).
Does pci=nomsi disable MSI-X as well, or just MSI?
I could try adding my chip versions to these quirk sections. I couldn't find a way to disable
MSI/MSI-X per device.
> A similar report is here:
> https://bugzilla.kernel.org/show_bug.cgi?id=201109
Also that report has the "link up" message after the WARN_ON.
> There the problem seems to start with the upgrade from 4.18.4 to 4.18.5.
> Can you try with 4.18.4 ?
>
> The diff between 4.18.4 and 4.18.5 shows nothing related to r8169.
Exactly. I think the incident is just so rare that correlating it with a specific upgrade is hard.
Thanks,
Ortwin
^ permalink raw reply
* Re: [GIT] Networking
From: Greg KH @ 2018-09-25 9:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20180924.203224.1604558581746424370.davem@davemloft.net>
On Mon, Sep 24, 2018 at 08:32:24PM -0700, David Miller wrote:
>
> 1) Fix multiqueue handling of coalesce timer in stmmac, from Jose
> Abreu.
>
> 2) Fix memory corruption in NFC, from Suren Baghdasaryan.
>
> 3) Don't write reserved bits in ravb driver, from Kazuya Mizuguchi.
>
> 4) SMC bug fixes from Karsten Graul, YueHaibing, and Ursula Braun.
>
> 5) Fix TX done race in mvpp2, from Antoine Tenart.
>
> 6) ipv6 metrics leak, from Wei Wang.
>
> 7) Adjust firmware version requirements in mlxsw, from Petr Machata.
>
> 8) Fix autonegotiation on resume in r8169, from Heiner Kallweit.
>
> 9) Fixed missing entries when dumping /proc/net/if_inet6, from Jeff
> Barnhill.
>
> 10) Fix double free in devlink, from Dan Carpenter.
>
> 11) Fix ethtool regression from UFO feature removal, from Maciej
> Żenczykowski.
>
> 12) Fix drivers that have a ndo_poll_controller() that captures the
> cpu entirely on loaded hosts by trying to drain all rx and tx
> queues, from Eric Dumazet.
>
> 13) Fix memory corruption with jumbo frames in aquantia driver, from
> Friedemann Gerold.
>
> Please pull, thanks a lot!
>
> The following changes since commit 5211da9ca526a5adddee1ccd078e6e33a583ab36:
>
> Merge gitolite.kernel.org:/pub/scm/linux/kernel/git/davem/net (2018-09-18 09:31:53 +0200)
>
> are available in the Git repository at:
>
> gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
Now pulled, thanks.
greg k-h
^ permalink raw reply
* netlink: 16 bytes leftover after parsing attributes in process `ip'.
From: David Ahern @ 2018-09-25 3:19 UTC (permalink / raw)
To: Christian Brauner; +Cc: netdev@vger.kernel.org, David Miller
On top of net-next I am see a dmesg error:
netlink: 16 bytes leftover after parsing attributes in process `ip'.
I traced it to address lists and commit:
commit 6ecf4c37eb3e89b0832c9616089a5cdca3747da7
Author: Christian Brauner <christian@brauner.io>
Date: Tue Sep 4 21:53:50 2018 +0200
ipv6: enable IFA_TARGET_NETNSID for RTM_GETADDR
Per the commit you are trying to guess whether the ancillary header is
an ifinfomsg or a ifaddrmsg. I am guessing you are guessing wrong. :-)
I don't have time to take this to ground, but address listing is not the
only area subject to iproute2's SNAFU of infomsg everywhere on dumps. I
have thought about this for route dumps, but its solution does not work
here. You'll need to find something because the current warning on every
address dump is not acceptable.
^ permalink raw reply
* [PATCH net] net: hns: fix for unmapping problem when SMMU is on
From: Salil Mehta @ 2018-09-25 9:21 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Yunsheng Lin
From: Yunsheng Lin <linyunsheng@huawei.com>
If SMMU is on, there is more likely that skb_shinfo(skb)->frags[i]
can not send by a single BD. when this happen, the
hns_nic_net_xmit_hw function map the whole data in a frags using
skb_frag_dma_map, but unmap each BD' data individually when tx is
done, which causes problem when SMMU is on.
This patch fixes this problem by ummapping the whole data in a
frags when tx is done.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hnae.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 30 +++++++++++++++++----------
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c b/drivers/net/ethernet/hisilicon/hns/hnae.c
index a051e58..79d03f8 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.c
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
@@ -84,7 +84,7 @@ static void hnae_unmap_buffer(struct hnae_ring *ring, struct hnae_desc_cb *cb)
if (cb->type == DESC_TYPE_SKB)
dma_unmap_single(ring_to_dev(ring), cb->dma, cb->length,
ring_to_dma_dir(ring));
- else
+ else if (cb->length)
dma_unmap_page(ring_to_dev(ring), cb->dma, cb->length,
ring_to_dma_dir(ring));
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index f56855e..5ce23d4 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -40,9 +40,9 @@
#define SKB_TMP_LEN(SKB) \
(((SKB)->transport_header - (SKB)->mac_header) + tcp_hdrlen(SKB))
-static void fill_v2_desc(struct hnae_ring *ring, void *priv,
- int size, dma_addr_t dma, int frag_end,
- int buf_num, enum hns_desc_type type, int mtu)
+static void fill_v2_desc_hw(struct hnae_ring *ring, void *priv, int size,
+ int send_sz, dma_addr_t dma, int frag_end,
+ int buf_num, enum hns_desc_type type, int mtu)
{
struct hnae_desc *desc = &ring->desc[ring->next_to_use];
struct hnae_desc_cb *desc_cb = &ring->desc_cb[ring->next_to_use];
@@ -64,7 +64,7 @@ static void fill_v2_desc(struct hnae_ring *ring, void *priv,
desc_cb->type = type;
desc->addr = cpu_to_le64(dma);
- desc->tx.send_size = cpu_to_le16((u16)size);
+ desc->tx.send_size = cpu_to_le16((u16)send_sz);
/* config bd buffer end */
hnae_set_bit(rrcfv, HNSV2_TXD_VLD_B, 1);
@@ -133,6 +133,14 @@ static void fill_v2_desc(struct hnae_ring *ring, void *priv,
ring_ptr_move_fw(ring, next_to_use);
}
+static void fill_v2_desc(struct hnae_ring *ring, void *priv,
+ int size, dma_addr_t dma, int frag_end,
+ int buf_num, enum hns_desc_type type, int mtu)
+{
+ fill_v2_desc_hw(ring, priv, size, size, dma, frag_end,
+ buf_num, type, mtu);
+}
+
static const struct acpi_device_id hns_enet_acpi_match[] = {
{ "HISI00C1", 0 },
{ "HISI00C2", 0 },
@@ -289,15 +297,15 @@ static void fill_tso_desc(struct hnae_ring *ring, void *priv,
/* when the frag size is bigger than hardware, split this frag */
for (k = 0; k < frag_buf_num; k++)
- fill_v2_desc(ring, priv,
- (k == frag_buf_num - 1) ?
+ fill_v2_desc_hw(ring, priv, k == 0 ? size : 0,
+ (k == frag_buf_num - 1) ?
sizeoflast : BD_MAX_SEND_SIZE,
- dma + BD_MAX_SEND_SIZE * k,
- frag_end && (k == frag_buf_num - 1) ? 1 : 0,
- buf_num,
- (type == DESC_TYPE_SKB && !k) ?
+ dma + BD_MAX_SEND_SIZE * k,
+ frag_end && (k == frag_buf_num - 1) ? 1 : 0,
+ buf_num,
+ (type == DESC_TYPE_SKB && !k) ?
DESC_TYPE_SKB : DESC_TYPE_PAGE,
- mtu);
+ mtu);
}
netdev_tx_t hns_nic_net_xmit_hw(struct net_device *ndev,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v9 0/6] net: vhost: improve performance when enable busyloop
From: Tonghao Zhang @ 2018-09-25 2:51 UTC (permalink / raw)
To: Jason Wang
Cc: mst, makita.toshiaki, virtualization,
Linux Kernel Network Developers
In-Reply-To: <08f01199-ad0f-446c-0bcf-187dc31f2b42@redhat.com>
On Tue, Sep 25, 2018 at 10:21 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
>
> On 2018年09月23日 21:48, Tonghao Zhang wrote:
> > On Sun, Sep 9, 2018 at 7:52 PM <xiangxia.m.yue@gmail.com> wrote:
> >> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >>
> >> This patches improve the guest receive performance.
> >> On the handle_tx side, we poll the sock receive queue
> >> at the same time. handle_rx do that in the same way.
> >>
> >> For more performance report, see patch 4, 5, 6
> >>
> >> Tonghao Zhang (6):
> >> net: vhost: lock the vqs one by one
> >> net: vhost: replace magic number of lock annotation
> >> net: vhost: factor out busy polling logic to vhost_net_busy_poll()
> >> net: vhost: add rx busy polling in tx path
> >> net: vhost: disable rx wakeup during tx busypoll
> >> net: vhost: make busyloop_intr more accurate
> >>
> >> drivers/vhost/net.c | 163 +++++++++++++++++++++++++++++++-------------------
> >> drivers/vhost/vhost.c | 24 +++-----
> >> 2 files changed, 108 insertions(+), 79 deletions(-)
> >>
> >> --
> >> 1.8.3.1
> >>
> > ping ?
>
> HI Tonghao:
>
> As David pointed out, we only receive first 4 patches. You probably need
> to resend the series.
OK
> Thanks
^ permalink raw reply
* Re: [PATCH net-next v9 0/6] net: vhost: improve performance when enable busyloop
From: Jason Wang @ 2018-09-25 2:21 UTC (permalink / raw)
To: Tonghao Zhang, mst, makita.toshiaki
Cc: virtualization, Linux Kernel Network Developers
In-Reply-To: <CAMDZJNWk7UThRus4fZeznx4SvWjtj38ruC6Y_xPc1LV95EfLnA@mail.gmail.com>
On 2018年09月23日 21:48, Tonghao Zhang wrote:
> On Sun, Sep 9, 2018 at 7:52 PM <xiangxia.m.yue@gmail.com> wrote:
>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>
>> This patches improve the guest receive performance.
>> On the handle_tx side, we poll the sock receive queue
>> at the same time. handle_rx do that in the same way.
>>
>> For more performance report, see patch 4, 5, 6
>>
>> Tonghao Zhang (6):
>> net: vhost: lock the vqs one by one
>> net: vhost: replace magic number of lock annotation
>> net: vhost: factor out busy polling logic to vhost_net_busy_poll()
>> net: vhost: add rx busy polling in tx path
>> net: vhost: disable rx wakeup during tx busypoll
>> net: vhost: make busyloop_intr more accurate
>>
>> drivers/vhost/net.c | 163 +++++++++++++++++++++++++++++++-------------------
>> drivers/vhost/vhost.c | 24 +++-----
>> 2 files changed, 108 insertions(+), 79 deletions(-)
>>
>> --
>> 1.8.3.1
>>
> ping ?
HI Tonghao:
As David pointed out, we only receive first 4 patches. You probably need
to resend the series.
Thanks
^ permalink raw reply
* Re: [PATCH v2 7/7] net: stmmac: dwmac-meson8b: use xxxsetbits32
From: Neil Armstrong @ 2018-09-25 7:53 UTC (permalink / raw)
To: Florian Fainelli, Corentin Labbe, Gilles.Muller, Julia.Lawall,
agust, airlied, alexandre.torgue, alistair, benh, carlo, davem,
galak, joabreu, khilman, maxime.ripard, michal.lkml, mpe, mporter,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens
Cc: netdev, linux-kernel, dri-devel, linux-ide, linux-amlogic,
linuxppc-dev, cocci, linux-arm-kernel
In-Reply-To: <a8d06d0a-b13b-384c-ade6-b0a3b0ee61f6@gmail.com>
Hi Florian,
On 24/09/2018 21:17, Florian Fainelli wrote:
> On 09/24/2018 12:04 PM, Corentin Labbe wrote:
>> This patch convert meson stmmac glue driver to use all xxxsetbits32 functions.
>>
>> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
>> ---
>> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 56 +++++++++-------------
>> 1 file changed, 22 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> index c5979569fd60..abcf65588576 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> @@ -23,6 +23,7 @@
>> #include <linux/mfd/syscon.h>
>> #include <linux/platform_device.h>
>> #include <linux/stmmac.h>
>> +#include <linux/setbits.h>
>>
>> #include "stmmac_platform.h"
>>
>> @@ -75,18 +76,6 @@ struct meson8b_dwmac_clk_configs {
>> struct clk_gate rgmii_tx_en;
>> };
>>
>> -static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
>> - u32 mask, u32 value)
>> -{
>> - u32 data;
>> -
>> - data = readl(dwmac->regs + reg);
>> - data &= ~mask;
>> - data |= (value & mask);
>> -
>> - writel(data, dwmac->regs + reg);
>> -}
>
> Why not make mseon8b_dwmac_mask_bits() a wrapper around
> clrsetbits_le32() whose purpose is only to dereference dwmac->regs and
> pass it to clrsetbits_le32()? That would be far less changes to review
> and audit for correctness, same goes with every other patch in this
> series touching the meson drivers.
>
Personally, I'll prefer dropping my custom writel_bits_relaxed() with something
more future proof (I also use it in spi-meson-spicc and ao-cec),
and I think the same for dwmac-meson8b.c
Neil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 0/3] mac80211_hwsim: radio destruction fixes
From: Martin Willi @ 2018-09-25 7:41 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Benjamin Beichler
This small series fixes two issues for cleaning up hwsim radios. The
first one is rather easy to hit when terminating namespaces with many
hwsim radios. The second one affects destroy-on-close users only.
Given that the use of a work-queue for deferred cleanup with namespaces
has been and still is tricky to get right, this series switches these
users to a synchronous cleanup in hwsim; The removal of that work-queue
is in a dedicated commit in case we want to skip that in backports.
Martin Willi (3):
mac80211_hwsim: fix locking when iterating radios during ns exit
mac80211_hwsim: fix race in radio destruction from netlink notifier
mac80211_hwsim: drop now unused work-queue from hwsim
drivers/net/wireless/mac80211_hwsim.c | 44 +++++++++++----------------
1 file changed, 17 insertions(+), 27 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Arnd Bergmann @ 2018-09-25 7:18 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Ard Biesheuvel, Eric Biggers, Linux Kernel Mailing List,
Networking, open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
David Miller, gregkh, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <CAK8P3a2VL16mtyq0HjNOXuSp8YJXik4J9Z_aPzksmTAbFB+=_g@mail.gmail.com>
On Sat, Sep 22, 2018 at 6:11 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Sep 20, 2018 at 5:12 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > Hey Arnd,
> >
> > On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > Right, if you hit a stack requirement like this, it's usually the compiler
> > > doing something bad, not just using too much stack but also generating
> > > rather slow object code in the process. It's better to fix the bug by
> > > optimizing the code to not spill registers to the stack.
> > >
> > > In the long run, I'd like to reduce the stack frame size further, so
> > > best assume that anything over 1024 bytes (on 32-bit) or 1280 bytes
> > > (on 64-bit) is a bug in the code, and stay below that.
> > >
> > > For prototyping, you can just mark the broken functions individually
> > > by setting the warning limit for a specific function that is known to
> > > be misoptimized by the compiler (with a comment about which compiler
> > > and architectures are affected), but not override the limit for the
> > > entire file.
> >
> > Thanks for the explanation. Fortunately in my case, the issues were
> > trivially fixable to get it under 1024/1280
>
> A lot of these bugs are not trivial, but we still need a full analysis of what
> failed and what the possible mititgations are. Can you describe more
> specifically what causes it?
I think I misread your earlier sentence and thought you had said the
exact opposite.
For confirmation, I've downloaded your git tree and built it with my
collection of compilers (gcc-4.6 through 8.1) and tried building it
in various configurations. Nothing alarming stood out, the only
thing that I think would might warrant some investigation is this one:
lib/zinc/curve25519/curve25519-hacl64.h: In function 'curve25519_generic':
lib/zinc/curve25519/curve25519-hacl64.h:785:1: warning: the frame size
of 1536 bytes is larger than 500 bytes [-Wframe-larger-than=]
Without KASAN, this takes 832 bytes, which is still more than it should
use from a look at the source code.
I first suspected some misoptimization around the get/put_unaligned_le64()
calls, but playing around with it some more led me to this patch:
diff --git a/lib/zinc/curve25519/curve25519-hacl64.h
b/lib/zinc/curve25519/curve25519-hacl64.h
index c7b2924a68c2..1f6eb5708a0e 100644
--- a/lib/zinc/curve25519/curve25519-hacl64.h
+++ b/lib/zinc/curve25519/curve25519-hacl64.h
@@ -182,8 +182,7 @@ static __always_inline void
fmul_mul_shift_reduce_(u128 *output, u64 *input,
static __always_inline void fmul_fmul(u64 *output, u64 *input, u64 *input21)
{
- u64 tmp[5];
- memcpy(tmp, input, 5 * sizeof(*input));
+ u64 tmp[5] = { input[0], input[1], input[2], input[3], input[4] };
{
u128 b4;
u128 b0;
That change gets it down to
lib/zinc/curve25519/curve25519-hacl64.h: In function 'curve25519_generic':
lib/zinc/curve25519/curve25519-hacl64.h:788:1: warning: the frame size
of 640 bytes is larger than 500 bytes [-Wframe-larger-than=]
with KASAN, or 496 bytes without it. This indicates that there might
be something wrong with either gcc-8 or with our fortified memset()
function that requires more investigation. Maybe you can see
something there that I missed.
Arnd
^ permalink raw reply related
* Re: [PATCH v2] net: macb: Clean 64b dma addresses if they are not detected
From: Nicolas Ferre @ 2018-09-25 7:00 UTC (permalink / raw)
To: Michal Simek, linux-kernel, monstr, Edgar E. Iglesias
Cc: David S. Miller, netdev, Claudiu Beznea - M18063
In-Reply-To: <68051905ba59d7cfd74c63ef5bf0830dc2b9f6fe.1537857166.git.michal.simek@xilinx.com>
On 25/09/2018 at 08:32, Michal Simek wrote:
> Clear ADDR64 dma bit in DMACFG register in case that HW_DMA_CAP_64B is
> not detected on 64bit system.
> The issue was observed when bootloader(u-boot) does not check macb
> feature at DCFG6 register (DAW64_OFFSET) and enabling 64bit dma support
> by default. Then macb driver is reading DMACFG register back and only
> adding 64bit dma configuration but not cleaning it out.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks Michal. Best regards,
Nicolas
> ---
>
> Changes in v2:
> - Clean reg at the first place - Edgar
> - Update commit message
>
> drivers/net/ethernet/cadence/macb_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 16e4ef7d7185..ed8a5c53467e 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -2160,6 +2160,7 @@ static void macb_configure_dma(struct macb *bp)
> else
> dmacfg &= ~GEM_BIT(TXCOEN);
>
> + dmacfg &= ~GEM_BIT(ADDR64);
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> if (bp->hw_dma_cap & HW_DMA_CAP_64B)
> dmacfg |= GEM_BIT(ADDR64);
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] net: macb: Clean 64b dma addresses if they are not detected
From: Michal Simek @ 2018-09-25 6:34 UTC (permalink / raw)
To: Nicolas Ferre, Michal Simek, Edgar E. Iglesias
Cc: Joe Hershberger, netdev, linux-kernel, u-boot, Edgar E. Iglesias,
David S. Miller
In-Reply-To: <20eb98a9-edbd-c613-1f76-eccd7e06e052@microchip.com>
On 21.9.2018 14:38, Nicolas Ferre wrote:
> Michal,
>
> On 20/09/2018 at 08:23, Michal Simek wrote:
>> On 19.9.2018 20:08, Edgar E. Iglesias wrote:
>>> On Wed, Sep 19, 2018 at 06:08:18PM +0200, Michal Simek wrote:
>>>> Clear ADDR64 dma bit in DMACFG register in case that HW_DMA_CAP_64B
>>>> is not detected on 64bit system.
>>>> The issue was observed when bootloader(u-boot) does not check macb
>>>> feature at DCFG6 register (DAW64_OFFSET) and enabling 64bit dma support
>>>> by default. Then macb driver is reading DMACFG register back and only
>>>> adding 64bit dma configuration but not cleaning it out.
>>>>
>>>> This is also align with other features which are also cleared if
>>>> they are not
>>>> present.
>>>
>>> Hi Michal,
>>>
>>>>
>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>>> ---
>>>>
>>>> drivers/net/ethernet/cadence/macb_main.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>>>> b/drivers/net/ethernet/cadence/macb_main.c
>>>> index 16e4ef7d7185..79707dff3f13 100644
>>>> --- a/drivers/net/ethernet/cadence/macb_main.c
>>>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>>>> @@ -2163,6 +2163,8 @@ static void macb_configure_dma(struct macb *bp)
>>>> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>>> if (bp->hw_dma_cap & HW_DMA_CAP_64B)
>>>> dmacfg |= GEM_BIT(ADDR64);
>>>> + else
>>>> + dmacfg &= ~GEM_BIT(ADDR64);
>>>> #endif
>>>
>>> I think you might want to do this clearing outside of the #ifdef.
>>> If CONFIG_ARCH_DMA_ADDR_T_64BIT is not defined, we'd want to make
>>> sure the ADDR64 is cleared. E.g something like:
>>>
>>> dmacfg &= ~GEM_BIT(ADDR64);
>>> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>> if (bp->hw_dma_cap & HW_DMA_CAP_64B)
>>> dmacfg |= GEM_BIT(ADDR64);
>>> #endif
>>>
>>>
>>> Same thing for the USE_HWSTAMP/PTP flags below.
>>
>> Origin patch, which introduce this read with mask,
>> macfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L);
>> was done in 2011 and from that time this function was extended a little
>> bit. I am even not quite sure if make sense to read this reg and apply
>> setting on the top of it.
>>
>> Nicolas: Isn't it better simply compose that reg from scratch?
>
> I have several arguments against composing this register from scratch:
>
> 1/ the reset value of this register is non-null for both of our
> platforms and it could be meaningful to keep some of these values.
>
> 2/ one bitfield could use different values between Zynq and AT91: RXBMS
> (1kB to 8kB for Zynq and 512 to 4KB for AT91), with same encoding.
>
> 3/ and well, this is the type of register with multiple bits that are
> marked as "reserved" and that experience tells that they might be
> connected to something...
>
> So, I'm all for correcting the code like what Edgar suggests.
ok. I have sent v2.
M
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
^ permalink raw reply
* [PATCH v2] net: macb: Clean 64b dma addresses if they are not detected
From: Michal Simek @ 2018-09-25 6:32 UTC (permalink / raw)
To: linux-kernel, monstr, Edgar E. Iglesias
Cc: David S. Miller, netdev, Nicolas Ferre
Clear ADDR64 dma bit in DMACFG register in case that HW_DMA_CAP_64B is
not detected on 64bit system.
The issue was observed when bootloader(u-boot) does not check macb
feature at DCFG6 register (DAW64_OFFSET) and enabling 64bit dma support
by default. Then macb driver is reading DMACFG register back and only
adding 64bit dma configuration but not cleaning it out.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
Changes in v2:
- Clean reg at the first place - Edgar
- Update commit message
drivers/net/ethernet/cadence/macb_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 16e4ef7d7185..ed8a5c53467e 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2160,6 +2160,7 @@ static void macb_configure_dma(struct macb *bp)
else
dmacfg &= ~GEM_BIT(TXCOEN);
+ dmacfg &= ~GEM_BIT(ADDR64);
#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
if (bp->hw_dma_cap & HW_DMA_CAP_64B)
dmacfg |= GEM_BIT(ADDR64);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH bpf-next 2/9] bpf: rework cgroup storage pointer passing
From: Song Liu @ 2018-09-25 6:05 UTC (permalink / raw)
To: guro
Cc: Networking, open list, Kernel-team, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <20180921171353.11050-2-guro@fb.com>
On Fri, Sep 21, 2018 at 10:16 AM Roman Gushchin <guro@fb.com> wrote:
>
> To simplify the following introduction of per-cpu cgroup storage,
> let's rework a bit a mechanism of passing a pointer to a cgroup
> storage into the bpf_get_local_storage(). Let's save a pointer
> to the corresponding bpf_cgroup_storage structure, instead of
> a pointer to the actual buffer.
>
> It will help us to handle per-cpu storage later, which has
> a different way of accessing to the actual data.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> include/linux/bpf-cgroup.h | 13 ++++---------
> kernel/bpf/helpers.c | 8 ++++++--
> kernel/bpf/local_storage.c | 3 ++-
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
> index e9871b012dac..7e0c9a1d48b7 100644
> --- a/include/linux/bpf-cgroup.h
> +++ b/include/linux/bpf-cgroup.h
> @@ -23,7 +23,8 @@ struct bpf_cgroup_storage;
> extern struct static_key_false cgroup_bpf_enabled_key;
> #define cgroup_bpf_enabled static_branch_unlikely(&cgroup_bpf_enabled_key)
>
> -DECLARE_PER_CPU(void*, bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
> +DECLARE_PER_CPU(struct bpf_cgroup_storage*,
> + bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
>
> #define for_each_cgroup_storage_type(stype) \
> for (stype = 0; stype < MAX_BPF_CGROUP_STORAGE_TYPE; stype++)
> @@ -115,15 +116,9 @@ static inline void bpf_cgroup_storage_set(struct bpf_cgroup_storage
> *storage[MAX_BPF_CGROUP_STORAGE_TYPE])
> {
> enum bpf_cgroup_storage_type stype;
> - struct bpf_storage_buffer *buf;
> -
> - for_each_cgroup_storage_type(stype) {
> - if (!storage[stype])
> - continue;
>
> - buf = READ_ONCE(storage[stype]->buf);
> - this_cpu_write(bpf_cgroup_storage[stype], &buf->data[0]);
> - }
> + for_each_cgroup_storage_type(stype)
> + this_cpu_write(bpf_cgroup_storage[stype], storage[stype]);
> }
>
> struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog,
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index 9070b2ace6aa..e42f8789b7ea 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -195,7 +195,8 @@ const struct bpf_func_proto bpf_get_current_cgroup_id_proto = {
> };
>
> #ifdef CONFIG_CGROUP_BPF
> -DECLARE_PER_CPU(void*, bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
> +DECLARE_PER_CPU(struct bpf_cgroup_storage*,
> + bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
>
> BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)
> {
> @@ -204,8 +205,11 @@ BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)
> * verifier checks that its value is correct.
> */
> enum bpf_cgroup_storage_type stype = cgroup_storage_type(map);
> + struct bpf_cgroup_storage *storage;
>
> - return (unsigned long) this_cpu_read(bpf_cgroup_storage[stype]);
> + storage = this_cpu_read(bpf_cgroup_storage[stype]);
> +
> + return (unsigned long)&READ_ONCE(storage->buf)->data[0];
> }
>
> const struct bpf_func_proto bpf_get_local_storage_proto = {
> diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> index 0bd9f19fc557..6742292fb39e 100644
> --- a/kernel/bpf/local_storage.c
> +++ b/kernel/bpf/local_storage.c
> @@ -7,7 +7,8 @@
> #include <linux/rbtree.h>
> #include <linux/slab.h>
>
> -DEFINE_PER_CPU(void*, bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
> +DEFINE_PER_CPU(struct bpf_cgroup_storage*,
> + bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
>
> #ifdef CONFIG_CGROUP_BPF
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH bpf-next 1/9] bpf: extend cgroup bpf core to allow multiple cgroup storage types
From: Song Liu @ 2018-09-25 5:56 UTC (permalink / raw)
To: guro
Cc: Networking, open list, Kernel-team, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <20180921171353.11050-1-guro@fb.com>
On Fri, Sep 21, 2018 at 10:17 AM Roman Gushchin <guro@fb.com> wrote:
>
> In order to introduce per-cpu cgroup storage, let's generalize
> bpf cgroup core to support multiple cgroup storage types.
> Potentially, per-node cgroup storage can be added later.
>
> This commit is mostly a formal change that replaces
> cgroup_storage pointer with a array of cgroup_storage pointers.
> It doesn't actually introduce a new storage type,
> it will be done later.
>
> Each bpf program is now able to have one cgroup storage of each type.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> include/linux/bpf-cgroup.h | 38 ++++++++++++++------
> include/linux/bpf.h | 11 ++++--
> kernel/bpf/cgroup.c | 74 ++++++++++++++++++++++++++------------
> kernel/bpf/helpers.c | 15 ++++----
> kernel/bpf/local_storage.c | 18 ++++++----
> kernel/bpf/syscall.c | 9 +++--
> kernel/bpf/verifier.c | 8 +++--
> net/bpf/test_run.c | 20 +++++++----
> 8 files changed, 136 insertions(+), 57 deletions(-)
>
> diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
> index f91b0f8ff3a9..e9871b012dac 100644
> --- a/include/linux/bpf-cgroup.h
> +++ b/include/linux/bpf-cgroup.h
> @@ -2,6 +2,7 @@
> #ifndef _BPF_CGROUP_H
> #define _BPF_CGROUP_H
>
> +#include <linux/bpf.h>
> #include <linux/errno.h>
> #include <linux/jump_label.h>
> #include <linux/percpu.h>
> @@ -22,7 +23,10 @@ struct bpf_cgroup_storage;
> extern struct static_key_false cgroup_bpf_enabled_key;
> #define cgroup_bpf_enabled static_branch_unlikely(&cgroup_bpf_enabled_key)
>
> -DECLARE_PER_CPU(void*, bpf_cgroup_storage);
> +DECLARE_PER_CPU(void*, bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
> +
> +#define for_each_cgroup_storage_type(stype) \
> + for (stype = 0; stype < MAX_BPF_CGROUP_STORAGE_TYPE; stype++)
>
> struct bpf_cgroup_storage_map;
>
> @@ -43,7 +47,7 @@ struct bpf_cgroup_storage {
> struct bpf_prog_list {
> struct list_head node;
> struct bpf_prog *prog;
> - struct bpf_cgroup_storage *storage;
> + struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE];
> };
>
> struct bpf_prog_array;
> @@ -101,18 +105,29 @@ int __cgroup_bpf_run_filter_sock_ops(struct sock *sk,
> int __cgroup_bpf_check_dev_permission(short dev_type, u32 major, u32 minor,
> short access, enum bpf_attach_type type);
>
> -static inline void bpf_cgroup_storage_set(struct bpf_cgroup_storage *storage)
> +static inline enum bpf_cgroup_storage_type cgroup_storage_type(
> + struct bpf_map *map)
> {
> + return BPF_CGROUP_STORAGE_SHARED;
> +}
> +
> +static inline void bpf_cgroup_storage_set(struct bpf_cgroup_storage
> + *storage[MAX_BPF_CGROUP_STORAGE_TYPE])
> +{
> + enum bpf_cgroup_storage_type stype;
> struct bpf_storage_buffer *buf;
>
> - if (!storage)
> - return;
> + for_each_cgroup_storage_type(stype) {
> + if (!storage[stype])
> + continue;
>
> - buf = READ_ONCE(storage->buf);
> - this_cpu_write(bpf_cgroup_storage, &buf->data[0]);
> + buf = READ_ONCE(storage[stype]->buf);
> + this_cpu_write(bpf_cgroup_storage[stype], &buf->data[0]);
> + }
> }
>
> -struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog);
> +struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog,
> + enum bpf_cgroup_storage_type stype);
> void bpf_cgroup_storage_free(struct bpf_cgroup_storage *storage);
> void bpf_cgroup_storage_link(struct bpf_cgroup_storage *storage,
> struct cgroup *cgroup,
> @@ -265,13 +280,14 @@ static inline int cgroup_bpf_prog_query(const union bpf_attr *attr,
> return -EINVAL;
> }
>
> -static inline void bpf_cgroup_storage_set(struct bpf_cgroup_storage *storage) {}
> +static inline void bpf_cgroup_storage_set(
> + struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE]) {}
> static inline int bpf_cgroup_storage_assign(struct bpf_prog *prog,
> struct bpf_map *map) { return 0; }
> static inline void bpf_cgroup_storage_release(struct bpf_prog *prog,
> struct bpf_map *map) {}
> static inline struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(
> - struct bpf_prog *prog) { return 0; }
> + struct bpf_prog *prog, enum bpf_cgroup_storage_type stype) { return 0; }
> static inline void bpf_cgroup_storage_free(
> struct bpf_cgroup_storage *storage) {}
>
> @@ -293,6 +309,8 @@ static inline void bpf_cgroup_storage_free(
> #define BPF_CGROUP_RUN_PROG_SOCK_OPS(sock_ops) ({ 0; })
> #define BPF_CGROUP_RUN_PROG_DEVICE_CGROUP(type,major,minor,access) ({ 0; })
>
> +#define for_each_cgroup_storage_type(stype) for (; false; )
> +
> #endif /* CONFIG_CGROUP_BPF */
>
> #endif /* _BPF_CGROUP_H */
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 988a00797bcd..b457fbe7b70b 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -272,6 +272,13 @@ struct bpf_prog_offload {
> u32 jited_len;
> };
>
> +enum bpf_cgroup_storage_type {
> + BPF_CGROUP_STORAGE_SHARED,
> + __BPF_CGROUP_STORAGE_MAX
> +};
> +
> +#define MAX_BPF_CGROUP_STORAGE_TYPE __BPF_CGROUP_STORAGE_MAX
> +
> struct bpf_prog_aux {
> atomic_t refcnt;
> u32 used_map_cnt;
> @@ -289,7 +296,7 @@ struct bpf_prog_aux {
> struct bpf_prog *prog;
> struct user_struct *user;
> u64 load_time; /* ns since boottime */
> - struct bpf_map *cgroup_storage;
> + struct bpf_map *cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE];
> char name[BPF_OBJ_NAME_LEN];
> #ifdef CONFIG_SECURITY
> void *security;
> @@ -358,7 +365,7 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
> */
> struct bpf_prog_array_item {
> struct bpf_prog *prog;
> - struct bpf_cgroup_storage *cgroup_storage;
> + struct bpf_cgroup_storage *cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE];
> };
>
> struct bpf_prog_array {
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 6a7d931bbc55..065c3d9ff8eb 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -25,6 +25,7 @@ EXPORT_SYMBOL(cgroup_bpf_enabled_key);
> */
> void cgroup_bpf_put(struct cgroup *cgrp)
> {
> + enum bpf_cgroup_storage_type stype;
> unsigned int type;
>
> for (type = 0; type < ARRAY_SIZE(cgrp->bpf.progs); type++) {
> @@ -34,8 +35,10 @@ void cgroup_bpf_put(struct cgroup *cgrp)
> list_for_each_entry_safe(pl, tmp, progs, node) {
> list_del(&pl->node);
> bpf_prog_put(pl->prog);
> - bpf_cgroup_storage_unlink(pl->storage);
> - bpf_cgroup_storage_free(pl->storage);
> + for_each_cgroup_storage_type(stype) {
> + bpf_cgroup_storage_unlink(pl->storage[stype]);
> + bpf_cgroup_storage_free(pl->storage[stype]);
> + }
> kfree(pl);
> static_branch_dec(&cgroup_bpf_enabled_key);
> }
> @@ -97,6 +100,7 @@ static int compute_effective_progs(struct cgroup *cgrp,
> enum bpf_attach_type type,
> struct bpf_prog_array __rcu **array)
> {
> + enum bpf_cgroup_storage_type stype;
> struct bpf_prog_array *progs;
> struct bpf_prog_list *pl;
> struct cgroup *p = cgrp;
> @@ -125,7 +129,9 @@ static int compute_effective_progs(struct cgroup *cgrp,
> continue;
>
> progs->items[cnt].prog = pl->prog;
> - progs->items[cnt].cgroup_storage = pl->storage;
> + for_each_cgroup_storage_type(stype)
> + progs->items[cnt].cgroup_storage[stype] =
> + pl->storage[stype];
> cnt++;
> }
> } while ((p = cgroup_parent(p)));
> @@ -232,7 +238,9 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
> {
> struct list_head *progs = &cgrp->bpf.progs[type];
> struct bpf_prog *old_prog = NULL;
> - struct bpf_cgroup_storage *storage, *old_storage = NULL;
> + struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE],
> + *old_storage[MAX_BPF_CGROUP_STORAGE_TYPE] = {NULL};
> + enum bpf_cgroup_storage_type stype;
> struct bpf_prog_list *pl;
> bool pl_was_allocated;
> int err;
> @@ -254,34 +262,44 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
> if (prog_list_length(progs) >= BPF_CGROUP_MAX_PROGS)
> return -E2BIG;
>
> - storage = bpf_cgroup_storage_alloc(prog);
> - if (IS_ERR(storage))
> - return -ENOMEM;
> + for_each_cgroup_storage_type(stype) {
> + storage[stype] = bpf_cgroup_storage_alloc(prog, stype);
> + if (IS_ERR(storage[stype])) {
> + storage[stype] = NULL;
> + for_each_cgroup_storage_type(stype)
> + bpf_cgroup_storage_free(storage[stype]);
> + return -ENOMEM;
> + }
> + }
>
> if (flags & BPF_F_ALLOW_MULTI) {
> list_for_each_entry(pl, progs, node) {
> if (pl->prog == prog) {
> /* disallow attaching the same prog twice */
> - bpf_cgroup_storage_free(storage);
> + for_each_cgroup_storage_type(stype)
> + bpf_cgroup_storage_free(storage[stype]);
> return -EINVAL;
> }
> }
>
> pl = kmalloc(sizeof(*pl), GFP_KERNEL);
> if (!pl) {
> - bpf_cgroup_storage_free(storage);
> + for_each_cgroup_storage_type(stype)
> + bpf_cgroup_storage_free(storage[stype]);
> return -ENOMEM;
> }
>
> pl_was_allocated = true;
> pl->prog = prog;
> - pl->storage = storage;
> + for_each_cgroup_storage_type(stype)
> + pl->storage[stype] = storage[stype];
> list_add_tail(&pl->node, progs);
> } else {
> if (list_empty(progs)) {
> pl = kmalloc(sizeof(*pl), GFP_KERNEL);
> if (!pl) {
> - bpf_cgroup_storage_free(storage);
> + for_each_cgroup_storage_type(stype)
> + bpf_cgroup_storage_free(storage[stype]);
> return -ENOMEM;
> }
> pl_was_allocated = true;
> @@ -289,12 +307,15 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
> } else {
> pl = list_first_entry(progs, typeof(*pl), node);
> old_prog = pl->prog;
> - old_storage = pl->storage;
> - bpf_cgroup_storage_unlink(old_storage);
> + for_each_cgroup_storage_type(stype) {
> + old_storage[stype] = pl->storage[stype];
> + bpf_cgroup_storage_unlink(old_storage[stype]);
> + }
> pl_was_allocated = false;
> }
> pl->prog = prog;
> - pl->storage = storage;
> + for_each_cgroup_storage_type(stype)
> + pl->storage[stype] = storage[stype];
> }
>
> cgrp->bpf.flags[type] = flags;
> @@ -304,21 +325,27 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
> goto cleanup;
>
> static_branch_inc(&cgroup_bpf_enabled_key);
> - if (old_storage)
> - bpf_cgroup_storage_free(old_storage);
> + for_each_cgroup_storage_type(stype) {
> + if (!old_storage[stype])
> + continue;
> + bpf_cgroup_storage_free(old_storage[stype]);
> + }
> if (old_prog) {
> bpf_prog_put(old_prog);
> static_branch_dec(&cgroup_bpf_enabled_key);
> }
> - bpf_cgroup_storage_link(storage, cgrp, type);
> + for_each_cgroup_storage_type(stype)
> + bpf_cgroup_storage_link(storage[stype], cgrp, type);
> return 0;
>
> cleanup:
> /* and cleanup the prog list */
> pl->prog = old_prog;
> - bpf_cgroup_storage_free(pl->storage);
> - pl->storage = old_storage;
> - bpf_cgroup_storage_link(old_storage, cgrp, type);
> + for_each_cgroup_storage_type(stype) {
> + bpf_cgroup_storage_free(pl->storage[stype]);
> + pl->storage[stype] = old_storage[stype];
> + bpf_cgroup_storage_link(old_storage[stype], cgrp, type);
> + }
> if (pl_was_allocated) {
> list_del(&pl->node);
> kfree(pl);
> @@ -339,6 +366,7 @@ int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
> enum bpf_attach_type type, u32 unused_flags)
> {
> struct list_head *progs = &cgrp->bpf.progs[type];
> + enum bpf_cgroup_storage_type stype;
> u32 flags = cgrp->bpf.flags[type];
> struct bpf_prog *old_prog = NULL;
> struct bpf_prog_list *pl;
> @@ -385,8 +413,10 @@ int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
>
> /* now can actually delete it from this cgroup list */
> list_del(&pl->node);
> - bpf_cgroup_storage_unlink(pl->storage);
> - bpf_cgroup_storage_free(pl->storage);
> + for_each_cgroup_storage_type(stype) {
> + bpf_cgroup_storage_unlink(pl->storage[stype]);
> + bpf_cgroup_storage_free(pl->storage[stype]);
> + }
> kfree(pl);
> if (list_empty(progs))
> /* last program was detached, reset flags to zero */
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index 1991466b8327..9070b2ace6aa 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -194,16 +194,18 @@ const struct bpf_func_proto bpf_get_current_cgroup_id_proto = {
> .ret_type = RET_INTEGER,
> };
>
> -DECLARE_PER_CPU(void*, bpf_cgroup_storage);
> +#ifdef CONFIG_CGROUP_BPF
> +DECLARE_PER_CPU(void*, bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
>
> BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)
> {
> - /* map and flags arguments are not used now,
> - * but provide an ability to extend the API
> - * for other types of local storages.
> - * verifier checks that their values are correct.
> + /* flags argument is not used now,
> + * but provides an ability to extend the API.
> + * verifier checks that its value is correct.
> */
> - return (unsigned long) this_cpu_read(bpf_cgroup_storage);
> + enum bpf_cgroup_storage_type stype = cgroup_storage_type(map);
> +
> + return (unsigned long) this_cpu_read(bpf_cgroup_storage[stype]);
> }
>
> const struct bpf_func_proto bpf_get_local_storage_proto = {
> @@ -214,3 +216,4 @@ const struct bpf_func_proto bpf_get_local_storage_proto = {
> .arg2_type = ARG_ANYTHING,
> };
> #endif
> +#endif
> diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> index 22ad967d1e5f..0bd9f19fc557 100644
> --- a/kernel/bpf/local_storage.c
> +++ b/kernel/bpf/local_storage.c
> @@ -7,7 +7,7 @@
> #include <linux/rbtree.h>
> #include <linux/slab.h>
>
> -DEFINE_PER_CPU(void*, bpf_cgroup_storage);
> +DEFINE_PER_CPU(void*, bpf_cgroup_storage[MAX_BPF_CGROUP_STORAGE_TYPE]);
>
> #ifdef CONFIG_CGROUP_BPF
>
> @@ -251,6 +251,7 @@ const struct bpf_map_ops cgroup_storage_map_ops = {
>
> int bpf_cgroup_storage_assign(struct bpf_prog *prog, struct bpf_map *_map)
> {
> + enum bpf_cgroup_storage_type stype = cgroup_storage_type(_map);
> struct bpf_cgroup_storage_map *map = map_to_storage(_map);
> int ret = -EBUSY;
>
> @@ -258,11 +259,12 @@ int bpf_cgroup_storage_assign(struct bpf_prog *prog, struct bpf_map *_map)
>
> if (map->prog && map->prog != prog)
> goto unlock;
> - if (prog->aux->cgroup_storage && prog->aux->cgroup_storage != _map)
> + if (prog->aux->cgroup_storage[stype] &&
> + prog->aux->cgroup_storage[stype] != _map)
> goto unlock;
>
> map->prog = prog;
> - prog->aux->cgroup_storage = _map;
> + prog->aux->cgroup_storage[stype] = _map;
> ret = 0;
> unlock:
> spin_unlock_bh(&map->lock);
> @@ -272,24 +274,26 @@ int bpf_cgroup_storage_assign(struct bpf_prog *prog, struct bpf_map *_map)
>
> void bpf_cgroup_storage_release(struct bpf_prog *prog, struct bpf_map *_map)
> {
> + enum bpf_cgroup_storage_type stype = cgroup_storage_type(_map);
> struct bpf_cgroup_storage_map *map = map_to_storage(_map);
>
> spin_lock_bh(&map->lock);
> if (map->prog == prog) {
> - WARN_ON(prog->aux->cgroup_storage != _map);
> + WARN_ON(prog->aux->cgroup_storage[stype] != _map);
> map->prog = NULL;
> - prog->aux->cgroup_storage = NULL;
> + prog->aux->cgroup_storage[stype] = NULL;
> }
> spin_unlock_bh(&map->lock);
> }
>
> -struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog)
> +struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog,
> + enum bpf_cgroup_storage_type stype)
> {
> struct bpf_cgroup_storage *storage;
> struct bpf_map *map;
> u32 pages;
>
> - map = prog->aux->cgroup_storage;
> + map = prog->aux->cgroup_storage[stype];
> if (!map)
> return NULL;
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index b3c2d09bcf7a..8c91d2b41b1e 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -988,10 +988,15 @@ static int find_prog_type(enum bpf_prog_type type, struct bpf_prog *prog)
> /* drop refcnt on maps used by eBPF program and free auxilary data */
> static void free_used_maps(struct bpf_prog_aux *aux)
> {
> + enum bpf_cgroup_storage_type stype;
> int i;
>
> - if (aux->cgroup_storage)
> - bpf_cgroup_storage_release(aux->prog, aux->cgroup_storage);
> + for_each_cgroup_storage_type(stype) {
> + if (!aux->cgroup_storage[stype])
> + continue;
> + bpf_cgroup_storage_release(aux->prog,
> + aux->cgroup_storage[stype]);
> + }
>
> for (i = 0; i < aux->used_map_cnt; i++)
> bpf_map_put(aux->used_maps[i]);
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 8ccbff4fff93..e75f36de91d6 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5171,11 +5171,15 @@ static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env)
> /* drop refcnt of maps used by the rejected program */
> static void release_maps(struct bpf_verifier_env *env)
> {
> + enum bpf_cgroup_storage_type stype;
> int i;
>
> - if (env->prog->aux->cgroup_storage)
> + for_each_cgroup_storage_type(stype) {
> + if (!env->prog->aux->cgroup_storage[stype])
> + continue;
> bpf_cgroup_storage_release(env->prog,
> - env->prog->aux->cgroup_storage);
> + env->prog->aux->cgroup_storage[stype]);
> + }
>
> for (i = 0; i < env->used_map_cnt; i++)
> bpf_map_put(env->used_maps[i]);
> diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> index f4078830ea50..0c423b8cd75c 100644
> --- a/net/bpf/test_run.c
> +++ b/net/bpf/test_run.c
> @@ -12,7 +12,7 @@
> #include <linux/sched/signal.h>
>
> static __always_inline u32 bpf_test_run_one(struct bpf_prog *prog, void *ctx,
> - struct bpf_cgroup_storage *storage)
> + struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE])
> {
> u32 ret;
>
> @@ -28,13 +28,20 @@ static __always_inline u32 bpf_test_run_one(struct bpf_prog *prog, void *ctx,
>
> static u32 bpf_test_run(struct bpf_prog *prog, void *ctx, u32 repeat, u32 *time)
> {
> - struct bpf_cgroup_storage *storage = NULL;
> + struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE] = { 0 };
> + enum bpf_cgroup_storage_type stype;
> u64 time_start, time_spent = 0;
> u32 ret = 0, i;
>
> - storage = bpf_cgroup_storage_alloc(prog);
> - if (IS_ERR(storage))
> - return PTR_ERR(storage);
> + for_each_cgroup_storage_type(stype) {
> + storage[stype] = bpf_cgroup_storage_alloc(prog, stype);
> + if (IS_ERR(storage[stype])) {
> + storage[stype] = NULL;
> + for_each_cgroup_storage_type(stype)
> + bpf_cgroup_storage_free(storage[stype]);
> + return -ENOMEM;
> + }
> + }
>
> if (!repeat)
> repeat = 1;
> @@ -53,7 +60,8 @@ static u32 bpf_test_run(struct bpf_prog *prog, void *ctx, u32 repeat, u32 *time)
> do_div(time_spent, repeat);
> *time = time_spent > U32_MAX ? U32_MAX : (u32)time_spent;
>
> - bpf_cgroup_storage_free(storage);
> + for_each_cgroup_storage_type(stype)
> + bpf_cgroup_storage_free(storage[stype]);
>
> return ret;
> }
> --
> 2.17.1
>
^ 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