* [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel
From: Rahul Lakkireddy @ 2018-03-24 10:56 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: indranil-ut6Up61K2wZBDgjK7y7TUQ, nirranjan-ut6Up61K2wZBDgjK7y7TUQ,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
ganeshgr-ut6Up61K2wZBDgjK7y7TUQ, Rahul Lakkireddy,
ebiederm-aS9lmoZGLiVWk0Htik3J/w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn
In-Reply-To: <cover.1521888444.git.rahul.lakkireddy-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Add a new module crashdd that exports the /sys/kernel/crashdd/
directory in second kernel, containing collected hardware/firmware
dumps.
The sequence of actions done by device drivers to append their device
specific hardware/firmware logs to /sys/kernel/crashdd/ directory are
as follows:
1. During probe (before hardware is initialized), device drivers
register to the crashdd module (via crashdd_add_dump()), with
callback function, along with buffer size and log name needed for
firmware/hardware log collection.
2. Crashdd creates a driver's directory under
/sys/kernel/crashdd/<driver>. Then, it allocates the buffer with
requested size and invokes the device driver's registered callback
function.
3. Device driver collects all hardware/firmware logs into the buffer
and returns control back to crashdd.
4. Crashdd exposes the buffer as a binary file via
/sys/kernel/crashdd/<driver>/<dump_file>.
Suggested-by: Eric Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>.
Suggested-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Ganesh Goudar <ganeshgr-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
---
v2:
- Added ABI Documentation for crashdd.
- Directly use octal permission instead of macro.
Changes since rfc v2:
- Moved exporting crashdd from procfs to sysfs. Suggested by
Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
- Moved code from fs/proc/crashdd.c to fs/crashdd/ directory.
- Replaced all proc API with sysfs API and updated comments.
- Calling driver callback before creating the binary file under
crashdd sysfs.
- Changed binary dump file permission from S_IRUSR to S_IRUGO.
- Changed module name from CRASH_DRIVER_DUMP to CRASH_DEVICE_DUMP.
rfc v2:
- Collecting logs in 2nd kernel instead of during kernel panic.
Suggested by Eric Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>.
- Patch added in this series.
Documentation/ABI/testing/sysfs-kernel-crashdd | 34 ++++
fs/Kconfig | 1 +
fs/Makefile | 1 +
fs/crashdd/Kconfig | 10 ++
fs/crashdd/Makefile | 3 +
fs/crashdd/crashdd.c | 233 +++++++++++++++++++++++++
fs/crashdd/crashdd_internal.h | 24 +++
include/linux/crashdd.h | 24 +++
8 files changed, 330 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-crashdd
create mode 100644 fs/crashdd/Kconfig
create mode 100644 fs/crashdd/Makefile
create mode 100644 fs/crashdd/crashdd.c
create mode 100644 fs/crashdd/crashdd_internal.h
create mode 100644 include/linux/crashdd.h
diff --git a/Documentation/ABI/testing/sysfs-kernel-crashdd b/Documentation/ABI/testing/sysfs-kernel-crashdd
new file mode 100644
index 000000000000..1f6b9e27bf2e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-crashdd
@@ -0,0 +1,34 @@
+What: /sys/kernel/crashdd
+Date: March 2018
+KernelVersion: 4.16
+Contact: Rahul Lakkireddy <rahul.lakkireddy-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
+ Ganesh Goudar <ganeshgr-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
+Description:
+ Snapshot of underlying hardware/firmware state (like register
+ dump, firmware logs, adapter memory, etc.), at the time of
+ kernel panic will be very helpful while debugging the culprit
+ device driver. Thus, Crash Device Dump (crashdd) module exports
+ API to allow device drivers to collect the device specific
+ snapshot of their hardware or firmware in crash recovery kernel.
+ The collected dumps will be exported under /sys/kernel/crashdd/
+ directory in crash recovery kernel.
+
+ The sequence of actions done by device drivers to append their
+ device specific hardware/firmware logs to /sys/kernel/crashdd/
+ directory are as follows:
+
+ 1. During probe (before hardware is initialized), device drivers
+ register to the crashdd module (via crashdd_add_dump()), with
+ callback function, along with buffer size and log name needed for
+ firmware/hardware log collection.
+
+ 2. Crashdd creates a driver's directory under
+ /sys/kernel/crashdd/<driver>. Then, it allocates the buffer
+ with requested size and invokes the device driver's registered
+ callback function.
+
+ 3. Device driver collects all hardware/firmware logs into the buffer
+ and returns control back to crashdd.
+
+ 4. Crashdd exposes the buffer as a file via
+ /sys/kernel/crashdd/<driver>/<dump_file>.
diff --git a/fs/Kconfig b/fs/Kconfig
index bc821a86d965..aae1c55a7dad 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -208,6 +208,7 @@ config ARCH_HAS_GIGANTIC_PAGE
source "fs/configfs/Kconfig"
source "fs/efivarfs/Kconfig"
+source "fs/crashdd/Kconfig"
endmenu
diff --git a/fs/Makefile b/fs/Makefile
index add789ea270a..ff398a44f611 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -128,3 +128,4 @@ obj-y += exofs/ # Multiple modules
obj-$(CONFIG_CEPH_FS) += ceph/
obj-$(CONFIG_PSTORE) += pstore/
obj-$(CONFIG_EFIVAR_FS) += efivarfs/
+obj-$(CONFIG_CRASH_DEVICE_DUMP) += crashdd/
diff --git a/fs/crashdd/Kconfig b/fs/crashdd/Kconfig
new file mode 100644
index 000000000000..5db9c7c98c17
--- /dev/null
+++ b/fs/crashdd/Kconfig
@@ -0,0 +1,10 @@
+config CRASH_DEVICE_DUMP
+ bool "Crash Kernel Device Hardware/Firmware Logs"
+ depends on SYSFS && CRASH_DUMP
+ default y
+ ---help---
+ Device drivers can collect the device specific snapshot of
+ their hardware or firmware before they are initialized in
+ crash recovery kernel. If you say Y here a tree of device
+ specific dumps will be made available under /sys/kernel/crashdd/
+ directory.
diff --git a/fs/crashdd/Makefile b/fs/crashdd/Makefile
new file mode 100644
index 000000000000..8dbf946c0ea4
--- /dev/null
+++ b/fs/crashdd/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-y := crashdd.o
diff --git a/fs/crashdd/crashdd.c b/fs/crashdd/crashdd.c
new file mode 100644
index 000000000000..996ba926578b
--- /dev/null
+++ b/fs/crashdd/crashdd.c
@@ -0,0 +1,233 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018 Chelsio Communications, Inc. All rights reserved. */
+
+#include <linux/vmalloc.h>
+#include <linux/crash_dump.h>
+#include <linux/crashdd.h>
+
+#include "crashdd_internal.h"
+
+static LIST_HEAD(crashdd_list);
+static DEFINE_MUTEX(crashdd_mutex);
+
+static struct kobject *crashdd_kobj;
+
+static ssize_t crashdd_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t fpos, size_t count)
+{
+ struct crashdd_dump_node *dump = bin_attr->private;
+
+ memcpy(buf, dump->buf + fpos, count);
+ return count;
+}
+
+static struct kobject *crashdd_mkdir(const char *name)
+{
+ return kobject_create_and_add(name, crashdd_kobj);
+}
+
+static int crashdd_add_file(struct kobject *kobj, const char *name,
+ struct crashdd_dump_node *dump)
+{
+ dump->bin_attr.attr.name = name;
+ dump->bin_attr.attr.mode = 0444;
+ dump->bin_attr.size = dump->size;
+ dump->bin_attr.read = crashdd_read;
+ dump->bin_attr.private = dump;
+
+ return sysfs_create_bin_file(kobj, &dump->bin_attr);
+}
+
+static void crashdd_rmdir(struct kobject *kobj)
+{
+ kobject_put(kobj);
+}
+
+/**
+ * crashdd_init_driver - create a sysfs driver entry.
+ * @name: Name of the directory.
+ *
+ * Creates a directory under /sys/kernel/crashdd/ with @name. Allocates
+ * and saves the sysfs entry. The sysfs entry is added to the global
+ * list and then returned to the caller. On failure, returns NULL.
+ */
+static struct crashdd_driver_node *crashdd_init_driver(const char *name)
+{
+ struct crashdd_driver_node *node;
+
+ node = vzalloc(sizeof(*node));
+ if (!node)
+ return NULL;
+
+ /* Create a driver's directory under /sys/kernel/crashdd/ */
+ node->kobj = crashdd_mkdir(name);
+ if (!node->kobj) {
+ vfree(node);
+ return NULL;
+ }
+
+ atomic_set(&node->refcnt, 1);
+
+ /* Initialize the list of dumps that go under this driver's
+ * directory.
+ */
+ INIT_LIST_HEAD(&node->dump_list);
+
+ /* Add the driver's entry to global list */
+ mutex_lock(&crashdd_mutex);
+ list_add_tail(&node->list, &crashdd_list);
+ mutex_unlock(&crashdd_mutex);
+
+ return node;
+}
+
+/**
+ * crashdd_get_driver - get an exisiting sysfs driver entry.
+ * @name: Name of the directory.
+ *
+ * Searches and fetches a sysfs entry having @name. If @name is
+ * found, then the reference count is incremented and the entry
+ * is returned. If @name is not found, NULL is returned.
+ */
+static struct crashdd_driver_node *crashdd_get_driver(const char *name)
+{
+ struct crashdd_driver_node *node;
+ int found = 0;
+
+ /* Search for an existing driver sysfs entry having @name */
+ mutex_lock(&crashdd_mutex);
+ list_for_each_entry(node, &crashdd_list, list) {
+ if (!strcmp(node->kobj->name, name)) {
+ atomic_inc(&node->refcnt);
+ found = 1;
+ break;
+ }
+ }
+ mutex_unlock(&crashdd_mutex);
+
+ if (found)
+ return node;
+
+ /* No driver with @name found */
+ return NULL;
+}
+
+/**
+ * crashdd_put_driver - put an exisiting sysfs driver entry.
+ * @node: driver sysfs entry.
+ *
+ * Decrement @node reference count. If there are no dumps left under it,
+ * delete the sysfs directory and remove it from the global list.
+ */
+static void crashdd_put_driver(struct crashdd_driver_node *node)
+{
+ mutex_lock(&crashdd_mutex);
+ if (atomic_dec_and_test(&node->refcnt)) {
+ /* Delete @node driver entry if it has no dumps under it */
+ crashdd_rmdir(node->kobj);
+ list_del(&node->list);
+ }
+ mutex_unlock(&crashdd_mutex);
+}
+
+/**
+ * crashdd_add_dump - Allocate a directory under /sys/kernel/crashdd/ and
+ * add the dump to it.
+ * @driver_name: directory name under which the dump should be added.
+ * @data: dump info.
+ *
+ * Search for /sys/kernel/crashdd/<@driver_name>/ directory. If not found,
+ * allocate a new directory under /sys/kernel/crashdd/ with @driver_name.
+ * Allocate the dump file's context and invoke the calling driver's dump
+ * collect routine. Once collection is done, add the dump under
+ * /sys/kernel/crashdd/<@driver_name>/ directory.
+ */
+int crashdd_add_dump(const char *driver_name, struct crashdd_data *data)
+{
+ struct crashdd_driver_node *node;
+ struct crashdd_dump_node *dump;
+ void *buf = NULL;
+ int ret;
+
+ if (!driver_name || !strlen(driver_name) ||
+ !data || !strlen(data->name) ||
+ !data->crashdd_callback || !data->size)
+ return -EINVAL;
+
+ /* Get a driver sysfs entry with specified name. */
+ node = crashdd_get_driver(driver_name);
+ if (!node) {
+ /* No driver sysfs entry found with specified name.
+ * So create a new one
+ */
+ node = crashdd_init_driver(driver_name);
+ if (!node)
+ return -ENOMEM;
+ }
+
+ dump = vzalloc(sizeof(*dump));
+ if (!dump) {
+ ret = -ENOMEM;
+ goto out_err;
+ }
+
+ /* Allocate buffer for driver's to write their dumps */
+ buf = vzalloc(data->size);
+ if (!buf) {
+ ret = -ENOMEM;
+ goto out_err;
+ }
+
+ /* Invoke the driver's dump collection routing */
+ ret = data->crashdd_callback(data, buf);
+ if (ret)
+ goto out_err;
+
+ dump->buf = buf;
+ dump->size = data->size;
+
+ /* Add a binary file under /sys/kernel/crashdd/@driver_name/ */
+ ret = crashdd_add_file(node->kobj, data->name, dump);
+ if (ret)
+ goto out_err;
+
+ /* Add the dump to driver sysfs list */
+ mutex_lock(&crashdd_mutex);
+ list_add_tail(&dump->list, &node->dump_list);
+ atomic_inc(&node->refcnt);
+ mutex_unlock(&crashdd_mutex);
+
+ /* Return back the driver sysfs reference */
+ crashdd_put_driver(node);
+ return 0;
+
+out_err:
+ if (buf)
+ vfree(buf);
+
+ if (dump)
+ vfree(dump);
+
+ crashdd_put_driver(node);
+ return ret;
+}
+EXPORT_SYMBOL(crashdd_add_dump);
+
+/* Init function for crash device dump module. */
+static int __init crashdd_init(void)
+{
+ /*
+ * Only export this directory in 2nd kernel.
+ */
+ if (!is_kdump_kernel())
+ return 0;
+
+ /* Create /sys/kernel/crashdd/ directory */
+ crashdd_kobj = kobject_create_and_add("crashdd", kernel_kobj);
+ if (!crashdd_kobj)
+ return -ENOMEM;
+
+ return 0;
+}
+fs_initcall(crashdd_init);
diff --git a/fs/crashdd/crashdd_internal.h b/fs/crashdd/crashdd_internal.h
new file mode 100644
index 000000000000..9162d1a4264b
--- /dev/null
+++ b/fs/crashdd/crashdd_internal.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018 Chelsio Communications, Inc. All rights reserved. */
+
+#ifndef CRASH_DEVICE_DUMP_INTERNAL_H
+#define CRASH_DEVICE_DUMP_INTERNAL_H
+
+/* Binary dump file's context internal to crashdd */
+struct crashdd_dump_node {
+ /* Pointer to list of dumps under the driver sysfs entry */
+ struct list_head list;
+ void *buf; /* Buffer containing device's dump */
+ unsigned long size; /* Size of the buffer */
+ struct bin_attribute bin_attr; /* Binary dump file's attributes */
+};
+
+/* Driver sysfs entry internal to crashdd */
+struct crashdd_driver_node {
+ /* Pointer to global list of driver sysfs entries */
+ struct list_head list;
+ struct list_head dump_list; /* List of dumps under this driver */
+ atomic_t refcnt; /* Number of dumps under this directory */
+ struct kobject *kobj; /* Pointer to driver sysfs kobject */
+};
+#endif /* CRASH_DEVICE_DUMP_INTERNAL_H */
diff --git a/include/linux/crashdd.h b/include/linux/crashdd.h
new file mode 100644
index 000000000000..edaba8424019
--- /dev/null
+++ b/include/linux/crashdd.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018 Chelsio Communications, Inc. All rights reserved. */
+
+#ifndef CRASH_DEVICE_DUMP_H
+#define CRASH_DEVICE_DUMP_H
+
+/* Max dump name length */
+#define CRASHDD_NAME_LENGTH 32
+
+/* Device Dump information to be filled by drivers */
+struct crashdd_data {
+ char name[CRASHDD_NAME_LENGTH]; /* Unique name of the dump */
+ unsigned long size; /* Size of the dump */
+ /* Driver's registered callback to be invoked to collect dump */
+ int (*crashdd_callback)(struct crashdd_data *data, void *buf);
+};
+
+#ifdef CONFIG_CRASH_DEVICE_DUMP
+int crashdd_add_dump(const char *driver_name, struct crashdd_data *data);
+#else
+#define crashdd_add_dump(x, y) 0
+#endif /* CONFIG_CRASH_DEVICE_DUMP */
+
+#endif /* CRASH_DEVICE_DUMP_H */
--
2.14.1
^ permalink raw reply related
* [PATCH net-next v2 0/2] kernel: add support to collect hardware logs in crash recovery kernel
From: Rahul Lakkireddy @ 2018-03-24 10:56 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: indranil-ut6Up61K2wZBDgjK7y7TUQ, nirranjan-ut6Up61K2wZBDgjK7y7TUQ,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
ganeshgr-ut6Up61K2wZBDgjK7y7TUQ, Rahul Lakkireddy,
ebiederm-aS9lmoZGLiVWk0Htik3J/w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn
On production servers running variety of workloads over time, kernel
panic can happen sporadically after days or even months. It is
important to collect as much debug logs as possible to root cause
and fix the problem, that may not be easy to reproduce. Snapshot of
underlying hardware/firmware state (like register dump, firmware
logs, adapter memory, etc.), at the time of kernel panic will be very
helpful while debugging the culprit device driver.
This series of patches add new generic framework that enable device
drivers to collect device specific snapshot of the hardware/firmware
state of the underlying device in the crash recovery kernel. In crash
recovery kernel, the collected logs are exposed via /sys/kernel/crashdd/
directory, which is copied by user space scripts for post-analysis.
A kernel module crashdd is newly added. In crash recovery kernel,
crashdd exposes /sys/kernel/crashdd/ directory containing device
specific hardware/firmware logs.
The sequence of actions done by device drivers to append their device
specific hardware/firmware logs to /sys/kernel/crashdd/ directory are
as follows:
1. During probe (before hardware is initialized), device drivers
register to the crashdd module (via crashdd_add_dump()), with
callback function, along with buffer size and log name needed for
firmware/hardware log collection.
2. Crashdd creates a driver's directory under /sys/kernel/crashdd/<driver>.
Then, it allocates the buffer with requested size and invokes the
device driver's registered callback function.
3. Device driver collects all hardware/firmware logs into the buffer
and returns control back to crashdd.
4. Crashdd exposes the buffer as a file via
/sys/kernel/crashdd/<driver>/<dump_file>.
5. User space script (/usr/lib/kdump/kdump-lib-initramfs.sh) copies
the entire /sys/kernel/crashdd/ directory to /var/crash/ directory.
Patch 1 adds crashdd module to allow drivers to register callback to
collect the device specific hardware/firmware logs. The module also
exports /sys/kernel/crashdd/ directory containing the hardware/firmware
logs.
Patch 2 shows a cxgb4 driver example using the API to collect
hardware/firmware logs in crash recovery kernel, before hardware is
initialized. The logs for the devices are made available under
/sys/kernel/crashdd/cxgb4/ directory.
Thanks,
Rahul
RFC v1: https://lkml.org/lkml/2018/3/2/542
RFC v2: https://lkml.org/lkml/2018/3/16/326
---
v2:
- Added ABI Documentation for crashdd.
- Directly use octal permission instead of macro.
Changes since rfc v2:
- Moved exporting crashdd from procfs to sysfs. Suggested by
Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
- Moved code from fs/proc/crashdd.c to fs/crashdd/ directory.
- Replaced all proc API with sysfs API and updated comments.
- Calling driver callback before creating the binary file under
crashdd sysfs.
- Changed binary dump file permission from S_IRUSR to S_IRUGO.
- Changed module name from CRASH_DRIVER_DUMP to CRASH_DEVICE_DUMP.
rfc v2:
- Collecting logs in 2nd kernel instead of during kernel panic.
Suggested by Eric Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>.
- Added new crashdd module that exports /proc/crashdd/ containing
driver's registered hardware/firmware logs in patch 1.
- Replaced the API to allow drivers to register their hardware/firmware
log collect routine in crash recovery kernel in patch 1.
- Updated patch 2 to use the new API in patch 1.
Rahul Lakkireddy (2):
fs/crashdd: add API to collect hardware dump in second kernel
cxgb4: collect hardware dump in second kernel
Documentation/ABI/testing/sysfs-kernel-crashdd | 34 ++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 4 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c | 25 +++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.h | 3 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 12 ++
fs/Kconfig | 1 +
fs/Makefile | 1 +
fs/crashdd/Kconfig | 10 +
fs/crashdd/Makefile | 3 +
fs/crashdd/crashdd.c | 233 +++++++++++++++++++++++
fs/crashdd/crashdd_internal.h | 24 +++
include/linux/crashdd.h | 24 +++
12 files changed, 374 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-crashdd
create mode 100644 fs/crashdd/Kconfig
create mode 100644 fs/crashdd/Makefile
create mode 100644 fs/crashdd/crashdd.c
create mode 100644 fs/crashdd/crashdd_internal.h
create mode 100644 include/linux/crashdd.h
--
2.14.1
^ permalink raw reply
* Re: [net 7/8] net/mlx5e: Avoid using the ipv6 stub in the TC offload neigh update path
From: Sergei Shtylyov @ 2018-03-24 9:52 UTC (permalink / raw)
To: Saeed Mahameed, David S. Miller; +Cc: netdev, Or Gerlitz
In-Reply-To: <20180323220534.19353-8-saeedm@mellanox.com>
Hello!
On 3/24/2018 1:05 AM, Saeed Mahameed wrote:
> From: Or Gerlitz <ogerlitz@mellanox.com>
>
> Currently we use the global ipv6_stub var to access the ipv6 global
> nd table. This practice gets us to troubles when the stub is only partially
> set e.g when ipv6 is loaded under the disabled policy. In this case, as of commit
> 343d60aada5a "ipv6: change ipv6_stub_impl.ipv6_dst_lookup to take net argument"
The summary line must be enclosed in (""), not just "".
> the stub is not null, but stub->nd_tbl is and we crash.
>
> As we can access directly the ipv6 nd_tbl, the fix is just avoid the
As we can access the ipv6 nd_tbl directly, the fix is just to avoid the
> reference through the stub. There is one place in the code were we
^^^^
Where?
> issue ipv6 route lookup and keep doing it through the stub, but that
> mentioned commit makes sure we get -EAFNOSUPPORT from the stack.
>
> Fixes: 232c001398ae ('net/mlx5e: Add support to neighbour update flow')
("") here as well.
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> Reviewed-by: Aviv Heller <avivh@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH][next] batman-adv: don't pass a NULL hard_iface to batadv_hardif_put
From: Sven Eckelmann @ 2018-03-24 9:36 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Marek Lindner,
netdev-u79uwXL29TY76Z2rM5mHXA, Antonio Quartulli,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Colin King, David S . Miller
In-Reply-To: <20180323225350.7350-1-colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
On Freitag, 23. März 2018 23:53:50 CET Colin King wrote:
> From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
>
> In the case where hard_iface is NULL, the error path may pass a null
> pointer to batadv_hardif_put causing a null pointer dereference error.
> Avoid this by only calling the function if hard_iface not null.
>
> Detected by CoverityScan, CID#1466456 ("Explicit null dereferenced")
>
> Fixes: 53dd9a68ba68 ("batman-adv: add multicast flags netlink support")
> Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> ---
> net/batman-adv/multicast.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Queued up for David in batadv/net-next as d5863c47d725 [1]
Now I only have to find out why I didn't receive the mail about this
from coverity.
Thanks,
Sven
[1] https://git.open-mesh.org/linux-merge.git/commit/d5863c47d7255448ec01713cbdb4f94b370d86ad
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation
From: Jiri Pirko @ 2018-03-24 7:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, davem, idosch, jakub.kicinski, mlxsw, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher
In-Reply-To: <20180323152412.GC24361@lunn.ch>
Fri, Mar 23, 2018 at 04:24:12PM CET, andrew@lunn.ch wrote:
>On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote:
>> Fri, Mar 23, 2018 at 02:43:57PM CET, andrew@lunn.ch wrote:
>> >> I tested this for mlxsw and nfp. I have no way to test this on DSA hw,
>> >> I would really appretiate DSA guys to test this.
>> >
>> >Hi Jiri
>> >
>> >With the missing break added, i get:
>> >
>> >root@zii-devel-b:~# ./iproute2/devlink/devlink port
>> >mdio_bus/0.1:00/0: type eth netdev lan0 flavour physical number 0
>> >mdio_bus/0.1:00/1: type eth netdev lan1 flavour physical number 1
>> >mdio_bus/0.1:00/2: type eth netdev lan2 flavour physical number 2
>> >mdio_bus/0.1:00/3: type notset
>> >mdio_bus/0.1:00/4: type notset
>> >mdio_bus/0.1:00/5: type notset flavour dsa number 5
>> >mdio_bus/0.1:00/6: type notset flavour cpu number 6
>> >mdio_bus/0.2:00/0: type eth netdev lan3 flavour physical number 0
>> >mdio_bus/0.2:00/1: type eth netdev lan4 flavour physical number 1
>> >mdio_bus/0.2:00/2: type eth netdev lan5 flavour physical number 2
>> >mdio_bus/0.2:00/3: type notset
>> >mdio_bus/0.2:00/4: type notset
>> >mdio_bus/0.2:00/5: type notset flavour dsa number 5
>> >mdio_bus/0.2:00/6: type notset flavour dsa number 6
>> >mdio_bus/0.4:00/0: type eth netdev lan6 flavour physical number 0
>> >mdio_bus/0.4:00/1: type eth netdev lan7 flavour physical number 1
>> >mdio_bus/0.4:00/2: type eth netdev lan8 flavour physical number 2
>> >mdio_bus/0.4:00/3: type eth netdev optical3 flavour physical number 3
>> >mdio_bus/0.4:00/4: type eth netdev optical4 flavour physical number 4
>> >mdio_bus/0.4:00/5: type notset
>> >mdio_bus/0.4:00/6: type notset
>> >mdio_bus/0.4:00/7: type notset
>> >mdio_bus/0.4:00/8: type notset
>> >mdio_bus/0.4:00/9: type notset flavour dsa number 9
>
>> That is basically front panel number for physical ports.
>
>You cannot make that assumption. As you can see here, we have 3 ports
>with the number 0.
>
>Look at clearfog, armada-388-clearfog.dts. port 0=lan5, port 1=lan4
>port 2=lan3, port 3=lan2, port 4=lan1, port 5=cpu, port 6=lan6.
>
>The hardware and mechanical engineer is free to wire switch ports to
>the front panel however they want. That is why we put the netdev name
>in device tree.
Got it. Hmm, so I think that the port number can be made optional and
when it is present, it would be used to generate phys_port_name. If
not, perhaps devlink port index could be used instead.
So iiuc, you don't really need phys_port_name in dsa, as it provides
misleading names, right? Why is it implemented then?
>
> Andrew
^ permalink raw reply
* Re: [patch net-next RFC 10/12] nfp: flower: create port for flower vnic
From: Jiri Pirko @ 2018-03-24 7:41 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, idosch, mlxsw, andrew, vivien.didelot, f.fainelli,
michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher
In-Reply-To: <20180323203202.2c0b4433@cakuba.netronome.com>
Sat, Mar 24, 2018 at 04:32:02AM CET, jakub.kicinski@netronome.com wrote:
>On Fri, 23 Mar 2018 07:29:41 +0100, Jiri Pirko wrote:
>> >This will associate the PF netdev with physical port, incl. all ethtool
>> >information. Im not sure we want to do that. phy_repr carries this
>> >functionality.
>>
>> I was not sure originally what this port is. Okay, what I would like to
>> see is another port flavour for "pf" and "vf". I guess that since the pf
>> has the same pci address, it would fall under the same devlink instance.
>> For vfs, which have each separate pci address, I would like to create
>> devlink instance for each and associate with one devlink port flavour
>> "vf".
>
>Why do we need a devlink instance and phys port name for vfs? Just
>wondering.. It seems they should be covered by having different bus
>address. For full coverage of all netdevs?
It is a matter of identification I believe. Pfs are under the same pci
address for nfp right? I think that user has to see then and
distinguish. For VFs and nfp, I agree this is probably not necessary, as
the pci address is different and there is also a different driver name.
But for mlx5 for example, the same driver name is shown for all netdevs
including VFs.
^ permalink raw reply
* Re: [patch net-next RFC 04/12] dsa: set devlink port attrs for dsa ports
From: Jiri Pirko @ 2018-03-24 7:28 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, netdev, davem, idosch, jakub.kicinski, mlxsw,
vivien.didelot, michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher
In-Reply-To: <e8cc464f-6fcb-7ecd-10f3-b6d80aa7dad5@gmail.com>
Fri, Mar 23, 2018 at 06:09:29PM CET, f.fainelli@gmail.com wrote:
>On 03/23/2018 07:49 AM, Jiri Pirko wrote:
>> Fri, Mar 23, 2018 at 02:30:02PM CET, andrew@lunn.ch wrote:
>>> On Thu, Mar 22, 2018 at 11:55:14AM +0100, Jiri Pirko wrote:
>>>> From: Jiri Pirko <jiri@mellanox.com>
>>>>
>>>> Set the attrs and allow to expose port flavour to user via devlink.
>>>>
>>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>>> ---
>>>> net/dsa/dsa2.c | 23 +++++++++++++++++++++++
>>>> 1 file changed, 23 insertions(+)
>>>>
>>>> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
>>>> index adf50fbc4c13..49453690696d 100644
>>>> --- a/net/dsa/dsa2.c
>>>> +++ b/net/dsa/dsa2.c
>>>> @@ -270,7 +270,27 @@ static int dsa_port_setup(struct dsa_port *dp)
>>>> case DSA_PORT_TYPE_UNUSED:
>>>> break;
>>>> case DSA_PORT_TYPE_CPU:
>>>> + /* dp->index is used now as port_number. However
>>>> + * CPU ports should have separate numbering
>>>> + * independent from front panel port numbers.
>>>> + */
>>>> + devlink_port_attrs_set(&dp->devlink_port,
>>>> + DEVLINK_PORT_FLAVOUR_CPU,
>>>> + dp->index, false, 0);
>>>> + err = dsa_port_link_register_of(dp);
>>>> + if (err) {
>>>> + dev_err(ds->dev, "failed to setup link for port %d.%d\n",
>>>> + ds->index, dp->index);
>>>> + return err;
>>>> + }
>>>
>>> Ah, i get it. These used to be two case statements with one code
>>> block. But you split them apart, so needed to duplicate the
>>> dsa_port_link_register.
>>>
>>> Unfortunately, you forgot to add a 'break;', so it still falls
>>> through, and overwrites the port flavour to DSA.
>>
>> ah, crap. Don't have hw to test this :/
>> Will fix. Thanks!
>
>You don't need hardware, there is drivers/net/dsa/dsa_loop.c which will
>emulate a DSA switch. It won't create interconnect ports, since only one
>switch can be created with the method chosen, but this would have helped
>you catch the missing break since the "CPU" port would have been
>displayed as "DSA" anyway.
Okay.
>
>If you need hardware, I am sure this can be somehow arranged. By that, I
>mean something on which you can run upstream Linux on without out of
>tree patches.
Andrew is already taking care of that. Thanks.
^ permalink raw reply
* Re: [PATCH RFC net-next 7/7] netdevsim: Add simple FIB resource controller via devlink
From: Jiri Pirko @ 2018-03-24 7:26 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
David Ahern
In-Reply-To: <fe5a4e1f-5681-4d74-b586-0c727eed717e@cumulusnetworks.com>
Fri, Mar 23, 2018 at 04:13:14PM CET, dsa@cumulusnetworks.com wrote:
>On 3/23/18 9:05 AM, Jiri Pirko wrote:
>> Fri, Mar 23, 2018 at 04:03:40PM CET, dsa@cumulusnetworks.com wrote:
>>> On 3/23/18 9:01 AM, Jiri Pirko wrote:
>>>> Fri, Mar 23, 2018 at 03:31:02PM CET, dsa@cumulusnetworks.com wrote:
>>>>> On 3/23/18 12:50 AM, Jiri Pirko wrote:
>>>>>>> +void nsim_devlink_setup(struct netdevsim *ns)
>>>>>>> +{
>>>>>>> + struct net *net = dev_net(ns->netdev);
>>>>>>> + bool *reg_devlink = net_generic(net, nsim_devlink_id);
>>>>>>> + struct devlink *devlink;
>>>>>>> + int err = -ENOMEM;
>>>>>>> +
>>>>>>> + /* only one device per namespace controls devlink */
>>>>>>> + if (!*reg_devlink) {
>>>>>>> + ns->devlink = NULL;
>>>>>>> + return;
>>>>>>> + }
>>>>>>> +
>>>>>>> + devlink = devlink_alloc(&nsim_devlink_ops, 0);
>>>>>>> + if (!devlink)
>>>>>>> + return;
>>>>>>> +
>>>>>>> + devlink_net_set(devlink, net);
>>>>>>> + err = devlink_register(devlink, &ns->dev);
>>>>>>
>>>>>> This reg_devlink construct looks odd. Why don't you leave the devlink
>>>>>> instance in init_ns?
>>>>>
>>>>> It is a per-network namespace resource controller. Since struct devlink
>>>>
>>>> Wait a second. What do you mean by "per-network namespace"? Devlink
>>>> instance is always associated with one physical device. Like an ASIC.
>>>>
>>>>
>>>>> has a net entry, the simplest design is to put it into the namespace of
>>>>> the controller. Without it, controlling resource sizes in namespace
>>>>> 'foobar' has to be done from init_net, which is just wrong.
>>>
>>> you need to look at how netdevsim creates a device per netdevice.
>>
>> That means one devlink instance for each netdevsim device, doesn't it?
>>
>
>yes.
Still not sure how to handle namespaces in devlink. Originally, I
thought it would be okay to leave all devlink instances in init_ns.
Because what happens if you move netdev to another namespace? Should the
devlink move as well? What if you have multiple ports, each in different
namespace. Can user move devlink instance to another namespace? Etc.
^ permalink raw reply
* [PATCH] Documentation/isdn: check and fix dead links ...
From: Sanjeev Gupta @ 2018-03-24 5:07 UTC (permalink / raw)
To: corbet, isdn; +Cc: netdev, pebolle
and switch to https where possible.
All links have been eyeballed to verify that the domains have
not changed, etc.
Signed-off-by: Sanjeev Gupta <ghane0@gmail.com>
---
Documentation/isdn/INTERFACE.CAPI | 2 +-
Documentation/isdn/README | 4 ++--
Documentation/isdn/README.FAQ | 4 ++--
Documentation/isdn/README.gigaset | 16 +++++++++-------
4 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/Documentation/isdn/INTERFACE.CAPI b/Documentation/isdn/INTERFACE.CAPI
index 1688b5a1fd77..021aa9cf139d 100644
--- a/Documentation/isdn/INTERFACE.CAPI
+++ b/Documentation/isdn/INTERFACE.CAPI
@@ -18,7 +18,7 @@ corresponding hardware driver. Kernel CAPI then forwards CAPI messages in both
directions between the application and the hardware driver.
Format and semantics of CAPI messages are specified in the CAPI 2.0 standard.
-This standard is freely available from http://www.capi.org.
+This standard is freely available from https://www.capi.org.
2. Driver and Device Registration
diff --git a/Documentation/isdn/README b/Documentation/isdn/README
index 32d4e80c2c03..74bd2bdb455b 100644
--- a/Documentation/isdn/README
+++ b/Documentation/isdn/README
@@ -33,10 +33,10 @@ README for the ISDN-subsystem
de.alt.comm.isdn4linux
There is also a well maintained FAQ in English available at
- http://www.mhessler.de/i4lfaq/
+ https://www.mhessler.de/i4lfaq/
It can be viewed online, or downloaded in sgml/text/html format.
The FAQ can also be viewed online at
- http://www.isdn4linux.de/faq/
+ https://www.isdn4linux.de/faq/i4lfaq.html
or downloaded from
ftp://ftp.isdn4linux.de/pub/isdn4linux/FAQ/
diff --git a/Documentation/isdn/README.FAQ b/Documentation/isdn/README.FAQ
index 356f7944641d..e5dd1addacdd 100644
--- a/Documentation/isdn/README.FAQ
+++ b/Documentation/isdn/README.FAQ
@@ -8,9 +8,9 @@ You find it in:
In case you just want to see the FAQ online, or download the newest version,
you can have a look at my website:
-http://www.mhessler.de/i4lfaq/ (view + download)
+https://www.mhessler.de/i4lfaq/ (view + download)
or:
-http://www.isdn4linux.de/faq/ (view)
+https://www.isdn4linux.de/faq/4lfaq.html (view)
As the extension tells, the FAQ is in SGML format, and you can convert it
into text/html/... format by using the sgml2txt/sgml2html/... tools.
diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset
index 7534c6039adc..9b1ce277ca3d 100644
--- a/Documentation/isdn/README.gigaset
+++ b/Documentation/isdn/README.gigaset
@@ -29,8 +29,9 @@ GigaSet 307x Device Driver
T-Com Sinus 721 data
Chicago 390 USB (KPN)
- See also http://www.erbze.info/sinus_gigaset.htm and
- http://gigaset307x.sourceforge.net/
+ See also http://www.erbze.info/sinus_gigaset.htm
+ (archived at https://web.archive.org/web/20100717020421/http://www.erbze.info:80/sinus_gigaset.htm ) and
+ http://gigaset307x.sourceforge.net/
We had also reports from users of Gigaset M105 who could use the drivers
with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 2.5.)
@@ -52,7 +53,7 @@ GigaSet 307x Device Driver
to use CAPI 2.0 or ISDN4Linux for ISDN connections (voice or data).
There are some user space tools available at
- http://sourceforge.net/projects/gigaset307x/
+ https://sourceforge.net/projects/gigaset307x/
which provide access to additional device specific functions like SMS,
phonebook or call journal.
@@ -202,7 +203,7 @@ GigaSet 307x Device Driver
You can use some configuration tool of your distribution to configure this
"modem" or configure pppd/wvdial manually. There are some example ppp
configuration files and chat scripts in the gigaset-VERSION/ppp directory
- in the driver packages from http://sourceforge.net/projects/gigaset307x/.
+ in the driver packages from https://sourceforge.net/projects/gigaset307x/.
Please note that the USB drivers are not able to change the state of the
control lines. This means you must use "Stupid Mode" if you are using
wvdial or you should use the nocrtscts option of pppd.
@@ -361,7 +362,7 @@ GigaSet 307x Device Driver
---------------------------
If you can't solve problems with the driver on your own, feel free to
use one of the forums, bug trackers, or mailing lists on
- http://sourceforge.net/projects/gigaset307x
+ https://sourceforge.net/projects/gigaset307x
or write an electronic mail to the maintainers.
Try to provide as much information as possible, such as
@@ -391,11 +392,12 @@ GigaSet 307x Device Driver
4. Links, other software
---------------------
- Sourceforge project developing this driver and associated tools
- http://sourceforge.net/projects/gigaset307x
+ https://sourceforge.net/projects/gigaset307x
- Yahoo! Group on the Siemens Gigaset family of devices
- http://de.groups.yahoo.com/group/Siemens-Gigaset
+ https://de.groups.yahoo.com/group/Siemens-Gigaset
- Siemens Gigaset/T-Sinus compatibility table
http://www.erbze.info/sinus_gigaset.htm
+ (archived at https://web.archive.org/web/20100717020421/http://www.erbze.info:80/sinus_gigaset.htm )
5. Credits
--
2.15.1
^ permalink raw reply related
* [PATCH net-next] ptp: Fix documentation to match code.
From: Richard Cochran @ 2018-03-24 4:24 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Ever since commit 3a06c7ac24f9 ("posix-clocks: Remove interval timer
facility and mmap/fasync callbacks") the possibility of PHC based
posix timers has been removed. In addition it will probably never
make sense to implement this functionality.
This patch removes the misleading text which seems to suggest that
posix timers for PHC devices will ever be a thing.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
Documentation/ptp/ptp.txt | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/ptp/ptp.txt b/Documentation/ptp/ptp.txt
index ae8fef86b832..11e904ee073f 100644
--- a/Documentation/ptp/ptp.txt
+++ b/Documentation/ptp/ptp.txt
@@ -18,7 +18,6 @@
- Adjust clock frequency
+ Ancillary clock features
- - One short or periodic alarms, with signal delivery to user program
- Time stamp external events
- Period output signals configurable from user space
- Synchronization of the Linux system time via the PPS subsystem
@@ -48,9 +47,7 @@
User space programs may control the clock using standardized
ioctls. A program may query, enable, configure, and disable the
ancillary clock features. User space can receive time stamped
- events via blocking read() and poll(). One shot and periodic
- signals may be configured via the POSIX timer_settime() system
- call.
+ events via blocking read() and poll().
** Writing clock drivers
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v6 6/6] bnxt_en: Eliminate duplicate barriers on weakly-ordered archs
From: Sinan Kaya @ 2018-03-24 4:02 UTC (permalink / raw)
To: Michael Chan
Cc: Netdev, timur, sulrich, linux-arm-msm, linux-arm-kernel,
open list
In-Reply-To: <CACKFLinCMQ6aFXJDcqkTGGuPSEWsPPB09sS=mJJgsCdm5mvjhA@mail.gmail.com>
On 3/23/2018 6:36 PM, Michael Chan wrote:
>> + mmiowb();
> Sorry for the late review. mmiowb() is not required here because we
> are in NAPI context, so only one CPU will be updating this doorbell.
>
> Other than that, it looks good.
>
OK, I'll fix this on the next version.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH RFC net-next 7/7] netdevsim: Add simple FIB resource controller via devlink
From: Jakub Kicinski @ 2018-03-24 3:47 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, roopa, shm, jiri, idosch, David Ahern
In-Reply-To: <20180322225757.10377-8-dsa@cumulusnetworks.com>
On Thu, 22 Mar 2018 15:57:57 -0700, David Ahern wrote:
> From: David Ahern <dsahern@gmail.com>
>
> Add devlink support to netdevsim and use it to implement a simple,
> profile based resource controller. Only one controller is needed
> per namespace, so the first netdevsim netdevice in a namespace
> registers with devlink. If that device is deleted, the resource
> settings are deleted.
FWIW some nits from me blow.
> diff --git a/drivers/net/netdevsim/Makefile b/drivers/net/netdevsim/Makefile
> index 09388c06171d..449b2a1a1800 100644
> --- a/drivers/net/netdevsim/Makefile
> +++ b/drivers/net/netdevsim/Makefile
> @@ -9,3 +9,7 @@ ifeq ($(CONFIG_BPF_SYSCALL),y)
> netdevsim-objs += \
> bpf.o
> endif
> +
> +ifneq ($(CONFIG_NET_DEVLINK),)
Hm. Don't you need MAY_USE_DEVLINK dependency perhaps?
> +netdevsim-objs += devlink.o fib.o
> +endif
> diff --git a/drivers/net/netdevsim/devlink.c b/drivers/net/netdevsim/devlink.c
> new file mode 100644
> index 000000000000..d10558e1b022
> --- /dev/null
> +++ b/drivers/net/netdevsim/devlink.c
> +static int devlink_resources_register(struct devlink *devlink)
> +{
> + struct devlink_resource_size_params params = {
> + .size_max = (u64)-1,
> + .size_granularity = 1,
> + .unit = DEVLINK_RESOURCE_UNIT_ENTRY
> + };
> + struct net *net = devlink_net(devlink);
> + int err;
> + u64 n;
> +
> + /* Resources for IPv4 */
> + err = devlink_resource_register(devlink, "IPv4", (u64)-1,
> + NSIM_RESOURCE_IPV4,
> + DEVLINK_RESOURCE_ID_PARENT_TOP,
> + ¶ms, NULL);
> + if (err) {
> + pr_err("Failed to register IPv4 top resource\n");
> + goto out;
nit: why goto out here and return err everywhere else? If I was to
choose I'd rather see returns. goto X; X: return; is less
obviously correct IMHO. Besides labels should be called by the
action they perform/undo, so goto err_return? :S
> + }
> +
> + n = nsim_fib_get_val(net, NSIM_RESOURCE_IPV4_FIB, true);
> + err = devlink_resource_register(devlink, "fib", n,
> + NSIM_RESOURCE_IPV4_FIB,
> + NSIM_RESOURCE_IPV4,
> + ¶ms, &nsim_ipv4_fib_res_ops);
> + if (err) {
> + pr_err("Failed to register IPv4 FIB resource\n");
> + return err;
> + }
> +
> + n = nsim_fib_get_val(net, NSIM_RESOURCE_IPV4_FIB_RULES, true);
> + err = devlink_resource_register(devlink, "fib-rules", n,
> + NSIM_RESOURCE_IPV4_FIB_RULES,
> + NSIM_RESOURCE_IPV4,
> + ¶ms, &nsim_ipv4_fib_rules_res_ops);
> + if (err) {
> + pr_err("Failed to register IPv4 FIB rules resource\n");
> + return err;
> + }
> +
> + /* Resources for IPv6 */
> + err = devlink_resource_register(devlink, "IPv6", (u64)-1,
> + NSIM_RESOURCE_IPV6,
> + DEVLINK_RESOURCE_ID_PARENT_TOP,
> + ¶ms, NULL);
> + if (err) {
> + pr_err("Failed to register IPv6 top resource\n");
> + goto out;
> + }
> +
> + n = nsim_fib_get_val(net, NSIM_RESOURCE_IPV6_FIB, true);
> + err = devlink_resource_register(devlink, "fib", n,
> + NSIM_RESOURCE_IPV6_FIB,
> + NSIM_RESOURCE_IPV6,
> + ¶ms, &nsim_ipv6_fib_res_ops);
> + if (err) {
> + pr_err("Failed to register IPv6 FIB resource\n");
> + return err;
> + }
> +
> + n = nsim_fib_get_val(net, NSIM_RESOURCE_IPV6_FIB_RULES, true);
> + err = devlink_resource_register(devlink, "fib-rules", n,
> + NSIM_RESOURCE_IPV6_FIB_RULES,
> + NSIM_RESOURCE_IPV6,
> + ¶ms, &nsim_ipv6_fib_rules_res_ops);
> + if (err) {
> + pr_err("Failed to register IPv6 FIB rules resource\n");
> + return err;
> + }
> +out:
> + return err;
> +}
> +void nsim_devlink_teardown(struct netdevsim *ns)
> +{
> + if (ns->devlink) {
> + struct net *net = dev_net(ns->netdev);
> + bool *reg_devlink = net_generic(net, nsim_devlink_id);
nit: reverse xmas tree
> + devlink_unregister(ns->devlink);
> + devlink_free(ns->devlink);
> + ns->devlink = NULL;
> +
> + nsim_devlink_net_reset(net);
> + *reg_devlink = true;
> + }
> +}
> diff --git a/drivers/net/netdevsim/fib.c b/drivers/net/netdevsim/fib.c
> new file mode 100644
> index 000000000000..b77dcafc7158
> --- /dev/null
> +++ b/drivers/net/netdevsim/fib.c
> +static int nsim_fib_event_nb(struct notifier_block *nb, unsigned long event,
> + void *ptr)
> +{
> + struct fib_notifier_info *info = ptr;
> + int err;
> +
> + switch (event) {
> + case FIB_EVENT_RULE_ADD: /* fall through */
nit: I don't think fall through comment is needed for back-to-back
cases.
> + case FIB_EVENT_RULE_DEL:
> + err = nsim_fib_rule_event(info, event == FIB_EVENT_RULE_ADD);
> + break;
> +
> + case FIB_EVENT_ENTRY_ADD: /* fall through */
> + case FIB_EVENT_ENTRY_DEL:
> + err = nsim_fib_event(info, event == FIB_EVENT_ENTRY_ADD);
> + break;
> + }
> +
> + return notifier_from_errno(err);
> +}
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v5 7/9] igb: Add MAC address support for ethtool nftuple filters
From: Brown, Aaron F @ 2018-03-24 3:40 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180322003353.29970-8-vinicius.gomes@intel.com>
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Wednesday, March 21, 2018 5:34 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v5 7/9] igb: Add MAC address
> support for ethtool nftuple filters
>
> This adds the capability of configuring the queue steering of arriving
> packets based on their source and destination MAC addresses.
>
> In practical terms this adds support for the following use cases,
> characterized by these examples:
>
> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> to the RX queue 0)
>
> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> (this will direct packets with source address "44:44:44:44:44:44" to
> the RX queue 3)
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 35
> ++++++++++++++++++++++++----
> 1 file changed, 31 insertions(+), 4 deletions(-)
Maybe not "this" patch, but this is the one that enables the ethtool commands, so replying here.
The filters do not seem to take effect with this version (v5) of the series. The commands are accepted for i210 and rejected with unsupported messages for the other adapters (as desired) and an ethtool -n shows the filter, however, with either the src or dst filter set I can run traffic (netperf) that should be caught by the filter and rather than being directed to the single queue it is spread across queues as would be expected without the filter set.
The test system still has a kernel / driver with the v4 series of this patch set and the exact same filter commands / system setup does filter the traffic to the specified rx queue with the v4 series.
^ permalink raw reply
* [PATCH net-next 5/5] net: hns3: never send command queue message to IMP when reset
From: Peng Li @ 2018-03-24 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, salil.mehta, lipeng321
In-Reply-To: <1521862367-111399-1-git-send-email-lipeng321@huawei.com>
IMP will not handle and command queue message any more when it is
in core/global, driver should not send command queue message to
IMP until reinitialize the NIC HW.
This patch checks the status and avoid the message sent to IMP when
reset.
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 23 +++++++++++++++++-----
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 6 ++++++
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index ce093c3..2066dd7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3584,6 +3584,9 @@ static int hclge_unmap_ring_frm_vector(struct hnae3_handle *handle,
struct hclge_dev *hdev = vport->back;
int vector_id, ret;
+ if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
+ return 0;
+
vector_id = hclge_get_vector_index(hdev, vector);
if (vector_id < 0) {
dev_err(&handle->pdev->dev,
@@ -3781,13 +3784,16 @@ static int hclge_ae_start(struct hnae3_handle *handle)
clear_bit(HCLGE_STATE_DOWN, &hdev->state);
mod_timer(&hdev->service_timer, jiffies + HZ);
+ /* reset tqp stats */
+ hclge_reset_tqp_stats(handle);
+
+ if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
+ return 0;
+
ret = hclge_mac_start_phy(hdev);
if (ret)
return ret;
- /* reset tqp stats */
- hclge_reset_tqp_stats(handle);
-
return 0;
}
@@ -3797,6 +3803,12 @@ static void hclge_ae_stop(struct hnae3_handle *handle)
struct hclge_dev *hdev = vport->back;
int i;
+ del_timer_sync(&hdev->service_timer);
+ cancel_work_sync(&hdev->service_task);
+
+ if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
+ return;
+
for (i = 0; i < vport->alloc_tqps; i++)
hclge_tqp_enable(hdev, i, 0, false);
@@ -3807,8 +3819,6 @@ static void hclge_ae_stop(struct hnae3_handle *handle)
/* reset tqp stats */
hclge_reset_tqp_stats(handle);
- del_timer_sync(&hdev->service_timer);
- cancel_work_sync(&hdev->service_task);
hclge_update_link_status(hdev);
}
@@ -4940,6 +4950,9 @@ void hclge_reset_tqp(struct hnae3_handle *handle, u16 queue_id)
u16 queue_gid;
int ret;
+ if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
+ return;
+
queue_gid = hclge_covert_handle_qid_global(handle, queue_id);
ret = hclge_tqp_enable(hdev, queue_id, 0, false);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
index c1dea3a..682c2d6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
@@ -60,6 +60,9 @@ static int hclge_mdio_write(struct mii_bus *bus, int phyid, int regnum,
struct hclge_desc desc;
int ret;
+ if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
+ return 0;
+
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_MDIO_CONFIG, false);
mdio_cmd = (struct hclge_mdio_cfg_cmd *)desc.data;
@@ -95,6 +98,9 @@ static int hclge_mdio_read(struct mii_bus *bus, int phyid, int regnum)
struct hclge_desc desc;
int ret;
+ if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state))
+ return 0;
+
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_MDIO_CONFIG, true);
mdio_cmd = (struct hclge_mdio_cfg_cmd *)desc.data;
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 4/5] net: hns3: fix for not initializing VF rss_hash_key problem
From: Peng Li @ 2018-03-24 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, salil.mehta, lipeng321
In-Reply-To: <1521862367-111399-1-git-send-email-lipeng321@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
Default rss_hash_key value should be given to all vports. But just the
PF rss_hash_key has the default value here. This patch adds rss_hash_key
Initialization for all vports.
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index bede411..ce093c3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3466,8 +3466,6 @@ static void hclge_rss_init_cfg(struct hclge_dev *hdev)
struct hclge_vport *vport = hdev->vport;
int i;
- netdev_rss_key_fill(vport->rss_hash_key, HCLGE_RSS_KEY_SIZE);
-
for (i = 0; i < hdev->num_vmdq_vport + 1; i++) {
vport[i].rss_tuple_sets.ipv4_tcp_en =
HCLGE_RSS_INPUT_TUPLE_OTHER;
@@ -3487,6 +3485,8 @@ static void hclge_rss_init_cfg(struct hclge_dev *hdev)
HCLGE_RSS_INPUT_TUPLE_OTHER;
vport[i].rss_algo = HCLGE_RSS_HASH_ALGO_TOEPLITZ;
+
+ netdev_rss_key_fill(vport[i].rss_hash_key, HCLGE_RSS_KEY_SIZE);
}
hclge_rss_indir_init_cfg(hdev);
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 3/5] net: hns3: fix for the wrong shift problem in hns3_set_txbd_baseinfo
From: Peng Li @ 2018-03-24 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, salil.mehta, lipeng321
In-Reply-To: <1521862367-111399-1-git-send-email-lipeng321@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
Third parameter of hnae_set_field is shift, But a mask is given. This
patch fixes it by replacing HNS3_TXD_BDTYPE_M with HNS3_TXD_BDTYPE_S.
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 40a3eb7..a31b4ad 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -764,7 +764,7 @@ static void hns3_set_txbd_baseinfo(u16 *bdtp_fe_sc_vld_ra_ri, int frag_end)
{
/* Config bd buffer end */
hnae_set_field(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_BDTYPE_M,
- HNS3_TXD_BDTYPE_M, 0);
+ HNS3_TXD_BDTYPE_S, 0);
hnae_set_bit(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_FE_B, !!frag_end);
hnae_set_bit(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_VLD_B, 1);
hnae_set_field(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_SC_M, HNS3_TXD_SC_S, 0);
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 2/5] net: hns3: fix for returning wrong value problem in hns3_get_rss_indir_size
From: Peng Li @ 2018-03-24 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, salil.mehta, lipeng321
In-Reply-To: <1521862367-111399-1-git-send-email-lipeng321@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
The return type of hns3_get_rss_indir_size is u32. But a negative value is
returned. This patch fixes it by replacing the negative value with zero.
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index ac523c9..eb3c34f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -649,7 +649,7 @@ static u32 hns3_get_rss_indir_size(struct net_device *netdev)
if (!h->ae_algo || !h->ae_algo->ops ||
!h->ae_algo->ops->get_rss_indir_size)
- return -EOPNOTSUPP;
+ return 0;
return h->ae_algo->ops->get_rss_indir_size(h);
}
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 1/5] net: hns3: fix for returning wrong value problem in hns3_get_rss_key_size
From: Peng Li @ 2018-03-24 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, salil.mehta, lipeng321
In-Reply-To: <1521862367-111399-1-git-send-email-lipeng321@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
The return type of hns3_get_rss_key_size is u32. But a negative value is
returned. This patch fixes it by replacing the negative value with zero.
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 9d07116..ac523c9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -638,7 +638,7 @@ static u32 hns3_get_rss_key_size(struct net_device *netdev)
if (!h->ae_algo || !h->ae_algo->ops ||
!h->ae_algo->ops->get_rss_key_size)
- return -EOPNOTSUPP;
+ return 0;
return h->ae_algo->ops->get_rss_key_size(h);
}
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 0/5] fix some bugs for HNS3
From: Peng Li @ 2018-03-24 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, salil.mehta, lipeng321
This patchset fixes some bugs for HNS3 driver:
[Patch 1/5 - 2/5] fix 2 return vlaue issues.
[Patch 3/5 - 4/5] fix 2 comments reported by code review.
[Ptach 5/5] avoid sending message to IMP because IMP will not
handle any message when it is resetting.
Fuyun Liang (4):
net: hns3: fix for returning wrong value problem in
hns3_get_rss_key_size
net: hns3: fix for returning wrong value problem in
hns3_get_rss_indir_size
net: hns3: fix for the wrong shift problem in hns3_set_txbd_baseinfo
net: hns3: fix for not initializing VF rss_hash_key problem
Peng Li (1):
net: hns3: never send command queue message to IMP when reset
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 4 ++--
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 27 ++++++++++++++++------
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 6 +++++
4 files changed, 29 insertions(+), 10 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [patch net-next RFC 10/12] nfp: flower: create port for flower vnic
From: Jakub Kicinski @ 2018-03-24 3:32 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, idosch, mlxsw, andrew, vivien.didelot, f.fainelli,
michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher
In-Reply-To: <20180323062941.GH2074@nanopsycho.orion>
On Fri, 23 Mar 2018 07:29:41 +0100, Jiri Pirko wrote:
> >This will associate the PF netdev with physical port, incl. all ethtool
> >information. Im not sure we want to do that. phy_repr carries this
> >functionality.
>
> I was not sure originally what this port is. Okay, what I would like to
> see is another port flavour for "pf" and "vf". I guess that since the pf
> has the same pci address, it would fall under the same devlink instance.
> For vfs, which have each separate pci address, I would like to create
> devlink instance for each and associate with one devlink port flavour
> "vf".
Why do we need a devlink instance and phys port name for vfs? Just
wondering.. It seems they should be covered by having different bus
address. For full coverage of all netdevs?
^ permalink raw reply
* [PATCH bpf] nfp: bpf: fix check of program max insn count
From: Jakub Kicinski @ 2018-03-24 3:00 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: oss-drivers, netdev, Jakub Kicinski
NFP program allocation length is in bytes and NFP program length
is in instructions, fix the comparison of the two.
Fixes: 9314c442d7dd ("nfp: bpf: move translation prepare to offload.c")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Jiong Wang <jiong.wang@netronome.com>
---
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/bpf/jit.c b/drivers/net/ethernet/netronome/nfp/bpf/jit.c
index 56451edf01c2..ecd7c33baf3c 100644
--- a/drivers/net/ethernet/netronome/nfp/bpf/jit.c
+++ b/drivers/net/ethernet/netronome/nfp/bpf/jit.c
@@ -74,7 +74,9 @@ nfp_meta_has_prev(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
static void nfp_prog_push(struct nfp_prog *nfp_prog, u64 insn)
{
- if (nfp_prog->__prog_alloc_len == nfp_prog->prog_len) {
+ if (nfp_prog->__prog_alloc_len / sizeof(u64) == nfp_prog->prog_len) {
+ pr_warn("instruction limit reached (%u NFP instructions)\n",
+ nfp_prog->prog_len);
nfp_prog->error = -ENOSPC;
return;
}
@@ -2463,6 +2465,8 @@ static int nfp_translate(struct nfp_prog *nfp_prog)
err = cb(nfp_prog, meta);
if (err)
return err;
+ if (nfp_prog->error)
+ return nfp_prog->error;
nfp_prog->n_translated++;
}
--
2.16.2
^ permalink raw reply related
* [PATCH bpf] tools: bpftool: don't use hex numbers in JSON output
From: Jakub Kicinski @ 2018-03-24 2:45 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: oss-drivers, netdev, Jakub Kicinski
JSON does not accept hex numbers with 0x prefix. Simply print
as decimal numbers, JSON should be primarily machine-readable.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Fixes: 831a0aafe5c3 ("tools: bpftool: add JSON output for `bpftool map *` commands")
---
tools/bpf/bpftool/map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index f95fa67bb498..f509c86faede 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -428,7 +428,7 @@ static int show_map_close_json(int fd, struct bpf_map_info *info)
jsonw_string_field(json_wtr, "name", info->name);
jsonw_name(json_wtr, "flags");
- jsonw_printf(json_wtr, "%#x", info->map_flags);
+ jsonw_printf(json_wtr, "%d", info->map_flags);
print_dev_json(info->ifindex, info->netns_dev, info->netns_ino);
--
2.16.2
^ permalink raw reply related
* [PATCH net] nfp: use full 40 bits of the NSP buffer address
From: Jakub Kicinski @ 2018-03-24 2:42 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Dirk van der Merwe, Jakub Kicinski
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
The NSP default buffer is a piece of NFP memory where additional
command data can be placed. Its format has been copied from
host buffer, but the PCIe selection bits do not make sense in
this case. If those get masked out from a NFP address - writes
to random place in the chip memory may be issued and crash the
device.
This has never been an issue because the buffer used to be
allocated in memory with less-than-38-bit-long address but that
is about to change.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
index 39abac678b71..b54ab02f5b33 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
@@ -71,8 +71,7 @@
/* CPP address to retrieve the data from */
#define NSP_BUFFER 0x10
#define NSP_BUFFER_CPP GENMASK_ULL(63, 40)
-#define NSP_BUFFER_PCIE GENMASK_ULL(39, 38)
-#define NSP_BUFFER_ADDRESS GENMASK_ULL(37, 0)
+#define NSP_BUFFER_ADDRESS GENMASK_ULL(39, 0)
#define NSP_DFLT_BUFFER 0x18
--
2.16.2
^ permalink raw reply related
* Re: [PATCH v5 bpf-next 00/10] bpf, tracing: introduce bpf raw tracepoints
From: Alexei Starovoitov @ 2018-03-24 2:35 UTC (permalink / raw)
To: davem; +Cc: daniel, torvalds, peterz, rostedt, netdev, kernel-team, linux-api
In-Reply-To: <20180324023038.938665-1-ast@fb.com>
On 3/23/18 7:30 PM, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
>
> v4->v5:
> - adopted Daniel's fancy REPEAT macro in bpf_trace.c in patch 7
Daniel,
if you don't mind I'd like to land the patch set in this shape
and you can follow up with additional macro magic,
since I don't understand how the UNPACK part of it works.
It sort of looks unnecessary, but if remove it then (,) doesn't
get 'unpacked' into single comma.
Yet if __DL_COM is defined as , without ()
then nothing works. My brain is hurting.
^ permalink raw reply
* Re: [PATCH v7 0/7] netdev: intel: Eliminate duplicate barriers on weakly-ordered archs
From: okaya @ 2018-03-24 2:34 UTC (permalink / raw)
To: Jeff Kirsher
Cc: sulrich, Netdev, Timur Tabi, Alexander Duyck, intel-wired-lan,
linux-arm-msm, linux-arm-kernel
In-Reply-To: <1521849496.15055.16.camel@intel.com>
On 2018-03-23 19:58, Jeff Kirsher wrote:
> On Fri, 2018-03-23 at 14:53 -0700, Alexander Duyck wrote:
>> On Fri, Mar 23, 2018 at 11:52 AM, Sinan Kaya <okaya@codeaurora.org>
>> wrote:
>> > Code includes wmb() followed by writel() in multiple places. writel()
>> > already has a barrier on some architectures like arm64.
>> >
>> > This ends up CPU observing two barriers back to back before executing
>> > the
>> > register write.
>> >
>> > Since code already has an explicit barrier call, changing writel() to
>> > writel_relaxed().
>> >
>> > I did a regex search for wmb() followed by writel() in each drivers
>> > directory.
>> > I scrubbed the ones I care about in this series.
>> >
>> > I considered "ease of change", "popular usage" and "performance
>> > critical
>> > path" as the determining criteria for my filtering.
>> >
>> > We used relaxed API heavily on ARM for a long time but
>> > it did not exist on other architectures. For this reason, relaxed
>> > architectures have been paying double penalty in order to use the
>> > common
>> > drivers.
>> >
>> > Now that relaxed API is present on all architectures, we can go and
>> > scrub
>> > all drivers to see what needs to change and what can remain.
>> >
>> > We start with mostly used ones and hope to increase the coverage over
>> > time.
>> > It will take a while to cover all drivers.
>> >
>> > Feel free to apply patches individually.
>>
>> I looked over the set and they seem good.
>>
>> Reviewed-by: Alexander Duyck <alexander.h.duyck@intel.com>
>
> Grrr, patch 1 does not apply cleanly to my next-queue tree (dev-queue
> branch). I will deal with this series in a day or two, after I have
> dealt
> with my driver pull requests.
Sorry, you will have to replace the ones you took from me.
>
>> >
>> > Changes since v6:
>> > clean up between 2..6 and then make your Alex's changes on 1 and 7
>> > The mmiowb shouldn't be needed for Rx. Only one CPU will be running
>> > NAPI for the queue and we will synchronize this with a full writel
>> > anyway when we re-enable the interrupts.
>> >
>> > Sinan Kaya (7):
>> > i40e/i40evf: Eliminate duplicate barriers on weakly-ordered archs
>> > ixgbe: eliminate duplicate barriers on weakly-ordered archs
>> > igbvf: eliminate duplicate barriers on weakly-ordered archs
>> > igb: eliminate duplicate barriers on weakly-ordered archs
>> > fm10k: Eliminate duplicate barriers on weakly-ordered archs
>> > ixgbevf: keep writel() closer to wmb()
>> > ixgbevf: eliminate duplicate barriers on weakly-ordered archs
>> >
>> > drivers/net/ethernet/intel/fm10k/fm10k_main.c | 4 ++--
>> > drivers/net/ethernet/intel/i40e/i40e_txrx.c | 14 ++++++++++----
>> > drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 4 ++--
>> > drivers/net/ethernet/intel/igb/igb_main.c | 4 ++--
>> > drivers/net/ethernet/intel/igbvf/netdev.c | 4 ++--
>> > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 ++++----
>> > drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 5 -----
>> > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 ++++++++---
>> > 8 files changed, 30 insertions(+), 24 deletions(-)
>> >
>> > --
>> > 2.7.4
>> >
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox