* [PATCH mlx5-next 1/5] net/mlx5: Introduce and use mlx5_eswitch_get_total_vports()
From: Saeed Mahameed @ 2019-07-03 7:39 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Parav Pandit
In-Reply-To: <20190703073909.14965-1-saeedm@mellanox.com>
From: Parav Pandit <parav@mellanox.com>
Instead MLX5_TOTAL_VPORTS, use mlx5_eswitch_get_total_vports().
mlx5_eswitch_get_total_vports() in subsequent patch accounts for SF
vports as well.
Expanding MLX5_TOTAL_VPORTS macro would require exposing SF internals to
more generic vport.h header file. Such exposure is not desired.
Hence a mlx5_eswitch_get_total_vports() is introduced.
Given that mlx5_eswitch_get_total_vports() API wants to work on const
mlx5_core_dev*, change its helper functions also to accept const *dev.
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/infiniband/hw/mlx5/ib_rep.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 4 ++-
.../mellanox/mlx5/core/eswitch_offloads.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/fs_core.c | 26 +++++++++++--------
.../net/ethernet/mellanox/mlx5/core/vport.c | 15 +++++++++++
include/linux/mlx5/driver.h | 9 ++++---
include/linux/mlx5/eswitch.h | 3 +++
include/linux/mlx5/vport.h | 3 ---
8 files changed, 43 insertions(+), 21 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/ib_rep.c b/drivers/infiniband/hw/mlx5/ib_rep.c
index 3065c5d0ee96..f2cb789d2331 100644
--- a/drivers/infiniband/hw/mlx5/ib_rep.c
+++ b/drivers/infiniband/hw/mlx5/ib_rep.c
@@ -29,7 +29,7 @@ mlx5_ib_set_vport_rep(struct mlx5_core_dev *dev, struct mlx5_eswitch_rep *rep)
static int
mlx5_ib_vport_rep_load(struct mlx5_core_dev *dev, struct mlx5_eswitch_rep *rep)
{
- int num_ports = MLX5_TOTAL_VPORTS(dev);
+ int num_ports = mlx5_eswitch_get_total_vports(dev);
const struct mlx5_ib_profile *profile;
struct mlx5_ib_dev *ibdev;
int vport_index;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 89f52370e770..9137a8390216 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1868,14 +1868,16 @@ void mlx5_eswitch_disable(struct mlx5_eswitch *esw)
int mlx5_eswitch_init(struct mlx5_core_dev *dev)
{
- int total_vports = MLX5_TOTAL_VPORTS(dev);
struct mlx5_eswitch *esw;
struct mlx5_vport *vport;
+ int total_vports;
int err, i;
if (!MLX5_VPORT_MANAGER(dev))
return 0;
+ total_vports = mlx5_eswitch_get_total_vports(dev);
+
esw_info(dev,
"Total vports %d, per vport: max uc(%d) max mc(%d)\n",
total_vports,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 50e5841c1698..5c8fb2597bfa 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -1394,7 +1394,7 @@ void esw_offloads_cleanup_reps(struct mlx5_eswitch *esw)
int esw_offloads_init_reps(struct mlx5_eswitch *esw)
{
- int total_vports = MLX5_TOTAL_VPORTS(esw->dev);
+ int total_vports = esw->total_vports;
struct mlx5_core_dev *dev = esw->dev;
struct mlx5_eswitch_rep *rep;
u8 hw_id[ETH_ALEN], rep_type;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index 9f5544ac6b8a..8162252585ad 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -2090,7 +2090,7 @@ struct mlx5_flow_namespace *mlx5_get_flow_vport_acl_namespace(struct mlx5_core_d
{
struct mlx5_flow_steering *steering = dev->priv.steering;
- if (!steering || vport >= MLX5_TOTAL_VPORTS(dev))
+ if (!steering || vport >= mlx5_eswitch_get_total_vports(dev))
return NULL;
switch (type) {
@@ -2421,7 +2421,7 @@ static void cleanup_egress_acls_root_ns(struct mlx5_core_dev *dev)
if (!steering->esw_egress_root_ns)
return;
- for (i = 0; i < MLX5_TOTAL_VPORTS(dev); i++)
+ for (i = 0; i < mlx5_eswitch_get_total_vports(dev); i++)
cleanup_root_ns(steering->esw_egress_root_ns[i]);
kfree(steering->esw_egress_root_ns);
@@ -2435,7 +2435,7 @@ static void cleanup_ingress_acls_root_ns(struct mlx5_core_dev *dev)
if (!steering->esw_ingress_root_ns)
return;
- for (i = 0; i < MLX5_TOTAL_VPORTS(dev); i++)
+ for (i = 0; i < mlx5_eswitch_get_total_vports(dev); i++)
cleanup_root_ns(steering->esw_ingress_root_ns[i]);
kfree(steering->esw_ingress_root_ns);
@@ -2614,16 +2614,18 @@ static int init_ingress_acl_root_ns(struct mlx5_flow_steering *steering, int vpo
static int init_egress_acls_root_ns(struct mlx5_core_dev *dev)
{
struct mlx5_flow_steering *steering = dev->priv.steering;
+ int total_vports = mlx5_eswitch_get_total_vports(dev);
int err;
int i;
- steering->esw_egress_root_ns = kcalloc(MLX5_TOTAL_VPORTS(dev),
- sizeof(*steering->esw_egress_root_ns),
- GFP_KERNEL);
+ steering->esw_egress_root_ns =
+ kcalloc(total_vports,
+ sizeof(*steering->esw_egress_root_ns),
+ GFP_KERNEL);
if (!steering->esw_egress_root_ns)
return -ENOMEM;
- for (i = 0; i < MLX5_TOTAL_VPORTS(dev); i++) {
+ for (i = 0; i < total_vports; i++) {
err = init_egress_acl_root_ns(steering, i);
if (err)
goto cleanup_root_ns;
@@ -2641,16 +2643,18 @@ static int init_egress_acls_root_ns(struct mlx5_core_dev *dev)
static int init_ingress_acls_root_ns(struct mlx5_core_dev *dev)
{
struct mlx5_flow_steering *steering = dev->priv.steering;
+ int total_vports = mlx5_eswitch_get_total_vports(dev);
int err;
int i;
- steering->esw_ingress_root_ns = kcalloc(MLX5_TOTAL_VPORTS(dev),
- sizeof(*steering->esw_ingress_root_ns),
- GFP_KERNEL);
+ steering->esw_ingress_root_ns =
+ kcalloc(total_vports,
+ sizeof(*steering->esw_ingress_root_ns),
+ GFP_KERNEL);
if (!steering->esw_ingress_root_ns)
return -ENOMEM;
- for (i = 0; i < MLX5_TOTAL_VPORTS(dev); i++) {
+ for (i = 0; i < total_vports; i++) {
err = init_ingress_acl_root_ns(steering, i);
if (err)
goto cleanup_root_ns;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index 670fa493c5f5..c912d82ca64b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -34,6 +34,7 @@
#include <linux/etherdevice.h>
#include <linux/mlx5/driver.h>
#include <linux/mlx5/vport.h>
+#include <linux/mlx5/eswitch.h>
#include "mlx5_core.h"
/* Mutex to hold while enabling or disabling RoCE */
@@ -1165,3 +1166,17 @@ u64 mlx5_query_nic_system_image_guid(struct mlx5_core_dev *mdev)
return tmp;
}
EXPORT_SYMBOL_GPL(mlx5_query_nic_system_image_guid);
+
+/**
+ * mlx5_eswitch_get_total_vports - Get total vports of the eswitch
+ *
+ * @dev: Pointer to core device
+ *
+ * mlx5_eswitch_get_total_vports returns total number of vports for
+ * the eswitch.
+ */
+u16 mlx5_eswitch_get_total_vports(const struct mlx5_core_dev *dev)
+{
+ return MLX5_SPECIAL_VPORTS(dev) + mlx5_core_max_vfs(dev);
+}
+EXPORT_SYMBOL(mlx5_eswitch_get_total_vports);
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index 7658a4908431..2c3e8d86e12d 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -1083,7 +1083,7 @@ enum {
MLX5_PCI_DEV_IS_VF = 1 << 0,
};
-static inline bool mlx5_core_is_pf(struct mlx5_core_dev *dev)
+static inline bool mlx5_core_is_pf(const struct mlx5_core_dev *dev)
{
return dev->coredev_type == MLX5_COREDEV_PF;
}
@@ -1093,17 +1093,18 @@ static inline bool mlx5_core_is_ecpf(struct mlx5_core_dev *dev)
return dev->caps.embedded_cpu;
}
-static inline bool mlx5_core_is_ecpf_esw_manager(struct mlx5_core_dev *dev)
+static inline bool
+mlx5_core_is_ecpf_esw_manager(const struct mlx5_core_dev *dev)
{
return dev->caps.embedded_cpu && MLX5_CAP_GEN(dev, eswitch_manager);
}
-static inline bool mlx5_ecpf_vport_exists(struct mlx5_core_dev *dev)
+static inline bool mlx5_ecpf_vport_exists(const struct mlx5_core_dev *dev)
{
return mlx5_core_is_pf(dev) && MLX5_CAP_ESW(dev, ecpf_vport_exists);
}
-static inline u16 mlx5_core_max_vfs(struct mlx5_core_dev *dev)
+static inline u16 mlx5_core_max_vfs(const struct mlx5_core_dev *dev)
{
return dev->priv.sriov.max_vfs;
}
diff --git a/include/linux/mlx5/eswitch.h b/include/linux/mlx5/eswitch.h
index d4731199edb4..61db37aa9642 100644
--- a/include/linux/mlx5/eswitch.h
+++ b/include/linux/mlx5/eswitch.h
@@ -66,6 +66,8 @@ struct mlx5_flow_handle *
mlx5_eswitch_add_send_to_vport_rule(struct mlx5_eswitch *esw,
int vport, u32 sqn);
+u16 mlx5_eswitch_get_total_vports(const struct mlx5_core_dev *dev);
+
#ifdef CONFIG_MLX5_ESWITCH
enum devlink_eswitch_encap_mode
mlx5_eswitch_get_encap_mode(const struct mlx5_core_dev *dev);
@@ -93,4 +95,5 @@ mlx5_eswitch_get_vport_metadata_for_match(const struct mlx5_eswitch *esw,
return 0;
};
#endif /* CONFIG_MLX5_ESWITCH */
+
#endif
diff --git a/include/linux/mlx5/vport.h b/include/linux/mlx5/vport.h
index 6cbf29229749..16060fb9b5e5 100644
--- a/include/linux/mlx5/vport.h
+++ b/include/linux/mlx5/vport.h
@@ -44,9 +44,6 @@
MLX5_VPORT_UPLINK_PLACEHOLDER + \
MLX5_VPORT_ECPF_PLACEHOLDER(mdev))
-#define MLX5_TOTAL_VPORTS(mdev) (MLX5_SPECIAL_VPORTS(mdev) + \
- mlx5_core_max_vfs(mdev))
-
#define MLX5_VPORT_MANAGER(mdev) \
(MLX5_CAP_GEN(mdev, vport_group_manager) && \
(MLX5_CAP_GEN(mdev, port_type) == MLX5_CAP_PORT_TYPE_ETH) && \
--
2.21.0
^ permalink raw reply related
* [PATCH mlx5-next 0/5] Mellanox, mlx5 low level updates 2019-07-02
From: Saeed Mahameed @ 2019-07-03 7:39 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org
Hi All,
This series includes some low level updates to mlx5 driver, required for
shared mlx5-next branch.
Tariq extends the WQE control fields names.
Eran adds the required HW definitions and structures for upcoming TLS
support.
Parav improves and refactors the E-Switch "function changed" handler.
In case of no objections these patches will be applied to mlx5-next and
will be sent later as pull request to both rdma-next and net-next trees.
Thanks,
Saeed.
---
Eran Ben Elisha (1):
net/mlx5: Introduce TLS TX offload hardware bits and structures
Parav Pandit (3):
net/mlx5: Introduce and use mlx5_eswitch_get_total_vports()
net/mlx5: E-Switch prepare functions change handler to be modular
net/mlx5: Refactor mlx5_esw_query_functions for modularity
Tariq Toukan (1):
net/mlx5: Properly name the generic WQE control field
drivers/infiniband/hw/mlx5/ib_rep.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 42 +++++--
.../net/ethernet/mellanox/mlx5/core/eswitch.h | 7 +-
.../mellanox/mlx5/core/eswitch_offloads.c | 46 +++++---
.../net/ethernet/mellanox/mlx5/core/fs_core.c | 26 +++--
.../net/ethernet/mellanox/mlx5/core/sriov.c | 15 ++-
.../net/ethernet/mellanox/mlx5/core/vport.c | 15 +++
include/linux/mlx5/device.h | 14 +++
include/linux/mlx5/driver.h | 9 +-
include/linux/mlx5/eswitch.h | 3 +
include/linux/mlx5/mlx5_ifc.h | 104 +++++++++++++++++-
include/linux/mlx5/qp.h | 7 +-
include/linux/mlx5/vport.h | 3 -
13 files changed, 232 insertions(+), 61 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH v5 net-next 6/6] net: ethernet: ti: cpsw: add XDP support
From: Ivan Khoronzhuk @ 2019-07-03 7:38 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: grygorii.strashko, hawk, davem, ast, linux-kernel, linux-omap,
xdp-newbies, ilias.apalodimas, netdev, daniel, jakub.kicinski,
john.fastabend
In-Reply-To: <20190703092603.66f36914@carbon>
On Wed, Jul 03, 2019 at 09:26:03AM +0200, Jesper Dangaard Brouer wrote:
>
>On Sun, 30 Jun 2019 20:23:48 +0300 Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
>
>> Add XDP support based on rx page_pool allocator, one frame per page.
>> Page pool allocator is used with assumption that only one rx_handler
>> is running simultaneously. DMA map/unmap is reused from page pool
>> despite there is no need to map whole page.
>>
>> Due to specific of cpsw, the same TX/RX handler can be used by 2
>> network devices, so special fields in buffer are added to identify
>> an interface the frame is destined to. Thus XDP works for both
>> interfaces, that allows to test xdp redirect between two interfaces
>> easily. Aslo, each rx queue have own page pools, but common for both
>> netdevs.
>
>Looking at the details what happen when a single RX-queue can receive
>into multiple net_device'es. I realize that this driver will
>violate/kill some of the "hidden"/implicit RX-bulking that the
>XDP_REDIRECT code depend on for performance.
>
>Specifically, it violate this assumption:
> https://github.com/torvalds/linux/blob/v5.2-rc7/kernel/bpf/devmap.c#L324-L329
>
> /* Ingress dev_rx will be the same for all xdp_frame's in
> * bulk_queue, because bq stored per-CPU and must be flushed
> * from net_device drivers NAPI func end.
> */
> if (!bq->dev_rx)
> bq->dev_rx = dev_rx;
>
>This drivers "NAPI func end", can have received into multiple
>net_devices, before it's NAPI cycle ends. Thus, violating this code
>assumption.
). I said, I moved to be per device in rx_handler. It violates nothing.
>
>Knowing all xdp_frame's in the bulk queue is from the same net_device,
>can be used to further optimize XDP. E.g. the dev->netdev_ops->ndo_xdp_xmit()
>call don't take fully advantage of this, yet. If we merge this driver,
>it will block optimizations in this area.
>
>NACK
Jesper,
Seems I said that I moved it to flush, that does
dev->netdev_ops->ndo_xdp_xmit(), to rx_handler, so that it's done per device,
so device is knows per each flush.
In the code, I hope everyone can see ..., after each flush dev_rx is cleared
to 0. So no any impact on it.
As for me, it's very not clear and strange decision.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH net-next v6 11/15] ethtool: provide link mode names as a string set
From: Michal Kubecek @ 2019-07-03 7:38 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, David Miller, Jiri Pirko, Andrew Lunn,
Florian Fainelli, John Linville, Stephen Hemminger, Johannes Berg,
linux-kernel
In-Reply-To: <20190702191124.259c6628@cakuba.netronome.com>
On Tue, Jul 02, 2019 at 07:11:24PM -0700, Jakub Kicinski wrote:
> On Tue, 2 Jul 2019 19:04:19 -0700, Jakub Kicinski wrote:
> > On Tue, 2 Jul 2019 13:50:34 +0200 (CEST), Michal Kubecek wrote:
> > > +const char *const link_mode_names[] = {
> > > + __DEFINE_LINK_MODE_NAME(10, T, Half),
> > > + __DEFINE_LINK_MODE_NAME(10, T, Full),
> > > + __DEFINE_LINK_MODE_NAME(100, T, Half),
> > > + __DEFINE_LINK_MODE_NAME(100, T, Full),
> > > + __DEFINE_LINK_MODE_NAME(1000, T, Half),
> > > + __DEFINE_LINK_MODE_NAME(1000, T, Full),
> > > + __DEFINE_SPECIAL_MODE_NAME(Autoneg, "Autoneg"),
> > > + __DEFINE_SPECIAL_MODE_NAME(TP, "TP"),
> > > + __DEFINE_SPECIAL_MODE_NAME(AUI, "AUI"),
> > > + __DEFINE_SPECIAL_MODE_NAME(MII, "MII"),
> > > + __DEFINE_SPECIAL_MODE_NAME(FIBRE, "FIBRE"),
> > > + __DEFINE_SPECIAL_MODE_NAME(BNC, "BNC"),
> >
> > > + __DEFINE_LINK_MODE_NAME(10000, T, Full),
> > > + __DEFINE_SPECIAL_MODE_NAME(Pause, "Pause"),
> > > + __DEFINE_SPECIAL_MODE_NAME(Asym_Pause, "Asym_Pause"),
> > > + __DEFINE_LINK_MODE_NAME(2500, X, Full),
> > > + __DEFINE_SPECIAL_MODE_NAME(Backplane, "Backplane"),
> > > + __DEFINE_LINK_MODE_NAME(1000, KX, Full),
> > ...
> > > + __DEFINE_LINK_MODE_NAME(5000, T, Full),
> > > + __DEFINE_SPECIAL_MODE_NAME(FEC_NONE, "None"),
> > > + __DEFINE_SPECIAL_MODE_NAME(FEC_RS, "RS"),
> > > + __DEFINE_SPECIAL_MODE_NAME(FEC_BASER, "BASER"),
> >
> > Why are port types and FEC params among link mode strings?
>
> Ah, FEC for autoneg, but port type?
The bits in supported bitmap are used to pass information which port
types the device supports (but the information which port is selected
is passed in a different way :-( ). It is used by ethtool to provide the
"Supported ports:" line in "ethtool <dev>" output.
I don't like this design where link modes are mixed with few different
and only loosely related bitmaps. Maybe it would be cleaner to split it
into multiple bitmaps and later change the backend (ethtool_ops) too and
only translate to/from this combined bitmap for legacy ioctl interface.
Michal
>
> > > + __DEFINE_LINK_MODE_NAME(50000, KR, Full),
> > ...
> > > + __DEFINE_LINK_MODE_NAME(1000, T1, Full),
> > > +};
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Greg KH @ 2019-07-03 7:28 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Song Liu, Networking, bpf, Alexei Starovoitov, Daniel Borkmann,
Kernel Team, Lorenz Bauer, Jann Horn
In-Reply-To: <CAEf4Bzb4ASMSNR0h+xgQHKEPryCtQnqFxtLnPvKuT4ME0eoe1Q@mail.gmail.com>
On Tue, Jul 02, 2019 at 12:22:56PM -0700, Andrii Nakryiko wrote:
> On Thu, Jun 27, 2019 at 1:20 PM Song Liu <songliubraving@fb.com> wrote:
> >
> > This patch introduce unprivileged BPF access. The access control is
> > achieved via device /dev/bpf. Users with write access to /dev/bpf are able
> > to call sys_bpf().
> >
> > Two ioctl command are added to /dev/bpf:
> >
> > The two commands enable/disable permission to call sys_bpf() for current
> > task. This permission is noted by bpf_permitted in task_struct. This
> > permission is inherited during clone(CLONE_THREAD).
> >
> > Helper function bpf_capable() is added to check whether the task has got
> > permission via /dev/bpf.
> >
> > Signed-off-by: Song Liu <songliubraving@fb.com>
> > ---
> > Documentation/ioctl/ioctl-number.txt | 1 +
> > include/linux/bpf.h | 11 +++++
> > include/linux/sched.h | 3 ++
> > include/uapi/linux/bpf.h | 6 +++
> > kernel/bpf/arraymap.c | 2 +-
> > kernel/bpf/cgroup.c | 2 +-
> > kernel/bpf/core.c | 4 +-
> > kernel/bpf/cpumap.c | 2 +-
> > kernel/bpf/devmap.c | 2 +-
> > kernel/bpf/hashtab.c | 4 +-
> > kernel/bpf/lpm_trie.c | 2 +-
> > kernel/bpf/offload.c | 2 +-
> > kernel/bpf/queue_stack_maps.c | 2 +-
> > kernel/bpf/reuseport_array.c | 2 +-
> > kernel/bpf/stackmap.c | 2 +-
> > kernel/bpf/syscall.c | 71 +++++++++++++++++++++-------
> > kernel/bpf/verifier.c | 2 +-
> > kernel/bpf/xskmap.c | 2 +-
> > kernel/fork.c | 5 ++
> > net/core/filter.c | 6 +--
> > 20 files changed, 99 insertions(+), 34 deletions(-)
> >
> > diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
> > index c9558146ac58..19998b99d603 100644
> > --- a/Documentation/ioctl/ioctl-number.txt
> > +++ b/Documentation/ioctl/ioctl-number.txt
> > @@ -327,6 +327,7 @@ Code Seq#(hex) Include File Comments
> > 0xB4 00-0F linux/gpio.h <mailto:linux-gpio@vger.kernel.org>
> > 0xB5 00-0F uapi/linux/rpmsg.h <mailto:linux-remoteproc@vger.kernel.org>
> > 0xB6 all linux/fpga-dfl.h
> > +0xBP 01-02 uapi/linux/bpf.h <mailto:bpf@vger.kernel.org>
>
> should this be 0xBF?
Why? It can be whatever the developer wants :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5 net-next 6/6] net: ethernet: ti: cpsw: add XDP support
From: Jesper Dangaard Brouer @ 2019-07-03 7:26 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: grygorii.strashko, hawk, davem, ast, linux-kernel, linux-omap,
xdp-newbies, ilias.apalodimas, netdev, daniel, jakub.kicinski,
john.fastabend, brouer
In-Reply-To: <20190630172348.5692-7-ivan.khoronzhuk@linaro.org>
On Sun, 30 Jun 2019 20:23:48 +0300 Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
> Add XDP support based on rx page_pool allocator, one frame per page.
> Page pool allocator is used with assumption that only one rx_handler
> is running simultaneously. DMA map/unmap is reused from page pool
> despite there is no need to map whole page.
>
> Due to specific of cpsw, the same TX/RX handler can be used by 2
> network devices, so special fields in buffer are added to identify
> an interface the frame is destined to. Thus XDP works for both
> interfaces, that allows to test xdp redirect between two interfaces
> easily. Aslo, each rx queue have own page pools, but common for both
> netdevs.
Looking at the details what happen when a single RX-queue can receive
into multiple net_device'es. I realize that this driver will
violate/kill some of the "hidden"/implicit RX-bulking that the
XDP_REDIRECT code depend on for performance.
Specifically, it violate this assumption:
https://github.com/torvalds/linux/blob/v5.2-rc7/kernel/bpf/devmap.c#L324-L329
/* Ingress dev_rx will be the same for all xdp_frame's in
* bulk_queue, because bq stored per-CPU and must be flushed
* from net_device drivers NAPI func end.
*/
if (!bq->dev_rx)
bq->dev_rx = dev_rx;
This drivers "NAPI func end", can have received into multiple
net_devices, before it's NAPI cycle ends. Thus, violating this code
assumption.
Knowing all xdp_frame's in the bulk queue is from the same net_device,
can be used to further optimize XDP. E.g. the dev->netdev_ops->ndo_xdp_xmit()
call don't take fully advantage of this, yet. If we merge this driver,
it will block optimizations in this area.
NACK
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v6 05/15] ethtool: helper functions for netlink interface
From: Michal Kubecek @ 2019-07-03 7:23 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, David Miller, Jiri Pirko, Andrew Lunn,
Florian Fainelli, John Linville, Stephen Hemminger, Johannes Berg,
linux-kernel
In-Reply-To: <20190702183724.423e3b1e@cakuba.netronome.com>
On Tue, Jul 02, 2019 at 06:37:24PM -0700, Jakub Kicinski wrote:
> On Tue, 2 Jul 2019 13:50:04 +0200 (CEST), Michal Kubecek wrote:
> > Add common request/reply header definition and helpers to parse request
> > header and fill reply header. Provide ethnl_update_* helpers to update
> > structure members from request attributes (to be used for *_SET requests).
> >
> > Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
>
> > diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
> > index 3c98b41f04e5..e13f29bbd625 100644
> > --- a/net/ethtool/netlink.c
> > +++ b/net/ethtool/netlink.c
> > @@ -1,8 +1,181 @@
> > // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
> >
> > +#include <net/sock.h>
> > #include <linux/ethtool_netlink.h>
> > #include "netlink.h"
> >
> > +static struct genl_family ethtool_genl_family;
> > +
> > +static const struct nla_policy dflt_header_policy[ETHTOOL_A_HEADER_MAX + 1] = {
> > + [ETHTOOL_A_HEADER_UNSPEC] = { .type = NLA_REJECT },
>
> I think we want strict checking on all new netlink interfaces, and
> unfortunately that feature is opt-in.. so you need to add:
>
> .strict_start_type = ETHTOOL_A_HEADER_UNSPEC + 1
>
> To the first attr.
Oops... I'll have to check again how this works. I thought using
nla_parse_nested() instead of nla_parse_nested_deprecated() is
sufficient to have everything strict checked.
Michal
^ permalink raw reply
* [PATCH net] r8152: move calling r8153b_rx_agg_chg_indicate()
From: Hayes Wang @ 2019-07-03 7:11 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
r8153b_rx_agg_chg_indicate() needs to be called after enabling TX/RX and
before calling rxdy_gated_en(tp, false). Otherwise, the change of the
settings of RX aggregation wouldn't work.
Besides, adjust rtl8152_set_coalesce() for the same reason. If
rx_coalesce_usecs is changed, restart TX/RX to let the setting work.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 36 ++++++++++++++++++++++++++----------
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 101d1325f3f1..e887ac86fbef 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2367,6 +2367,12 @@ static int rtl_stop_rx(struct r8152 *tp)
return 0;
}
+static inline void r8153b_rx_agg_chg_indicate(struct r8152 *tp)
+{
+ ocp_write_byte(tp, MCU_TYPE_USB, USB_UPT_RXDMA_OWN,
+ OWN_UPDATE | OWN_CLEAR);
+}
+
static int rtl_enable(struct r8152 *tp)
{
u32 ocp_data;
@@ -2377,6 +2383,15 @@ static int rtl_enable(struct r8152 *tp)
ocp_data |= CR_RE | CR_TE;
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CR, ocp_data);
+ switch (tp->version) {
+ case RTL_VER_08:
+ case RTL_VER_09:
+ r8153b_rx_agg_chg_indicate(tp);
+ break;
+ default:
+ break;
+ }
+
rxdy_gated_en(tp, false);
return 0;
@@ -2393,12 +2408,6 @@ static int rtl8152_enable(struct r8152 *tp)
return rtl_enable(tp);
}
-static inline void r8153b_rx_agg_chg_indicate(struct r8152 *tp)
-{
- ocp_write_byte(tp, MCU_TYPE_USB, USB_UPT_RXDMA_OWN,
- OWN_UPDATE | OWN_CLEAR);
-}
-
static void r8153_set_rx_early_timeout(struct r8152 *tp)
{
u32 ocp_data = tp->coalesce / 8;
@@ -2421,7 +2430,6 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
128 / 8);
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EXTRA_AGGR_TMR,
ocp_data);
- r8153b_rx_agg_chg_indicate(tp);
break;
default:
@@ -2445,7 +2453,6 @@ static void r8153_set_rx_early_size(struct r8152 *tp)
case RTL_VER_09:
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE,
ocp_data / 8);
- r8153b_rx_agg_chg_indicate(tp);
break;
default:
WARN_ON_ONCE(1);
@@ -4919,8 +4926,17 @@ static int rtl8152_set_coalesce(struct net_device *netdev,
if (tp->coalesce != coalesce->rx_coalesce_usecs) {
tp->coalesce = coalesce->rx_coalesce_usecs;
- if (netif_running(tp->netdev) && netif_carrier_ok(netdev))
- r8153_set_rx_early_timeout(tp);
+ if (netif_running(netdev) && netif_carrier_ok(netdev)) {
+ netif_stop_queue(netdev);
+ napi_disable(&tp->napi);
+ tp->rtl_ops.disable(tp);
+ tp->rtl_ops.enable(tp);
+ rtl_start_rx(tp);
+ clear_bit(RTL8152_SET_RX_MODE, &tp->flags);
+ _rtl8152_set_rx_mode(netdev);
+ napi_enable(&tp->napi);
+ netif_wake_queue(netdev);
+ }
}
mutex_unlock(&tp->control);
--
2.21.0
^ permalink raw reply related
* [PATCH] wireless: core: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2019-07-03 7:01 UTC (permalink / raw)
To: Johannes Berg, David S. Miller; +Cc: linux-wireless, netdev
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/core.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 037816163e70..339b0ccb3241 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -142,12 +142,10 @@ int cfg80211_dev_rename(struct cfg80211_registered_device *rdev,
if (result)
return result;
- if (rdev->wiphy.debugfsdir &&
- !debugfs_rename(rdev->wiphy.debugfsdir->d_parent,
- rdev->wiphy.debugfsdir,
- rdev->wiphy.debugfsdir->d_parent,
- newname))
- pr_err("failed to rename debugfs dir to %s!\n", newname);
+ if (rdev->wiphy.debugfsdir)
+ debugfs_rename(rdev->wiphy.debugfsdir->d_parent,
+ rdev->wiphy.debugfsdir,
+ rdev->wiphy.debugfsdir->d_parent, newname);
nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY);
@@ -886,11 +884,8 @@ int wiphy_register(struct wiphy *wiphy)
cfg80211_rdev_list_generation++;
/* add to debugfs */
- rdev->wiphy.debugfsdir =
- debugfs_create_dir(wiphy_name(&rdev->wiphy),
- ieee80211_debugfs_dir);
- if (IS_ERR(rdev->wiphy.debugfsdir))
- rdev->wiphy.debugfsdir = NULL;
+ rdev->wiphy.debugfsdir = debugfs_create_dir(wiphy_name(&rdev->wiphy),
+ ieee80211_debugfs_dir);
cfg80211_debugfs_rdev_add(rdev);
nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY);
--
2.22.0
^ permalink raw reply related
* [PATCH] rt2x00: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2019-07-03 6:56 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa, Kalle Valo
Cc: David S. Miller, linux-wireless, netdev
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because we don't need to save the individual debugfs files and
directories, remove the local storage of them and just remove the entire
debugfs directory in a single call, making things a lot simpler.
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
.../net/wireless/ralink/rt2x00/rt2x00debug.c | 100 ++++--------------
1 file changed, 23 insertions(+), 77 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
index aac3aae7afaa..7103904de28a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
@@ -64,25 +64,6 @@ struct rt2x00debug_intf {
* - crypto stats file
*/
struct dentry *driver_folder;
- struct dentry *driver_entry;
- struct dentry *chipset_entry;
- struct dentry *dev_flags;
- struct dentry *cap_flags;
- struct dentry *register_folder;
- struct dentry *csr_off_entry;
- struct dentry *csr_val_entry;
- struct dentry *eeprom_off_entry;
- struct dentry *eeprom_val_entry;
- struct dentry *bbp_off_entry;
- struct dentry *bbp_val_entry;
- struct dentry *rf_off_entry;
- struct dentry *rf_val_entry;
- struct dentry *rfcsr_off_entry;
- struct dentry *rfcsr_val_entry;
- struct dentry *queue_folder;
- struct dentry *queue_frame_dump_entry;
- struct dentry *queue_stats_entry;
- struct dentry *crypto_stats_entry;
/*
* The frame dump file only allows a single reader,
@@ -631,6 +612,8 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
{
const struct rt2x00debug *debug = rt2x00dev->ops->debugfs;
struct rt2x00debug_intf *intf;
+ struct dentry *queue_folder;
+ struct dentry *register_folder;
intf = kzalloc(sizeof(struct rt2x00debug_intf), GFP_KERNEL);
if (!intf) {
@@ -646,39 +629,28 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
debugfs_create_dir(intf->rt2x00dev->ops->name,
rt2x00dev->hw->wiphy->debugfsdir);
- intf->driver_entry =
- rt2x00debug_create_file_driver("driver", intf, &intf->driver_blob);
+ rt2x00debug_create_file_driver("driver", intf, &intf->driver_blob);
- intf->chipset_entry =
- rt2x00debug_create_file_chipset("chipset",
- intf, &intf->chipset_blob);
+ rt2x00debug_create_file_chipset("chipset", intf, &intf->chipset_blob);
- intf->dev_flags = debugfs_create_file("dev_flags", 0400,
- intf->driver_folder, intf,
- &rt2x00debug_fop_dev_flags);
+ debugfs_create_file("dev_flags", 0400, intf->driver_folder, intf,
+ &rt2x00debug_fop_dev_flags);
- intf->cap_flags = debugfs_create_file("cap_flags", 0400,
- intf->driver_folder, intf,
- &rt2x00debug_fop_cap_flags);
+ debugfs_create_file("cap_flags", 0400, intf->driver_folder, intf,
+ &rt2x00debug_fop_cap_flags);
- intf->register_folder =
- debugfs_create_dir("register", intf->driver_folder);
+ register_folder = debugfs_create_dir("register", intf->driver_folder);
#define RT2X00DEBUGFS_CREATE_REGISTER_ENTRY(__intf, __name) \
({ \
if (debug->__name.read) { \
- (__intf)->__name##_off_entry = \
- debugfs_create_u32(__stringify(__name) "_offset", \
- 0600, \
- (__intf)->register_folder, \
- &(__intf)->offset_##__name); \
+ debugfs_create_u32(__stringify(__name) "_offset", 0600, \
+ register_folder, \
+ &(__intf)->offset_##__name); \
\
- (__intf)->__name##_val_entry = \
- debugfs_create_file(__stringify(__name) "_value", \
- 0600, \
- (__intf)->register_folder, \
- (__intf), \
- &rt2x00debug_fop_##__name); \
+ debugfs_create_file(__stringify(__name) "_value", 0600, \
+ register_folder, (__intf), \
+ &rt2x00debug_fop_##__name); \
} \
})
@@ -690,26 +662,21 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
#undef RT2X00DEBUGFS_CREATE_REGISTER_ENTRY
- intf->queue_folder =
- debugfs_create_dir("queue", intf->driver_folder);
+ queue_folder = debugfs_create_dir("queue", intf->driver_folder);
- intf->queue_frame_dump_entry =
- debugfs_create_file("dump", 0400, intf->queue_folder,
- intf, &rt2x00debug_fop_queue_dump);
+ debugfs_create_file("dump", 0400, queue_folder, intf,
+ &rt2x00debug_fop_queue_dump);
skb_queue_head_init(&intf->frame_dump_skbqueue);
init_waitqueue_head(&intf->frame_dump_waitqueue);
- intf->queue_stats_entry =
- debugfs_create_file("queue", 0400, intf->queue_folder,
- intf, &rt2x00debug_fop_queue_stats);
+ debugfs_create_file("queue", 0400, queue_folder, intf,
+ &rt2x00debug_fop_queue_stats);
#ifdef CONFIG_RT2X00_LIB_CRYPTO
if (rt2x00_has_cap_hw_crypto(rt2x00dev))
- intf->crypto_stats_entry =
- debugfs_create_file("crypto", 0444, intf->queue_folder,
- intf,
- &rt2x00debug_fop_crypto_stats);
+ debugfs_create_file("crypto", 0444, queue_folder, intf,
+ &rt2x00debug_fop_crypto_stats);
#endif
return;
@@ -724,28 +691,7 @@ void rt2x00debug_deregister(struct rt2x00_dev *rt2x00dev)
skb_queue_purge(&intf->frame_dump_skbqueue);
-#ifdef CONFIG_RT2X00_LIB_CRYPTO
- debugfs_remove(intf->crypto_stats_entry);
-#endif
- debugfs_remove(intf->queue_stats_entry);
- debugfs_remove(intf->queue_frame_dump_entry);
- debugfs_remove(intf->queue_folder);
- debugfs_remove(intf->rfcsr_val_entry);
- debugfs_remove(intf->rfcsr_off_entry);
- debugfs_remove(intf->rf_val_entry);
- debugfs_remove(intf->rf_off_entry);
- debugfs_remove(intf->bbp_val_entry);
- debugfs_remove(intf->bbp_off_entry);
- debugfs_remove(intf->eeprom_val_entry);
- debugfs_remove(intf->eeprom_off_entry);
- debugfs_remove(intf->csr_val_entry);
- debugfs_remove(intf->csr_off_entry);
- debugfs_remove(intf->register_folder);
- debugfs_remove(intf->dev_flags);
- debugfs_remove(intf->cap_flags);
- debugfs_remove(intf->chipset_entry);
- debugfs_remove(intf->driver_entry);
- debugfs_remove(intf->driver_folder);
+ debugfs_remove_recursive(intf->driver_folder);
kfree(intf->chipset_blob.data);
kfree(intf->driver_blob.data);
kfree(intf);
--
2.22.0
^ permalink raw reply related
* Re: [PATCH net-next v6 04/15] ethtool: introduce ethtool netlink interface
From: Michal Kubecek @ 2019-07-03 6:35 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, David Miller, Jiri Pirko, Andrew Lunn,
Florian Fainelli, John Linville, Stephen Hemminger, Johannes Berg,
linux-kernel
In-Reply-To: <20190702182956.26435d63@cakuba.netronome.com>
On Tue, Jul 02, 2019 at 06:29:56PM -0700, Jakub Kicinski wrote:
> On Tue, 2 Jul 2019 13:49:59 +0200 (CEST), Michal Kubecek wrote:
> > diff --git a/Documentation/networking/ethtool-netlink.txt b/Documentation/networking/ethtool-netlink.txt
> > new file mode 100644
> > index 000000000000..97c369aa290b
> > --- /dev/null
> > +++ b/Documentation/networking/ethtool-netlink.txt
> > @@ -0,0 +1,208 @@
> > + Netlink interface for ethtool
> > + =============================
> > +
> > +
> > +Basic information
> > +-----------------
>
> Probably not a blocker for initial merging, but please note a TODO to
> convert the documentation to ReST.
Yes, I want to do that. What stopped me was that I wasn't sure what to
do with the message structure descriptions. I guess I'll leave them as
preformated text (literal paragraph) for now and leave finding something
more fancy for later.
Michal
^ permalink raw reply
* [PATCH next] loopback: fix lockdep splat
From: Mahesh Bandewar @ 2019-07-03 6:16 UTC (permalink / raw)
To: Netdev
Cc: Eric Dumazet, David Miller, Mahesh Bandewar, Mahesh Bandewar,
Geert Uytterhoeven
dev_init_scheduler() and dev_activate() expect the caller to
hold RTNL. Since we don't want blackhole device to be initialized
per ns, we are initializing at init.
[ 3.855027] Call Trace:
[ 3.855034] dump_stack+0x67/0x95
[ 3.855037] lockdep_rcu_suspicious+0xd5/0x110
[ 3.855044] dev_init_scheduler+0xe3/0x120
[ 3.855048] ? net_olddevs_init+0x60/0x60
[ 3.855050] blackhole_netdev_init+0x45/0x6e
[ 3.855052] do_one_initcall+0x6c/0x2fa
[ 3.855058] ? rcu_read_lock_sched_held+0x8c/0xa0
[ 3.855066] kernel_init_freeable+0x1e5/0x288
[ 3.855071] ? rest_init+0x260/0x260
[ 3.855074] kernel_init+0xf/0x180
[ 3.855076] ? rest_init+0x260/0x260
[ 3.855078] ret_from_fork+0x24/0x30
Fixes: 4de83b88c66 ("loopback: create blackhole net device similar to loopack.")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/loopback.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index 3b39def5471e..14545a8797a8 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -261,8 +261,10 @@ static int __init blackhole_netdev_init(void)
if (!blackhole_netdev)
return -ENOMEM;
+ rtnl_lock();
dev_init_scheduler(blackhole_netdev);
dev_activate(blackhole_netdev);
+ rtnl_unlock();
blackhole_netdev->flags |= IFF_UP | IFF_RUNNING;
dev_net_set(blackhole_netdev, &init_net);
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH net-next v2 1/1] qed: Add support for Timestamping the unicast PTP packets.
From: Sudarsana Reddy Kalluru @ 2019-07-03 6:01 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
This patch adds driver changes to detect/timestamp the unicast PTP packets.
Changes from previous version:
-------------------------------
v2: Defined a macro for unicast ptp param mask.
Please consider applying this to "net-next".
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_ptp.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ptp.c b/drivers/net/ethernet/qlogic/qed/qed_ptp.c
index f3ebdc5..0dacf2c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ptp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ptp.c
@@ -44,6 +44,8 @@
/* Add/subtract the Adjustment_Value when making a Drift adjustment */
#define QED_DRIFT_CNTR_DIRECTION_SHIFT 31
#define QED_TIMESTAMP_MASK BIT(16)
+/* Param mask for Hardware to detect/timestamp the unicast PTP packets */
+#define QED_PTP_UCAST_PARAM_MASK 0xF
static enum qed_resc_lock qed_ptcdev_to_resc(struct qed_hwfn *p_hwfn)
{
@@ -243,7 +245,8 @@ static int qed_ptp_hw_cfg_filters(struct qed_dev *cdev,
return -EINVAL;
}
- qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_PTP_PARAM_MASK, 0);
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_PTP_PARAM_MASK,
+ QED_PTP_UCAST_PARAM_MASK);
qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_PTP_RULE_MASK, rule_mask);
qed_wr(p_hwfn, p_ptt, NIG_REG_RX_PTP_EN, enable_cfg);
@@ -253,7 +256,8 @@ static int qed_ptp_hw_cfg_filters(struct qed_dev *cdev,
qed_wr(p_hwfn, p_ptt, NIG_REG_TX_LLH_PTP_RULE_MASK, 0x3FFF);
} else {
qed_wr(p_hwfn, p_ptt, NIG_REG_TX_PTP_EN, enable_cfg);
- qed_wr(p_hwfn, p_ptt, NIG_REG_TX_LLH_PTP_PARAM_MASK, 0);
+ qed_wr(p_hwfn, p_ptt, NIG_REG_TX_LLH_PTP_PARAM_MASK,
+ QED_PTP_UCAST_PARAM_MASK);
qed_wr(p_hwfn, p_ptt, NIG_REG_TX_LLH_PTP_RULE_MASK, rule_mask);
}
--
1.8.3.1
^ permalink raw reply related
* Reminder: 36 open syzbot bugs in "net/bpf" subsystem
From: Eric Biggers @ 2019-07-03 6:01 UTC (permalink / raw)
To: netdev, bpf, David S. Miller, Alexei Starovoitov, Daniel Borkmann,
John Fastabend
Cc: Martin KaFai Lau, Song Liu, Yonghong Song, linux-kernel,
syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 36 of them as possibly being bugs in the "net/bpf" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 36 bugs, 8 were seen in mainline in the last week.
Of these 36 bugs, 12 were bisected to commits from the following people:
John Fastabend <john.fastabend@gmail.com>
Daniel Borkmann <daniel@iogearbox.net>
Alexei Starovoitov <ast@fb.com>
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/bpf" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: WARNING in bpf_jit_free
Last occurred: 0 days ago
Reported: 351 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d04f9c2ec11ab2678f7427795ff5170cb9eb2220
Original thread: https://lkml.kernel.org/lkml/000000000000e92d1805711f5552@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 5 replies; the last was 21 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+2ff1e7cb738fd3c41113@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000e92d1805711f5552@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in bpf_prog_kallsyms_add
Last occurred: 0 days ago
Reported: 295 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=97f89d84d528e4f5150dcfbdeb97347bc8471e96
Original thread: https://lkml.kernel.org/lkml/0000000000009417ef0575802d44@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug received 2 replies; the last was 120 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c827a78260579449ad39@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009417ef0575802d44@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in sk_psock_unlink
Last occurred: 1 day ago
Reported: 249 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d691981726208716cc7aec231fb915e27763d662
Original thread: https://lkml.kernel.org/lkml/000000000000fd342e05791cc86f@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 1 reply, 41 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3acd9f67a6a15766686e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fd342e05791cc86f@google.com
--------------------------------------------------------------------------------
Title: kernel panic: corrupted stack end in corrupted
Last occurred: 1 day ago
Reported: 12 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1ee6edc829856a31fccb0c66cab50d2de0863f96
Original thread: https://lkml.kernel.org/lkml/00000000000097ca41058bc129cc@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
The original thread for this bug has received 1 reply, 12 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b764c7ca388222ddfb17@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 12 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/00000000000097ca41058bc129cc@google.com
--------------------------------------------------------------------------------
Title: WARNING in bpf_prog_kallsyms_find
Last occurred: 0 days ago
Reported: 56 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=40b0c218e639f1d882b86abff2549cfe11c5101e
Original thread: https://lkml.kernel.org/lkml/000000000000a8fa360588580820@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+89d1ce6e80218a6192d8@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000a8fa360588580820@google.com
--------------------------------------------------------------------------------
Title: kernel panic: corrupted stack end in dput
Last occurred: 2 days ago
Reported: 1 day ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=84982a1f2b31c5239596ed6f436db8696418e233
Original thread: https://lkml.kernel.org/lkml/000000000000a5d3cb058c9a64f0@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
The original thread for this bug has received 1 reply, 9 hours ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d88a977731a9888db7ba@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 9 hours ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/000000000000a5d3cb058c9a64f0@google.com
--------------------------------------------------------------------------------
Title: kernel panic: stack is corrupted in validate_chain
Last occurred: 7 days ago
Reported: 7 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=947c912ab7a1a9e3500b2cc279ba12f9be813d25
Original thread: https://lkml.kernel.org/lkml/000000000000c7a272058c2cde21@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6ba34346b252f2d497c7@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000c7a272058c2cde21@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in corrupted (3)
Last occurred: 6 days ago
Reported: 6 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=5a60c112b10202cbf01ef00c3e912c160ad17b87
Original thread: https://lkml.kernel.org/lkml/000000000000f4f847058c387616@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8a821b383523654227bf@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f4f847058c387616@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in class_equal
Last occurred: 0 days ago
Reported: 38 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d299ab18d8295ac16f481e28f727e3aa0e01a1cf
Original thread: https://lkml.kernel.org/lkml/00000000000016cb560589b9c7c4@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 37 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3d04999521633dceb439@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000016cb560589b9c7c4@google.com
--------------------------------------------------------------------------------
Title: memory leak in sock_hash_update_common
Last occurred: 1 day ago
Reported: 41 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=9992588b3bbe2617f62f41b1162af9fc8ea4829c
Original thread: https://lkml.kernel.org/lkml/000000000000fa662405897c0774@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+30c7a1fc662026545124@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fa662405897c0774@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Write in validate_chain
Last occurred: 1 day ago
Reported: 11 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=e73b1b9f0fb147bf4b79e9f6fe7a465abd9256c5
Original thread: https://lkml.kernel.org/lkml/0000000000000c4e3e058bd5008d@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+55c548ad445cef6063ab@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000000c4e3e058bd5008d@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in usage_accumulate
Last occurred: 7 days ago
Reported: 26 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=53d11b9bbe4e2149cb3cc4cbe56068aa8202f079
Original thread: https://lkml.kernel.org/lkml/000000000000454279058aa80535@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
The original thread for this bug has received 1 reply, 26 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b0d730107e2ca6cb952f@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000454279058aa80535@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel NULL pointer dereference in corrupted (4)
Last occurred: 8 days ago
Reported: 7 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=6751daddb34d9d52970e2c252b87564bf6876fbd
Original thread: https://lkml.kernel.org/lkml/000000000000c3bb59058c2cdef2@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4b5d77fdf765668f9eba@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000c3bb59058c2cdef2@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rb_next (3)
Last occurred: 17 days ago
Reported: 15 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=18230564bca6dbde79a399755fefaca3a974f0c0
Original thread: https://lkml.kernel.org/lkml/0000000000003f07fe058b803013@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+ab4c44191771d56c4eda@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003f07fe058b803013@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Write in validate_chain
Last occurred: 1 day ago
Reported: 11 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=af95641bc8a50769fceae59ec58e8e35ea052914
Original thread: https://lkml.kernel.org/lkml/000000000000e672c6058bd7ee45@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 2 replies; the last was 6 days
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8893700724999566d6a9@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 6 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/000000000000e672c6058bd7ee45@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rb_erase (2)
Last occurred: 27 days ago
Reported: 180 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=562d6c89d913184d9ed9bef5eec82105d71d2dc5
Original thread: https://lkml.kernel.org/lkml/0000000000008ab3c0057e8b747f@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e8c40862180d8949d624@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008ab3c0057e8b747f@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in corrupted (2)
Last occurred: 26 days ago
Reported: 26 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=9360900ac995e4ff25dea7f3ac939652b1f716e1
Original thread: https://lkml.kernel.org/lkml/0000000000004945f1058aa80556@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit d40b0116c94bd8fc2b63aae35ce8e66bb53bba42
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu Aug 16 19:49:08 2018 +0000
bpf, sockmap: fix leakage of smap_psock_map_entry
The original thread for this bug has received 1 reply, 26 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+9a901acbc447313bfe3e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000004945f1058aa80556@google.com
--------------------------------------------------------------------------------
Title: WARNING in is_bpf_text_address
Last occurred: 0 days ago
Reported: 11 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=2386340f7a641010bb1e17228d1e9319592c01ba
Original thread: https://lkml.kernel.org/lkml/00000000000000ac4f058bd50039@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 2 replies; the last was 1 day ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+bd3bba6ff3fcea7a6ec6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 1 day ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/00000000000000ac4f058bd50039@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in tls_prots
Last occurred: 6 days ago
Reported: 6 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=8de86ced049e882cd68c3ef51cc69c634d8aeb7c
Original thread: https://lkml.kernel.org/lkml/000000000000d7bcbb058c3758a1@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4207c7f3a443366d8aa2@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000d7bcbb058c3758a1@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in cpuacct_account_field
Last occurred: 12 days ago
Reported: 11 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=8155f45b63050b3a24f5e9091005488492d48461
Original thread: https://lkml.kernel.org/lkml/00000000000008f38a058bd500b9@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 10 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a952f743523593b39174@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 10 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/00000000000008f38a058bd500b9@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in __do_softirq
Last occurred: 14 days ago
Reported: 13 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=a0772f3c173c018b078174c3108eb00078c5818b
Original thread: https://lkml.kernel.org/lkml/00000000000017c9e2058baf4825@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 13 days ago.
I believe that syzbot originally sent this report to the wrong people.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0b224895cb9454584de1@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 13 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/00000000000017c9e2058baf4825@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in hrtimer_interrupt
Last occurred: 14 days ago
Reported: 13 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=fe68b600c03d48b14a769e379d1cda8704ffe9cb
Original thread: https://lkml.kernel.org/lkml/0000000000001c03bf058baf488a@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 13 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+037e18398ba8c655a652@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 13 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000001c03bf058baf488a@google.com
--------------------------------------------------------------------------------
Title: general protection fault in mm_update_next_owner
Last occurred: 24 days ago
Reported: 24 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=eaeca1c76639c47820399a4478080ebcf931c489
Original thread: https://lkml.kernel.org/lkml/000000000000a802e6058ad4bc53@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
The original thread for this bug has received 2 replies; the last was 21 days
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f625baafb9a1c4bfc3f6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000a802e6058ad4bc53@google.com
--------------------------------------------------------------------------------
Title: WARNING: kernel stack frame pointer has bad value (2)
Last occurred: 14 days ago
Reported: 351 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=02a32f98a4e3b5a2ed6929aabdd28dd1618b9c03
Original thread: https://lkml.kernel.org/lkml/0000000000000956640571197f98@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 1 reply, 351 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+903cdd6bce9a6eb832a4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000000956640571197f98@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in bpf_prog_kallsyms_del
Last occurred: 182 days ago
Reported: 260 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=55d929463ecf8859c0c4836a4f8f004cfec28cf7
Original thread: https://lkml.kernel.org/lkml/0000000000001d985405783e8aee@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit f4d7e40a5b7157e1329c3c5b10f60d8289fc2941
Author: Alexei Starovoitov <ast@fb.com>
Date: Fri Dec 15 01:55:06 2017 +0000
bpf: introduce function calls (verification)
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+10cffda23c81a3ff1088@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001d985405783e8aee@google.com
--------------------------------------------------------------------------------
Title: WARNING in mark_lock
Last occurred: 12 days ago
Reported: 8 days ago
Branches: linux-next
Dashboard link: https://syzkaller.appspot.com/bug?id=cff2f292a776c2e85f65789d6a62a8c3b640aa98
Original thread: https://lkml.kernel.org/lkml/0000000000005aedf1058c1bf7e8@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 8 replies; the last was 1 day ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a861f52659ae2596492b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 1 day ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000005aedf1058c1bf7e8@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in bpf_prog_kallsyms_add
Last occurred: 61 days ago
Reported: 295 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=0d9e7892096514a76e429ff8353aca183dac6e73
Original thread: https://lkml.kernel.org/lkml/000000000000ebd44005758029c2@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+ac0311cfc9e80cd2e0e8@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ebd44005758029c2@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in sock_hash_ctx_update_elem
Last occurred: 337 days ago
Reported: 337 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=4387b587226bb5f873bcf7dc8febc50c2dd3c540
Original thread: https://lkml.kernel.org/lkml/000000000000cc883b05723824b2@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4207b2e0c72d65cc775d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000cc883b05723824b2@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in psock_map_pop
Last occurred: 252 days ago
Reported: 295 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=931ba7ed06ce22b5933fbc3992e6377a889d3ceb
Original thread: https://lkml.kernel.org/lkml/0000000000008cc5260575802d0d@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+5bbe234204453085d43e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008cc5260575802d0d@google.com
--------------------------------------------------------------------------------
Title: general protection fault in bpf_tcp_close (2)
Last occurred: 312 days ago
Reported: 356 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=50e6f582ccc13e995abdad2ecdefed35f91bebad
Original thread: https://lkml.kernel.org/lkml/00000000000054fd6b0570be9fa8@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+339037020e772651f1d8@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000054fd6b0570be9fa8@google.com
--------------------------------------------------------------------------------
Title: general protection fault in smap_list_hash_remove
Last occurred: 344 days ago
Reported: 363 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=293f48c6a63935b5872fac5eafff89a15518864e
Original thread: https://lkml.kernel.org/lkml/000000000000b0e80905702dcf6f@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b912ba691bb508925d72@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b0e80905702dcf6f@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in bpf_prog_kallsyms_find
Last occurred: 151 days ago
Reported: 226 days ago
Branches: bpf-next and linux-next
Dashboard link: https://syzkaller.appspot.com/bug?id=a1c27d97870876dcccbac41a965e46f672fc3855
Original thread: https://lkml.kernel.org/lkml/000000000000b99324057af4dabb@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit f4d7e40a5b7157e1329c3c5b10f60d8289fc2941
Author: Alexei Starovoitov <ast@fb.com>
Date: Fri Dec 15 01:55:06 2017 +0000
bpf: introduce function calls (verification)
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+66d6b1d3055f1d9ee4f3@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b99324057af4dabb@google.com
--------------------------------------------------------------------------------
Title: WARNING in bpf_prog_kallsyms_add
Last occurred: 180 days ago
Reported: 179 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=b658eb696c8279d9951a4ceea79efba8a1d12467
Original thread: https://lkml.kernel.org/lkml/000000000000f302fc057ea3b499@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 2 replies; the last was 98 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+987e48d84abddbe2506d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f302fc057ea3b499@google.com
--------------------------------------------------------------------------------
Title: WARNING: suspicious RCU usage in trace_call_bpf
Last occurred: 285 days ago
Reported: 302 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=b4ec822cd97ffa2800cd27429997e0c8ea82331d
Original thread: https://lkml.kernel.org/lkml/00000000000072d3ab0574f40f80@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1c843dc17610ca4c764f@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000072d3ab0574f40f80@google.com
--------------------------------------------------------------------------------
Title: WARNING in bpf_base_func_proto
Last occurred: 34 days ago
Reported: 32 days ago
Branches: bpf
Dashboard link: https://syzkaller.appspot.com/bug?id=5157126acdd38b1aedd23aeea5a3cfc26e16ce79
Original thread: https://lkml.kernel.org/lkml/0000000000002ea227058a2b28a4@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+5b595d1c2cd4d7d0f521@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002ea227058a2b28a4@google.com
--------------------------------------------------------------------------------
Title: INFO: rcu detected stall in sys_bpf
Last occurred: 65 days ago
Reported: 97 days ago
Branches: bpf and linux-next
Dashboard link: https://syzkaller.appspot.com/bug?id=8a99735caa3c5e2b342382d6731db9da1a18aefd
Original thread: https://lkml.kernel.org/lkml/00000000000012a28e058517a481@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c70685d9eac9589eaffc@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000012a28e058517a481@google.com
^ permalink raw reply
* Re: [PATCH net-next] net: socionext: remove set but not used variable 'pkts'
From: Ilias Apalodimas @ 2019-07-03 5:12 UTC (permalink / raw)
To: YueHaibing
Cc: Jassi Brar, Alexei Starovoitov, David S . Miller, Daniel Borkmann,
Jakub Kicinski, Jesper Dangaard Brouer, netdev, xdp-newbies, bpf,
kernel-janitors
In-Reply-To: <20190703024213.191191-1-yuehaibing@huawei.com>
On Wed, Jul 03, 2019 at 02:42:13AM +0000, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/socionext/netsec.c: In function 'netsec_clean_tx_dring':
> drivers/net/ethernet/socionext/netsec.c:637:15: warning:
> variable 'pkts' set but not used [-Wunused-but-set-variable]
>
> It is not used since commit ba2b232108d3 ("net: netsec: add XDP support")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/socionext/netsec.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
> index 5544a722543f..015d1ec5436a 100644
> --- a/drivers/net/ethernet/socionext/netsec.c
> +++ b/drivers/net/ethernet/socionext/netsec.c
> @@ -634,7 +634,7 @@ static void netsec_set_rx_de(struct netsec_priv *priv,
> static bool netsec_clean_tx_dring(struct netsec_priv *priv)
> {
> struct netsec_desc_ring *dring = &priv->desc_ring[NETSEC_RING_TX];
> - unsigned int pkts, bytes;
> + unsigned int bytes;
> struct netsec_de *entry;
> int tail = dring->tail;
> int cnt = 0;
> @@ -642,7 +642,6 @@ static bool netsec_clean_tx_dring(struct netsec_priv *priv)
> if (dring->is_xdp)
> spin_lock(&dring->lock);
>
> - pkts = 0;
> bytes = 0;
> entry = dring->vaddr + DESC_SZ * tail;
>
>
>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
^ permalink raw reply
* RE: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and port attribute
From: Parav Pandit @ 2019-07-03 4:46 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Jiri Pirko, netdev@vger.kernel.org, Saeed Mahameed
In-Reply-To: <20190702191536.4de1ac68@cakuba.netronome.com>
> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Sent: Wednesday, July 3, 2019 7:46 AM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Jiri Pirko <jiri@mellanox.com>; netdev@vger.kernel.org; Saeed
> Mahameed <saeedm@mellanox.com>
> Subject: Re: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and
> port attribute
>
> On Wed, 3 Jul 2019 02:08:39 +0000, Parav Pandit wrote:
> > > If you want to expose some device specific eswitch port ID please
> > > add a new attribute for that.
> > > The fact that that ID may match port_number for your device today is
> > > coincidental. port_number, and split attributes should not be
> > > exposed for PCI ports.
> >
> > So your concern is non mellanox hw has eswitch but there may not be a
> > unique handle to identify a eswitch port?
>
> That's not a concern, no. Like any debug attribute it should be optional.
>
> > Or that handle may be wider than 32-bit?
>
> 64 bit would probably be better, yes, although that wasn't my initial
> concern.
>
Why 32-bit is not enough?
> > And instead of treating port_number as handle, there should be
> > different attribute, is that the ask?
>
> Yes, the ask, as always, is to not abuse existing attributes to carry
> tangentially related information.
Why it is tangential?
Devlink_port has got a port_number. Depending on flavour this port_number represents a port.
If it is floavour=PHYSICAL, its physical port number.
If it is eswitch pf/vf ports, it represents eswitch port.
Why you see it only as physical_port_number?
Jiri,
Do you see it this way too?
^ permalink raw reply
* Re: suspicious RCU usage (was: Re: [PATCHv3 next 1/3] loopback: create blackhole net device similar to loopack.)
From: Mahesh Bandewar (महेश बंडेवार) @ 2019-07-03 4:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Netdev, Eric Dumazet, David Miller, Michael Chan, Daniel Axtens,
Mahesh Bandewar, Paul E. McKenney, linux-arm-kernel, linux-kernel
In-Reply-To: <alpine.DEB.2.21.1907021450320.5764@ramsan.of.borg>
On Tue, Jul 2, 2019 at 5:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Mahesh,
>
> On Mon, 1 Jul 2019, Mahesh Bandewar wrote:
> > Create a blackhole net device that can be used for "dead"
> > dst entries instead of loopback device. This blackhole device differs
> > from loopback in few aspects: (a) It's not per-ns. (b) MTU on this
> > device is ETH_MIN_MTU (c) The xmit function is essentially kfree_skb().
> > and (d) since it's not registered it won't have ifindex.
> >
> > Lower MTU effectively make the device not pass the MTU check during
> > the route check when a dst associated with the skb is dead.
> >
> > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>
> This is now commit 4de83b88c66a1e4d ("loopback: create blackhole net
> device similar to loopack.") in net-next, and causes the following
> warning on arm64:
>
> WARNING: suspicious RCU usage
> 5.2.0-rc6-arm64-renesas-01699-g4de83b88c66a1e4d #263 Not tainted
> -----------------------------
> include/linux/rtnetlink.h:85 suspicious rcu_dereference_protected() usage!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 1
> no locks held by swapper/0/1.
>
thanks for the report. Let me take a look at this.
> stack backtrace:
> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc6-arm64-renesas-01699-g4de83b88c66a1e4d #263
> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
> Call trace:
> dump_backtrace+0x0/0x148
> show_stack+0x14/0x20
> dump_stack+0xd4/0x11c
> lockdep_rcu_suspicious+0xcc/0x110
> dev_init_scheduler+0x114/0x150
> blackhole_netdev_init+0x40/0x80
> do_one_initcall+0x178/0x37c
> kernel_init_freeable+0x490/0x530
> kernel_init+0x10/0x100
> ret_from_fork+0x10/0x1c
>
>
> > ---
> > v1->v2->v3
> > no change
> >
> > drivers/net/loopback.c | 76 ++++++++++++++++++++++++++++++++++-----
> > include/linux/netdevice.h | 2 ++
> > 2 files changed, 69 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
> > index 87d361666cdd..3b39def5471e 100644
> > --- a/drivers/net/loopback.c
> > +++ b/drivers/net/loopback.c
> > @@ -55,6 +55,13 @@
> > #include <net/net_namespace.h>
> > #include <linux/u64_stats_sync.h>
> >
> > +/* blackhole_netdev - a device used for dsts that are marked expired!
> > + * This is global device (instead of per-net-ns) since it's not needed
> > + * to be per-ns and gets initialized at boot time.
> > + */
> > +struct net_device *blackhole_netdev;
> > +EXPORT_SYMBOL(blackhole_netdev);
> > +
> > /* The higher levels take care of making this non-reentrant (it's
> > * called with bh's disabled).
> > */
> > @@ -150,12 +157,14 @@ static const struct net_device_ops loopback_ops = {
> > .ndo_set_mac_address = eth_mac_addr,
> > };
> >
> > -/* The loopback device is special. There is only one instance
> > - * per network namespace.
> > - */
> > -static void loopback_setup(struct net_device *dev)
> > +static void gen_lo_setup(struct net_device *dev,
> > + unsigned int mtu,
> > + const struct ethtool_ops *eth_ops,
> > + const struct header_ops *hdr_ops,
> > + const struct net_device_ops *dev_ops,
> > + void (*dev_destructor)(struct net_device *dev))
> > {
> > - dev->mtu = 64 * 1024;
> > + dev->mtu = mtu;
> > dev->hard_header_len = ETH_HLEN; /* 14 */
> > dev->min_header_len = ETH_HLEN; /* 14 */
> > dev->addr_len = ETH_ALEN; /* 6 */
> > @@ -174,11 +183,20 @@ static void loopback_setup(struct net_device *dev)
> > | NETIF_F_NETNS_LOCAL
> > | NETIF_F_VLAN_CHALLENGED
> > | NETIF_F_LOOPBACK;
> > - dev->ethtool_ops = &loopback_ethtool_ops;
> > - dev->header_ops = ð_header_ops;
> > - dev->netdev_ops = &loopback_ops;
> > + dev->ethtool_ops = eth_ops;
> > + dev->header_ops = hdr_ops;
> > + dev->netdev_ops = dev_ops;
> > dev->needs_free_netdev = true;
> > - dev->priv_destructor = loopback_dev_free;
> > + dev->priv_destructor = dev_destructor;
> > +}
> > +
> > +/* The loopback device is special. There is only one instance
> > + * per network namespace.
> > + */
> > +static void loopback_setup(struct net_device *dev)
> > +{
> > + gen_lo_setup(dev, (64 * 1024), &loopback_ethtool_ops, ð_header_ops,
> > + &loopback_ops, loopback_dev_free);
> > }
> >
> > /* Setup and register the loopback device. */
> > @@ -213,3 +231,43 @@ static __net_init int loopback_net_init(struct net *net)
> > struct pernet_operations __net_initdata loopback_net_ops = {
> > .init = loopback_net_init,
> > };
> > +
> > +/* blackhole netdevice */
> > +static netdev_tx_t blackhole_netdev_xmit(struct sk_buff *skb,
> > + struct net_device *dev)
> > +{
> > + kfree_skb(skb);
> > + net_warn_ratelimited("%s(): Dropping skb.\n", __func__);
> > + return NETDEV_TX_OK;
> > +}
> > +
> > +static const struct net_device_ops blackhole_netdev_ops = {
> > + .ndo_start_xmit = blackhole_netdev_xmit,
> > +};
> > +
> > +/* This is a dst-dummy device used specifically for invalidated
> > + * DSTs and unlike loopback, this is not per-ns.
> > + */
> > +static void blackhole_netdev_setup(struct net_device *dev)
> > +{
> > + gen_lo_setup(dev, ETH_MIN_MTU, NULL, NULL, &blackhole_netdev_ops, NULL);
> > +}
> > +
> > +/* Setup and register the blackhole_netdev. */
> > +static int __init blackhole_netdev_init(void)
> > +{
> > + blackhole_netdev = alloc_netdev(0, "blackhole_dev", NET_NAME_UNKNOWN,
> > + blackhole_netdev_setup);
> > + if (!blackhole_netdev)
> > + return -ENOMEM;
> > +
> > + dev_init_scheduler(blackhole_netdev);
> > + dev_activate(blackhole_netdev);
> > +
> > + blackhole_netdev->flags |= IFF_UP | IFF_RUNNING;
> > + dev_net_set(blackhole_netdev, &init_net);
> > +
> > + return 0;
> > +}
> > +
> > +device_initcall(blackhole_netdev_init);
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index eeacebd7debb..88292953aa6f 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -4870,4 +4870,6 @@ do { \
> > #define PTYPE_HASH_SIZE (16)
> > #define PTYPE_HASH_MASK (PTYPE_HASH_SIZE - 1)
> >
> > +extern struct net_device *blackhole_netdev;
> > +
> > #endif /* _LINUX_NETDEVICE_H */
> >
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply
* Re: [PATCH net-next] skbuff: increase verbosity when dumping skb data
From: Yunsheng Lin @ 2019-07-03 3:28 UTC (permalink / raw)
To: Willem de Bruijn, netdev
Cc: davem, xiyou.wangcong, herbert, eric.dumazet, saeedm,
Willem de Bruijn
In-Reply-To: <20190702193927.116668-1-willemdebruijn.kernel@gmail.com>
On 2019/7/3 3:39, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> skb_warn_bad_offload and netdev_rx_csum_fault trigger on hard to debug
> issues. Dump more state and the header.
>
> Optionally dump the entire packet and linear segment. This is required
> to debug checksum bugs that may include bytes past skb_tail_pointer().
>
> Both call sites call this function inside a net_ratelimit() block.
> Limit full packet log further to a hard limit of can_dump_full (5).
>
> Based on an earlier patch by Cong Wang, see link below.
>
> Link: https://patchwork.ozlabs.org/patch/1000841/
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
> include/linux/skbuff.h | 1 +
> net/core/dev.c | 16 ++-----
> net/core/skbuff.c | 103 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 108 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index b5d427b149c92..48b08549a8b78 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1024,6 +1024,7 @@ static inline bool skb_unref(struct sk_buff *skb)
> void skb_release_head_state(struct sk_buff *skb);
> void kfree_skb(struct sk_buff *skb);
> void kfree_skb_list(struct sk_buff *segs);
> +void skb_dump(const char *level, const struct sk_buff *skb, bool full_pkt);
> void skb_tx_error(struct sk_buff *skb);
> void consume_skb(struct sk_buff *skb);
> void __consume_stateless_skb(struct sk_buff *skb);
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 58529318b3a94..fc676b2610e3c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2900,12 +2900,10 @@ static void skb_warn_bad_offload(const struct sk_buff *skb)
> else
> name = netdev_name(dev);
> }
> - WARN(1, "%s: caps=(%pNF, %pNF) len=%d data_len=%d gso_size=%d "
> - "gso_type=%d ip_summed=%d\n",
> + skb_dump(KERN_WARNING, skb, false);
> + WARN(1, "%s: caps=(%pNF, %pNF)\n",
> name, dev ? &dev->features : &null_features,
> - skb->sk ? &skb->sk->sk_route_caps : &null_features,
> - skb->len, skb->data_len, skb_shinfo(skb)->gso_size,
> - skb_shinfo(skb)->gso_type, skb->ip_summed);
> + skb->sk ? &skb->sk->sk_route_caps : &null_features);
> }
>
> /*
> @@ -3124,13 +3122,7 @@ void netdev_rx_csum_fault(struct net_device *dev, struct sk_buff *skb)
> {
> if (net_ratelimit()) {
> pr_err("%s: hw csum failure\n", dev ? dev->name : "<unknown>");
> - if (dev)
> - pr_err("dev features: %pNF\n", &dev->features);
> - pr_err("skb len=%u data_len=%u pkt_type=%u gso_size=%u gso_type=%u nr_frags=%u ip_summed=%u csum=%x csum_complete_sw=%d csum_valid=%d csum_level=%u\n",
> - skb->len, skb->data_len, skb->pkt_type,
> - skb_shinfo(skb)->gso_size, skb_shinfo(skb)->gso_type,
> - skb_shinfo(skb)->nr_frags, skb->ip_summed, skb->csum,
> - skb->csum_complete_sw, skb->csum_valid, skb->csum_level);
> + skb_dump(KERN_ERR, skb, true);
> dump_stack();
> }
> }
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 5323441a12ccf..5d501066d00ca 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -707,6 +707,109 @@ void kfree_skb_list(struct sk_buff *segs)
> }
> EXPORT_SYMBOL(kfree_skb_list);
>
> +/* Dump skb information and contents.
> + *
> + * Must only be called from net_ratelimit()-ed paths.
> + *
> + * Dumps up to can_dump_full whole packets if full_pkt, headers otherwise.
> + */
> +void skb_dump(const char *level, const struct sk_buff *skb, bool full_pkt)
> +{
> + static atomic_t can_dump_full = ATOMIC_INIT(5);
> + struct skb_shared_info *sh = skb_shinfo(skb);
> + struct net_device *dev = skb->dev;
> + struct sock *sk = skb->sk;
> + struct sk_buff *list_skb;
> + bool has_mac, has_trans;
> + int headroom, tailroom;
> + int i, len, seg_len;
> +
> + if (full_pkt)
> + full_pkt = atomic_dec_if_positive(&can_dump_full) >= 0;
> +
> + if (full_pkt)
> + len = skb->len;
Minor question:
Here we set the len to skb->len if full_pkt is true when skb_dump is
called with frag_list skb and full_pkt being true below, which may
cause some problem?
Maybe change the definition to:
void skb_dump(const char *level, const struct sk_buff *skb, int len, bool full_pkt)
skb_dump(KERN_ERR, skb, skb->len, true);
> + else
> + len = min_t(int, skb->len, MAX_HEADER + 128);
> +
> + headroom = skb_headroom(skb);
> + tailroom = skb_tailroom(skb);
> +
> + has_mac = skb_mac_header_was_set(skb);
> + has_trans = skb_transport_header_was_set(skb);
> +
> + printk("%sskb len=%u headroom=%u headlen=%u tailroom=%u\n"
> + "mac=(%d,%d) net=(%d,%d) trans=%d\n"
> + "shinfo(txflags=%u nr_frags=%u gso(size=%hu type=%u segs=%hu))\n"
> + "csum(0x%x ip_summed=%u complete_sw=%u valid=%u level=%u)\n"
> + "hash(0x%x sw=%u l4=%u) proto=0x%04x pkttype=%u iif=%d\n",
> + level, skb->len, headroom, skb_headlen(skb), tailroom,
> + has_mac ? skb->mac_header : -1,
> + has_mac ? skb_mac_header_len(skb) : -1,
> + skb->network_header,
> + has_trans ? skb_network_header_len(skb) : -1,
> + has_trans ? skb->transport_header : -1,
> + sh->tx_flags, sh->nr_frags,
> + sh->gso_size, sh->gso_type, sh->gso_segs,
> + skb->csum, skb->ip_summed, skb->csum_complete_sw,
> + skb->csum_valid, skb->csum_level,
> + skb->hash, skb->sw_hash, skb->l4_hash,
> + ntohs(skb->protocol), skb->pkt_type, skb->skb_iif);
> +
> + if (dev)
> + printk("%sdev name=%s feat=0x%pNF\n",
> + level, dev->name, &dev->features);
> + if (sk)
> + printk("%ssk family=%hu type=%hu proto=%hu\n",
> + level, sk->sk_family, sk->sk_type, sk->sk_protocol);
> +
> + if (full_pkt && headroom)
> + print_hex_dump(level, "skb headroom: ", DUMP_PREFIX_OFFSET,
> + 16, 1, skb->head, headroom, false);
> +
> + seg_len = min_t(int, skb_headlen(skb), len);
> + if (seg_len)
> + print_hex_dump(level, "skb linear: ", DUMP_PREFIX_OFFSET,
> + 16, 1, skb->data, seg_len, false);
> + len -= seg_len;
> +
> + if (full_pkt && tailroom)
> + print_hex_dump(level, "skb tailroom: ", DUMP_PREFIX_OFFSET,
> + 16, 1, skb_tail_pointer(skb), tailroom, false);
> +
> + for (i = 0; len && i < skb_shinfo(skb)->nr_frags; i++) {
> + skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
> + u32 p_off, p_len, copied;
> + struct page *p;
> + u8 *vaddr;
> +
> + skb_frag_foreach_page(frag, frag->page_offset,
> + skb_frag_size(frag), p, p_off, p_len,
> + copied) {
> + seg_len = min_t(int, p_len, len);
> + vaddr = kmap_atomic(p);
> + print_hex_dump(level, "skb frag: ",
> + DUMP_PREFIX_OFFSET,
> + 16, 1, vaddr + p_off, seg_len, false);
> + kunmap_atomic(vaddr);
> + len -= seg_len;
> + if (!len)
> + break;
> + }
> + }
> +
> + if (len && skb_has_frag_list(skb)) {
> + printk("skb fraglist:\n");
> + skb_walk_frags(skb, list_skb) {
> + if (len <= 0)
> + break;
> + skb_dump(level, list_skb, len);
Here we call skb_dump passing len as full_pkt.
Maybe call it with skb_dump(level, list_skb, len, full_pkt);
> + len -= list_skb->len;
> + }
> + }
> +}
> +EXPORT_SYMBOL(skb_dump);
> +
> /**
> * skb_tx_error - report an sk_buff xmit error
> * @skb: buffer that triggered an error
>
^ permalink raw reply
* Re: [PATCH net] tcp: refine memory limit test in tcp_fragment()
From: Tony Lu @ 2019-07-03 3:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, Christoph Paasch,
oliver.yang, xlpang, dust.li
In-Reply-To: <20190621130955.147974-1-edumazet@google.com>
Hello Eric,
We have applied that commit e358f4af19db ("tcp: tcp_fragment() should apply sane memory limits")
as a hotpatch in production environment. We found that it will make
tcp long connection reset during sending out packet when applying
that commit.
Our applications which in A/B test have suffered that
and made them retransmit large data, and then caused retransmission
storm and lower the performance and increase RT.
Therefore we discontinued to apply this hotpatch in A/B test.
After invesgation, we found this patch already fix this issue in
stable. Before applying this patch, we have some questions:
1. This commit in stable hard coded a magic number 0x20000. I am
wondering this value and if there any better solution.
2. Is there any known or unknown side effect? If any, we could test
it in some suspicious scenarios before testing in prod env.
Thanks.
Cheers,
Tony Lu
On Fri, Jun 21, 2019 at 06:09:55AM -0700, Eric Dumazet wrote:
> tcp_fragment() might be called for skbs in the write queue.
>
> Memory limits might have been exceeded because tcp_sendmsg() only
> checks limits at full skb (64KB) boundaries.
>
> Therefore, we need to make sure tcp_fragment() wont punish applications
> that might have setup very low SO_SNDBUF values.
>
> Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Christoph Paasch <cpaasch@apple.com>
> ---
> net/ipv4/tcp_output.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 00c01a01b547ec67c971dc25a74c9258563cf871..0ebc33d1c9e5099d163a234930e213ee35e9fbd1 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1296,7 +1296,8 @@ int tcp_fragment(struct sock *sk, enum tcp_queue tcp_queue,
> if (nsize < 0)
> nsize = 0;
>
> - if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf)) {
> + if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf &&
> + tcp_queue != TCP_FRAG_IN_WRITE_QUEUE)) {
> NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
> return -ENOMEM;
> }
> --
> 2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: cgroup: Fix build error without CONFIG_NET
From: Yuehaibing @ 2019-07-03 3:26 UTC (permalink / raw)
To: Yonghong Song
Cc: Stanislav Fomichev, ast@kernel.org, daniel@iogearbox.net,
Martin Lau, Song Liu, sdf@google.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
bpf@vger.kernel.org
In-Reply-To: <fd312c26-db8e-cae3-1c14-869d8e3a62ae@fb.com>
On 2019/7/3 0:04, Yonghong Song wrote:
>
>
> On 7/2/19 8:53 AM, Stanislav Fomichev wrote:
>> On 07/02, YueHaibing wrote:
>>> If CONFIG_NET is not set, gcc building fails:
>>>
>>> kernel/bpf/cgroup.o: In function `cg_sockopt_func_proto':
>>> cgroup.c:(.text+0x237e): undefined reference to `bpf_sk_storage_get_proto'
>>> cgroup.c:(.text+0x2394): undefined reference to `bpf_sk_storage_delete_proto'
>>> kernel/bpf/cgroup.o: In function `__cgroup_bpf_run_filter_getsockopt':
>>> (.text+0x2a1f): undefined reference to `lock_sock_nested'
>>> (.text+0x2ca2): undefined reference to `release_sock'
>>> kernel/bpf/cgroup.o: In function `__cgroup_bpf_run_filter_setsockopt':
>>> (.text+0x3006): undefined reference to `lock_sock_nested'
>>> (.text+0x32bb): undefined reference to `release_sock'
>>>
>>> Add CONFIG_NET dependency to fix this.
>> Can you share the config? Do I understand correctly that you have
>> CONFIG_NET=n and CONFIG_BPF=y? What parts of BPF do you expect to
>> work in this case?
>>
>> Less invasive fix would be something along the lines:
>>
>> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
>> index 76fa0076f20d..0a00eaca6fae 100644
>> --- a/kernel/bpf/cgroup.c
>> +++ b/kernel/bpf/cgroup.c
>> @@ -939,6 +939,7 @@ int __cgroup_bpf_run_filter_sysctl(struct ctl_table_header *head,
>> }
>> EXPORT_SYMBOL(__cgroup_bpf_run_filter_sysctl);
>>
>> +#ifdef CONFIG_NET
>> static bool __cgroup_bpf_prog_array_is_empty(struct cgroup *cgrp,
>> enum bpf_attach_type attach_type)
>> {
>> @@ -1120,6 +1121,7 @@ int __cgroup_bpf_run_filter_getsockopt(struct sock *sk, int level,
>> return ret;
>> }
>> EXPORT_SYMBOL(__cgroup_bpf_run_filter_getsockopt);
>> +#endif
>>
>> static ssize_t sysctl_cpy_dir(const struct ctl_dir *dir, char **bufp,
>> size_t *lenp)
>> @@ -1386,10 +1388,12 @@ static const struct bpf_func_proto *
>> cg_sockopt_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>> {
>> switch (func_id) {
>> +#ifdef CONFIG_NET
>> case BPF_FUNC_sk_storage_get:
>> return &bpf_sk_storage_get_proto;
>> case BPF_FUNC_sk_storage_delete:
>> return &bpf_sk_storage_delete_proto;
>> +#endif
>> #ifdef CONFIG_INET
>> case BPF_FUNC_tcp_sock:
>> return &bpf_tcp_sock_proto;
>
> Ah. Just send another email without checking inbox.
> Looks like the above change is preferred.
> YueHaibing, could you make change and resubmit your patch?
Sure, I will test and resubmit it.
>
>>
>>> Reported-by: Hulk Robot <hulkci@huawei.com>
>>> Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>> ---
>>> init/Kconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/init/Kconfig b/init/Kconfig
>>> index e2e51b5..341cf2a 100644
>>> --- a/init/Kconfig
>>> +++ b/init/Kconfig
>>> @@ -998,6 +998,7 @@ config CGROUP_PERF
>>> config CGROUP_BPF
>>> bool "Support for eBPF programs attached to cgroups"
>>> depends on BPF_SYSCALL
>>> + depends on NET
>>> select SOCK_CGROUP_DATA
>>> help
>>> Allow attaching eBPF programs to a cgroup using the bpf(2)
>>> --
>>> 2.7.4
>>>
>>>
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Chris Chiu @ 2019-07-03 3:25 UTC (permalink / raw)
To: Jes Sorensen
Cc: Kalle Valo, David Miller, linux-wireless, netdev, Linux Kernel,
Linux Upstreaming Team
In-Reply-To: <31f59db2-0e04-447b-48f8-66ea53ebfa7d@gmail.com>
On Tue, Jul 2, 2019 at 8:44 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>
> On 6/27/19 5:52 AM, Chris Chiu wrote:
> > The WiFi tx power of RTL8723BU is extremely low after booting. So
> > the WiFi scan gives very limited AP list and it always fails to
> > connect to the selected AP. This module only supports 1x1 antenna
> > and the antenna is switched to bluetooth due to some incorrect
> > register settings.
> >
> > This commit hand over the antenna control to PTA, the wifi signal
> > will be back to normal and the bluetooth scan can also work at the
> > same time. However, the btcoexist still needs to be handled under
> > different circumstances. If there's a BT connection established,
> > the wifi still fails to connect until disconneting the BT.
> >
> > Signed-off-by: Chris Chiu <chiu@endlessm.com>
> > ---
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 9 ++++++---
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
> > 2 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > index 3adb1d3d47ac..6c3c70d93ac1 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> > /*
> > * WLAN action by PTA
> > */
> > - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
> > + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
> >
> > /*
> > * BT select S0/S1 controlled by WiFi
> > @@ -1568,9 +1568,12 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> > rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
> >
> > /*
> > - * 0x280, 0x00, 0x200, 0x80 - not clear
> > + * Different settings per different antenna position.
> > + * Antenna switch to BT: 0x280, 0x00 (inverse)
> > + * Antenna switch to WiFi: 0x0, 0x280 (inverse)
> > + * Antenna controlled by PTA: 0x200, 0x80 (inverse)
> > */
> > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
> >
> > /*
> > * Software control, antenna at WiFi side
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > index 8136e268b4e6..87b2179a769e 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > @@ -3891,12 +3891,13 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
> >
> > /* Check if MAC is already powered on */
> > val8 = rtl8xxxu_read8(priv, REG_CR);
> > + val16 = rtl8xxxu_read16(priv, REG_SYS_CLKR);
> >
> > /*
> > * Fix 92DU-VC S3 hang with the reason is that secondary mac is not
> > * initialized. First MAC returns 0xea, second MAC returns 0x00
> > */
> > - if (val8 == 0xea)
> > + if (val8 == 0xea || !(val16 & BIT(11)))
> > macpower = false;
> > else
> > macpower = true;
>
> This part I would like to ask you take a good look at the other chips to
> make sure you don't break support for 8192cu, 8723au, 8188eu with this.
>
> Cheers,
> Jes
I checked the vendor code of 8192cu and 8188eu, they don't have this part
of code to check the REG_CR before power on sequence. I can only find
similar code in rtl8723be.
if (tmp_u1b != 0 && tmp_u1b !=0xea)
rtlhal->mac_func_enable = true;
By definition, the BIT(11) of REG_SYS_CLKR in rtl8xxxu_regs.h is
SYS_CLK_MAC_CLK_ENABLE. It seems to make sense to check this value
for macpower no matter what chip it is. I think I can make it more
self-expressive
as down below.
if (val8 == 0xea || !(val16 & SYS_CLK_MAC_CLK_ENABLE))
And per the comment, this code is for 92DU-VC S3 hang problem and I think an
OR check for SYS_CLK_MAC_CLK_ENABLE is still safe for this.
Chris
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/8] bpf: TCP RTT sock_ops bpf callback
From: Lawrence Brakmo @ 2019-07-03 3:04 UTC (permalink / raw)
To: Y Song, Stanislav Fomichev
Cc: netdev, bpf, David Miller, Alexei Starovoitov, Daniel Borkmann,
Eric Dumazet, Priyaranjan Jha, Yuchung Cheng,
Soheil Hassas Yeganeh
In-Reply-To: <CAH3MdRXz-AHMuNQNWhnrxCrZhD9xKi44HiQdMh99R1FGaFYnhA@mail.gmail.com>
On 7/2/19, 10:55 AM, "netdev-owner@vger.kernel.org on behalf of Y Song" <netdev-owner@vger.kernel.org on behalf of ys114321@gmail.com> wrote:
On Tue, Jul 2, 2019 at 9:14 AM Stanislav Fomichev <sdf@google.com> wrote:
>
> Congestion control team would like to have a periodic callback to
> track some TCP statistics. Let's add a sock_ops callback that can be
> selectively enabled on a socket by socket basis and is executed for
> every RTT. BPF program frequency can be further controlled by calling
> bpf_ktime_get_ns and bailing out early.
>
> I run neper tcp_stream and tcp_rr tests with the sample program
> from the last patch and didn't observe any noticeable performance
> difference.
>
> v2:
> * add a comment about second accept() in selftest (Yonghong Song)
> * refer to tcp_bpf.readme in sample program (Yonghong Song)
>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Priyaranjan Jha <priyarjha@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
Ack for the whole series.
Acked-by: Yonghong Song <yhs@fb.com>
Thanks, this is a very nice feature!
Ack for the whole series.
Acked-by: Lawrence Brakmo <brakmo@fb.com>
>
> Stanislav Fomichev (8):
> bpf: add BPF_CGROUP_SOCK_OPS callback that is executed on every RTT
> bpf: split shared bpf_tcp_sock and bpf_sock_ops implementation
> bpf: add dsack_dups/delivered{,_ce} to bpf_tcp_sock
> bpf: add icsk_retransmits to bpf_tcp_sock
> bpf/tools: sync bpf.h
> selftests/bpf: test BPF_SOCK_OPS_RTT_CB
> samples/bpf: add sample program that periodically dumps TCP stats
> samples/bpf: fix tcp_bpf.readme detach command
>
> include/net/tcp.h | 8 +
> include/uapi/linux/bpf.h | 12 +-
> net/core/filter.c | 207 +++++++++++-----
> net/ipv4/tcp_input.c | 4 +
> samples/bpf/Makefile | 1 +
> samples/bpf/tcp_bpf.readme | 2 +-
> samples/bpf/tcp_dumpstats_kern.c | 68 ++++++
> tools/include/uapi/linux/bpf.h | 12 +-
> tools/testing/selftests/bpf/Makefile | 3 +-
> tools/testing/selftests/bpf/progs/tcp_rtt.c | 61 +++++
> tools/testing/selftests/bpf/test_tcp_rtt.c | 254 ++++++++++++++++++++
> 11 files changed, 574 insertions(+), 58 deletions(-)
> create mode 100644 samples/bpf/tcp_dumpstats_kern.c
> create mode 100644 tools/testing/selftests/bpf/progs/tcp_rtt.c
> create mode 100644 tools/testing/selftests/bpf/test_tcp_rtt.c
>
> --
> 2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply
* RE: [PATCH net-next 1/1] devlink: Add APIs to publish/unpublish the port parameters.
From: Sudarsana Reddy Kalluru @ 2019-07-03 2:46 UTC (permalink / raw)
To: Parav Pandit, Andrew Lunn
Cc: davem@davemloft.net, netdev@vger.kernel.org, Michal Kalderon,
Ariel Elior, jiri@resnulli.us
In-Reply-To: <AM0PR05MB4866CBFB93C42453068376DED1F80@AM0PR05MB4866.eurprd05.prod.outlook.com>
> -----Original Message-----
> From: Parav Pandit <parav@mellanox.com>
> Sent: Tuesday, July 2, 2019 10:49 PM
> To: Andrew Lunn <andrew@lunn.ch>
> Cc: Sudarsana Reddy Kalluru <skalluru@marvell.com>;
> davem@davemloft.net; netdev@vger.kernel.org; Michal Kalderon
> <mkalderon@marvell.com>; Ariel Elior <aelior@marvell.com>;
> jiri@resnulli.us
> Subject: [EXT] RE: [PATCH net-next 1/1] devlink: Add APIs to
> publish/unpublish the port parameters.
>
> External Email
>
> ----------------------------------------------------------------------
>
>
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Tuesday, July 2, 2019 10:19 PM
> > To: Parav Pandit <parav@mellanox.com>
> > Cc: Sudarsana Reddy Kalluru <skalluru@marvell.com>;
> > davem@davemloft.net; netdev@vger.kernel.org;
> mkalderon@marvell.com;
> > aelior@marvell.com; jiri@resnulli.us
> > Subject: Re: [PATCH net-next 1/1] devlink: Add APIs to
> > publish/unpublish the port parameters.
> >
> > > A vendor driver calling these APIs is needed at minimum.
> >
> > Not a vendor driver, but a mainline driver.
> >
> My apologies for terminology.
> I meant to say that a NIC/hw driver from the kernel tree that created the
> devlink port should call this API (as user) in the patch.
> You said it rightly below. Thanks.
>
> > But yes, a new API should not be added without at least one user.
> >
> > Andrew
Thanks a lot for your reviews.
Marvell NIC driver has a requirement to support the display/configuration of device attributes. Sent the proposed changes with following 'subject line',
[PATCH net-next 4/4] qed: Add devlink support for configuration attributes.
Have received a comment (from community) suggesting to move some of the attributes to devlink-port interface, which
requires the proposed APIs.
Will update the commit message and send it with the Marvel driver patch series which use this functionality.
^ permalink raw reply
* [PATCH net-next 3/3] tc-testing: introduce scapyPlugin for basic traffic
From: Lucas Bates @ 2019-07-03 2:41 UTC (permalink / raw)
To: davem
Cc: netdev, jhs, xiyou.wangcong, jiri, mleitner, vladbu, dcaratti,
kernel, Lucas Bates
In-Reply-To: <1562121681-9365-1-git-send-email-lucasb@mojatatu.com>
The scapyPlugin allows for simple traffic generation in tdc to
test various tc features. It was tested with scapy v2.4.2, but
should work with any successive version.
In order to use the plugin's functionality, scapy must be
installed. This can be done with:
pip3 install scapy
or to install 2.4.2:
pip3 install scapy==2.4.2
If the plugin is unable to import the scapy module, it will
terminate the tdc run.
The plugin makes use of a new key in the test case data, 'scapy'.
This block contains three other elements: 'iface', 'count', and
'packet':
"scapy": {
"iface": "$DEV0",
"count": 1,
"packet": "Ether(type=0x800)/IP(src='16.61.16.61')/ICMP()"
},
* iface is the name of the device on the host machine from which
the packet(s) will be sent. Values contained within tdc_config.py's
NAMES dict can be used here - this is useful if paired with
nsPlugin
* count is the number of copies of this packet to be sent
* packet is a string detailing the different layers of the packet
to be sent. If a property isn't explicitly set, scapy will set
default values for you.
Layers in the packet info are separated by slashes. For info about
common TCP and IP properties, see:
https://blogs.sans.org/pen-testing/files/2016/04/ScapyCheatSheet_v0.2.pdf
Caution is advised when running tests using the scapy functionality,
since the plugin blindly sends the packet as defined in the test case
data.
See creating-testcases/scapy-example.json for sample test cases;
the first test is intended to pass while the second is intended to
fail. Consider using the matchJSON functionality for verification
when using scapy.
---
.../creating-testcases/scapy-example.json | 98 ++++++++++++++++++++++
.../selftests/tc-testing/plugin-lib/scapyPlugin.py | 51 +++++++++++
2 files changed, 149 insertions(+)
create mode 100644 tools/testing/selftests/tc-testing/creating-testcases/scapy-example.json
create mode 100644 tools/testing/selftests/tc-testing/plugin-lib/scapyPlugin.py
diff --git a/tools/testing/selftests/tc-testing/creating-testcases/scapy-example.json b/tools/testing/selftests/tc-testing/creating-testcases/scapy-example.json
new file mode 100644
index 0000000..5a9377b
--- /dev/null
+++ b/tools/testing/selftests/tc-testing/creating-testcases/scapy-example.json
@@ -0,0 +1,98 @@
+[
+ {
+ "id": "b1e9",
+ "name": "Test matching of source IP",
+ "category": [
+ "actions",
+ "scapy"
+ ],
+ "plugins": {
+ "requires": [
+ "nsPlugin",
+ "scapyPlugin"
+ ]
+ },
+ "setup": [
+ [
+ "$TC qdisc del dev $DEV1 ingress",
+ 0,
+ 1,
+ 2,
+ 255
+ ],
+ "$TC qdisc add dev $DEV1 ingress"
+ ],
+ "cmdUnderTest": "$TC filter add dev $DEV1 parent ffff: prio 3 protocol ip flower src_ip 16.61.16.61 flowid 1:1 action ok",
+ "scapy": {
+ "iface": "$DEV0",
+ "count": 1,
+ "packet": "Ether(type=0x800)/IP(src='16.61.16.61')/ICMP()"
+ },
+ "expExitCode": "0",
+ "verifyCmd": "$TC -s -j filter ls dev $DEV1 ingress prio 3",
+ "matchJSON": [
+ {
+ "path": [
+ 1,
+ "options",
+ "actions",
+ 0,
+ "stats",
+ "packets"
+ ],
+ "value": 1
+ }
+ ],
+ "teardown": [
+ "$TC qdisc del dev $DEV1 ingress"
+ ]
+ },
+ {
+ "id": "e9c4",
+ "name": "Test matching of source IP with wrong count",
+ "category": [
+ "actions",
+ "scapy"
+ ],
+ "plugins": {
+ "requires": [
+ "nsPlugin",
+ "scapyPlugin"
+ ]
+ },
+ "setup": [
+ [
+ "$TC qdisc del dev $DEV1 ingress",
+ 0,
+ 1,
+ 2,
+ 255
+ ],
+ "$TC qdisc add dev $DEV1 ingress"
+ ],
+ "cmdUnderTest": "$TC filter add dev $DEV1 parent ffff: prio 3 protocol ip flower src_ip 16.61.16.61 flowid 1:1 action ok",
+ "scapy": {
+ "iface": "$DEV0",
+ "count": 3,
+ "packet": "Ether(type=0x800)/IP(src='16.61.16.61')/ICMP()"
+ },
+ "expExitCode": "0",
+ "verifyCmd": "$TC -s -j filter ls dev $DEV1 parent ffff:",
+ "matchJSON": [
+ {
+ "path": [
+ 1,
+ "options",
+ "actions",
+ 0,
+ "stats",
+ "packets"
+ ],
+ "value": 1
+ }
+ ],
+ "teardown": [
+ "$TC qdisc del dev $DEV1 ingress"
+ ]
+ }
+]
diff --git a/tools/testing/selftests/tc-testing/plugin-lib/scapyPlugin.py b/tools/testing/selftests/tc-testing/plugin-lib/scapyPlugin.py
new file mode 100644
index 0000000..db57916
--- /dev/null
+++ b/tools/testing/selftests/tc-testing/plugin-lib/scapyPlugin.py
@@ -0,0 +1,51 @@
+#!/usr/bin/env python3
+
+import os
+import signal
+from string import Template
+import subprocess
+import time
+from TdcPlugin import TdcPlugin
+
+from tdc_config import *
+
+try:
+ from scapy.all import *
+except ImportError:
+ print("Unable to import the scapy python module.")
+ print("\nIf not already installed, you may do so with:")
+ print("\t\tpip3 install scapy==2.4.2")
+ exit(1)
+
+class SubPlugin(TdcPlugin):
+ def __init__(self):
+ self.sub_class = 'scapy/SubPlugin'
+ super().__init__()
+
+ def post_execute(self):
+ if 'scapy' not in self.args.caseinfo:
+ if self.args.verbose:
+ print('{}.post_execute: no scapy info in test case'.format(self.sub_class))
+ return
+
+ # Check for required fields
+ scapyinfo = self.args.caseinfo['scapy']
+ scapy_keys = ['iface', 'count', 'packet']
+ missing_keys = []
+ keyfail = False
+ for k in scapy_keys:
+ if k not in scapyinfo:
+ keyfail = True
+ missing_keys.add(k)
+ if keyfail:
+ print('{}: Scapy block present in the test, but is missing info:'
+ .format(self.sub_class))
+ print('{}'.format(missing_keys))
+
+ pkt = eval(scapyinfo['packet'])
+ if '$' in scapyinfo['iface']:
+ tpl = Template(scapyinfo['iface'])
+ scapyinfo['iface'] = tpl.safe_substitute(NAMES)
+ for count in range(scapyinfo['count']):
+ sendp(pkt, iface=scapyinfo['iface'])
+
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/3] tc-testing: Allow tdc plugins to see test case data
From: Lucas Bates @ 2019-07-03 2:41 UTC (permalink / raw)
To: davem
Cc: netdev, jhs, xiyou.wangcong, jiri, mleitner, vladbu, dcaratti,
kernel, Lucas Bates
In-Reply-To: <1562121681-9365-1-git-send-email-lucasb@mojatatu.com>
Instead of only passing the test case name and ID, pass the
entire current test case down to the plugins. This change
allows plugins to start accepting commands and directives
from the test cases themselves, for greater flexibility
in testing.
---
tools/testing/selftests/tc-testing/TdcPlugin.py | 5 ++---
tools/testing/selftests/tc-testing/tdc.py | 10 +++++-----
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/tc-testing/TdcPlugin.py b/tools/testing/selftests/tc-testing/TdcPlugin.py
index b980a56..79f3ca8 100644
--- a/tools/testing/selftests/tc-testing/TdcPlugin.py
+++ b/tools/testing/selftests/tc-testing/TdcPlugin.py
@@ -18,12 +18,11 @@ class TdcPlugin:
if self.args.verbose > 1:
print(' -- {}.post_suite'.format(self.sub_class))
- def pre_case(self, testid, test_name, test_skip):
+ def pre_case(self, caseinfo, test_skip):
'''run commands before test_runner does one test'''
if self.args.verbose > 1:
print(' -- {}.pre_case'.format(self.sub_class))
- self.args.testid = testid
- self.args.test_name = test_name
+ self.args.caseinfo = caseinfo
self.args.test_skip = test_skip
def post_case(self):
diff --git a/tools/testing/selftests/tc-testing/tdc.py b/tools/testing/selftests/tc-testing/tdc.py
index 1afa803..de7da9a 100755
--- a/tools/testing/selftests/tc-testing/tdc.py
+++ b/tools/testing/selftests/tc-testing/tdc.py
@@ -126,15 +126,15 @@ class PluginMgr:
for pgn_inst in reversed(self.plugin_instances):
pgn_inst.post_suite(index)
- def call_pre_case(self, testid, test_name, *, test_skip=False):
+ def call_pre_case(self, caseinfo, *, test_skip=False):
for pgn_inst in self.plugin_instances:
try:
- pgn_inst.pre_case(testid, test_name, test_skip)
+ pgn_inst.pre_case(caseinfo, test_skip)
except Exception as ee:
print('exception {} in call to pre_case for {} plugin'.
format(ee, pgn_inst.__class__))
print('test_ordinal is {}'.format(test_ordinal))
- print('testid is {}'.format(testid))
+ print('testid is {}'.format(caseinfo['id']))
raise
def call_post_case(self):
@@ -379,14 +379,14 @@ def run_one_test(pm, args, index, tidx):
res = TestResult(tidx['id'], tidx['name'])
res.set_result(ResultState.skip)
res.set_errormsg('Test case designated as skipped.')
- pm.call_pre_case(tidx['id'], tidx['name'], test_skip=True)
+ pm.call_pre_case(tidx, test_skip=True)
pm.call_post_execute()
return res
# populate NAMES with TESTID for this test
NAMES['TESTID'] = tidx['id']
- pm.call_pre_case(tidx['id'], tidx['name'])
+ pm.call_pre_case(tidx)
prepare_env(args, pm, 'setup', "-----> prepare stage", tidx["setup"])
if (args.verbose > 0):
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox