* [PATCH 3/3] MAINTAINERS: Add the driver info of the ZHOUYI AI accelerator
@ 2021-11-24 6:57 6% ` Cai Huoqing
0 siblings, 0 replies; 200+ results
From: Cai Huoqing @ 2021-11-24 6:57 UTC (permalink / raw)
To: caihuoqing
Cc: Rob Herring, Greg Kroah-Hartman, devicetree, linux-kernel,
linux-staging
ZHOUYI NPU is an AI accelerator chip which is integrated into ARM SOC,
such as Allwinner R329 SOC.
Add the driver info of ZHOUYI NPU to MAINTAINERS file.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f32c7d733255..5d231aadaa3e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18163,6 +18163,12 @@ M: Forest Bond <forest@alittletooquiet.net>
S: Odd Fixes
F: drivers/staging/vt665?/
+STAGING - ARM ZHOUYI NPU SUPPORT
+M: Cai Huoqing <caihuoqing@baidu.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/staging/zynpu/
+
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
L: linux-staging@lists.linux.dev
--
2.25.1
^ permalink raw reply related [relevance 6%]
* [PATCH v2 3/3] MAINTAINERS: Add the driver info of the ZHOUYI AI accelerator
@ 2021-11-24 8:46 6% ` Cai Huoqing
0 siblings, 0 replies; 200+ results
From: Cai Huoqing @ 2021-11-24 8:46 UTC (permalink / raw)
To: caihuoqing
Cc: Rob Herring, Greg Kroah-Hartman, devicetree, linux-kernel,
linux-staging
ZHOUYI NPU is an AI accelerator chip which is integrated into ARM SOC,
such as Allwinner R329 SOC.
Add the driver info of ZHOUYI NPU to MAINTAINERS file.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f32c7d733255..5d231aadaa3e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18163,6 +18163,12 @@ M: Forest Bond <forest@alittletooquiet.net>
S: Odd Fixes
F: drivers/staging/vt665?/
+STAGING - ARM ZHOUYI NPU SUPPORT
+M: Cai Huoqing <caihuoqing@baidu.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/staging/zynpu/
+
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
L: linux-staging@lists.linux.dev
--
2.25.1
^ permalink raw reply related [relevance 6%]
* [PATCH v2 3/3] MAINTAINERS: Add the driver info of the ZHOUYI AI accelerator
@ 2021-11-26 2:19 6% ` Cai Huoqing
0 siblings, 0 replies; 200+ results
From: Cai Huoqing @ 2021-11-26 2:19 UTC (permalink / raw)
To: caihuoqing
Cc: Rob Herring, Greg Kroah-Hartman, devicetree, linux-kernel,
linux-staging
ZHOUYI NPU is an AI accelerator chip which is integrated into ARM SOC,
such as Allwinner R329 SOC.
Add the driver info of ZHOUYI NPU to MAINTAINERS file.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f32c7d733255..5d231aadaa3e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18163,6 +18163,12 @@ M: Forest Bond <forest@alittletooquiet.net>
S: Odd Fixes
F: drivers/staging/vt665?/
+STAGING - ARM ZHOUYI NPU SUPPORT
+M: Cai Huoqing <caihuoqing@baidu.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/staging/zynpu/
+
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
L: linux-staging@lists.linux.dev
--
2.25.1
^ permalink raw reply related [relevance 6%]
* [PATCH] MAINTAINERS: Update Hemant's email id
@ 2022-04-04 6:42 6% Manivannan Sadhasivam
0 siblings, 0 replies; 200+ results
From: Manivannan Sadhasivam @ 2022-04-04 6:42 UTC (permalink / raw)
To: mhi
Cc: quic_hemantk, quic_bbhatt, linux-arm-msm, linux-kernel,
Manivannan Sadhasivam
The codeaurora email domain is no longer available for Qualcomm employees.
Qualcomm employees should now use the new email ids from quicinc domain for
opensource contributions.
So let's use the new email id for Hemant.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index fd768d43e048..d714313d5cb0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12793,7 +12793,7 @@ F: arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
MHI BUS
M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
-R: Hemant Kumar <hemantk@codeaurora.org>
+R: Hemant Kumar <quic_hemantk@quicinc.com>
L: mhi@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
--
2.25.1
^ permalink raw reply related [relevance 6%]
* [PATCH] MAINTAINERS: Remove Hemant from MHI bus
@ 2022-10-28 17:42 6% Manivannan Sadhasivam
0 siblings, 0 replies; 200+ results
From: Manivannan Sadhasivam @ 2022-10-28 17:42 UTC (permalink / raw)
To: mhi, linux-arm-msm; +Cc: Manivannan Sadhasivam
Hemant moved out of Qualcomm and expressed his wish to not continue doing
any reviews for MHI patches. So let's remove him from MAINTAINERS file.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cf0f18502372..ad9279218885 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13395,7 +13395,6 @@ F: arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
MHI BUS
M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
-R: Hemant Kumar <quic_hemantk@quicinc.com>
L: mhi@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
--
2.25.1
^ permalink raw reply related [relevance 6%]
* [PATCH 6/8] MAINTAINERS/DAMON: link maintainer profile, git trees, and website
@ 2023-01-10 19:03 6% ` SeongJae Park
2023-01-10 19:03 6% ` [PATCH 5/8] Docs/mm/damon: add a maintainer-profile for DAMON SeongJae Park
1 sibling, 0 replies; 200+ results
From: SeongJae Park @ 2023-01-10 19:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: SeongJae Park, damon, linux-mm, linux-kernel
Add links to below DAMON development related resource to DAMON section
in MAINTAINERS file.
- The basic policies and expectations of DAMON development,
- DAMON development trees, and
- DAMON introduction website.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9a0c3d3b9093..4b222f67663a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5790,6 +5790,11 @@ M: SeongJae Park <sj@kernel.org>
L: damon@lists.linux.dev
L: linux-mm@kvack.org
S: Maintained
+W: https://damonitor.github.io
+P: Documentation/mm/damon/maintainer-profile.rst
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
+T: quilt git://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/sj/linux.git damon/next
F: Documentation/ABI/testing/sysfs-kernel-mm-damon
F: Documentation/admin-guide/mm/damon/
F: Documentation/mm/damon/
--
2.25.1
^ permalink raw reply related [relevance 6%]
* [PATCH v2 2/3] watchdog: Add ChromeOS EC-based watchdog driver
@ 2024-01-18 19:53 6% ` Lukasz Majczak
0 siblings, 0 replies; 200+ results
From: Lukasz Majczak @ 2024-01-18 19:53 UTC (permalink / raw)
To: Gwendal Grignou, Tzung-Bi Shih, Radoslaw Biernacki,
Wim Van Sebroeck, Lee Jones, Benson Leung, Guenter Roeck,
Krzysztof Kozlowski, linux-watchdog, linux-kernel,
chrome-platform
Cc: Lukasz Majczak
Embedded Controller (EC) present on Chromebook devices
can be used as a watchdog.
Implement a driver to support it.
Signed-off-by: Lukasz Majczak <lma@chromium.org>
---
MAINTAINERS | 6 +
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/cros_ec_wdt.c | 202 +++++++++++++++++++++++++++++++++
4 files changed, 220 insertions(+)
create mode 100644 drivers/watchdog/cros_ec_wdt.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ef90ddc0fda6..aaae581aae70 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4981,6 +4981,12 @@ R: Sami Kyöstilä <skyostil@chromium.org>
S: Maintained
F: drivers/platform/chrome/cros_hps_i2c.c
+CHROMEOS EC WATCHDOG
+M: Lukasz Majczak <lma@chromium.org>
+L: chrome-platform@lists.linux.dev
+S: Maintained
+F: drivers/watchdog/cros_ec_wdt.c
+
CHRONTEL CH7322 CEC DRIVER
M: Joe Tessler <jrt@google.com>
L: linux-media@vger.kernel.org
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7d22051b15a2..4700b218340f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -181,6 +181,17 @@ config BD957XMUF_WATCHDOG
watchdog. Alternatively say M to compile the driver as a module,
which will be called bd9576_wdt.
+config CROS_EC_WATCHDOG
+ tristate "ChromeOS EC-based watchdog"
+ select WATCHDOG_CORE
+ depends on CROS_EC
+ help
+ Watchdog driver for Chromebook devices equipped with embedded controller.
+ Trigger event is recorded in EC and checked on the subsequent boot.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_ec_wdt.
+
config DA9052_WATCHDOG
tristate "Dialog DA9052 Watchdog"
depends on PMIC_DA9052 || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 7cbc34514ec1..3710c218f05e 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -217,6 +217,7 @@ obj-$(CONFIG_XEN_WDT) += xen_wdt.o
# Architecture Independent
obj-$(CONFIG_BD957XMUF_WATCHDOG) += bd9576_wdt.o
+obj-$(CONFIG_CROS_EC_WATCHDOG) += cros_ec_wdt.o
obj-$(CONFIG_DA9052_WATCHDOG) += da9052_wdt.o
obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
obj-$(CONFIG_DA9062_WATCHDOG) += da9062_wdt.o
diff --git a/drivers/watchdog/cros_ec_wdt.c b/drivers/watchdog/cros_ec_wdt.c
new file mode 100644
index 000000000000..1915b8d55e45
--- /dev/null
+++ b/drivers/watchdog/cros_ec_wdt.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2024 Google LLC.
+ * Author: Lukasz Majczak <lma@chromium.com>
+ */
+
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_data/cros_ec_commands.h>
+#include <linux/platform_data/cros_ec_proto.h>
+#include <linux/platform_device.h>
+#include <linux/watchdog.h>
+
+#define CROS_EC_WATCHDOG_DEFAULT_TIME 30 /* seconds */
+#define DRV_NAME "cros-ec-wdt-drv"
+
+union cros_ec_wdt_data {
+ struct ec_params_hang_detect req;
+ struct ec_response_hang_detect resp;
+} __packed;
+
+static int cros_ec_wdt_send_cmd(struct cros_ec_device *cros_ec,
+ union cros_ec_wdt_data *arg)
+{
+ int ret;
+ struct {
+ struct cros_ec_command msg;
+ union cros_ec_wdt_data data;
+ } __packed buf = {
+ .msg = {
+ .version = 0,
+ .command = EC_CMD_HANG_DETECT,
+ .insize = (arg->req.command == EC_HANG_DETECT_CMD_GET_STATUS) ?
+ sizeof(struct ec_response_hang_detect) :
+ 0,
+ .outsize = sizeof(struct ec_params_hang_detect),
+ },
+ .data.req = arg->req
+ };
+
+ ret = cros_ec_cmd_xfer_status(cros_ec, &buf.msg);
+ if (ret < 0)
+ return ret;
+
+ arg->resp = buf.data.resp;
+
+ return 0;
+}
+
+static int cros_ec_wdt_ping(struct watchdog_device *wdd)
+{
+ struct cros_ec_device *cros_ec = watchdog_get_drvdata(wdd);
+ union cros_ec_wdt_data arg;
+ int ret;
+
+ arg.req.command = EC_HANG_DETECT_CMD_RELOAD;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ dev_dbg(wdd->parent, "Failed to ping watchdog (%d)", ret);
+
+ return ret;
+}
+
+static int cros_ec_wdt_start(struct watchdog_device *wdd)
+{
+ struct cros_ec_device *cros_ec = watchdog_get_drvdata(wdd);
+ union cros_ec_wdt_data arg;
+ int ret;
+
+ /* Prepare watchdog on EC side */
+ arg.req.command = EC_HANG_DETECT_CMD_SET_TIMEOUT;
+ arg.req.reboot_timeout_sec = wdd->timeout;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ dev_dbg(wdd->parent, "Failed to start watchdog (%d)", ret);
+
+ return ret;
+}
+
+static int cros_ec_wdt_stop(struct watchdog_device *wdd)
+{
+ struct cros_ec_device *cros_ec = watchdog_get_drvdata(wdd);
+ union cros_ec_wdt_data arg;
+ int ret;
+
+ arg.req.command = EC_HANG_DETECT_CMD_CANCEL;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ dev_dbg(wdd->parent, "Failed to stop watchdog (%d)", ret);
+
+ return ret;
+}
+
+static int cros_ec_wdt_set_timeout(struct watchdog_device *wdd, unsigned int t)
+{
+ unsigned int old_timeout = wdd->timeout;
+ int ret;
+
+ wdd->timeout = t;
+ ret = cros_ec_wdt_start(wdd);
+ if (ret < 0)
+ wdd->timeout = old_timeout;
+
+ return ret;
+}
+
+static const struct watchdog_info cros_ec_wdt_ident = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .firmware_version = 0,
+ .identity = DRV_NAME,
+};
+
+static const struct watchdog_ops cros_ec_wdt_ops = {
+ .owner = THIS_MODULE,
+ .ping = cros_ec_wdt_ping,
+ .start = cros_ec_wdt_start,
+ .stop = cros_ec_wdt_stop,
+ .set_timeout = cros_ec_wdt_set_timeout,
+};
+
+static int cros_ec_wdt_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct cros_ec_dev *ec_dev = dev_get_drvdata(dev->parent);
+ struct cros_ec_device *cros_ec = ec_dev->ec_dev;
+ struct watchdog_device *wdd;
+ union cros_ec_wdt_data arg;
+ int ret = 0;
+
+ wdd = devm_kzalloc(&pdev->dev, sizeof(struct watchdog_device), GFP_KERNEL);
+ if (!wdd)
+ return -ENOMEM;
+
+ arg.req.command = EC_HANG_DETECT_CMD_GET_STATUS;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to get watchdog bootstatus");
+
+ wdd->parent = &pdev->dev;
+ wdd->info = &cros_ec_wdt_ident;
+ wdd->ops = &cros_ec_wdt_ops;
+ wdd->timeout = CROS_EC_WATCHDOG_DEFAULT_TIME;
+ wdd->min_timeout = EC_HANG_DETECT_MIN_TIMEOUT;
+ wdd->max_timeout = EC_HANG_DETECT_MAX_TIMEOUT;
+ if (arg.resp.status == EC_HANG_DETECT_AP_BOOT_EC_WDT)
+ wdd->bootstatus = WDIOF_CARDRESET;
+
+ arg.req.command = EC_HANG_DETECT_CMD_CLEAR_STATUS;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to clear watchdog bootstatus");
+
+ watchdog_stop_on_reboot(wdd);
+ watchdog_stop_on_unregister(wdd);
+ watchdog_set_drvdata(wdd, cros_ec);
+ platform_set_drvdata(pdev, wdd);
+
+ return devm_watchdog_register_device(dev, wdd);
+}
+
+static int __maybe_unused cros_ec_wdt_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct watchdog_device *wdd = platform_get_drvdata(pdev);
+ int ret = 0;
+
+ if (watchdog_active(wdd))
+ ret = cros_ec_wdt_stop(wdd);
+
+ return ret;
+}
+
+static int __maybe_unused cros_ec_wdt_resume(struct platform_device *pdev)
+{
+ struct watchdog_device *wdd = platform_get_drvdata(pdev);
+ int ret = 0;
+
+ if (watchdog_active(wdd))
+ ret = cros_ec_wdt_start(wdd);
+
+ return ret;
+}
+
+static struct platform_driver cros_ec_wdt_driver = {
+ .probe = cros_ec_wdt_probe,
+ .suspend = pm_ptr(cros_ec_wdt_suspend),
+ .resume = pm_ptr(cros_ec_wdt_resume),
+ .driver = {
+ .name = DRV_NAME,
+ },
+};
+
+module_platform_driver(cros_ec_wdt_driver);
+
+static const struct platform_device_id cros_ec_wdt_id[] = {
+ { DRV_NAME, 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(platform, cros_ec_wdt_id);
+MODULE_DESCRIPTION("Cros EC Watchdog Device Driver");
+MODULE_LICENSE("GPL");
--
2.43.0.429.g432eaa2c6b-goog
^ permalink raw reply related [relevance 6%]
* [PATCH v4 2/3] watchdog: Add ChromeOS EC-based watchdog driver
@ 2024-01-26 9:57 6% ` Lukasz Majczak
0 siblings, 0 replies; 200+ results
From: Lukasz Majczak @ 2024-01-26 9:57 UTC (permalink / raw)
To: Gwendal Grignou, Tzung-Bi Shih, Radoslaw Biernacki,
Wim Van Sebroeck, Lee Jones, Benson Leung, Guenter Roeck,
Krzysztof Kozlowski, linux-watchdog, linux-kernel,
chrome-platform
Cc: Lukasz Majczak
Embedded Controller (EC) present on Chromebook devices
can be used as a watchdog.
Implement a driver to support it.
Signed-off-by: Lukasz Majczak <lma@chromium.org>
---
MAINTAINERS | 6 +
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/cros_ec_wdt.c | 204 +++++++++++++++++++++++++++++++++
4 files changed, 222 insertions(+)
create mode 100644 drivers/watchdog/cros_ec_wdt.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ef90ddc0fda6..aaae581aae70 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4981,6 +4981,12 @@ R: Sami Kyöstilä <skyostil@chromium.org>
S: Maintained
F: drivers/platform/chrome/cros_hps_i2c.c
+CHROMEOS EC WATCHDOG
+M: Lukasz Majczak <lma@chromium.org>
+L: chrome-platform@lists.linux.dev
+S: Maintained
+F: drivers/watchdog/cros_ec_wdt.c
+
CHRONTEL CH7322 CEC DRIVER
M: Joe Tessler <jrt@google.com>
L: linux-media@vger.kernel.org
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7d22051b15a2..4700b218340f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -181,6 +181,17 @@ config BD957XMUF_WATCHDOG
watchdog. Alternatively say M to compile the driver as a module,
which will be called bd9576_wdt.
+config CROS_EC_WATCHDOG
+ tristate "ChromeOS EC-based watchdog"
+ select WATCHDOG_CORE
+ depends on CROS_EC
+ help
+ Watchdog driver for Chromebook devices equipped with embedded controller.
+ Trigger event is recorded in EC and checked on the subsequent boot.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_ec_wdt.
+
config DA9052_WATCHDOG
tristate "Dialog DA9052 Watchdog"
depends on PMIC_DA9052 || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 7cbc34514ec1..3710c218f05e 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -217,6 +217,7 @@ obj-$(CONFIG_XEN_WDT) += xen_wdt.o
# Architecture Independent
obj-$(CONFIG_BD957XMUF_WATCHDOG) += bd9576_wdt.o
+obj-$(CONFIG_CROS_EC_WATCHDOG) += cros_ec_wdt.o
obj-$(CONFIG_DA9052_WATCHDOG) += da9052_wdt.o
obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
obj-$(CONFIG_DA9062_WATCHDOG) += da9062_wdt.o
diff --git a/drivers/watchdog/cros_ec_wdt.c b/drivers/watchdog/cros_ec_wdt.c
new file mode 100644
index 000000000000..ba045e29f9a5
--- /dev/null
+++ b/drivers/watchdog/cros_ec_wdt.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2024 Google LLC.
+ * Author: Lukasz Majczak <lma@chromium.com>
+ */
+
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_data/cros_ec_commands.h>
+#include <linux/platform_data/cros_ec_proto.h>
+#include <linux/platform_device.h>
+#include <linux/watchdog.h>
+
+#define CROS_EC_WATCHDOG_DEFAULT_TIME 30 /* seconds */
+#define DRV_NAME "cros-ec-wdt"
+
+union cros_ec_wdt_data {
+ struct ec_params_hang_detect req;
+ struct ec_response_hang_detect resp;
+} __packed;
+
+static int cros_ec_wdt_send_cmd(struct cros_ec_device *cros_ec,
+ union cros_ec_wdt_data *arg)
+{
+ int ret;
+ struct {
+ struct cros_ec_command msg;
+ union cros_ec_wdt_data data;
+ } __packed buf = {
+ .msg = {
+ .version = 0,
+ .command = EC_CMD_HANG_DETECT,
+ .insize = (arg->req.command == EC_HANG_DETECT_CMD_GET_STATUS) ?
+ sizeof(struct ec_response_hang_detect) :
+ 0,
+ .outsize = sizeof(struct ec_params_hang_detect),
+ },
+ .data.req = arg->req
+ };
+
+ ret = cros_ec_cmd_xfer_status(cros_ec, &buf.msg);
+ if (ret < 0)
+ return ret;
+
+ arg->resp = buf.data.resp;
+
+ return 0;
+}
+
+static int cros_ec_wdt_ping(struct watchdog_device *wdd)
+{
+ struct cros_ec_device *cros_ec = watchdog_get_drvdata(wdd);
+ union cros_ec_wdt_data arg;
+ int ret;
+
+ arg.req.command = EC_HANG_DETECT_CMD_RELOAD;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ dev_dbg(wdd->parent, "Failed to ping watchdog (%d)", ret);
+
+ return ret;
+}
+
+static int cros_ec_wdt_start(struct watchdog_device *wdd)
+{
+ struct cros_ec_device *cros_ec = watchdog_get_drvdata(wdd);
+ union cros_ec_wdt_data arg;
+ int ret;
+
+ /* Prepare watchdog on EC side */
+ arg.req.command = EC_HANG_DETECT_CMD_SET_TIMEOUT;
+ arg.req.reboot_timeout_sec = wdd->timeout;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ dev_dbg(wdd->parent, "Failed to start watchdog (%d)", ret);
+
+ return ret;
+}
+
+static int cros_ec_wdt_stop(struct watchdog_device *wdd)
+{
+ struct cros_ec_device *cros_ec = watchdog_get_drvdata(wdd);
+ union cros_ec_wdt_data arg;
+ int ret;
+
+ arg.req.command = EC_HANG_DETECT_CMD_CANCEL;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ dev_dbg(wdd->parent, "Failed to stop watchdog (%d)", ret);
+
+ return ret;
+}
+
+static int cros_ec_wdt_set_timeout(struct watchdog_device *wdd, unsigned int t)
+{
+ unsigned int old_timeout = wdd->timeout;
+ int ret;
+
+ wdd->timeout = t;
+ ret = cros_ec_wdt_start(wdd);
+ if (ret < 0)
+ wdd->timeout = old_timeout;
+
+ return ret;
+}
+
+static const struct watchdog_info cros_ec_wdt_ident = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .firmware_version = 0,
+ .identity = DRV_NAME,
+};
+
+static const struct watchdog_ops cros_ec_wdt_ops = {
+ .owner = THIS_MODULE,
+ .ping = cros_ec_wdt_ping,
+ .start = cros_ec_wdt_start,
+ .stop = cros_ec_wdt_stop,
+ .set_timeout = cros_ec_wdt_set_timeout,
+};
+
+static int cros_ec_wdt_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct cros_ec_dev *ec_dev = dev_get_drvdata(dev->parent);
+ struct cros_ec_device *cros_ec = ec_dev->ec_dev;
+ struct watchdog_device *wdd;
+ union cros_ec_wdt_data arg;
+ int ret = 0;
+
+ wdd = devm_kzalloc(&pdev->dev, sizeof(*wdd), GFP_KERNEL);
+ if (!wdd)
+ return -ENOMEM;
+
+ arg.req.command = EC_HANG_DETECT_CMD_GET_STATUS;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to get watchdog bootstatus");
+
+ wdd->parent = &pdev->dev;
+ wdd->info = &cros_ec_wdt_ident;
+ wdd->ops = &cros_ec_wdt_ops;
+ wdd->timeout = CROS_EC_WATCHDOG_DEFAULT_TIME;
+ wdd->min_timeout = EC_HANG_DETECT_MIN_TIMEOUT;
+ wdd->max_timeout = EC_HANG_DETECT_MAX_TIMEOUT;
+ if (arg.resp.status == EC_HANG_DETECT_AP_BOOT_EC_WDT)
+ wdd->bootstatus = WDIOF_CARDRESET;
+
+ arg.req.command = EC_HANG_DETECT_CMD_CLEAR_STATUS;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to clear watchdog bootstatus");
+
+ watchdog_stop_on_reboot(wdd);
+ watchdog_stop_on_unregister(wdd);
+ watchdog_set_drvdata(wdd, cros_ec);
+ platform_set_drvdata(pdev, wdd);
+
+ return devm_watchdog_register_device(dev, wdd);
+}
+
+static int __maybe_unused cros_ec_wdt_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct watchdog_device *wdd = platform_get_drvdata(pdev);
+ int ret = 0;
+
+ if (watchdog_active(wdd))
+ ret = cros_ec_wdt_stop(wdd);
+
+ return ret;
+}
+
+static int __maybe_unused cros_ec_wdt_resume(struct platform_device *pdev)
+{
+ struct watchdog_device *wdd = platform_get_drvdata(pdev);
+ int ret = 0;
+
+ if (watchdog_active(wdd))
+ ret = cros_ec_wdt_start(wdd);
+
+ return ret;
+}
+
+static const struct platform_device_id cros_ec_wdt_id[] = {
+ { DRV_NAME, 0 },
+ {}
+};
+
+static struct platform_driver cros_ec_wdt_driver = {
+ .probe = cros_ec_wdt_probe,
+ .suspend = pm_ptr(cros_ec_wdt_suspend),
+ .resume = pm_ptr(cros_ec_wdt_resume),
+ .driver = {
+ .name = DRV_NAME,
+ },
+ .id_table = cros_ec_wdt_id,
+};
+
+module_platform_driver(cros_ec_wdt_driver);
+
+MODULE_DEVICE_TABLE(platform, cros_ec_wdt_id);
+MODULE_DESCRIPTION("Cros EC Watchdog Device Driver");
+MODULE_LICENSE("GPL");
--
2.43.0.429.g432eaa2c6b-goog
^ permalink raw reply related [relevance 6%]
* [PATCH v3 2/3] watchdog: Add ChromeOS EC-based watchdog driver
@ 2024-01-19 8:43 6% ` Lukasz Majczak
0 siblings, 0 replies; 200+ results
From: Lukasz Majczak @ 2024-01-19 8:43 UTC (permalink / raw)
To: Gwendal Grignou, Tzung-Bi Shih, Radoslaw Biernacki,
Wim Van Sebroeck, Lee Jones, Benson Leung, Guenter Roeck,
Krzysztof Kozlowski, linux-watchdog, linux-kernel,
chrome-platform
Cc: Lukasz Majczak
Embedded Controller (EC) present on Chromebook devices
can be used as a watchdog.
Implement a driver to support it.
Signed-off-by: Lukasz Majczak <lma@chromium.org>
---
MAINTAINERS | 6 +
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/cros_ec_wdt.c | 202 +++++++++++++++++++++++++++++++++
4 files changed, 220 insertions(+)
create mode 100644 drivers/watchdog/cros_ec_wdt.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ef90ddc0fda6..aaae581aae70 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4981,6 +4981,12 @@ R: Sami Kyöstilä <skyostil@chromium.org>
S: Maintained
F: drivers/platform/chrome/cros_hps_i2c.c
+CHROMEOS EC WATCHDOG
+M: Lukasz Majczak <lma@chromium.org>
+L: chrome-platform@lists.linux.dev
+S: Maintained
+F: drivers/watchdog/cros_ec_wdt.c
+
CHRONTEL CH7322 CEC DRIVER
M: Joe Tessler <jrt@google.com>
L: linux-media@vger.kernel.org
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7d22051b15a2..4700b218340f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -181,6 +181,17 @@ config BD957XMUF_WATCHDOG
watchdog. Alternatively say M to compile the driver as a module,
which will be called bd9576_wdt.
+config CROS_EC_WATCHDOG
+ tristate "ChromeOS EC-based watchdog"
+ select WATCHDOG_CORE
+ depends on CROS_EC
+ help
+ Watchdog driver for Chromebook devices equipped with embedded controller.
+ Trigger event is recorded in EC and checked on the subsequent boot.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_ec_wdt.
+
config DA9052_WATCHDOG
tristate "Dialog DA9052 Watchdog"
depends on PMIC_DA9052 || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 7cbc34514ec1..3710c218f05e 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -217,6 +217,7 @@ obj-$(CONFIG_XEN_WDT) += xen_wdt.o
# Architecture Independent
obj-$(CONFIG_BD957XMUF_WATCHDOG) += bd9576_wdt.o
+obj-$(CONFIG_CROS_EC_WATCHDOG) += cros_ec_wdt.o
obj-$(CONFIG_DA9052_WATCHDOG) += da9052_wdt.o
obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
obj-$(CONFIG_DA9062_WATCHDOG) += da9062_wdt.o
diff --git a/drivers/watchdog/cros_ec_wdt.c b/drivers/watchdog/cros_ec_wdt.c
new file mode 100644
index 000000000000..d03eb0562e08
--- /dev/null
+++ b/drivers/watchdog/cros_ec_wdt.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2024 Google LLC.
+ * Author: Lukasz Majczak <lma@chromium.com>
+ */
+
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_data/cros_ec_commands.h>
+#include <linux/platform_data/cros_ec_proto.h>
+#include <linux/platform_device.h>
+#include <linux/watchdog.h>
+
+#define CROS_EC_WATCHDOG_DEFAULT_TIME 30 /* seconds */
+#define DRV_NAME "cros-ec-wdt"
+
+union cros_ec_wdt_data {
+ struct ec_params_hang_detect req;
+ struct ec_response_hang_detect resp;
+} __packed;
+
+static int cros_ec_wdt_send_cmd(struct cros_ec_device *cros_ec,
+ union cros_ec_wdt_data *arg)
+{
+ int ret;
+ struct {
+ struct cros_ec_command msg;
+ union cros_ec_wdt_data data;
+ } __packed buf = {
+ .msg = {
+ .version = 0,
+ .command = EC_CMD_HANG_DETECT,
+ .insize = (arg->req.command == EC_HANG_DETECT_CMD_GET_STATUS) ?
+ sizeof(struct ec_response_hang_detect) :
+ 0,
+ .outsize = sizeof(struct ec_params_hang_detect),
+ },
+ .data.req = arg->req
+ };
+
+ ret = cros_ec_cmd_xfer_status(cros_ec, &buf.msg);
+ if (ret < 0)
+ return ret;
+
+ arg->resp = buf.data.resp;
+
+ return 0;
+}
+
+static int cros_ec_wdt_ping(struct watchdog_device *wdd)
+{
+ struct cros_ec_device *cros_ec = watchdog_get_drvdata(wdd);
+ union cros_ec_wdt_data arg;
+ int ret;
+
+ arg.req.command = EC_HANG_DETECT_CMD_RELOAD;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ dev_dbg(wdd->parent, "Failed to ping watchdog (%d)", ret);
+
+ return ret;
+}
+
+static int cros_ec_wdt_start(struct watchdog_device *wdd)
+{
+ struct cros_ec_device *cros_ec = watchdog_get_drvdata(wdd);
+ union cros_ec_wdt_data arg;
+ int ret;
+
+ /* Prepare watchdog on EC side */
+ arg.req.command = EC_HANG_DETECT_CMD_SET_TIMEOUT;
+ arg.req.reboot_timeout_sec = wdd->timeout;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ dev_dbg(wdd->parent, "Failed to start watchdog (%d)", ret);
+
+ return ret;
+}
+
+static int cros_ec_wdt_stop(struct watchdog_device *wdd)
+{
+ struct cros_ec_device *cros_ec = watchdog_get_drvdata(wdd);
+ union cros_ec_wdt_data arg;
+ int ret;
+
+ arg.req.command = EC_HANG_DETECT_CMD_CANCEL;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ dev_dbg(wdd->parent, "Failed to stop watchdog (%d)", ret);
+
+ return ret;
+}
+
+static int cros_ec_wdt_set_timeout(struct watchdog_device *wdd, unsigned int t)
+{
+ unsigned int old_timeout = wdd->timeout;
+ int ret;
+
+ wdd->timeout = t;
+ ret = cros_ec_wdt_start(wdd);
+ if (ret < 0)
+ wdd->timeout = old_timeout;
+
+ return ret;
+}
+
+static const struct watchdog_info cros_ec_wdt_ident = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .firmware_version = 0,
+ .identity = DRV_NAME,
+};
+
+static const struct watchdog_ops cros_ec_wdt_ops = {
+ .owner = THIS_MODULE,
+ .ping = cros_ec_wdt_ping,
+ .start = cros_ec_wdt_start,
+ .stop = cros_ec_wdt_stop,
+ .set_timeout = cros_ec_wdt_set_timeout,
+};
+
+static int cros_ec_wdt_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct cros_ec_dev *ec_dev = dev_get_drvdata(dev->parent);
+ struct cros_ec_device *cros_ec = ec_dev->ec_dev;
+ struct watchdog_device *wdd;
+ union cros_ec_wdt_data arg;
+ int ret = 0;
+
+ wdd = devm_kzalloc(&pdev->dev, sizeof(struct watchdog_device), GFP_KERNEL);
+ if (!wdd)
+ return -ENOMEM;
+
+ arg.req.command = EC_HANG_DETECT_CMD_GET_STATUS;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to get watchdog bootstatus");
+
+ wdd->parent = &pdev->dev;
+ wdd->info = &cros_ec_wdt_ident;
+ wdd->ops = &cros_ec_wdt_ops;
+ wdd->timeout = CROS_EC_WATCHDOG_DEFAULT_TIME;
+ wdd->min_timeout = EC_HANG_DETECT_MIN_TIMEOUT;
+ wdd->max_timeout = EC_HANG_DETECT_MAX_TIMEOUT;
+ if (arg.resp.status == EC_HANG_DETECT_AP_BOOT_EC_WDT)
+ wdd->bootstatus = WDIOF_CARDRESET;
+
+ arg.req.command = EC_HANG_DETECT_CMD_CLEAR_STATUS;
+ ret = cros_ec_wdt_send_cmd(cros_ec, &arg);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to clear watchdog bootstatus");
+
+ watchdog_stop_on_reboot(wdd);
+ watchdog_stop_on_unregister(wdd);
+ watchdog_set_drvdata(wdd, cros_ec);
+ platform_set_drvdata(pdev, wdd);
+
+ return devm_watchdog_register_device(dev, wdd);
+}
+
+static int __maybe_unused cros_ec_wdt_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct watchdog_device *wdd = platform_get_drvdata(pdev);
+ int ret = 0;
+
+ if (watchdog_active(wdd))
+ ret = cros_ec_wdt_stop(wdd);
+
+ return ret;
+}
+
+static int __maybe_unused cros_ec_wdt_resume(struct platform_device *pdev)
+{
+ struct watchdog_device *wdd = platform_get_drvdata(pdev);
+ int ret = 0;
+
+ if (watchdog_active(wdd))
+ ret = cros_ec_wdt_start(wdd);
+
+ return ret;
+}
+
+static struct platform_driver cros_ec_wdt_driver = {
+ .probe = cros_ec_wdt_probe,
+ .suspend = pm_ptr(cros_ec_wdt_suspend),
+ .resume = pm_ptr(cros_ec_wdt_resume),
+ .driver = {
+ .name = DRV_NAME,
+ },
+};
+
+module_platform_driver(cros_ec_wdt_driver);
+
+static const struct platform_device_id cros_ec_wdt_id[] = {
+ { DRV_NAME, 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(platform, cros_ec_wdt_id);
+MODULE_DESCRIPTION("Cros EC Watchdog Device Driver");
+MODULE_LICENSE("GPL");
--
2.43.0.429.g432eaa2c6b-goog
^ permalink raw reply related [relevance 6%]
* [PATCH 4/5] fstests/MAINTAINERS: add some specific reviewers
2023-04-04 17:14 6% ` [f2fs-dev] " Zorro Lang
@ 2023-04-04 17:14 6% ` Zorro Lang
1 sibling, 0 replies; 200+ results
From: Zorro Lang @ 2023-04-04 17:14 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, ceph-devel, linux-cifs, linux-ext4, linux-f2fs-devel,
linux-fsdevel, linux-nfs, ocfs2-devel, linux-unionfs, jack,
linux-xfs, fdmanana, ebiggers, brauner, amir73il, djwong,
anand.jain
Some people contribute to someone specific fs testing mostly, record
some of them as Reviewer.
Signed-off-by: Zorro Lang <zlang@kernel.org>
---
If someone doesn't want to be in cc list of related fstests patch, please
reply this email, I'll remove that reviewer line.
Or if someone else (who contribute to fstests very much) would like to a
specific reviewer, nominate yourself to get a review.
Thanks,
Zorro
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 620368cb..0ad12a38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -108,6 +108,7 @@ Maintainers List
or reviewer or co-maintainer can be in cc list.
BTRFS
+R: Filipe Manana <fdmanana@suse.com>
L: linux-btrfs@vger.kernel.org
S: Supported
F: tests/btrfs/
@@ -137,16 +138,19 @@ F: tests/f2fs/
F: common/f2fs
FSVERITY
+R: Eric Biggers <ebiggers@google.com>
L: fsverity@lists.linux.dev
S: Supported
F: common/verity
FSCRYPT
+R: Eric Biggers <ebiggers@google.com>
L: linux-fscrypt@vger.kernel.org
S: Supported
F: common/encrypt
FS-IDMAPPED
+R: Christian Brauner <brauner@kernel.org>
L: linux-fsdevel@vger.kernel.org
S: Supported
F: src/vfs/
@@ -163,6 +167,7 @@ S: Supported
F: tests/ocfs2/
OVERLAYFS
+R: Amir Goldstein <amir73il@gmail.com>
L: linux-unionfs@vger.kernel.org
S: Supported
F: tests/overlay
@@ -174,6 +179,7 @@ S: Supported
F: tests/udf/
XFS
+R: Darrick J. Wong <djwong@kernel.org>
L: linux-xfs@vger.kernel.org
S: Supported
F: common/dump
--
2.39.2
^ permalink raw reply related [relevance 6%]
* x86/coco MAINTAINERS mailing list
@ 2022-04-07 18:05 6% Dave Hansen
0 siblings, 0 replies; 200+ results
From: Dave Hansen @ 2022-04-07 18:05 UTC (permalink / raw)
To: linux-coco, Shutemov, Kirill
[-- Attachment #1: Type: text/plain, Size: 756 bytes --]
Hi coco folks,
There are some x86-specific "coco" additions being proposed here:
> https://lore.kernel.org/all/b43720c6-0763-f4bb-64a0-7745c6ad920a@intel.com/
that we're thinking about merging some time soon. They add some
"arch/x86/coco/" files:
> arch/x86/coco/Makefile | 2 +
> arch/x86/coco/core.c | 22 +-
> arch/x86/coco/tdx/Makefile | 3 +
> arch/x86/coco/tdx/tdcall.S | 204 +++++++
> arch/x86/coco/tdx/tdx.c | 692 +++++++++++++++++++++++
It would be nice to have a MAINTAINERS entry for these. I know this
list is ideally arch-agnostic, but would anyone mind if it is listed as
the x86/coco mailing list? Maybe something like the attached patch.
[-- Attachment #2: x86-coco.patch --]
[-- Type: text/x-patch, Size: 470 bytes --]
diff --git a/MAINTAINERS b/MAINTAINERS
index fd768d43e048..f8fa4786cc3d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10807,6 +10807,13 @@ F: arch/x86/kernel/kvmclock.c
F: arch/x86/kvm/
F: arch/x86/kvm/*/
+X86 CONFIDENTIAL COMPUTING
+M: x86@kernel.org
+R: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+L: linux-coco@lists.linux.dev
+S: Supported
+F: arch/x86/coco/
+
KERNFS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Tejun Heo <tj@kernel.org>
^ permalink raw reply related [relevance 6%]
* [PATCH 1/1] MAINTAINERS: Add HTE/timestamp subsystem details
@ 2022-08-25 21:37 6% Dipen Patel
0 siblings, 0 replies; 200+ results
From: Dipen Patel @ 2022-08-25 21:37 UTC (permalink / raw)
To: thierry.reding, linus.walleij; +Cc: linux-kernel, linux-gpio, Dipen Patel
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8fd6a1721e69..b97cfb7d6fd9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9326,6 +9326,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <dipenp@nvidia.com>
+L: timestamp@lists.linux.dev
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
base-commit: b5d939c951865f6fc229094e84b77c9a9e0ed0c7
--
2.17.1
^ permalink raw reply related [relevance 6%]
* [PATCH 1/1] MAINTAINERS: Add HTE/timestamp subsystem details
@ 2022-08-25 21:49 6% Dipen Patel
0 siblings, 0 replies; 200+ results
From: Dipen Patel @ 2022-08-25 21:49 UTC (permalink / raw)
To: timestamp; +Cc: Dipen Patel
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8fd6a1721e69..b97cfb7d6fd9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9326,6 +9326,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <dipenp@nvidia.com>
+L: timestamp@lists.linux.dev
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
base-commit: b5d939c951865f6fc229094e84b77c9a9e0ed0c7
--
2.17.1
^ permalink raw reply related [relevance 6%]
* [PATCH 1/7] MAINTAINERS: Add HTE/timestamp subsystem details
@ 2022-11-03 17:45 6% ` Dipen Patel
0 siblings, 0 replies; 200+ results
From: Dipen Patel @ 2022-11-03 17:45 UTC (permalink / raw)
To: thierry.reding, jonathanh, linux-kernel, linux-tegra, linux-gpio,
linus.walleij, devicetree, linux-doc, robh+dt
Cc: Dipen Patel
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cf0f18502372..37b17c1f1388 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9414,6 +9414,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <dipenp@nvidia.com>
+L: timestamp@lists.linux.dev
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
--
2.17.1
^ permalink raw reply related [relevance 6%]
* [PATCH 1/7] MAINTAINERS: Add HTE/timestamp subsystem details
@ 2022-11-03 17:46 6% ` Dipen Patel
0 siblings, 0 replies; 200+ results
From: Dipen Patel @ 2022-11-03 17:46 UTC (permalink / raw)
To: timestamp; +Cc: Dipen Patel
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cf0f18502372..37b17c1f1388 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9414,6 +9414,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <dipenp@nvidia.com>
+L: timestamp@lists.linux.dev
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
--
2.17.1
^ permalink raw reply related [relevance 6%]
* [PATCH V2 1/6] MAINTAINERS: Add HTE/timestamp subsystem details
@ 2023-02-14 11:55 6% ` Dipen Patel
0 siblings, 0 replies; 200+ results
From: Dipen Patel @ 2023-02-14 11:55 UTC (permalink / raw)
To: thierry.reding, jonathanh, linux-kernel, linux-tegra, linux-gpio,
linus.walleij, devicetree, linux-doc, robh+dt, timestamp
Cc: Dipen Patel
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f61eb221415b..734c988a7f7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9533,6 +9533,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <dipenp@nvidia.com>
+L: timestamp@lists.linux.dev
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
--
2.17.1
^ permalink raw reply related [relevance 6%]
* [PATCH V3 1/6] MAINTAINERS: Add HTE/timestamp subsystem details
@ 2023-03-10 19:06 6% ` Dipen Patel
0 siblings, 0 replies; 200+ results
From: Dipen Patel @ 2023-03-10 19:06 UTC (permalink / raw)
To: thierry.reding, jonathanh, linux-kernel, linux-tegra, linux-gpio,
linus.walleij, devicetree, linux-doc, robh+dt, timestamp,
krzysztof.kozlowski+dt, brgl, corbet, gregkh
Cc: Dipen Patel
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..65b58963f0d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9425,6 +9425,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <dipenp@nvidia.com>
+L: timestamp@lists.linux.dev
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
--
2.17.1
^ permalink raw reply related [relevance 6%]
* [PATCH V4 01/10] MAINTAINERS: Add HTE/timestamp subsystem details
@ 2023-03-23 1:29 6% ` Dipen Patel
0 siblings, 0 replies; 200+ results
From: Dipen Patel @ 2023-03-23 1:29 UTC (permalink / raw)
To: thierry.reding, jonathanh, linux-kernel, linux-tegra, linux-gpio,
linus.walleij, devicetree, linux-doc, robh+dt, timestamp,
krzysztof.kozlowski+dt, brgl, corbet, gregkh
Cc: Dipen Patel
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..65b58963f0d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9425,6 +9425,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <dipenp@nvidia.com>
+L: timestamp@lists.linux.dev
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
--
2.17.1
^ permalink raw reply related [relevance 6%]
* [V5 01/10] MAINTAINERS: Add HTE/timestamp subsystem details
@ 2023-04-06 17:18 6% ` Dipen Patel
0 siblings, 0 replies; 200+ results
From: Dipen Patel @ 2023-04-06 17:18 UTC (permalink / raw)
To: thierry.reding, jonathanh, linux-kernel, linux-tegra, linux-gpio,
linus.walleij, devicetree, linux-doc, robh+dt, timestamp,
krzysztof.kozlowski+dt, brgl, corbet, gregkh
Cc: Dipen Patel
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..65b58963f0d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9425,6 +9425,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <dipenp@nvidia.com>
+L: timestamp@lists.linux.dev
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
--
2.17.1
^ permalink raw reply related [relevance 6%]
* [V6 1/9] MAINTAINERS: Add HTE/timestamp subsystem details
@ 2023-04-14 0:44 6% ` Dipen Patel
0 siblings, 0 replies; 200+ results
From: Dipen Patel @ 2023-04-14 0:44 UTC (permalink / raw)
To: thierry.reding, jonathanh, linux-kernel, linux-tegra, linux-gpio,
linus.walleij, devicetree, linux-doc, robh+dt, timestamp,
krzysztof.kozlowski+dt, brgl, corbet, gregkh
Cc: Dipen Patel
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..65b58963f0d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9425,6 +9425,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <dipenp@nvidia.com>
+L: timestamp@lists.linux.dev
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
--
2.17.1
^ permalink raw reply related [relevance 6%]
* [PATCH net 3/3] MAINTAINERS: update Matthieu's email address
@ 2023-10-04 20:38 6% ` Mat Martineau
0 siblings, 0 replies; 200+ results
From: Mat Martineau @ 2023-10-04 20:38 UTC (permalink / raw)
To: Matthieu Baerts, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Matthieu Baerts
Cc: netdev, mptcp, Kishen Maloor, Florian Westphal, Mat Martineau
From: Matthieu Baerts <matttbe@kernel.org>
Use my kernel.org account instead.
The other one will bounce by the end of the year.
Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
Signed-off-by: Mat Martineau <martineau@kernel.org>
---
.mailmap | 1 +
MAINTAINERS | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index a0a6efe87186..c80903efec75 100644
--- a/.mailmap
+++ b/.mailmap
@@ -377,6 +377,7 @@ Matthew Wilcox <willy@infradead.org> <willy@debian.org>
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
Matthias Fuchs <socketcan@esd.eu> <matthias.fuchs@esd.eu>
+Matthieu Baerts <matttbe@kernel.org> <matthieu.baerts@tessares.net>
Matthieu CASTET <castet.matthieu@free.fr>
Matti Vaittinen <mazziesaccount@gmail.com> <matti.vaittinen@fi.rohmeurope.com>
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
diff --git a/MAINTAINERS b/MAINTAINERS
index 9275708c9b96..0bb5451e9b86 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14942,7 +14942,7 @@ K: macsec
K: \bmdo_
NETWORKING [MPTCP]
-M: Matthieu Baerts <matthieu.baerts@tessares.net>
+M: Matthieu Baerts <matttbe@kernel.org>
M: Mat Martineau <martineau@kernel.org>
L: netdev@vger.kernel.org
L: mptcp@lists.linux.dev
--
2.41.0
^ permalink raw reply related [relevance 6%]
* [PATCH] MAINTAINERS: Add Intel TDX entry
@ 2023-11-01 23:33 6% Kirill A. Shutemov
0 siblings, 0 replies; 200+ results
From: Kirill A. Shutemov @ 2023-11-01 23:33 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen
Cc: x86, Kuppuswamy Sathyanarayanan, Kai Huang, linux-kernel,
Kirill A. Shutemov
Add myself as Intel TDX maintainer.
I drove upstreaming most of TDX code so far and I will continue
working on TDX for foreseeable future.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
---
MAINTAINERS | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7608b714653f..1cbec6b235f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23466,6 +23466,18 @@ F: arch/x86/kernel/dumpstack.c
F: arch/x86/kernel/stacktrace.c
F: arch/x86/kernel/unwind_*.c
+X86 TRUST DOMAIN EXTENSIONS (TDX)
+M: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+L: x86@kernel.org
+L: linux-coco@lists.linux.dev
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/tdx
+F: arch/x86/boot/compressed/tdx*
+F: arch/x86/coco/tdx/
+F: arch/x86/include/asm/shared/tdx.h
+F: arch/x86/include/asm/tdx.h
+F: arch/x86/virt/vmx/tdx/
+
X86 VDSO
M: Andy Lutomirski <luto@kernel.org>
L: linux-kernel@vger.kernel.org
--
2.41.0
^ permalink raw reply related [relevance 6%]
* PURCHASE ORDER lists.linux.dev
@ 2023-02-16 14:13 6% Jessica Hernandez
0 siblings, 0 replies; 200+ results
From: Jessica Hernandez @ 2023-02-16 14:13 UTC (permalink / raw)
To: asahi
[-- Attachment #1.1: Type: text/plain, Size: 1650 bytes --]
Good day.
We have an inquiry according to the attachment, please send your quote as soon as possible.
Kindly provide the following details in your quote:
Delivery lead time ( goods to be ready for shipping ) , less time would be more advantage.
Delivery terms
Total weight and dimensions
Manufacturer name and Country of origin
HS code
Kindly send us your best quotation , brochures, technical specs by today .
Hope that this opportunity would be a good chance to start a long term co-operation with your company in the near future .
Looking forward to your offer.
Thanks
Jessica Hernandez
This e-mail, its content, and any files transmitted with it (the «message ») are confidential and intended solely for the use of the addressees. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accordance with its purpose, any dissemination or disclosure, either whole or partial, is strictly prohibited except formal approval of Daher. Any views or opinions presented are solely those of its author and do not necessarily represent those of Daher or any of its subsidiary companies. The internet cannot guarantee the integrity of this message. Neither Daher nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. While we take all reasonable precautions to ensure that viruses are not transmitted via emails, we recommend that you take your own measures to prevent viruses from entering your computer system. This email, its content and any files transmitted with it does not imply entering into a binding contract.
[-- Attachment #1.2: Type: text/html, Size: 942 bytes --]
[-- Attachment #2: Order Requirement .pdf --]
[-- Type: application/pdf, Size: 342740 bytes --]
^ permalink raw reply [relevance 6%]
* [f2fs-dev] [PATCH 4/5] fstests/MAINTAINERS: add some specific reviewers
@ 2023-04-04 17:14 6% ` Zorro Lang
0 siblings, 0 replies; 200+ results
From: Zorro Lang @ 2023-04-04 17:14 UTC (permalink / raw)
To: fstests
Cc: brauner, linux-cifs, linux-nfs, ebiggers, djwong, amir73il,
linux-unionfs, anand.jain, linux-f2fs-devel, linux-xfs, fdmanana,
ocfs2-devel, jack, linux-fsdevel, ceph-devel, linux-ext4,
linux-btrfs
Some people contribute to someone specific fs testing mostly, record
some of them as Reviewer.
Signed-off-by: Zorro Lang <zlang@kernel.org>
---
If someone doesn't want to be in cc list of related fstests patch, please
reply this email, I'll remove that reviewer line.
Or if someone else (who contribute to fstests very much) would like to a
specific reviewer, nominate yourself to get a review.
Thanks,
Zorro
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 620368cb..0ad12a38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -108,6 +108,7 @@ Maintainers List
or reviewer or co-maintainer can be in cc list.
BTRFS
+R: Filipe Manana <fdmanana@suse.com>
L: linux-btrfs@vger.kernel.org
S: Supported
F: tests/btrfs/
@@ -137,16 +138,19 @@ F: tests/f2fs/
F: common/f2fs
FSVERITY
+R: Eric Biggers <ebiggers@google.com>
L: fsverity@lists.linux.dev
S: Supported
F: common/verity
FSCRYPT
+R: Eric Biggers <ebiggers@google.com>
L: linux-fscrypt@vger.kernel.org
S: Supported
F: common/encrypt
FS-IDMAPPED
+R: Christian Brauner <brauner@kernel.org>
L: linux-fsdevel@vger.kernel.org
S: Supported
F: src/vfs/
@@ -163,6 +167,7 @@ S: Supported
F: tests/ocfs2/
OVERLAYFS
+R: Amir Goldstein <amir73il@gmail.com>
L: linux-unionfs@vger.kernel.org
S: Supported
F: tests/overlay
@@ -174,6 +179,7 @@ S: Supported
F: tests/udf/
XFS
+R: Darrick J. Wong <djwong@kernel.org>
L: linux-xfs@vger.kernel.org
S: Supported
F: common/dump
--
2.39.2
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply related [relevance 6%]
* [Ocfs2-devel] [PATCH 4/5] fstests/MAINTAINERS: add some specific reviewers
@ 2023-04-04 17:14 6% ` Zorro Lang
0 siblings, 0 replies; 200+ results
From: Zorro Lang via Ocfs2-devel @ 2023-04-04 17:14 UTC (permalink / raw)
To: fstests
Cc: brauner, linux-cifs, linux-nfs, ebiggers, amir73il, linux-unionfs,
anand.jain, linux-f2fs-devel, linux-xfs, fdmanana, ocfs2-devel,
jack, linux-fsdevel, ceph-devel, linux-ext4, linux-btrfs
Some people contribute to someone specific fs testing mostly, record
some of them as Reviewer.
Signed-off-by: Zorro Lang <zlang@kernel.org>
---
If someone doesn't want to be in cc list of related fstests patch, please
reply this email, I'll remove that reviewer line.
Or if someone else (who contribute to fstests very much) would like to a
specific reviewer, nominate yourself to get a review.
Thanks,
Zorro
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 620368cb..0ad12a38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -108,6 +108,7 @@ Maintainers List
or reviewer or co-maintainer can be in cc list.
BTRFS
+R: Filipe Manana <fdmanana@suse.com>
L: linux-btrfs@vger.kernel.org
S: Supported
F: tests/btrfs/
@@ -137,16 +138,19 @@ F: tests/f2fs/
F: common/f2fs
FSVERITY
+R: Eric Biggers <ebiggers@google.com>
L: fsverity@lists.linux.dev
S: Supported
F: common/verity
FSCRYPT
+R: Eric Biggers <ebiggers@google.com>
L: linux-fscrypt@vger.kernel.org
S: Supported
F: common/encrypt
FS-IDMAPPED
+R: Christian Brauner <brauner@kernel.org>
L: linux-fsdevel@vger.kernel.org
S: Supported
F: src/vfs/
@@ -163,6 +167,7 @@ S: Supported
F: tests/ocfs2/
OVERLAYFS
+R: Amir Goldstein <amir73il@gmail.com>
L: linux-unionfs@vger.kernel.org
S: Supported
F: tests/overlay
@@ -174,6 +179,7 @@ S: Supported
F: tests/udf/
XFS
+R: Darrick J. Wong <djwong@kernel.org>
L: linux-xfs@vger.kernel.org
S: Supported
F: common/dump
--
2.39.2
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply related [relevance 6%]
* [PATCH mptcp-net] MAINTAINERS: update Geliang's email address
@ 2024-02-01 1:06 6% Geliang Tang
0 siblings, 0 replies; 200+ results
From: Geliang Tang @ 2024-02-01 1:06 UTC (permalink / raw)
To: mptcp; +Cc: Geliang Tang, Mat Martineau
Update my email-address in MAINTAINERS and .mailmap entries to my
kernel.org account.
Suggested-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <geliang@kernel.org>
---
.mailmap | 9 +++++----
MAINTAINERS | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/.mailmap b/.mailmap
index 04998f7bda81..327e7eddd146 100644
--- a/.mailmap
+++ b/.mailmap
@@ -191,10 +191,11 @@ Gao Xiang <xiang@kernel.org> <gaoxiang25@huawei.com>
Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
Gao Xiang <xiang@kernel.org> <hsiangkao@linux.alibaba.com>
Gao Xiang <xiang@kernel.org> <hsiangkao@redhat.com>
-Geliang Tang <geliang.tang@linux.dev> <geliang.tang@suse.com>
-Geliang Tang <geliang.tang@linux.dev> <geliangtang@xiaomi.com>
-Geliang Tang <geliang.tang@linux.dev> <geliangtang@gmail.com>
-Geliang Tang <geliang.tang@linux.dev> <geliangtang@163.com>
+Geliang Tang <geliang@kernel.org> <geliang.tang@linux.dev>
+Geliang Tang <geliang@kernel.org> <geliang.tang@suse.com>
+Geliang Tang <geliang@kernel.org> <geliangtang@xiaomi.com>
+Geliang Tang <geliang@kernel.org> <geliangtang@gmail.com>
+Geliang Tang <geliang@kernel.org> <geliangtang@163.com>
Georgi Djakov <djakov@kernel.org> <georgi.djakov@linaro.org>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@de.ibm.com>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <gerald.schaefer@de.ibm.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 6b49df9d5eb4..61a07588edb9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15326,7 +15326,7 @@ K: \bmdo_
NETWORKING [MPTCP]
M: Matthieu Baerts <matttbe@kernel.org>
M: Mat Martineau <martineau@kernel.org>
-R: Geliang Tang <geliang.tang@linux.dev>
+R: Geliang Tang <geliang@kernel.org>
L: netdev@vger.kernel.org
L: mptcp@lists.linux.dev
S: Maintained
--
2.40.1
^ permalink raw reply related [relevance 6%]
* [PATCH] tty: virtio: drop virtio_cons_early_init()
@ 2023-11-30 11:30 6% Jiri Slaby (SUSE)
0 siblings, 0 replies; 200+ results
From: Jiri Slaby (SUSE) @ 2023-11-30 11:30 UTC (permalink / raw)
To: gregkh
Cc: linux-serial, linux-kernel, Jiri Slaby (SUSE), Richard Henderson,
Ivan Kokshaysky, Matt Turner, Amit Shah, Arnd Bergmann,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, linux-alpha,
virtualization
The last user of virtio_cons_early_init() was dropped in commit
7fb2b2d51244 ("s390/virtio: remove the old KVM virtio transport").
So now, drop virtio_cons_early_init() and the logic and headers behind
too.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Amit Shah <amit@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: linux-alpha@vger.kernel.org
Cc: virtualization@lists.linux.dev
---
MAINTAINERS | 1 -
drivers/char/virtio_console.c | 48 ----------------------------------
include/linux/virtio_console.h | 38 ---------------------------
3 files changed, 87 deletions(-)
delete mode 100644 include/linux/virtio_console.h
diff --git a/MAINTAINERS b/MAINTAINERS
index b81da7a36a36..345797d89e11 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23055,7 +23055,6 @@ M: Amit Shah <amit@kernel.org>
L: virtualization@lists.linux.dev
S: Maintained
F: drivers/char/virtio_console.c
-F: include/linux/virtio_console.h
F: include/uapi/linux/virtio_console.h
VIRTIO CORE AND NET DRIVERS
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 431e9e5bf9c1..8abe599c1c07 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -230,9 +230,6 @@ struct port {
bool guest_connected;
};
-/* This is the very early arch-specified put chars function. */
-static int (*early_put_chars)(u32, const char *, int);
-
static struct port *find_port_by_vtermno(u32 vtermno)
{
struct port *port;
@@ -1114,9 +1111,6 @@ static int put_chars(u32 vtermno, const char *buf, int count)
void *data;
int ret;
- if (unlikely(early_put_chars))
- return early_put_chars(vtermno, buf, count);
-
port = find_port_by_vtermno(vtermno);
if (!port)
return -EPIPE;
@@ -1142,10 +1136,6 @@ static int get_chars(u32 vtermno, char *buf, int count)
{
struct port *port;
- /* If we've not set up the port yet, we have no input to give. */
- if (unlikely(early_put_chars))
- return 0;
-
port = find_port_by_vtermno(vtermno);
if (!port)
return -EPIPE;
@@ -1201,21 +1191,6 @@ static const struct hv_ops hv_ops = {
.notifier_hangup = notifier_del_vio,
};
-/*
- * Console drivers are initialized very early so boot messages can go
- * out, so we do things slightly differently from the generic virtio
- * initialization of the net and block drivers.
- *
- * At this stage, the console is output-only. It's too early to set
- * up a virtqueue, so we let the drivers do some boutique early-output
- * thing.
- */
-int __init virtio_cons_early_init(int (*put_chars)(u32, const char *, int))
-{
- early_put_chars = put_chars;
- return hvc_instantiate(0, 0, &hv_ops);
-}
-
static int init_port_console(struct port *port)
{
int ret;
@@ -1256,13 +1231,6 @@ static int init_port_console(struct port *port)
spin_unlock_irq(&pdrvdata_lock);
port->guest_connected = true;
- /*
- * Start using the new console output if this is the first
- * console to come up.
- */
- if (early_put_chars)
- early_put_chars = NULL;
-
/* Notify host of port being opened */
send_control_msg(port, VIRTIO_CONSOLE_PORT_OPEN, 1);
@@ -1999,7 +1967,6 @@ static int virtcons_probe(struct virtio_device *vdev)
struct ports_device *portdev;
int err;
bool multiport;
- bool early = early_put_chars != NULL;
/* We only need a config space if features are offered */
if (!vdev->config->get &&
@@ -2010,9 +1977,6 @@ static int virtcons_probe(struct virtio_device *vdev)
return -EINVAL;
}
- /* Ensure to read early_put_chars now */
- barrier();
-
portdev = kmalloc(sizeof(*portdev), GFP_KERNEL);
if (!portdev) {
err = -ENOMEM;
@@ -2100,18 +2064,6 @@ static int virtcons_probe(struct virtio_device *vdev)
__send_control_msg(portdev, VIRTIO_CONSOLE_BAD_ID,
VIRTIO_CONSOLE_DEVICE_READY, 1);
- /*
- * If there was an early virtio console, assume that there are no
- * other consoles. We need to wait until the hvc_alloc matches the
- * hvc_instantiate, otherwise tty_open will complain, resulting in
- * a "Warning: unable to open an initial console" boot failure.
- * Without multiport this is done in add_port above. With multiport
- * this might take some host<->guest communication - thus we have to
- * wait.
- */
- if (multiport && early)
- wait_for_completion(&early_console_added);
-
return 0;
free_chrdev:
diff --git a/include/linux/virtio_console.h b/include/linux/virtio_console.h
deleted file mode 100644
index d2e2785af602..000000000000
--- a/include/linux/virtio_console.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * This header, excluding the #ifdef __KERNEL__ part, is BSD licensed so
- * anyone can use the definitions to implement compatible drivers/servers:
- *
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution.
- * 3. Neither the name of IBM nor the names of its contributors
- * may be used to endorse or promote products derived from this software
- * without specific prior written permission.
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- * Copyright (C) Red Hat, Inc., 2009, 2010, 2011
- * Copyright (C) Amit Shah <amit.shah@redhat.com>, 2009, 2010, 2011
- */
-#ifndef _LINUX_VIRTIO_CONSOLE_H
-#define _LINUX_VIRTIO_CONSOLE_H
-
-#include <uapi/linux/virtio_console.h>
-
-int __init virtio_cons_early_init(int (*put_chars)(u32, const char *, int));
-#endif /* _LINUX_VIRTIO_CONSOLE_H */
--
2.43.0
^ permalink raw reply related [relevance 6%]
* [PATCH mptcp-net] MAINTAINERS: update Matthieu's email address
@ 2023-10-03 15:29 6% Matthieu Baerts
0 siblings, 0 replies; 200+ results
From: Matthieu Baerts @ 2023-10-03 15:29 UTC (permalink / raw)
To: mptcp; +Cc: Matthieu Baerts, Matthieu Baerts
Use my kernel.org account instead.
The other one will bounce by the end of the year.
Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
---
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
.mailmap | 1 +
MAINTAINERS | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index a0a6efe87186..c80903efec75 100644
--- a/.mailmap
+++ b/.mailmap
@@ -377,6 +377,7 @@ Matthew Wilcox <willy@infradead.org> <willy@debian.org>
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
Matthias Fuchs <socketcan@esd.eu> <matthias.fuchs@esd.eu>
+Matthieu Baerts <matttbe@kernel.org> <matthieu.baerts@tessares.net>
Matthieu CASTET <castet.matthieu@free.fr>
Matti Vaittinen <mazziesaccount@gmail.com> <matti.vaittinen@fi.rohmeurope.com>
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
diff --git a/MAINTAINERS b/MAINTAINERS
index 768e5cbd5868..51ba9d8a2dfc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14958,7 +14958,7 @@ K: macsec
K: \bmdo_
NETWORKING [MPTCP]
-M: Matthieu Baerts <matthieu.baerts@tessares.net>
+M: Matthieu Baerts <matttbe@kernel.org>
M: Mat Martineau <martineau@kernel.org>
L: netdev@vger.kernel.org
L: mptcp@lists.linux.dev
---
base-commit: 9de414b56675cd517b7ea3d523dd35737e89ee94
change-id: 20231003-mptcp-matt-email-6338e0aa66d3
Best regards,
--
Matthieu Baerts <matttbe@kernel.org>
^ permalink raw reply related [relevance 6%]
* [merged] documentation-llvm-update-irc-location.patch removed from -mm tree
@ 2021-09-09 21:04 6% akpm
0 siblings, 0 replies; 200+ results
From: akpm @ 2021-09-09 21:04 UTC (permalink / raw)
To: keescook, masahiroy, mm-commits, nathan, ndesaulniers,
samitolvanen
The patch titled
Subject: Documentation/llvm: update IRC location
has been removed from the -mm tree. Its filename was
documentation-llvm-update-irc-location.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Nathan Chancellor <nathan@kernel.org>
Subject: Documentation/llvm: update IRC location
This should have been done with commit 91ed3ed0f798 ("MAINTAINERS: update
ClangBuiltLinux IRC chat") but I did not realize it was in two separate
spots.
Link: https://lkml.kernel.org/r/20210825211823.6406-3-nathan@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/kbuild/llvm.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Documentation/kbuild/llvm.rst~documentation-llvm-update-irc-location
+++ a/Documentation/kbuild/llvm.rst
@@ -114,7 +114,7 @@ Getting Help
- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev>
- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_
- `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_
-- IRC: #clangbuiltlinux on chat.freenode.net
+- IRC: #clangbuiltlinux on irc.libera.chat
- `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux
- `Wiki <https://github.com/ClangBuiltLinux/linux/wiki>`_
- `Beginner Bugs <https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22>`_
_
Patches currently in -mm which might be from nathan@kernel.org are
^ permalink raw reply [relevance 6%]
* [kvm-unit-tests PATCH] MAINTAINERS: new kvmarm mailing list
@ 2022-10-25 16:07 6% ` Cornelia Huck
0 siblings, 0 replies; 200+ results
From: Cornelia Huck @ 2022-10-25 16:07 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvm, kvmarm, kvmarm, Cornelia Huck
KVM/arm64 development is moving to a new mailing list (see
https://lore.kernel.org/all/20221001091245.3900668-1-maz@kernel.org/);
kvm-unit-tests should advertise the new list as well.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 90ead214a75d..649de509a511 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -67,7 +67,8 @@ ARM
M: Andrew Jones <andrew.jones@linux.dev>
S: Supported
L: kvm@vger.kernel.org
-L: kvmarm@lists.cs.columbia.edu
+L: kvmarm@lists.linux.dev
+L: kvmarm@lists.cs.columbia.edu (deprecated)
F: arm/
F: lib/arm/
F: lib/arm64/
--
2.37.3
^ permalink raw reply related [relevance 6%]
* [kvm-unit-tests PATCH] MAINTAINERS: new kvmarm mailing list
@ 2022-10-25 16:07 6% ` Cornelia Huck
0 siblings, 0 replies; 200+ results
From: Cornelia Huck @ 2022-10-25 16:07 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvmarm, Cornelia Huck, kvmarm, kvm
KVM/arm64 development is moving to a new mailing list (see
https://lore.kernel.org/all/20221001091245.3900668-1-maz@kernel.org/);
kvm-unit-tests should advertise the new list as well.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 90ead214a75d..649de509a511 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -67,7 +67,8 @@ ARM
M: Andrew Jones <andrew.jones@linux.dev>
S: Supported
L: kvm@vger.kernel.org
-L: kvmarm@lists.cs.columbia.edu
+L: kvmarm@lists.linux.dev
+L: kvmarm@lists.cs.columbia.edu (deprecated)
F: arm/
F: lib/arm/
F: lib/arm64/
--
2.37.3
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [relevance 6%]
* [PATCH] MAINTAINERS: update maintainers of chrome-platform
@ 2023-08-03 10:08 6% Tzung-Bi Shih
0 siblings, 0 replies; 200+ results
From: Tzung-Bi Shih @ 2023-08-03 10:08 UTC (permalink / raw)
To: bleung, groeck; +Cc: chrome-platform, tzungbi
Add Tzung-Bi as a maintainer of chrome-platform.
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3be1bdfe8ecc..76299dc9a04c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4812,6 +4812,7 @@ F: drivers/input/touchscreen/chipone_icn8505.c
CHROME HARDWARE PLATFORM SUPPORT
M: Benson Leung <bleung@chromium.org>
+M: Tzung-Bi Shih <tzungbi@kernel.org>
L: chrome-platform@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
--
2.41.0.585.gd2178a4bd4-goog
^ permalink raw reply related [relevance 6%]
* [merged mm-stable] docs-mm-damon-add-a-maintainer-profile-for-damon.patch removed from -mm tree
@ 2023-02-03 6:35 6% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2023-02-03 6:35 UTC (permalink / raw)
To: mm-commits, shuah, corbet, sj, akpm
The quilt patch titled
Subject: Docs/mm/damon: add a maintainer-profile for DAMON
has been removed from the -mm tree. Its filename was
docs-mm-damon-add-a-maintainer-profile-for-damon.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: Docs/mm/damon: add a maintainer-profile for DAMON
Date: Tue, 10 Jan 2023 19:03:57 +0000
Document the basic policies and expectations for DAMON development.
Link: https://lkml.kernel.org/r/20230110190400.119388-6-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
--- a/Documentation/mm/damon/index.rst~docs-mm-damon-add-a-maintainer-profile-for-damon
+++ a/Documentation/mm/damon/index.rst
@@ -32,3 +32,4 @@ operations with no code but simple confi
faq
design
api
+ maintainer-profile
--- /dev/null
+++ a/Documentation/mm/damon/maintainer-profile.rst
@@ -0,0 +1,62 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+DAMON Maintainer Entry Profile
+==============================
+
+The DAMON subsystem covers the files that listed in 'DATA ACCESS MONITOR'
+section of 'MAINTAINERS' file.
+
+The mailing lists for the subsystem are damon@lists.linux.dev and
+linux-mm@kvack.org. Patches should be made against the mm-unstable tree [1]_
+whenever possible and posted to the mailing lists.
+
+SCM Trees
+---------
+
+There are multiple Linux trees for DAMON development. Patches under
+development or testing are queued in damon/next [2]_ by the DAMON maintainer.
+Suffieicntly reviewed patches will be queued in mm-unstable [1]_ by the memory
+management subsystem maintainer. After more sufficient tests, the patches will
+be queued in mm-stable [3]_ , and finally pull-requested to the mainline by the
+memory management subsystem maintainer.
+
+Note again the patches for review should be made against the mm-unstable
+tree[1] whenever possible. damon/next is only for preview of others' works in
+progress.
+
+Submit checklist addendum
+-------------------------
+
+When making DAMON changes, you should do below.
+
+- Build changes related outputs including kernel and documents.
+- Ensure the builds introduce no new errors or warnings.
+- Run and ensure no new failures for DAMON selftests [4]_ and kunittests [5]_ .
+
+Further doing below and putting the results will be helpful.
+
+- Run damon-tests/corr [6]_ for normal changes.
+- Run damon-tests/perf [7]_ for performance changes.
+
+Key cycle dates
+---------------
+
+Patches can be sent anytime. Key cycle dates of the mm-unstable[1] and
+mm-stable[3] trees depend on the memory management subsystem maintainer.
+
+Review cadence
+--------------
+
+The DAMON maintainer does the work on the usual work hour (09:00 to 17:00,
+Mon-Fri) in PST. The response to patches will occasionally be slow. Do not
+hesitate to send a ping if you have not heard back within a week of sending a
+patch.
+
+
+.. [1] https://git.kernel.org/akpm/mm/h/mm-unstable
+.. [2] https://git.kernel.org/sj/h/damon/next
+.. [3] https://git.kernel.org/akpm/mm/h/mm-stable
+.. [4] https://github.com/awslabs/damon-tests/blob/master/corr/run.sh#L49
+.. [5] https://github.com/awslabs/damon-tests/blob/master/corr/tests/kunit.sh
+.. [6] https://github.com/awslabs/damon-tests/tree/master/corr
+.. [7] https://github.com/awslabs/damon-tests/tree/master/perf
_
Patches currently in -mm which might be from sj@kernel.org are
scripts-spelling-add-a-few-more-typos.patch
^ permalink raw reply [relevance 6%]
* [PATCH v4 1/3] docs: add two documents about regression handling
@ 2022-02-01 10:26 6% ` Thorsten Leemhuis
0 siblings, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2022-02-01 10:26 UTC (permalink / raw)
To: linux-doc, Linus Torvalds
Cc: workflows, Linux Kernel Mailing List, Jonathan Corbet,
Randy Dunlap, regressions, Greg Kroah-Hartman, Lukas Bulwahn
Create two documents explaining various aspects around regression
handling and tracking; one is aimed at users, the other targets
developers.
The texts among others describe the first rule of Linux kernel
development and what it means in practice. They also explain what a
regression actually is and how to report one properly.
Both texts additionally provide a brief introduction to the bot the
kernel's regression tracker uses to facilitate the work, but mention the
use is optional.
To sum things up, provide a few quotes from Linus in the document for
developers to show how serious he takes regressions.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
Documentation/admin-guide/index.rst | 1 +
.../admin-guide/regressions-users.rst | 436 ++++++++++++
Documentation/process/index.rst | 1 +
Documentation/process/regressions-devs.rst | 672 ++++++++++++++++++
MAINTAINERS | 2 +
5 files changed, 1112 insertions(+)
create mode 100644 Documentation/admin-guide/regressions-users.rst
create mode 100644 Documentation/process/regressions-devs.rst
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 1bedab498104..5cb1f46c8626 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -35,6 +35,7 @@ problems and bugs in particular.
:maxdepth: 1
reporting-issues
+ regressions-users
security-bugs
bug-hunting
bug-bisect
diff --git a/Documentation/admin-guide/regressions-users.rst b/Documentation/admin-guide/regressions-users.rst
new file mode 100644
index 000000000000..d32f446e9651
--- /dev/null
+++ b/Documentation/admin-guide/regressions-users.rst
@@ -0,0 +1,436 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+.. [see the bottom of this file for redistribution information]
+
+Regressions: everything users want to know
+++++++++++++++++++++++++++++++++++++++++++
+
+"*We don't cause regressions*" is the first rule of Linux kernel development;
+Linux founder and lead developer Linus Torvalds established it himself and
+ensures it's obeyed.
+
+This document describes what the rule means for users and how the Linux kernel's
+development model ensures to address all reported regressions; aspects relevant
+for kernel developers are left to Documentation/process/regressions-devs.rst.
+
+
+The important bits (aka "TL;DR")
+================================
+
+#. It's a regression if something running fine with one Linux kernel works worse
+ or not at all with a newer version. Note, the newer kernel has to be compiled
+ using a similar configuration; the detailed explanations below describes this
+ and other fine print in more detail.
+
+#. Report your issue as outlined in Documentation/admin-guide/reporting-issues.rst,
+ it already covers all aspects important for regressions and repeated
+ below for convenience. Two of them: start your report's subject with
+ "[REGRESSION]" and CC or forward it to `the regression mailing list
+ <https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev).
+
+#. Optional, but recommended: when sending or forwarding your report, make the
+ Linux kernel regression tracking bot "regzbot" track the issue by specifying
+ when the regression started like this::
+
+ #regzbot introduced v5.13..v5.14-rc1
+
+
+All the details on Linux kernel regressions relevant for users
+==============================================================
+
+
+The important basics
+--------------------
+
+
+What is a "regression" and what is the "no regressions rule"?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's a regression if some application or practical use case running fine with
+one Linux kernel works worse or not at all with a newer version compiled using a
+similar configuration. The "no regressions rule" forbids this to take place; if
+it happens by accident, developers that caused it are expected to quickly fix
+the issue.
+
+It thus is a regression when a WiFi driver from Linux 5.13 works fine, but with
+5.14 doesn't work at all, works significantly slower, or misbehaves somehow.
+It's also a regression if a perfectly working application suddenly shows erratic
+behavior with a newer kernel version; such issues can be caused by changes in
+procfs, sysfs, or one of the many other interfaces Linux provides to userland
+software. But keep in mind, as mentioned earlier: 5.14 in this example needs to
+be built from a configuration similar to the one from 5.13. This can be achieved
+using ``make olddefconfig``, as explained in more detail below.
+
+Note the "practical use case" in the first sentence of this section: developers
+despite the "no regressions" rule are free to change any aspect of the kernel
+and even APIs or ABIs to userland, as long as no existing application or use
+case breaks.
+
+Also be aware the "no regressions" rule covers only interfaces the kernel
+provides to the userland. It thus does not apply to kernel-internal interfaces
+like the module API, which some externally developed drivers use to hook into
+the kernel.
+
+How do I report a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Just report the issue as outlined in
+Documentation/admin-guide/reporting-issues.rst, it already describes the
+important points. The following aspects described there are especially relevant
+for regressions:
+
+ * When checking for existing reports to join, also search the `archives of the
+ Linux regressions mailing list <https://lore.kernel.org/regressions/>`_ and
+ `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_.
+
+ * Start your report's subject with "[REGRESSION]".
+
+ * In your report, clearly mention the last kernel version that worked fine and
+ the first broken one. Ideally try to find the exact change causing the
+ regression using a bisection, as explained below in more detail.
+
+ * Remember to let the Linux regressions mailing list
+ (regressions@lists.linux.dev) know about your report:
+
+ * If you report the regression by mail, CC the regressions list.
+
+ * If you report your regression to some bug tracker, forward the submitted
+ report by mail to the regressions list while CCing the maintainer and the
+ mailing list for the subsystem in question.
+
+ If it's a regression within a stable or longterm series (e.g.
+ v5.15.3..v5.15.5), remember to CC the Linux stable mailing list
+ (stable@vger.kernel.org).
+
+ In case you performed a successful bisection, add everyone to the CC the
+ culprit's commit message mentions in lines starting with "Signed-off-by:".
+
+When CCing for forwarding your report to the list, consider directly telling the
+aforementioned Linux kernel regression tracking bot about your report. To do
+that, include a paragraph like this in your mail::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+
+Regzbot will then consider your mail a report for a regression introduced in the
+specified version range. In above case Linux v5.13 still worked fine and Linux
+v5.14-rc1 was the first version where you encountered the issue. If you
+performed a bisection to find the commit that caused the regression, specify the
+culprit's commit-id instead::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+Placing such a "regzbot command" is in your interest, as it will ensure the
+report won't fall through the cracks unnoticed. If you omit this, the Linux
+kernel's regressions tracker will take care of telling regzbot about your
+regression, as long as you send a copy to the regressions mailing lists. But the
+regression tracker is just one human which sometimes has to rest or occasionally
+might even enjoy some time away from computers (as crazy as that might sound).
+Relying on this person thus will result in an unnecessary delay before the
+regressions becomes mentioned `on the list of tracked and unresolved Linux
+kernel regressions <https://linux-regtracking.leemhuis.info/regzbot/>`_ and the
+weekly regression reports sent by regzbot. Such delays can result in Linus
+Torvalds being unaware of important regressions when deciding between "continue
+development or call this finished and release the final?".
+
+Are really all regressions fixed?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Nearly all of them are, as long as the change causing the regression (the
+"culprit commit") is reliably identified. Some regressions can be fixed without
+this, but often it's required.
+
+Who needs to find the root cause of a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Developers of the affected code area should try to locate the culprit on their
+own. But for them that's often impossible to do with reasonable effort, as quite
+a lot of issues only occur in a particular environment outside the developer's
+reach -- for example, a specific hardware platform, firmware, Linux distro,
+system's configuration, or application. That's why in the end it's often up to
+the reporter to locate the culprit commit; sometimes users might even need to
+run additional tests afterwards to pinpoint the exact root cause. Developers
+should offer advice and reasonably help where they can, to make this process
+relatively easy and achievable for typical users.
+
+How can I find the culprit?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Perform a bisection, as roughly outlined in
+Documentation/admin-guide/reporting-issues.rst and described in more detail by
+Documentation/admin-guide/bug-bisect.rst. It might sound like a lot of work, but
+in many cases finds the culprit relatively quickly. If it's hard or
+time-consuming to reliably reproduce the issue, consider teaming up with other
+affected users to narrow down the search range together.
+
+Who can I ask for advice when it comes to regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
+CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the
+issue might better be dealt with in private, feel free to omit the list.
+
+
+Additional details about regressions
+------------------------------------
+
+
+What is the goal of the "no regressions rule"?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Users should feel safe when updating kernel versions and not have to worry
+something might break. This is in the interest of the kernel developers to make
+updating attractive: they don't want users to stay on stable or longterm Linux
+series that are either abandoned or more than one and a half years old. That's
+in everybody's interest, as `those series might have known bugs, security
+issues, or other problematic aspects already fixed in later versions
+<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_.
+Additionally, the kernel developers want to make it simple and appealing for
+users to test the latest pre-release or regular release. That's also in
+everybody's interest, as it's a lot easier to track down and fix problems, if
+they are reported shortly after being introduced.
+
+Is the "no regressions" rule really adhered in practice?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's taken really serious, as can be seen by many mailing list posts from Linux
+creator and lead developer Linus Torvalds, some of which are quoted in
+Documentation/process/regressions-devs.rst.
+
+Exceptions to this rule are extremely rare; in the past developers almost always
+turned out to be wrong when they assumed a particular situation was warranting
+an exception.
+
+Who ensures the "no regressions" is actually followed?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The subsystem maintainers should take care of that, which are watched and
+supported by the tree maintainers -- e.g. Linus Torvalds for mainline and
+Greg Kroah-Hartman et al. for various stable/longterm series.
+
+All of them are helped by people trying to ensure no regression report falls
+through the cracks. One of them is Thorsten Leemhuis, who's currently acting as
+the Linux kernel's "regressions tracker"; to facilitate this work he relies on
+regzbot, the Linux kernel regression tracking bot. That's why you want to bring
+your report on the radar of these people by CCing or forwarding each report to
+the regressions mailing list, ideally with a "regzbot command" in your mail to
+get it tracked.
+
+Is it a regression, if the issue can be avoided by updating some software?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Almost always: yes. If a developer tells you otherwise, ask the regression
+tracker for advice as outlined above.
+
+Is it a regression, if a newer kernel works slower or consumes more energy?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Yes, but the difference has to be significant. A five percent slow-down in a
+micro-benchmark thus is unlikely to qualify as regression, unless it also
+influences the results of a broad benchmark by more than one percent. If in
+doubt, ask for advice.
+
+Is it a regression, if an external kernel module breaks when updating Linux?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+No, as the "no regression" rule is about interfaces and services the Linux
+kernel provides to the userland. It thus does not cover building or running
+externally developed kernel modules, as they run in kernel-space and hook into
+the kernel using internal interfaces occasionally changed.
+
+How are regressions handled that are caused by security fixes?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In extremely rare situations security issues can't be fixed without causing
+regressions; those are given way, as they are the lesser evil in the end.
+Luckily this middling almost always can be avoided, as key developers for the
+affected area and often Linus Torvalds himself try very hard to fix security
+issues without causing regressions.
+
+If you nevertheless face such a case, check the mailing list archives if people
+tried their best to avoid the regression; if in doubt, ask for advice as
+outlined above.
+
+What happens if fixing a regression is impossible without causing another?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sadly these things happen, but luckily not very often; if they occur, expert
+developers of the affected code area should look into the issue to find a fix
+that avoids regressions or at least their impact. If you run into such a
+situation, do what was outlined already for regressions caused by security
+fixes: check earlier discussions if people already tried their best and ask for
+advice if in doubt.
+
+A quick note while at it: these situations could be avoided, if people would
+regularly give mainline pre-releases (say v5.15-rc1 or -rc3) from each cycle a
+test run. This is best explained by imagining a change integrated between Linux
+v5.14 and v5.15-rc1 which causes a regression, but at the same time is a hard
+requirement for some other improvement applied for 5.15-rc1. All these changes
+often can simply be reverted and the regression thus solved, if someone finds
+and reports it before 5.15 is released. A few days or weeks later this solution
+can become impossible, as some software might have started to rely on aspects
+introduced by one of the follow-up changes: reverting all changes would then
+cause a regression for users of said software and thus is out of the question.
+
+Is it a regression, if some feature I relied on was removed months ago?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but often it's hard to fix such regressions due to the aspects outlined
+in the previous section. It hence needs to be dealt with on a case-by-case
+basis. This is another reason why it's in everybody's interest to regularly test
+mainline pre-releases.
+
+Does the "no regression" rule apply if I seem to be the only affected person?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but only for practical usage: the Linux developers want to be free to
+remove support for hardware only to be found in attics and museums anymore.
+
+Note, sometimes regressions can't be avoided to make progress -- and the latter
+is needed to prevent Linux from stagnation. Hence, if only very few users seem
+to be affected by a regression, it for the greater good might be in their and
+everyone else's interest to lettings things pass. Especially if there is an
+easy way to circumvent the regression somehow, for example by updating some
+software or using a kernel parameter created just for this purpose.
+
+Does the regression rule apply for code in the staging tree as well?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Not according to the `help text for the configuration option covering all
+staging code <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_,
+which since its early days states::
+
+ Please note that these drivers are under heavy development, may or
+ may not work, and may contain userspace interfaces that most likely
+ will be changed in the near future.
+
+The staging developers nevertheless often adhere to the "no regressions" rule,
+but sometimes bend it to make progress. That's for example why some users had to
+deal with (often negligible) regressions when a WiFi driver from the staging
+tree was replaced by a totally different one written from scratch.
+
+Why do later versions have to be "compiled with a similar configuration"?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Because the Linux kernel developers sometimes integrate changes known to cause
+regressions, but make them optional and disable them in the kernel's default
+configuration. This trick allows progress, as the "no regressions" rule
+otherwise would lead to stagnation.
+
+Consider for example a new security feature blocking access to some kernel
+interfaces often abused by malware, which at the same time are required to run a
+few rarely used applications. The outlined approach makes both camps happy:
+people using these applications can leave the new security feature off, while
+everyone else can enable it without running into trouble.
+
+How to create a configuration similar to the one of an older kernel?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Start your machine with a known-good kernel and configure the newer Linux
+version with ``make olddefconfig``. This makes the kernel's build scripts pick
+up the configuration file (the ".config" file) from the running kernel as base
+for the new one you are about to compile; afterwards they set all new
+configuration options to their default value, which should disable new features
+that might cause regressions.
+
+Can I report a regression I found with pre-compiled vanilla kernels?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You need to ensure the newer kernel was compiled with a similar configuration
+file as the older one (see above), as those that built them might have enabled
+some known-to-be incompatible feature for the newer kernel. If in doubt, report
+the matter to the kernel's provider and ask for advice.
+
+
+More about regression tracking with "regzbot"
+---------------------------------------------
+
+What is regression tracking and why should I care about it?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Rules like "no regressions" need someone to ensure they are followed, otherwise
+they are broken either accidentally or on purpose. History has shown this to be
+true for Linux kernel development as well. That's why Thorsten Leemhuis, the
+Linux Kernel's regression tracker, and some people try to ensure all regression
+are fixed by keeping an eye on them until they are resolved. Neither of them are
+paid for this, that's why the work is done on a best effort basis.
+
+Why and how are Linux kernel regressions tracked using a bot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Tracking regressions completely manually has proven to be quite hard due to the
+distributed and loosely structured nature of Linux kernel development process.
+That's why the Linux kernel's regression tracker developed regzbot to facilitate
+the work, with the long term goal to automate regression tracking as much as
+possible for everyone involved.
+
+Regzbot works by watching for replies to reports of tracked regressions.
+Additionally, it's looking out for posted or committed patches referencing such
+reports with "Link:" tags; replies to such patch postings are tracked as well.
+Combined this data provides good insights into the current state of the fixing
+process.
+
+How to see which regressions regzbot tracks currently?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check out `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_.
+
+What kind of issues are supposed to be tracked by regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bot is meant to track regressions, hence please don't involve regzbot for
+ordinary issues.
+
+How to change aspects of a tracked regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By using a 'regzbot command' in a direct or indirect reply to the mail with the
+report. The easiest way to do that: find the report in your "Sent" folder or the
+mailing list archive and reply to it using your mailer's "Reply-all" function.
+In that mail, use one of the following commands in a stand-alone paragraph (IOW:
+use blank lines to separate one or multiple of these commands from the rest of
+the mail's text).
+
+ * Update when the regression started to happen, for example after performing a
+ bisection::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+ * Set or update the title::
+
+ #regzbot title: foo
+
+ * Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of
+ the issue or a fix are discussed:::
+
+ #regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * Point to a place with further details of interest, like a mailing list post
+ or a ticket in a bug tracker that are slightly related, but about a different
+ topic::
+
+ #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * Mark a regression as invalid::
+
+ #regzbot invalid: wasn't a regression, problem has always existed
+
+Regzbot supports a few other commands primarily used by developers or people
+tracking regressions. They and more details about the aforementioned regzbot
+commands can be found in the `getting started guide
+<https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_ and
+the `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
+for regzbot.
+
+..
+ end-of-content
+..
+ This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
+ of the file. If you want to distribute this text under CC-BY-4.0 only,
+ please use "The Linux kernel developers" for author attribution and link
+ this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/regressions-users.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index 9f1b88492bb3..750ef43f2f0d 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -27,6 +27,7 @@ Below are the essential guides that every developer should read.
submitting-patches
programming-language
coding-style
+ regressions-devs
maintainer-handbooks
maintainer-pgp-guide
email-clients
diff --git a/Documentation/process/regressions-devs.rst b/Documentation/process/regressions-devs.rst
new file mode 100644
index 000000000000..7eb66304a694
--- /dev/null
+++ b/Documentation/process/regressions-devs.rst
@@ -0,0 +1,672 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+.. See the bottom of this file for additional redistribution information.
+
+Regressions: what developers should know
+++++++++++++++++++++++++++++++++++++++++
+
+*We don't cause regressions* -- this document describes what this "first rule of
+Linux kernel development" means in practice for developers. It complements
+Documentation/admin-guide/regressions-users.rst, which covers the topic from a
+user's point of view; if you never read that text, go and at least skim over it
+before continuing here.
+
+The important bits (aka "The TL;DR")
+====================================
+
+#. Ensure subscribers of the `regression mailing list <https://lore.kernel.org/regressions/>`_
+ (regressions@lists.linux.dev) quickly become aware of any new regression
+ report:
+
+ * When receiving a mailed report that did not CC the list, bring it into the
+ loop by immediately sending at least a brief "Reply-all" with the list
+ CCed.
+
+ * Forward or bounce any reports filed in bug trackers to the list.
+
+#. Make the Linux kernel regression tracking bot "regzbot" track the issue (this
+ is optional, but recommended):
+
+ * For mailed reports, check if the reporter included a line like ``#regzbot
+ introduced v5.13..v5.14-rc1``. If not, send a reply (with the regressions
+ list in CC) containing a paragraph like the following, which tells regzbot
+ when the issue started to happen::
+
+ #regzbot ^introduced 1f2e3d4c5b6a
+
+ * When forwarding reports from a bug tracker to the regressions list (see
+ above), include a paragraph like the following::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+ #regzbot from: Some N. Ice Human <some.human@example.com>
+ #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
+
+#. When submitting fixes for regressions, add "Link:" tags to the patch
+ description pointing to all places where the issue was reported, as
+ mandated by Documentation/process/submitting-patches.rst and
+ :ref:`Documentation/process/5.Posting.rst <development_posting>`.
+
+
+All the details on Linux kernel regressions relevant for developers
+===================================================================
+
+
+The important basics in more detail
+-----------------------------------
+
+
+What to do when receiving regression reports
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ensure the Linux kernel's regression tracker and others subscribers of the
+`regression mailing list <https://lore.kernel.org/regressions/>`_
+(regressions@lists.linux.dev) become aware of any newly reported regression:
+
+ * When you receive a report by mail that did not CC the list, immediately bring
+ it into the loop by sending at least a brief "Reply-all" with the list CCed;
+ try to ensure it gets CCed again in case you reply to a reply that omitted
+ the list.
+
+ * If a report filed in a bug tracker hits your Inbox, forward or bounce it to
+ the list. Consider checking the list archives beforehand, if the reporter
+ already forwarded the report as instructed by
+ Documentation/admin-guide/reporting-issues.rst.
+
+When doing either, consider making the Linux kernel regression tracking bot
+"regzbot" immediately start tracking the issue:
+
+ * For mailed reports, check if the reporter included a "regzbot command" like
+ ``#regzbot introduced 1f2e3d4c5b6a``. If not, send a reply (with the
+ regressions list in CC) with a paragraph like the following:::
+
+ #regzbot ^introduced: v5.13..v5.14-rc1
+
+ This tells regzbot the version range in which the issue started to happen;
+ you can specify a range using commit-ids as well or state a single commit-id
+ in case the reporter bisected the culprit.
+
+ Note the caret (^) before the "introduced": it tells regzbot to treat the
+ parent mail (the one you reply to) as the initial report for the regression
+ you want to see tracked; that's important, as regzbot will later look out
+ for patches with "Link:" tags pointing to the report in the archives on
+ lore.kernel.org.
+
+ * When forwarding a regressions reported to a bug tracker, include a paragraph
+ with these regzbot commands::
+
+ #regzbot introduced: 1f2e3d4c5b6a
+ #regzbot from: Some N. Ice Human <some.human@example.com>
+ #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
+
+ Regzbot will then automatically associate patches with the report that
+ contain "Link:" tags pointing to your mail or the mentioned ticket.
+
+What's important when fixing regressions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You don't need to do anything special when submitting fixes for regression, just
+ensure doing what Documentation/process/submitting-patches.rst and
+:ref:`Documentation/process/5.Posting.rst <development_posting>` already
+explain: add "Link:" tags to your patch description pointing to all places where
+the issue was reported like this::
+
+ Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
+
+This is expected from developers, as these pointers are of great value when you
+or others might need to look into the fix months or years later; these links are
+also crucial for tools and scripts like regzbot, as it allows them to associate
+changes with reports that were mailed or submitted to bug trackers.
+
+More aspects regarding regressions developers should be aware of
+----------------------------------------------------------------
+
+
+Whom to ask for advice when it comes to regressions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
+CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the
+issue might better be dealt with in private, feel free to omit the list.
+
+
+How to deal with changes where a risk of regression is known
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Evaluate how big the risk of regressions is, for example by performing a code
+search in Linux distributions and Git forges. Also consider asking other
+developers or projects likely to be affected to evaluate or even test the
+proposed change; if problems surface, maybe some solution acceptable for all
+can be found.
+
+If the risk of regressions in the end seems to be relatively small, go ahead
+with the change, but let all involved parties know about the risk. Hence, make
+sure your patch description makes this aspect obvious. Once the change is
+merged, tell the Linux kernel's regression tracker and the regressions mailing
+list about the risk, so everyone has the change on the radar in case reports
+trickle in. Depending on the risk, you also might want to ask the subsystem
+maintainer to mention the issue in his mainline pull request.
+
+What else is there to known about regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check out Documentation/admin-guide/regressions-users.rst, it covers a lot of
+other aspects you want might want to be aware of:
+
+ * the purpose of the "no regressions rule"
+
+ * what issues actually qualify as regression
+
+ * who's in charge for finding the root cause of a regression
+
+ * how to handle tricky situations, e.g. when a regression is caused by a
+ security fix or when fixing a regression might cause another one
+
+
+More about regression tracking and regzbot
+------------------------------------------
+
+
+Why the Linux kernel has a regression tracker, and why is regzbot used?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Rules like "no regressions" need someone to ensure they are followed, otherwise
+they are broken either accidentally or on purpose. History has shown this to be
+true for the Linux kernel as well. That's why Thorsten Leemhuis volunteered to
+keep an eye on things as the Linux kernel's regression tracker, who's
+occasionally helped by other people. Neither of them are paid to do this,
+that's why regression tracking is done on a best effort basis.
+
+Earlier attempts to manually track regressions have shown it's an exhausting and
+frustrating work, which is why they were abandoned after a while. To prevent this
+from happening again, Thorsten developed regzbot to facilitate the work, with the
+long term goal to automate regression tracking as much as possible for everyone
+involved.
+
+How does regression tracking work with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bot watches for replies to reports of tracked regressions. Additionally,
+it's looking out for posted or committed patches referencing such reports
+with "Link:" tags; replies to such patch postings are tracked as well.
+Combined this data provides good insights into the current state of the fixing
+process.
+
+Regzbot tries to do its job with as little overhead as possible for both
+reporters and developers. In fact, only reporters are burdened with an extra
+duty: they need to tell regzbot about the regression report using the ``#regzbot
+introduced`` command outlined above; if they don't do that, someone else can
+take care of that using ``#regzbot ^introduced``.
+
+For developers there normally is no extra work involved, they just need to make
+sure to do something that was expected long before regzbot came to light: add
+"Link:" tags to the patch description pointing to all reports about the issue
+fixed.
+
+Do I have to use regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's in the interest of everyone if you do, as kernel maintainers like Linus
+Torvalds partly rely on regzbot's tracking in their work -- for example when
+deciding to release a new version or extend the development phase. For this they
+need to be aware of all unfixed regression; to do that, Linus is known to look
+into the weekly reports sent by regzbot.
+
+Do I have to tell regzbot about every regression I stumble upon?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ideally yes: we are all humans and easily forget problems when something more
+important unexpectedly comes up -- for example a bigger problem in the Linux
+kernel or something in real life that's keeping us away from keyboards for a
+while. Hence, it's best to tell regzbot about every regression, except when you
+immediately write a fix and commit it to a tree regularly merged to the affected
+kernel series.
+
+How to see which regressions regzbot tracks currently?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_
+for the latest info; alternatively, `search for the latest regression report
+<https://lore.kernel.org/lkml/?q=%22Linux+regressions+report%22+f%3Aregzbot>`_,
+which regzbot normally sends out once a week on Sunday evening (UTC), which is a
+few hours before Linus usually publishes new (pre-)releases.
+
+What places is regzbot monitoring?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Regzbot is watching the most important Linux mailing lists as well as the git
+repositories of linux-next, mainline, and stable/longterm.
+
+What kind of issues are supposed to be tracked by regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bot is meant to track regressions, hence please don't involve regzbot for
+ordinary issues. But it's totally okay for the kernel's regression tracker if
+developers involve regzbot to not forget about severe issues, like reports about
+hangs, corrupted data, or internal errors (Panic, Oops, BUG(), warning, ...).
+
+Can I add regressions found by CI systems to regzbot's tracking?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Feel free to do so, if the particular regression likely has impact on practical
+use cases and thus might be noticed by users; hence, please don't involve
+regzbot for theoretical regressions unlikely to show themselves in real world
+usage.
+
+How to interact with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By using a regzbot command in a reply to the mail with the report or a reply to
+the latter. These commands need to be in their own paragraph (IOW: they need to
+be separated from the rest of the mail using blank lines).
+
+One such command is ``#regzbot introduced <version or commit>``,
+which adds a report to the tracking, as already described above;
+``#regzbot ^introduced <version or commit>`` is another such command,
+which makes regzbot consider the parent mail as a report for a regression
+which it starts to track.
+
+Once one of those two commands has been utilized, other regzbot commands can be
+used in direct or indirect replies to the report. You can write them below one
+of the `introduced` commands or in replies to the mail that used one of them
+or itself is a reply to that mail:
+
+ * Set or update the title::
+
+ #regzbot title: foo
+
+ * Link to a related discussion (for example the posting of a patch to fix the
+ issue) or bug ticket and monitor it::
+
+ #regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ Monitoring only works for lore.kernel.org and bugzilla.kernel.org; regzbot
+ will consider all messages in that thread or ticket as related to the fixing
+ process.
+
+ * Point to a place with further details, like a bug tracker or a related
+ mailing list post::
+
+ #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * Mark a regression as fixed by a commit that is heading upstream or already
+ landed::
+
+ #regzbot fixed-by: 1f2e3d4c5d
+
+ * Mark a regression as a duplicate of another one already tracked by regzbot::
+
+ #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ * Mark a regression as invalid::
+
+ #regzbot invalid: wasn't a regression, problem has always existed
+
+Is there more to tell about regzbot and its commands?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+More detailed and up-to-date information about the Linux
+kernel's regression tracking bot can be found on its
+`project page <https://gitlab.com/knurd42/regzbot>`_, which among others
+contains a `getting started guide <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
+and `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
+which both cover more details than the above section.
+
+Quotes from Linus about regression
+----------------------------------
+
+Find below a few real life examples of how Linus Torvalds expects regressions to
+be handled:
+
+ * From `2017-10-26 (1/2)
+ <https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_::
+
+ If you break existing user space setups THAT IS A REGRESSION.
+
+ It's not ok to say "but we'll fix the user space setup".
+
+ Really. NOT OK.
+
+ [...]
+
+ The first rule is:
+
+ - we don't cause regressions
+
+ and the corollary is that when regressions *do* occur, we admit to
+ them and fix them, instead of blaming user space.
+
+ The fact that you have apparently been denying the regression now for
+ three weeks means that I will revert, and I will stop pulling apparmor
+ requests until the people involved understand how kernel development
+ is done.
+
+ * From `2017-10-26 (2/2)
+ <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_::
+
+ People should basically always feel like they can update their kernel
+ and simply not have to worry about it.
+
+ I refuse to introduce "you can only update the kernel if you also
+ update that other program" kind of limitations. If the kernel used to
+ work for you, the rule is that it continues to work for you.
+
+ There have been exceptions, but they are few and far between, and they
+ generally have some major and fundamental reasons for having happened,
+ that were basically entirely unavoidable, and people _tried_hard_ to
+ avoid them. Maybe we can't practically support the hardware any more
+ after it is decades old and nobody uses it with modern kernels any
+ more. Maybe there's a serious security issue with how we did things,
+ and people actually depended on that fundamentally broken model. Maybe
+ there was some fundamental other breakage that just _had_ to have a
+ flag day for very core and fundamental reasons.
+
+ And notice that this is very much about *breaking* peoples environments.
+
+ Behavioral changes happen, and maybe we don't even support some
+ feature any more. There's a number of fields in /proc/<pid>/stat that
+ are printed out as zeroes, simply because they don't even *exist* in
+ the kernel any more, or because showing them was a mistake (typically
+ an information leak). But the numbers got replaced by zeroes, so that
+ the code that used to parse the fields still works. The user might not
+ see everything they used to see, and so behavior is clearly different,
+ but things still _work_, even if they might no longer show sensitive
+ (or no longer relevant) information.
+
+ But if something actually breaks, then the change must get fixed or
+ reverted. And it gets fixed in the *kernel*. Not by saying "well, fix
+ your user space then". It was a kernel change that exposed the
+ problem, it needs to be the kernel that corrects for it, because we
+ have a "upgrade in place" model. We don't have a "upgrade with new
+ user space".
+
+ And I seriously will refuse to take code from people who do not
+ understand and honor this very simple rule.
+
+ This rule is also not going to change.
+
+ And yes, I realize that the kernel is "special" in this respect. I'm
+ proud of it.
+
+ I have seen, and can point to, lots of projects that go "We need to
+ break that use case in order to make progress" or "you relied on
+ undocumented behavior, it sucks to be you" or "there's a better way to
+ do what you want to do, and you have to change to that new better
+ way", and I simply don't think that's acceptable outside of very early
+ alpha releases that have experimental users that know what they signed
+ up for. The kernel hasn't been in that situation for the last two
+ decades.
+
+ We do API breakage _inside_ the kernel all the time. We will fix
+ internal problems by saying "you now need to do XYZ", but then it's
+ about internal kernel API's, and the people who do that then also
+ obviously have to fix up all the in-kernel users of that API. Nobody
+ can say "I now broke the API you used, and now _you_ need to fix it
+ up". Whoever broke something gets to fix it too.
+
+ And we simply do not break user space.
+
+ * From `2020-05-21
+ <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_::
+
+ The rules about regressions have never been about any kind of
+ documented behavior, or where the code lives.
+
+ The rules about regressions are always about "breaks user workflow".
+
+ Users are literally the _only_ thing that matters.
+
+ No amount of "you shouldn't have used this" or "that behavior was
+ undefined, it's your own fault your app broke" or "that used to work
+ simply because of a kernel bug" is at all relevant.
+
+ Now, reality is never entirely black-and-white. So we've had things
+ like "serious security issue" etc that just forces us to make changes
+ that may break user space. But even then the rule is that we don't
+ really have other options that would allow things to continue.
+
+ And obviously, if users take years to even notice that something
+ broke, or if we have sane ways to work around the breakage that
+ doesn't make for too much trouble for users (ie "ok, there are a
+ handful of users, and they can use a kernel command line to work
+ around it" kind of things) we've also been a bit less strict.
+
+ But no, "that was documented to be broken" (whether it's because the
+ code was in staging or because the man-page said something else) is
+ irrelevant. If staging code is so useful that people end up using it,
+ that means that it's basically regular kernel code with a flag saying
+ "please clean this up".
+
+ The other side of the coin is that people who talk about "API
+ stability" are entirely wrong. API's don't matter either. You can make
+ any changes to an API you like - as long as nobody notices.
+
+ Again, the regression rule is not about documentation, not about
+ API's, and not about the phase of the moon.
+
+ It's entirely about "we caused problems for user space that used to work".
+
+ * From `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_::
+
+ > Now this got me wondering if Debian _unstable_ actually qualifies as a
+ > standard distro userspace.
+
+ Oh, if the kernel breaks some standard user space, that counts. Tons
+ of people run Debian unstable (and from my limited interactions with
+ it, for damn good reasons: -stable tends to run so old versions of
+ everything that you have to sometimes deal with cuneiform writing when
+ using it)
+
+ * From `2017-11-05
+ <https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_::
+
+ And our regression rule has never been "behavior doesn't change".
+ That would mean that we could never make any changes at all.
+
+ For example, we do things like add new error handling etc all the
+ time, which we then sometimes even add tests for in our kselftest
+ directory.
+
+ So clearly behavior changes all the time and we don't consider that a
+ regression per se.
+
+ The rule for a regression for the kernel is that some real user
+ workflow breaks. Not some test. Not a "look, I used to be able to do
+ X, now I can't".
+
+ * From `2018-08-03
+ <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_::
+
+ YOU ARE MISSING THE #1 KERNEL RULE.
+
+ We do not regress, and we do not regress exactly because your are 100% wrong.
+
+ And the reason you state for your opinion is in fact exactly *WHY* you
+ are wrong.
+
+ Your "good reasons" are pure and utter garbage.
+
+ The whole point of "we do not regress" is so that people can upgrade
+ the kernel and never have to worry about it.
+
+ > Kernel had a bug which has been fixed
+
+ That is *ENTIRELY* immaterial.
+
+ Guys, whether something was buggy or not DOES NOT MATTER.
+
+ Why?
+
+ Bugs happen. That's a fact of life. Arguing that "we had to break
+ something because we were fixing a bug" is completely insane. We fix
+ tens of bugs every single day, thinking that "fixing a bug" means that
+ we can break something is simply NOT TRUE.
+
+ So bugs simply aren't even relevant to the discussion. They happen,
+ they get found, they get fixed, and it has nothing to do with "we
+ break users".
+
+ Because the only thing that matters IS THE USER.
+
+ How hard is that to understand?
+
+ Anybody who uses "but it was buggy" as an argument is entirely missing
+ the point. As far as the USER was concerned, it wasn't buggy - it
+ worked for him/her.
+
+ Maybe it worked *because* the user had taken the bug into account,
+ maybe it worked because the user didn't notice - again, it doesn't
+ matter. It worked for the user.
+
+ Breaking a user workflow for a "bug" is absolutely the WORST reason
+ for breakage you can imagine.
+
+ It's basically saying "I took something that worked, and I broke it,
+ but now it's better". Do you not see how f*cking insane that statement
+ is?
+
+ And without users, your program is not a program, it's a pointless
+ piece of code that you might as well throw away.
+
+ Seriously. This is *why* the #1 rule for kernel development is "we
+ don't break users". Because "I fixed a bug" is absolutely NOT AN
+ ARGUMENT if that bug fix broke a user setup. You actually introduced a
+ MUCH BIGGER bug by "fixing" something that the user clearly didn't
+ even care about.
+
+ And dammit, we upgrade the kernel ALL THE TIME without upgrading any
+ other programs at all. It is absolutely required, because flag-days
+ and dependencies are horribly bad.
+
+ And it is also required simply because I as a kernel developer do not
+ upgrade random other tools that I don't even care about as I develop
+ the kernel, and I want any of my users to feel safe doing the same
+ time.
+
+ So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel
+ without upgrading some other random binary, then we have a problem.
+
+ * From `2021-06-05
+ <https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_::
+
+ THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS.
+
+ Honestly, security people need to understand that "not working" is not
+ a success case of security. It's a failure case.
+
+ Yes, "not working" may be secure. But security in that case is *pointless*.
+
+ * From `2021-07-30
+ <https://lore.kernel.org/lkml/CAHk-=witY33b-vqqp=ApqyoFDpx9p+n4PwG9N-TvF8bq7-tsHw@mail.gmail.com/>`_::
+
+ But we have the policy that regressions aren't about documentation or
+ even sane behavior.
+
+ Regressions are about whether a user application broke in a noticeable way.
+
+ * From `2011-05-06 (1/3)
+ <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_::
+
+ Binary compatibility is more important.
+
+ And if binaries don't use the interface to parse the format (or just
+ parse it wrongly - see the fairly recent example of adding uuid's to
+ /proc/self/mountinfo), then it's a regression.
+
+ And regressions get reverted, unless there are security issues or
+ similar that makes us go "Oh Gods, we really have to break things".
+
+ I don't understand why this simple logic is so hard for some kernel
+ developers to understand. Reality matters. Your personal wishes matter
+ NOT AT ALL.
+
+ If you made an interface that can be used without parsing the
+ interface description, then we're stuck with the interface. Theory
+ simply doesn't matter.
+
+ You could help fix the tools, and try to avoid the compatibility
+ issues that way. There aren't that many of them.
+
+ * From `2011-05-06 (2/3)
+ <https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_::
+
+ it's clearly NOT an internal tracepoint. By definition. It's being
+ used by powertop.
+
+ * From `2011-05-06 (3/3)
+ <https://lore.kernel.org/all/BANLkTinazaXRdGovYL7rRVp+j6HbJ7pzhg@mail.gmail.com/>`_::
+
+ We have programs that use that ABI and thus it's a regression if they break.
+
+ * From `2006-02-21
+ <https://lore.kernel.org/lkml/Pine.LNX.4.64.0602211631310.30245@g5.osdl.org/>`_::
+
+ The fact is, if changing the kernel breaks user-space, it's a regression.
+ IT DOES NOT MATTER WHETHER IT'S IN /sbin/hotplug OR ANYTHING ELSE. If it
+ was installed by a distribution, it's user-space. If it got installed by
+ "vmlinux", it's the kernel.
+
+ The only piece of user-space code we ship with the kernel is the system
+ call trampoline etc that the kernel sets up. THOSE interfaces we can
+ really change, because it changes with the kernel.
+
+ * From `2019-09-15
+ <https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_::
+
+ One _particularly_ last-minute revert is the top-most commit (ignoring
+ the version change itself) done just before the release, and while
+ it's very annoying, it's perhaps also instructive.
+
+ What's instructive about it is that I reverted a commit that wasn't
+ actually buggy. In fact, it was doing exactly what it set out to do,
+ and did it very well. In fact it did it _so_ well that the much
+ improved IO patterns it caused then ended up revealing a user-visible
+ regression due to a real bug in a completely unrelated area.
+
+ The actual details of that regression are not the reason I point that
+ revert out as instructive, though. It's more that it's an instructive
+ example of what counts as a regression, and what the whole "no
+ regressions" kernel rule means. The reverted commit didn't change any
+ API's, and it didn't introduce any new bugs. But it ended up exposing
+ another problem, and as such caused a kernel upgrade to fail for a
+ user. So it got reverted.
+
+ The point here being that we revert based on user-reported _behavior_,
+ not based on some "it changes the ABI" or "it caused a bug" concept.
+ The problem was really pre-existing, and it just didn't happen to
+ trigger before. The better IO patterns introduced by the change just
+ happened to expose an old bug, and people had grown to depend on the
+ previously benign behavior of that old issue.
+
+ And never fear, we'll re-introduce the fix that improved on the IO
+ patterns once we've decided just how to handle the fact that we had a
+ bad interaction with an interface that people had then just happened
+ to rely on incidental behavior for before. It's just that we'll have
+ to hash through how to do that (there are no less than three different
+ patches by three different developers being discussed, and there might
+ be more coming...). In the meantime, I reverted the thing that exposed
+ the problem to users for this release, even if I hope it will be
+ re-introduced (perhaps even backported as a stable patch) once we have
+ consensus about the issue it exposed.
+
+ Take-away from the whole thing: it's not about whether you change the
+ kernel-userspace ABI, or fix a bug, or about whether the old code
+ "should never have worked in the first place". It's about whether
+ something breaks existing users' workflow.
+
+ Anyway, that was my little aside on the whole regression thing. Since
+ it's that "first rule of kernel programming", I felt it is perhaps
+ worth just bringing it up every once in a while
+
+..
+ end-of-content
+..
+ This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
+ of the file. If you want to distribute this text under CC-BY-4.0 only,
+ please use "The Linux kernel developers" for author attribution and link
+ this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/regressions-devs.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..2a39fbc036fe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10438,6 +10438,8 @@ KERNEL REGRESSIONS
M: Thorsten Leemhuis <linux@leemhuis.info>
L: regressions@lists.linux.dev
S: Supported
+F: Documentation/admin-guide/regressions-users.rst
+F: Documentation/process/regressions-devs.rst
KERNEL SELFTEST FRAMEWORK
M: Shuah Khan <shuah@kernel.org>
--
2.31.1
^ permalink raw reply related [relevance 6%]
* [patch 098/147] Documentation/llvm: update IRC location
2021-09-08 2:58 8% ` [patch 097/147] Documentation/llvm: update mailing list Andrew Morton
@ 2021-09-08 2:58 6% ` Andrew Morton
1 sibling, 0 replies; 200+ results
From: Andrew Morton @ 2021-09-08 2:58 UTC (permalink / raw)
To: akpm, keescook, linux-mm, masahiroy, mm-commits, nathan,
ndesaulniers, samitolvanen, torvalds
From: Nathan Chancellor <nathan@kernel.org>
Subject: Documentation/llvm: update IRC location
This should have been done with commit 91ed3ed0f798 ("MAINTAINERS: update
ClangBuiltLinux IRC chat") but I did not realize it was in two separate
spots.
Link: https://lkml.kernel.org/r/20210825211823.6406-3-nathan@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/kbuild/llvm.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Documentation/kbuild/llvm.rst~documentation-llvm-update-irc-location
+++ a/Documentation/kbuild/llvm.rst
@@ -114,7 +114,7 @@ Getting Help
- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev>
- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_
- `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_
-- IRC: #clangbuiltlinux on chat.freenode.net
+- IRC: #clangbuiltlinux on irc.libera.chat
- `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux
- `Wiki <https://github.com/ClangBuiltLinux/linux/wiki>`_
- `Beginner Bugs <https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22>`_
_
^ permalink raw reply [relevance 6%]
* [merged mm-stable] docs-admin-guide-mm-damon-usage-add-damon-debugfs-interface-deprecation-notice.patch removed from -mm tree
@ 2023-02-13 23:55 6% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2023-02-13 23:55 UTC (permalink / raw)
To: mm-commits, corbet, sj, akpm
The quilt patch titled
Subject: Docs/admin-guide/mm/damon/usage: add DAMON debugfs interface deprecation notice
has been removed from the -mm tree. Its filename was
docs-admin-guide-mm-damon-usage-add-damon-debugfs-interface-deprecation-notice.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: Docs/admin-guide/mm/damon/usage: add DAMON debugfs interface deprecation notice
Date: Thu, 9 Feb 2023 19:20:07 +0000
Patch series "mm/damon: deprecate DAMON debugfs interface".
DAMON debugfs interface has announced to be deprecated after >v5.15 LTS
kernel is released. And v6.1.y has been announced to be an LTS[1].
Though the announcement was there for a while, some people might not have
noticed that so far. Also, some users could depend on it and have
problems at movng to the alternative (DAMON sysfs interface).
For such cases, keep the code and documents with warning messages and
contacts to ask helps for the deprecation.
[1] https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=332e9121320bc7461b2d3a79665caf153e51732c
This patch (of 3):
DAMON debugfs interface has announced to be deprecated after >v5.15 LTS
kernel is released. And, v6.1.y has announced to be an LTS[1].
Though the announcement was there for a while, some people might not
noticed that so far. Also, some users could depend on it and have
problems at movng to the alternative (DAMON sysfs interface).
For such cases, note DAMON debugfs interface as deprecated, and contacts
to ask helps on the document.
[1] https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=332e9121320bc7461b2d3a79665caf153e51732c
Link: https://lkml.kernel.org/r/20230209192009.7885-1-sj@kernel.org
Link: https://lkml.kernel.org/r/20230209192009.7885-2-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
--- a/Documentation/admin-guide/mm/damon/usage.rst~docs-admin-guide-mm-damon-usage-add-damon-debugfs-interface-deprecation-notice
+++ a/Documentation/admin-guide/mm/damon/usage.rst
@@ -25,10 +25,12 @@ DAMON provides below interfaces for diff
interface provides only simple :ref:`statistics <damos_stats>` for the
monitoring results. For detailed monitoring results, DAMON provides a
:ref:`tracepoint <tracepoint>`.
-- *debugfs interface.*
+- *debugfs interface. (DEPRECATED!)*
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
- <sysfs_interface>`. This will be removed after next LTS kernel is released,
- so users should move to the :ref:`sysfs interface <sysfs_interface>`.
+ <sysfs_interface>`. This is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
@@ -487,13 +489,17 @@ the files as above. Above is only for a
.. _debugfs_interface:
-debugfs Interface
-=================
+debugfs Interface (DEPRECATED!)
+===============================
.. note::
- DAMON debugfs interface will be removed after next LTS kernel is released, so
- users should move to the :ref:`sysfs interface <sysfs_interface>`.
+ THIS IS DEPRECATED!
+
+ DAMON debugfs interface is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
_
Patches currently in -mm which might be from sj@kernel.org are
^ permalink raw reply [relevance 6%]
* [PATCH v5 1/3] docs: add two documents about regression handling
@ 2022-02-16 6:51 6% ` Thorsten Leemhuis
0 siblings, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2022-02-16 6:51 UTC (permalink / raw)
To: linux-doc, Linus Torvalds, Greg Kroah-Hartman
Cc: workflows, Linux Kernel Mailing List, Jonathan Corbet,
Randy Dunlap, regressions, Lukas Bulwahn
Create two documents explaining various aspects around regression
handling and tracking; one is aimed at users, the other targets
developers.
The texts among others describes the first rule of Linux kernel
development and what it means in practice. They also explain what a
regression actually is and how to report one properly.
Both texts additionally provide a brief introduction to the bot the
kernel's regression tracker uses to facilitate the work, but mention the
use is optional.
To sum things up, provide a few quotes from Linus in the document for
developers to show how serious we take regressions.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
Documentation/admin-guide/index.rst | 1 +
.../admin-guide/reporting-regressions.rst | 439 ++++++++++++
.../process/handling-regressions.rst | 659 ++++++++++++++++++
Documentation/process/index.rst | 1 +
MAINTAINERS | 2 +
5 files changed, 1102 insertions(+)
create mode 100644 Documentation/admin-guide/reporting-regressions.rst
create mode 100644 Documentation/process/handling-regressions.rst
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 1bedab498104..5bfafcbb9562 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -35,6 +35,7 @@ problems and bugs in particular.
:maxdepth: 1
reporting-issues
+ reporting-regressions
security-bugs
bug-hunting
bug-bisect
diff --git a/Documentation/admin-guide/reporting-regressions.rst b/Documentation/admin-guide/reporting-regressions.rst
new file mode 100644
index 000000000000..6fbd24ceb3bf
--- /dev/null
+++ b/Documentation/admin-guide/reporting-regressions.rst
@@ -0,0 +1,439 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+.. [see the bottom of this file for redistribution information]
+
+Reporting regressions
++++++++++++++++++++++
+
+"*We don't cause regressions*" is the first rule of Linux kernel development;
+Linux founder and lead developer Linus Torvalds established it himself and
+ensures it's obeyed.
+
+This document describes what the rule means for users and how the Linux kernel's
+development model ensures to address all reported regressions; aspects relevant
+for kernel developers are left to Documentation/process/handling-regressions.rst.
+
+
+The important bits (aka "TL;DR")
+================================
+
+#. It's a regression if something running fine with one Linux kernel works worse
+ or not at all with a newer version. Note, the newer kernel has to be compiled
+ using a similar configuration; the detailed explanations below describes this
+ and other fine print in more detail.
+
+#. Report your issue as outlined in Documentation/admin-guide/reporting-issues.rst,
+ it already covers all aspects important for regressions and repeated
+ below for convenience. Two of them are important: start your report's subject
+ with "[REGRESSION]" and CC or forward it to `the regression mailing list
+ <https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev).
+
+#. Optional, but recommended: when sending or forwarding your report, make the
+ Linux kernel regression tracking bot "regzbot" track the issue by specifying
+ when the regression started like this::
+
+ #regzbot introduced v5.13..v5.14-rc1
+
+
+All the details on Linux kernel regressions relevant for users
+==============================================================
+
+
+The important basics
+--------------------
+
+
+What is a "regression" and what is the "no regressions rule"?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's a regression if some application or practical use case running fine with
+one Linux kernel works worse or not at all with a newer version compiled using a
+similar configuration. The "no regressions rule" forbids this to take place; if
+it happens by accident, developers that caused it are expected to quickly fix
+the issue.
+
+It thus is a regression when a WiFi driver from Linux 5.13 works fine, but with
+5.14 doesn't work at all, works significantly slower, or misbehaves somehow.
+It's also a regression if a perfectly working application suddenly shows erratic
+behavior with a newer kernel version; such issues can be caused by changes in
+procfs, sysfs, or one of the many other interfaces Linux provides to userland
+software. But keep in mind, as mentioned earlier: 5.14 in this example needs to
+be built from a configuration similar to the one from 5.13. This can be achieved
+using ``make olddefconfig``, as explained in more detail below.
+
+Note the "practical use case" in the first sentence of this section: developers
+despite the "no regressions" rule are free to change any aspect of the kernel
+and even APIs or ABIs to userland, as long as no existing application or use
+case breaks.
+
+Also be aware the "no regressions" rule covers only interfaces the kernel
+provides to the userland. It thus does not apply to kernel-internal interfaces
+like the module API, which some externally developed drivers use to hook into
+the kernel.
+
+How do I report a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Just report the issue as outlined in
+Documentation/admin-guide/reporting-issues.rst, it already describes the
+important points. The following aspects outlined there are especially relevant
+for regressions:
+
+ * When checking for existing reports to join, also search the `archives of the
+ Linux regressions mailing list <https://lore.kernel.org/regressions/>`_ and
+ `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_.
+
+ * Start your report's subject with "[REGRESSION]".
+
+ * In your report, clearly mention the last kernel version that worked fine and
+ the first broken one. Ideally try to find the exact change causing the
+ regression using a bisection, as explained below in more detail.
+
+ * Remember to let the Linux regressions mailing list
+ (regressions@lists.linux.dev) know about your report:
+
+ * If you report the regression by mail, CC the regressions list.
+
+ * If you report your regression to some bug tracker, forward the submitted
+ report by mail to the regressions list while CCing the maintainer and the
+ mailing list for the subsystem in question.
+
+ If it's a regression within a stable or longterm series (e.g.
+ v5.15.3..v5.15.5), remember to CC the `Linux stable mailing list
+ <https://lore.kernel.org/stable/>`_ (stable@vger.kernel.org).
+
+ In case you performed a successful bisection, add everyone to the CC the
+ culprit's commit message mentions in lines starting with "Signed-off-by:".
+
+When CCing for forwarding your report to the list, consider directly telling the
+aforementioned Linux kernel regression tracking bot about your report. To do
+that, include a paragraph like this in your mail::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+
+Regzbot will then consider your mail a report for a regression introduced in the
+specified version range. In above case Linux v5.13 still worked fine and Linux
+v5.14-rc1 was the first version where you encountered the issue. If you
+performed a bisection to find the commit that caused the regression, specify the
+culprit's commit-id instead::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+Placing such a "regzbot command" is in your interest, as it will ensure the
+report won't fall through the cracks unnoticed. If you omit this, the Linux
+kernel's regressions tracker will take care of telling regzbot about your
+regression, as long as you send a copy to the regressions mailing lists. But the
+regression tracker is just one human which sometimes has to rest or occasionally
+might even enjoy some time away from computers (as crazy as that might sound).
+Relying on this person thus will result in an unnecessary delay before the
+regressions becomes mentioned `on the list of tracked and unresolved Linux
+kernel regressions <https://linux-regtracking.leemhuis.info/regzbot/>`_ and the
+weekly regression reports sent by regzbot. Such delays can result in Linus
+Torvalds being unaware of important regressions when deciding between "continue
+development or call this finished and release the final?".
+
+Are really all regressions fixed?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Nearly all of them are, as long as the change causing the regression (the
+"culprit commit") is reliably identified. Some regressions can be fixed without
+this, but often it's required.
+
+Who needs to find the root cause of a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Developers of the affected code area should try to locate the culprit on their
+own. But for them that's often impossible to do with reasonable effort, as quite
+a lot of issues only occur in a particular environment outside the developer's
+reach -- for example, a specific hardware platform, firmware, Linux distro,
+system's configuration, or application. That's why in the end it's often up to
+the reporter to locate the culprit commit; sometimes users might even need to
+run additional tests afterwards to pinpoint the exact root cause. Developers
+should offer advice and reasonably help where they can, to make this process
+relatively easy and achievable for typical users.
+
+How can I find the culprit?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Perform a bisection, as roughly outlined in
+Documentation/admin-guide/reporting-issues.rst and described in more detail by
+Documentation/admin-guide/bug-bisect.rst. It might sound like a lot of work, but
+in many cases finds the culprit relatively quickly. If it's hard or
+time-consuming to reliably reproduce the issue, consider teaming up with other
+affected users to narrow down the search range together.
+
+Who can I ask for advice when it comes to regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
+CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the
+issue might better be dealt with in private, feel free to omit the list.
+
+
+Additional details about regressions
+------------------------------------
+
+
+What is the goal of the "no regressions rule"?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Users should feel safe when updating kernel versions and not have to worry
+something might break. This is in the interest of the kernel developers to make
+updating attractive: they don't want users to stay on stable or longterm Linux
+series that are either abandoned or more than one and a half years old. That's
+in everybody's interest, as `those series might have known bugs, security
+issues, or other problematic aspects already fixed in later versions
+<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_.
+Additionally, the kernel developers want to make it simple and appealing for
+users to test the latest pre-release or regular release. That's also in
+everybody's interest, as it's a lot easier to track down and fix problems, if
+they are reported shortly after being introduced.
+
+Is the "no regressions" rule really adhered in practice?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's taken really seriously, as can be seen by many mailing list posts from
+Linux creator and lead developer Linus Torvalds, some of which are quoted in
+Documentation/process/handling-regressions.rst.
+
+Exceptions to this rule are extremely rare; in the past developers almost always
+turned out to be wrong when they assumed a particular situation was warranting
+an exception.
+
+Who ensures the "no regressions" is actually followed?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The subsystem maintainers should take care of that, which are watched and
+supported by the tree maintainers -- e.g. Linus Torvalds for mainline and
+Greg Kroah-Hartman et al. for various stable/longterm series.
+
+All of them are helped by people trying to ensure no regression report falls
+through the cracks. One of them is Thorsten Leemhuis, who's currently acting as
+the Linux kernel's "regressions tracker"; to facilitate this work he relies on
+regzbot, the Linux kernel regression tracking bot. That's why you want to bring
+your report on the radar of these people by CCing or forwarding each report to
+the regressions mailing list, ideally with a "regzbot command" in your mail to
+get it tracked immediately.
+
+Is it a regression, if the issue can be avoided by updating some software?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Almost always: yes. If a developer tells you otherwise, ask the regression
+tracker for advice as outlined above.
+
+Is it a regression, if a newer kernel works slower or consumes more energy?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Yes, but the difference has to be significant. A five percent slow-down in a
+micro-benchmark thus is unlikely to qualify as regression, unless it also
+influences the results of a broad benchmark by more than one percent. If in
+doubt, ask for advice.
+
+Is it a regression, if an external kernel module breaks when updating Linux?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+No, as the "no regression" rule is about interfaces and services the Linux
+kernel provides to the userland. It thus does not cover building or running
+externally developed kernel modules, as they run in kernel-space and hook into
+the kernel using internal interfaces occasionally changed.
+
+How are regressions handled that are caused by security fixes?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In extremely rare situations security issues can't be fixed without causing
+regressions; those fixes are given way, as they are the lesser evil in the end.
+Luckily this middling almost always can be avoided, as key developers for the
+affected area and often Linus Torvalds himself try very hard to fix security
+issues without causing regressions.
+
+If you nevertheless face such a case, check the mailing list archives if people
+tried their best to avoid the regression. If not, report it; if in doubt, ask
+for advice as outlined above.
+
+What happens if fixing a regression is impossible without causing another?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sadly these things happen, but luckily not very often; if they occur, expert
+developers of the affected code area should look into the issue to find a fix
+that avoids regressions or at least their impact. If you run into such a
+situation, do what was outlined already for regressions caused by security
+fixes: check earlier discussions if people already tried their best and ask for
+advice if in doubt.
+
+A quick note while at it: these situations could be avoided, if people would
+regularly give mainline pre-releases (say v5.15-rc1 or -rc3) from each
+development cycle a test run. This is best explained by imagining a change
+integrated between Linux v5.14 and v5.15-rc1 which causes a regression, but at
+the same time is a hard requirement for some other improvement applied for
+5.15-rc1. All these changes often can simply be reverted and the regression thus
+solved, if someone finds and reports it before 5.15 is released. A few days or
+weeks later this solution can become impossible, as some software might have
+started to rely on aspects introduced by one of the follow-up changes: reverting
+all changes would then cause a regression for users of said software and thus is
+out of the question.
+
+Is it a regression, if some feature I relied on was removed months ago?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It is, but often it's hard to fix such regressions due to the aspects outlined
+in the previous section. It hence needs to be dealt with on a case-by-case
+basis. This is another reason why it's in everybody's interest to regularly test
+mainline pre-releases.
+
+Does the "no regression" rule apply if I seem to be the only affected person?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but only for practical usage: the Linux developers want to be free to
+remove support for hardware only to be found in attics and museums anymore.
+
+Note, sometimes regressions can't be avoided to make progress -- and the latter
+is needed to prevent Linux from stagnation. Hence, if only very few users seem
+to be affected by a regression, it for the greater good might be in their and
+everyone else's interest to lettings things pass. Especially if there is an
+easy way to circumvent the regression somehow, for example by updating some
+software or using a kernel parameter created just for this purpose.
+
+Does the regression rule apply for code in the staging tree as well?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Not according to the `help text for the configuration option covering all
+staging code <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_,
+which since its early days states::
+
+ Please note that these drivers are under heavy development, may or
+ may not work, and may contain userspace interfaces that most likely
+ will be changed in the near future.
+
+The staging developers nevertheless often adhere to the "no regressions" rule,
+but sometimes bend it to make progress. That's for example why some users had to
+deal with (often negligible) regressions when a WiFi driver from the staging
+tree was replaced by a totally different one written from scratch.
+
+Why do later versions have to be "compiled with a similar configuration"?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Because the Linux kernel developers sometimes integrate changes known to cause
+regressions, but make them optional and disable them in the kernel's default
+configuration. This trick allows progress, as the "no regressions" rule
+otherwise would lead to stagnation.
+
+Consider for example a new security feature blocking access to some kernel
+interfaces often abused by malware, which at the same time are required to run a
+few rarely used applications. The outlined approach makes both camps happy:
+people using these applications can leave the new security feature off, while
+everyone else can enable it without running into trouble.
+
+How to create a configuration similar to the one of an older kernel?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Start your machine with a known-good kernel and configure the newer Linux
+version with ``make olddefconfig``. This makes the kernel's build scripts pick
+up the configuration file (the ".config" file) from the running kernel as base
+for the new one you are about to compile; afterwards they set all new
+configuration options to their default value, which should disable new features
+that might cause regressions.
+
+Can I report a regression I found with pre-compiled vanilla kernels?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You need to ensure the newer kernel was compiled with a similar configuration
+file as the older one (see above), as those that built them might have enabled
+some known-to-be incompatible feature for the newer kernel. If in doubt, report
+the matter to the kernel's provider and ask for advice.
+
+
+More about regression tracking with "regzbot"
+---------------------------------------------
+
+What is regression tracking and why should I care about it?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Rules like "no regressions" need someone to ensure they are followed, otherwise
+they are broken either accidentally or on purpose. History has shown this to be
+true for Linux kernel development as well. That's why Thorsten Leemhuis, the
+Linux Kernel's regression tracker, and some people try to ensure all regression
+are fixed by keeping an eye on them until they are resolved. Neither of them are
+paid for this, that's why the work is done on a best effort basis.
+
+Why and how are Linux kernel regressions tracked using a bot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Tracking regressions completely manually has proven to be quite hard due to the
+distributed and loosely structured nature of Linux kernel development process.
+That's why the Linux kernel's regression tracker developed regzbot to facilitate
+the work, with the long term goal to automate regression tracking as much as
+possible for everyone involved.
+
+Regzbot works by watching for replies to reports of tracked regressions.
+Additionally, it's looking out for posted or committed patches referencing such
+reports with "Link:" tags; replies to such patch postings are tracked as well.
+Combined this data provides good insights into the current state of the fixing
+process.
+
+How to see which regressions regzbot tracks currently?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check out `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_.
+
+What kind of issues are supposed to be tracked by regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bot is meant to track regressions, hence please don't involve regzbot for
+regular issues. But it's okay for the Linux kernel's regression tracker if you
+involve regzbot to track severe issues, like reports about hangs, corrupted
+data, or internal errors (Panic, Oops, BUG(), warning, ...).
+
+How to change aspects of a tracked regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By using a 'regzbot command' in a direct or indirect reply to the mail with the
+report. The easiest way to do that: find the report in your "Sent" folder or the
+mailing list archive and reply to it using your mailer's "Reply-all" function.
+In that mail, use one of the following commands in a stand-alone paragraph (IOW:
+use blank lines to separate one or multiple of these commands from the rest of
+the mail's text).
+
+ * Update when the regression started to happen, for example after performing a
+ bisection::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+ * Set or update the title::
+
+ #regzbot title: foo
+
+ * Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of
+ the issue or a fix are discussed:::
+
+ #regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * Point to a place with further details of interest, like a mailing list post
+ or a ticket in a bug tracker that are slightly related, but about a different
+ topic::
+
+ #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * Mark a regression as invalid::
+
+ #regzbot invalid: wasn't a regression, problem has always existed
+
+Regzbot supports a few other commands primarily used by developers or people
+tracking regressions. They and more details about the aforementioned regzbot
+commands can be found in the `getting started guide
+<https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_ and
+the `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
+for regzbot.
+
+..
+ end-of-content
+..
+ This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
+ of the file. If you want to distribute this text under CC-BY-4.0 only,
+ please use "The Linux kernel developers" for author attribution and link
+ this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-regressions.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst
new file mode 100644
index 000000000000..e1102a3207e3
--- /dev/null
+++ b/Documentation/process/handling-regressions.rst
@@ -0,0 +1,659 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+.. See the bottom of this file for additional redistribution information.
+
+Handling regressions
+++++++++++++++++++++
+
+*We don't cause regressions* -- this document describes what this "first rule of
+Linux kernel development" means in practice for developers. It complements
+Documentation/admin-guide/reporting-regressions.rst, which covers the topic from a
+user's point of view; if you never read that text, go and at least skim over it
+before continuing here.
+
+The important bits (aka "The TL;DR")
+====================================
+
+#. Ensure subscribers of the `regression mailing list <https://lore.kernel.org/regressions/>`_
+ (regressions@lists.linux.dev) quickly become aware of any new regression
+ report:
+
+ * When receiving a mailed report that did not CC the list, bring it into the
+ loop by immediately sending at least a brief "Reply-all" with the list
+ CCed.
+
+ * Forward or bounce any reports submitted in bug trackers to the list.
+
+#. Make the Linux kernel regression tracking bot "regzbot" track the issue (this
+ is optional, but recommended):
+
+ * For mailed reports, check if the reporter included a line like ``#regzbot
+ introduced v5.13..v5.14-rc1``. If not, send a reply (with the regressions
+ list in CC) containing a paragraph like the following, which tells regzbot
+ when the issue started to happen::
+
+ #regzbot ^introduced 1f2e3d4c5b6a
+
+ * When forwarding reports from a bug tracker to the regressions list (see
+ above), include a paragraph like the following::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+ #regzbot from: Some N. Ice Human <some.human@example.com>
+ #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
+
+#. When submitting fixes for regressions, add "Link:" tags to the patch
+ description pointing to all places where the issue was reported, as
+ mandated by Documentation/process/submitting-patches.rst and
+ :ref:`Documentation/process/5.Posting.rst <development_posting>`.
+
+
+All the details on Linux kernel regressions relevant for developers
+===================================================================
+
+
+The important basics in more detail
+-----------------------------------
+
+
+What to do when receiving regression reports
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ensure the Linux kernel's regression tracker and others subscribers of the
+`regression mailing list <https://lore.kernel.org/regressions/>`_
+(regressions@lists.linux.dev) become aware of any newly reported regression:
+
+ * When you receive a report by mail that did not CC the list, immediately bring
+ it into the loop by sending at least a brief "Reply-all" with the list CCed;
+ try to ensure it gets CCed again in case you reply to a reply that omitted
+ the list.
+
+ * If a report submitted in a bug tracker hits your Inbox, forward or bounce it
+ to the list. Consider checking the list archives beforehand, if the reporter
+ already forwarded the report as instructed by
+ Documentation/admin-guide/reporting-issues.rst.
+
+When doing either, consider making the Linux kernel regression tracking bot
+"regzbot" immediately start tracking the issue:
+
+ * For mailed reports, check if the reporter included a "regzbot command" like
+ ``#regzbot introduced 1f2e3d4c5b6a``. If not, send a reply (with the
+ regressions list in CC) with a paragraph like the following:::
+
+ #regzbot ^introduced: v5.13..v5.14-rc1
+
+ This tells regzbot the version range in which the issue started to happen;
+ you can specify a range using commit-ids as well or state a single commit-id
+ in case the reporter bisected the culprit.
+
+ Note the caret (^) before the "introduced": it tells regzbot to treat the
+ parent mail (the one you reply to) as the initial report for the regression
+ you want to see tracked; that's important, as regzbot will later look out
+ for patches with "Link:" tags pointing to the report in the archives on
+ lore.kernel.org.
+
+ * When forwarding a regressions reported to a bug tracker, include a paragraph
+ with these regzbot commands::
+
+ #regzbot introduced: 1f2e3d4c5b6a
+ #regzbot from: Some N. Ice Human <some.human@example.com>
+ #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
+
+ Regzbot will then automatically associate patches with the report that
+ contain "Link:" tags pointing to your mail or the mentioned ticket.
+
+What's important when fixing regressions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You don't need to do anything special when submitting fixes for regression, just
+remember to do what Documentation/process/submitting-patches.rst,
+:ref:`Documentation/process/5.Posting.rst <development_posting>`, and
+Documentation/process/stable-kernel-rules.rst already explain in more detail:
+
+ * Point to all places where the issue was reported using "Link:" tags::
+
+ Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
+
+ * Add a "Fixes:" tag to specify the commit causing the regression.
+
+ * If the culprit was merged in an earlier development cycle, explicitly mark
+ the fix for backporting using the ``Cc: stable@vger.kernel.org`` tag.
+
+All this is expected from you and important when it comes to regression, as
+these tags are of great value for everyone (you included) that might be looking
+into the issue weeks, months, or years later. These tags are also crucial for
+tools and scripts used by other kernel developers or Linux distributions; one of
+these tools is regzbot, which heavily relies on the "Link:" tags to associate
+reports for regression with changes resolving them.
+
+
+More aspects regarding regressions developers should be aware of
+----------------------------------------------------------------
+
+
+How to deal with changes where a risk of regression is known
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Evaluate how big the risk of regressions is, for example by performing a code
+search in Linux distributions and Git forges. Also consider asking other
+developers or projects likely to be affected to evaluate or even test the
+proposed change; if problems surface, maybe some solution acceptable for all
+can be found.
+
+If the risk of regressions in the end seems to be relatively small, go ahead
+with the change, but let all involved parties know about the risk. Hence, make
+sure your patch description makes this aspect obvious. Once the change is
+merged, tell the Linux kernel's regression tracker and the regressions mailing
+list about the risk, so everyone has the change on the radar in case reports
+trickle in. Depending on the risk, you also might want to ask the subsystem
+maintainer to mention the issue in his mainline pull request.
+
+What else is there to known about regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot
+of other aspects you want might want to be aware of:
+
+ * the purpose of the "no regressions rule"
+
+ * what issues actually qualify as regression
+
+ * who's in charge for finding the root cause of a regression
+
+ * how to handle tricky situations, e.g. when a regression is caused by a
+ security fix or when fixing a regression might cause another one
+
+Whom to ask for advice when it comes to regressions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
+CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the
+issue might better be dealt with in private, feel free to omit the list.
+
+
+More about regression tracking and regzbot
+------------------------------------------
+
+
+Why the Linux kernel has a regression tracker, and why is regzbot used?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Rules like "no regressions" need someone to ensure they are followed, otherwise
+they are broken either accidentally or on purpose. History has shown this to be
+true for the Linux kernel as well. That's why Thorsten Leemhuis volunteered to
+keep an eye on things as the Linux kernel's regression tracker, who's
+occasionally helped by other people. Neither of them are paid to do this,
+that's why regression tracking is done on a best effort basis.
+
+Earlier attempts to manually track regressions have shown it's an exhausting and
+frustrating work, which is why they were abandoned after a while. To prevent
+this from happening again, Thorsten developed regzbot to facilitate the work,
+with the long term goal to automate regression tracking as much as possible for
+everyone involved.
+
+How does regression tracking work with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bot watches for replies to reports of tracked regressions. Additionally,
+it's looking out for posted or committed patches referencing such reports
+with "Link:" tags; replies to such patch postings are tracked as well.
+Combined this data provides good insights into the current state of the fixing
+process.
+
+Regzbot tries to do its job with as little overhead as possible for both
+reporters and developers. In fact, only reporters are burdened with an extra
+duty: they need to tell regzbot about the regression report using the ``#regzbot
+introduced`` command outlined above; if they don't do that, someone else can
+take care of that using ``#regzbot ^introduced``.
+
+For developers there normally is no extra work involved, they just need to make
+sure to do something that was expected long before regzbot came to light: add
+"Link:" tags to the patch description pointing to all reports about the issue
+fixed.
+
+Do I have to use regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's in the interest of everyone if you do, as kernel maintainers like Linus
+Torvalds partly rely on regzbot's tracking in their work -- for example when
+deciding to release a new version or extend the development phase. For this they
+need to be aware of all unfixed regression; to do that, Linus is known to look
+into the weekly reports sent by regzbot.
+
+Do I have to tell regzbot about every regression I stumble upon?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ideally yes: we are all humans and easily forget problems when something more
+important unexpectedly comes up -- for example a bigger problem in the Linux
+kernel or something in real life that's keeping us away from keyboards for a
+while. Hence, it's best to tell regzbot about every regression, except when you
+immediately write a fix and commit it to a tree regularly merged to the affected
+kernel series.
+
+How to see which regressions regzbot tracks currently?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_
+for the latest info; alternatively, `search for the latest regression report
+<https://lore.kernel.org/lkml/?q=%22Linux+regressions+report%22+f%3Aregzbot>`_,
+which regzbot normally sends out once a week on Sunday evening (UTC), which is a
+few hours before Linus usually publishes new (pre-)releases.
+
+What places is regzbot monitoring?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Regzbot is watching the most important Linux mailing lists as well as the git
+repositories of linux-next, mainline, and stable/longterm.
+
+What kind of issues are supposed to be tracked by regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bot is meant to track regressions, hence please don't involve regzbot for
+regular issues. But it's okay for the Linux kernel's regression tracker if you
+use regzbot to track severe issues, like reports about hangs, corrupted data,
+or internal errors (Panic, Oops, BUG(), warning, ...).
+
+Can I add regressions found by CI systems to regzbot's tracking?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Feel free to do so, if the particular regression likely has impact on practical
+use cases and thus might be noticed by users; hence, please don't involve
+regzbot for theoretical regressions unlikely to show themselves in real world
+usage.
+
+How to interact with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By using a 'regzbot command' in a direct or indirect reply to the mail with the
+regression report. These commands need to be in their own paragraph (IOW: they
+need to be separated from the rest of the mail using blank lines).
+
+One such command is ``#regzbot introduced <version or commit>``, which makes
+regzbot consider your mail as a regressions report added to the tracking, as
+already described above; ``#regzbot ^introduced <version or commit>`` is another
+such command, which makes regzbot consider the parent mail as a report for a
+regression which it starts to track.
+
+Once one of those two commands has been utilized, other regzbot commands can be
+used in direct or indirect replies to the report. You can write them below one
+of the `introduced` commands or in replies to the mail that used one of them
+or itself is a reply to that mail:
+
+ * Set or update the title::
+
+ #regzbot title: foo
+
+ * Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of
+ the issue or a fix are discussed -- for example the posting of a patch fixing
+ the regression::
+
+ #regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ Monitoring only works for lore.kernel.org and bugzilla.kernel.org; regzbot
+ will consider all messages in that thread or ticket as related to the fixing
+ process.
+
+ * Point to a place with further details of interest, like a mailing list post
+ or a ticket in a bug tracker that are slightly related, but about a different
+ topic::
+
+ #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * Mark a regression as fixed by a commit that is heading upstream or already
+ landed::
+
+ #regzbot fixed-by: 1f2e3d4c5d
+
+ * Mark a regression as a duplicate of another one already tracked by regzbot::
+
+ #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ * Mark a regression as invalid::
+
+ #regzbot invalid: wasn't a regression, problem has always existed
+
+Is there more to tell about regzbot and its commands?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+More detailed and up-to-date information about the Linux
+kernel's regression tracking bot can be found on its
+`project page <https://gitlab.com/knurd42/regzbot>`_, which among others
+contains a `getting started guide <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
+and `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
+which both cover more details than the above section.
+
+Quotes from Linus about regression
+----------------------------------
+
+Find below a few real life examples of how Linus Torvalds expects regressions to
+be handled:
+
+ * From `2017-10-26 (1/2)
+ <https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_::
+
+ If you break existing user space setups THAT IS A REGRESSION.
+
+ It's not ok to say "but we'll fix the user space setup".
+
+ Really. NOT OK.
+
+ [...]
+
+ The first rule is:
+
+ - we don't cause regressions
+
+ and the corollary is that when regressions *do* occur, we admit to
+ them and fix them, instead of blaming user space.
+
+ The fact that you have apparently been denying the regression now for
+ three weeks means that I will revert, and I will stop pulling apparmor
+ requests until the people involved understand how kernel development
+ is done.
+
+ * From `2017-10-26 (2/2)
+ <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_::
+
+ People should basically always feel like they can update their kernel
+ and simply not have to worry about it.
+
+ I refuse to introduce "you can only update the kernel if you also
+ update that other program" kind of limitations. If the kernel used to
+ work for you, the rule is that it continues to work for you.
+
+ There have been exceptions, but they are few and far between, and they
+ generally have some major and fundamental reasons for having happened,
+ that were basically entirely unavoidable, and people _tried_hard_ to
+ avoid them. Maybe we can't practically support the hardware any more
+ after it is decades old and nobody uses it with modern kernels any
+ more. Maybe there's a serious security issue with how we did things,
+ and people actually depended on that fundamentally broken model. Maybe
+ there was some fundamental other breakage that just _had_ to have a
+ flag day for very core and fundamental reasons.
+
+ And notice that this is very much about *breaking* peoples environments.
+
+ Behavioral changes happen, and maybe we don't even support some
+ feature any more. There's a number of fields in /proc/<pid>/stat that
+ are printed out as zeroes, simply because they don't even *exist* in
+ the kernel any more, or because showing them was a mistake (typically
+ an information leak). But the numbers got replaced by zeroes, so that
+ the code that used to parse the fields still works. The user might not
+ see everything they used to see, and so behavior is clearly different,
+ but things still _work_, even if they might no longer show sensitive
+ (or no longer relevant) information.
+
+ But if something actually breaks, then the change must get fixed or
+ reverted. And it gets fixed in the *kernel*. Not by saying "well, fix
+ your user space then". It was a kernel change that exposed the
+ problem, it needs to be the kernel that corrects for it, because we
+ have a "upgrade in place" model. We don't have a "upgrade with new
+ user space".
+
+ And I seriously will refuse to take code from people who do not
+ understand and honor this very simple rule.
+
+ This rule is also not going to change.
+
+ And yes, I realize that the kernel is "special" in this respect. I'm
+ proud of it.
+
+ I have seen, and can point to, lots of projects that go "We need to
+ break that use case in order to make progress" or "you relied on
+ undocumented behavior, it sucks to be you" or "there's a better way to
+ do what you want to do, and you have to change to that new better
+ way", and I simply don't think that's acceptable outside of very early
+ alpha releases that have experimental users that know what they signed
+ up for. The kernel hasn't been in that situation for the last two
+ decades.
+
+ We do API breakage _inside_ the kernel all the time. We will fix
+ internal problems by saying "you now need to do XYZ", but then it's
+ about internal kernel API's, and the people who do that then also
+ obviously have to fix up all the in-kernel users of that API. Nobody
+ can say "I now broke the API you used, and now _you_ need to fix it
+ up". Whoever broke something gets to fix it too.
+
+ And we simply do not break user space.
+
+ * From `2020-05-21
+ <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_::
+
+ The rules about regressions have never been about any kind of
+ documented behavior, or where the code lives.
+
+ The rules about regressions are always about "breaks user workflow".
+
+ Users are literally the _only_ thing that matters.
+
+ No amount of "you shouldn't have used this" or "that behavior was
+ undefined, it's your own fault your app broke" or "that used to work
+ simply because of a kernel bug" is at all relevant.
+
+ Now, reality is never entirely black-and-white. So we've had things
+ like "serious security issue" etc that just forces us to make changes
+ that may break user space. But even then the rule is that we don't
+ really have other options that would allow things to continue.
+
+ And obviously, if users take years to even notice that something
+ broke, or if we have sane ways to work around the breakage that
+ doesn't make for too much trouble for users (ie "ok, there are a
+ handful of users, and they can use a kernel command line to work
+ around it" kind of things) we've also been a bit less strict.
+
+ But no, "that was documented to be broken" (whether it's because the
+ code was in staging or because the man-page said something else) is
+ irrelevant. If staging code is so useful that people end up using it,
+ that means that it's basically regular kernel code with a flag saying
+ "please clean this up".
+
+ The other side of the coin is that people who talk about "API
+ stability" are entirely wrong. API's don't matter either. You can make
+ any changes to an API you like - as long as nobody notices.
+
+ Again, the regression rule is not about documentation, not about
+ API's, and not about the phase of the moon.
+
+ It's entirely about "we caused problems for user space that used to work".
+
+ * From `2017-11-05
+ <https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_::
+
+ And our regression rule has never been "behavior doesn't change".
+ That would mean that we could never make any changes at all.
+
+ For example, we do things like add new error handling etc all the
+ time, which we then sometimes even add tests for in our kselftest
+ directory.
+
+ So clearly behavior changes all the time and we don't consider that a
+ regression per se.
+
+ The rule for a regression for the kernel is that some real user
+ workflow breaks. Not some test. Not a "look, I used to be able to do
+ X, now I can't".
+
+ * From `2018-08-03
+ <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_::
+
+ YOU ARE MISSING THE #1 KERNEL RULE.
+
+ We do not regress, and we do not regress exactly because your are 100% wrong.
+
+ And the reason you state for your opinion is in fact exactly *WHY* you
+ are wrong.
+
+ Your "good reasons" are pure and utter garbage.
+
+ The whole point of "we do not regress" is so that people can upgrade
+ the kernel and never have to worry about it.
+
+ > Kernel had a bug which has been fixed
+
+ That is *ENTIRELY* immaterial.
+
+ Guys, whether something was buggy or not DOES NOT MATTER.
+
+ Why?
+
+ Bugs happen. That's a fact of life. Arguing that "we had to break
+ something because we were fixing a bug" is completely insane. We fix
+ tens of bugs every single day, thinking that "fixing a bug" means that
+ we can break something is simply NOT TRUE.
+
+ So bugs simply aren't even relevant to the discussion. They happen,
+ they get found, they get fixed, and it has nothing to do with "we
+ break users".
+
+ Because the only thing that matters IS THE USER.
+
+ How hard is that to understand?
+
+ Anybody who uses "but it was buggy" as an argument is entirely missing
+ the point. As far as the USER was concerned, it wasn't buggy - it
+ worked for him/her.
+
+ Maybe it worked *because* the user had taken the bug into account,
+ maybe it worked because the user didn't notice - again, it doesn't
+ matter. It worked for the user.
+
+ Breaking a user workflow for a "bug" is absolutely the WORST reason
+ for breakage you can imagine.
+
+ It's basically saying "I took something that worked, and I broke it,
+ but now it's better". Do you not see how f*cking insane that statement
+ is?
+
+ And without users, your program is not a program, it's a pointless
+ piece of code that you might as well throw away.
+
+ Seriously. This is *why* the #1 rule for kernel development is "we
+ don't break users". Because "I fixed a bug" is absolutely NOT AN
+ ARGUMENT if that bug fix broke a user setup. You actually introduced a
+ MUCH BIGGER bug by "fixing" something that the user clearly didn't
+ even care about.
+
+ And dammit, we upgrade the kernel ALL THE TIME without upgrading any
+ other programs at all. It is absolutely required, because flag-days
+ and dependencies are horribly bad.
+
+ And it is also required simply because I as a kernel developer do not
+ upgrade random other tools that I don't even care about as I develop
+ the kernel, and I want any of my users to feel safe doing the same
+ time.
+
+ So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel
+ without upgrading some other random binary, then we have a problem.
+
+ * From `2021-06-05
+ <https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_::
+
+ THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS.
+
+ Honestly, security people need to understand that "not working" is not
+ a success case of security. It's a failure case.
+
+ Yes, "not working" may be secure. But security in that case is *pointless*.
+
+ * From `2011-05-06 (1/3)
+ <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_::
+
+ Binary compatibility is more important.
+
+ And if binaries don't use the interface to parse the format (or just
+ parse it wrongly - see the fairly recent example of adding uuid's to
+ /proc/self/mountinfo), then it's a regression.
+
+ And regressions get reverted, unless there are security issues or
+ similar that makes us go "Oh Gods, we really have to break things".
+
+ I don't understand why this simple logic is so hard for some kernel
+ developers to understand. Reality matters. Your personal wishes matter
+ NOT AT ALL.
+
+ If you made an interface that can be used without parsing the
+ interface description, then we're stuck with the interface. Theory
+ simply doesn't matter.
+
+ You could help fix the tools, and try to avoid the compatibility
+ issues that way. There aren't that many of them.
+
+ From `2011-05-06 (2/3)
+ <https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_::
+
+ it's clearly NOT an internal tracepoint. By definition. It's being
+ used by powertop.
+
+ From `2011-05-06 (3/3)
+ <https://lore.kernel.org/all/BANLkTinazaXRdGovYL7rRVp+j6HbJ7pzhg@mail.gmail.com/>`_::
+
+ We have programs that use that ABI and thus it's a regression if they break.
+
+ * From `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_::
+
+ > Now this got me wondering if Debian _unstable_ actually qualifies as a
+ > standard distro userspace.
+
+ Oh, if the kernel breaks some standard user space, that counts. Tons
+ of people run Debian unstable
+
+ * From `2019-09-15
+ <https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_::
+
+ One _particularly_ last-minute revert is the top-most commit (ignoring
+ the version change itself) done just before the release, and while
+ it's very annoying, it's perhaps also instructive.
+
+ What's instructive about it is that I reverted a commit that wasn't
+ actually buggy. In fact, it was doing exactly what it set out to do,
+ and did it very well. In fact it did it _so_ well that the much
+ improved IO patterns it caused then ended up revealing a user-visible
+ regression due to a real bug in a completely unrelated area.
+
+ The actual details of that regression are not the reason I point that
+ revert out as instructive, though. It's more that it's an instructive
+ example of what counts as a regression, and what the whole "no
+ regressions" kernel rule means. The reverted commit didn't change any
+ API's, and it didn't introduce any new bugs. But it ended up exposing
+ another problem, and as such caused a kernel upgrade to fail for a
+ user. So it got reverted.
+
+ The point here being that we revert based on user-reported _behavior_,
+ not based on some "it changes the ABI" or "it caused a bug" concept.
+ The problem was really pre-existing, and it just didn't happen to
+ trigger before. The better IO patterns introduced by the change just
+ happened to expose an old bug, and people had grown to depend on the
+ previously benign behavior of that old issue.
+
+ And never fear, we'll re-introduce the fix that improved on the IO
+ patterns once we've decided just how to handle the fact that we had a
+ bad interaction with an interface that people had then just happened
+ to rely on incidental behavior for before. It's just that we'll have
+ to hash through how to do that (there are no less than three different
+ patches by three different developers being discussed, and there might
+ be more coming...). In the meantime, I reverted the thing that exposed
+ the problem to users for this release, even if I hope it will be
+ re-introduced (perhaps even backported as a stable patch) once we have
+ consensus about the issue it exposed.
+
+ Take-away from the whole thing: it's not about whether you change the
+ kernel-userspace ABI, or fix a bug, or about whether the old code
+ "should never have worked in the first place". It's about whether
+ something breaks existing users' workflow.
+
+ Anyway, that was my little aside on the whole regression thing. Since
+ it's that "first rule of kernel programming", I felt it is perhaps
+ worth just bringing it up every once in a while
+
+..
+ end-of-content
+..
+ This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
+ of the file. If you want to distribute this text under CC-BY-4.0 only,
+ please use "The Linux kernel developers" for author attribution and link
+ this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/handling-regressions.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index 9f1b88492bb3..428e39074f61 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -25,6 +25,7 @@ Below are the essential guides that every developer should read.
code-of-conduct-interpretation
development-process
submitting-patches
+ handling-regressions
programming-language
coding-style
maintainer-handbooks
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..6c62f7e0dc9d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10438,6 +10438,8 @@ KERNEL REGRESSIONS
M: Thorsten Leemhuis <linux@leemhuis.info>
L: regressions@lists.linux.dev
S: Supported
+F: Documentation/admin-guide/reporting-regressions.rst
+F: Documentation/process/handling-regressions.rst
KERNEL SELFTEST FRAMEWORK
M: Shuah Khan <shuah@kernel.org>
--
2.35.1
^ permalink raw reply related [relevance 6%]
* [PATCH v9 09/11] docs/system: Add vhost-user-input documentation
@ 2024-01-04 21:09 6% ` Alex Bennée
0 siblings, 0 replies; 200+ results
From: Alex Bennée @ 2024-01-04 21:09 UTC (permalink / raw)
To: qemu-devel
Cc: Gerd Hoffmann, Mathieu Poirier, Kevin Wolf, Mark Cave-Ayland,
Jason Wang, Erik Schilling, Eric Blake, Fam Zheng,
Marc-André Lureau, Eduardo Habkost, virtio-fs, Hanna Reitz,
Alex Bennée, Manos Pitsidianakis, Daniel P. Berrangé,
qemu-block, Markus Armbruster, Gonglei (Arei), Michael S. Tsirkin,
Raphael Norwitz, Paolo Bonzini, Viresh Kumar, Stefan Hajnoczi,
Leo Yan
From: Leo Yan <leo.yan@linaro.org>
This adds basic documentation for vhost-user-input.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Message-Id: <20231120043721.50555-3-leo.yan@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
MAINTAINERS | 1 +
docs/system/device-emulation.rst | 1 +
docs/system/devices/vhost-user-input.rst | 45 ++++++++++++++++++++++++
docs/system/devices/vhost-user.rst | 4 ++-
4 files changed, 50 insertions(+), 1 deletion(-)
create mode 100644 docs/system/devices/vhost-user-input.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index 607f71817f8..ff70987aeb3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2274,6 +2274,7 @@ L: virtio-fs@lists.linux.dev
virtio-input
M: Gerd Hoffmann <kraxel@redhat.com>
S: Odd Fixes
+F: docs/system/devices/vhost-user-input.rst
F: hw/input/vhost-user-input.c
F: hw/input/virtio-input*.c
F: include/hw/virtio/virtio-input.h
diff --git a/docs/system/device-emulation.rst b/docs/system/device-emulation.rst
index d1f3277cb02..f19777411cd 100644
--- a/docs/system/device-emulation.rst
+++ b/docs/system/device-emulation.rst
@@ -94,6 +94,7 @@ Emulated Devices
devices/virtio-gpu.rst
devices/virtio-pmem.rst
devices/virtio-snd.rst
+ devices/vhost-user-input.rst
devices/vhost-user-rng.rst
devices/canokey.rst
devices/usb-u2f.rst
diff --git a/docs/system/devices/vhost-user-input.rst b/docs/system/devices/vhost-user-input.rst
new file mode 100644
index 00000000000..118eb78101c
--- /dev/null
+++ b/docs/system/devices/vhost-user-input.rst
@@ -0,0 +1,45 @@
+.. _vhost_user_input:
+
+QEMU vhost-user-input - Input emulation
+=======================================
+
+This document describes the setup and usage of the Virtio input device.
+The Virtio input device is a paravirtualized device for input events.
+
+Description
+-----------
+
+The vhost-user-input device implementation was designed to work with a daemon
+polling on input devices and passes input events to the guest.
+
+QEMU provides a backend implementation in contrib/vhost-user-input.
+
+Linux kernel support
+--------------------
+
+Virtio input requires a guest Linux kernel built with the
+``CONFIG_VIRTIO_INPUT`` option.
+
+Examples
+--------
+
+The backend daemon should be started first:
+
+::
+
+ host# vhost-user-input --socket-path=input.sock \
+ --evdev-path=/dev/input/event17
+
+The QEMU invocation needs to create a chardev socket to communicate with the
+backend daemon and access the VirtIO queues with the guest over the
+:ref:`shared memory <shared_memory_object>`.
+
+::
+
+ host# qemu-system \
+ -chardev socket,path=/tmp/input.sock,id=mouse0 \
+ -device vhost-user-input-pci,chardev=mouse0 \
+ -m 4096 \
+ -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
+ -numa node,memdev=mem \
+ ...
diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
index c6afc4836f9..9b2da106cec 100644
--- a/docs/system/devices/vhost-user.rst
+++ b/docs/system/devices/vhost-user.rst
@@ -42,7 +42,7 @@ platform details for what sort of virtio bus to use.
- See https://github.com/rust-vmm/vhost-device
* - vhost-user-input
- Generic input driver
- - See contrib/vhost-user-input
+ - :ref:`vhost_user_input`
* - vhost-user-rng
- Entropy driver
- :ref:`vhost_user_rng`
@@ -91,6 +91,8 @@ following the :ref:`vhost_user_proto`. There are a number of daemons
that can be built when enabled by the project although any daemon that
meets the specification for a given device can be used.
+.. _shared_memory_object:
+
Shared memory object
====================
--
2.39.2
^ permalink raw reply related [relevance 6%]
* Re: Create mm@lists.linux.dev
[not found] <YMJLJR/atypu++qU@casper.infradead.org>
@ 2021-06-10 19:44 6% ` Johannes Weiner
2021-06-14 14:25 6% ` Jason Gunthorpe
0 siblings, 1 reply; 200+ results
From: Johannes Weiner @ 2021-06-10 19:44 UTC (permalink / raw)
To: Matthew Wilcox
Cc: helpdesk, Andrew Morton, Naoya Horiguchi, Michal Hocko,
Vladimir Davydov, Jérôme Glisse, Mike Kravetz,
Mike Rapoport, Will Deacon, Aneesh Kumar K.V, Nick Piggin,
Peter Zijlstra, Dennis Zhou, Tejun Heo, Christoph Lameter,
David Rientjes, Vlastimil Babka, Hugh Dickins, linux-mm
On Thu, Jun 10, 2021 at 06:25:57PM +0100, Matthew Wilcox wrote:
> Address : mm@lists.linux.dev
> Description: Linux Memory Management
> Owners : bcrl@kvack.org, willy@infradead.org, vbabka@suse.cz
> Allow HTML : N
> Archives : Y
>
> Reasons for the list and additional info:
> kvack.org has been regrettably unreliable recently, and it makes sense
> to have a full-time sysadmin who can fix issues without being forced to
> drive for five hours to the colo.
Agreed.
It was eating my email too in the past, and I spent a lot of time
making speculative changes to my setup to get it to work. We may as
well take advantage of the infrastructure used by most every other
subsystem already, and avoid this pain for both users and owners.
Thanks for pushing for this
^ permalink raw reply [relevance 6%]
* Re: Create mm@lists.linux.dev
2021-06-10 19:44 6% ` Create mm@lists.linux.dev Johannes Weiner
@ 2021-06-14 14:25 6% ` Jason Gunthorpe
0 siblings, 0 replies; 200+ results
From: Jason Gunthorpe @ 2021-06-14 14:25 UTC (permalink / raw)
To: Johannes Weiner
Cc: Matthew Wilcox, helpdesk, Andrew Morton, Naoya Horiguchi,
Michal Hocko, Vladimir Davydov, Jérôme Glisse,
Mike Kravetz, Mike Rapoport, Will Deacon, Aneesh Kumar K.V,
Nick Piggin, Peter Zijlstra, Dennis Zhou, Tejun Heo,
Christoph Lameter, David Rientjes, Vlastimil Babka, Hugh Dickins,
linux-mm
On Thu, Jun 10, 2021 at 03:44:19PM -0400, Johannes Weiner wrote:
> On Thu, Jun 10, 2021 at 06:25:57PM +0100, Matthew Wilcox wrote:
> > Address : mm@lists.linux.dev
> > Description: Linux Memory Management
> > Owners : bcrl@kvack.org, willy@infradead.org, vbabka@suse.cz
> > Allow HTML : N
> > Archives : Y
> >
> > Reasons for the list and additional info:
> > kvack.org has been regrettably unreliable recently, and it makes sense
> > to have a full-time sysadmin who can fix issues without being forced to
> > drive for five hours to the colo.
>
> Agreed.
>
> It was eating my email too in the past, and I spent a lot of time
> making speculative changes to my setup to get it to work. We may as
> well take advantage of the infrastructure used by most every other
> subsystem already, and avoid this pain for both users and owners.
>
> Thanks for pushing for this
+1 here too.
linux-mm emails are often in my spam folder because it mangles
DKIM. Other lists don't have this problem
Jason
^ permalink raw reply [relevance 6%]
* Test delivery to ofono@lists.linux.dev
@ 2021-09-15 18:23 6% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2021-09-15 18:23 UTC (permalink / raw)
To: ofono
Testing new list archiving. Please ignore.
-K
^ permalink raw reply [relevance 6%]
* Test delivery to ell@lists.linux.dev
@ 2021-09-15 18:25 6% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2021-09-15 18:25 UTC (permalink / raw)
To: ell
Testing list archival, please ignore.
-K
^ permalink raw reply [relevance 6%]
* Test delivery to iwd@lists.linux.dev
@ 2021-09-15 18:26 6% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2021-09-15 18:26 UTC (permalink / raw)
To: iwd
Testing list archival, please ignore.
-K
^ permalink raw reply [relevance 6%]
* Re: [PATCH] MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list
2022-01-27 3:06 6% ` Prashant Malani
@ 2022-01-27 1:58 6% ` Benson Leung
1 sibling, 0 replies; 200+ results
From: Benson Leung @ 2022-01-27 1:58 UTC (permalink / raw)
To: Benson Leung, cychiang, groeck
Cc: chrome-platform, linux-kernel, pmalani, tzungbi
[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]
On Wed, Jan 26, 2022 at 02:22:33PM -0800, Benson Leung wrote:
> Signed-off-by: Benson Leung <bleung@chromium.org>
Attention to cychiang@ and groeck@ who are both listed as M and R below.
Be advised there is a new chrome-platform mailing list spun up.
https://lore.kernel.org/chrome-platform/
Thanks,
Benson
> ---
> MAINTAINERS | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..cad7b0fff9f4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4537,6 +4537,7 @@ F: drivers/input/touchscreen/chipone_icn8505.c
>
> CHROME HARDWARE PLATFORM SUPPORT
> M: Benson Leung <bleung@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
> F: drivers/platform/chrome/
> @@ -4544,6 +4545,7 @@ F: drivers/platform/chrome/
> CHROMEOS EC CODEC DRIVER
> M: Cheng-Yi Chiang <cychiang@chromium.org>
> R: Guenter Roeck <groeck@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml
> F: sound/soc/codecs/cros_ec_codec.*
> @@ -4551,6 +4553,7 @@ F: sound/soc/codecs/cros_ec_codec.*
> CHROMEOS EC SUBDRIVERS
> M: Benson Leung <bleung@chromium.org>
> R: Guenter Roeck <groeck@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: drivers/power/supply/cros_usbpd-charger.c
> N: cros_ec
> @@ -4558,11 +4561,13 @@ N: cros-ec
>
> CHROMEOS EC USB TYPE-C DRIVER
> M: Prashant Malani <pmalani@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: drivers/platform/chrome/cros_ec_typec.c
>
> CHROMEOS EC USB PD NOTIFY DRIVER
> M: Prashant Malani <pmalani@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: drivers/platform/chrome/cros_usbpd_notify.c
> F: include/linux/platform_data/cros_usbpd_notify.h
> --
> 2.35.0.rc0.227.g00780c9af4-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [relevance 6%]
* Re: [PATCH] MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list
@ 2022-01-27 3:06 6% ` Prashant Malani
2022-01-27 1:58 6% ` Benson Leung
1 sibling, 0 replies; 200+ results
From: Prashant Malani @ 2022-01-27 3:06 UTC (permalink / raw)
To: Benson Leung; +Cc: chrome-platform, linux-kernel, bleung
Hi Benson,
On Jan 26 14:22, Benson Leung wrote:
> Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Prashant Malani <pmalani@chromium.org>
> ---
> MAINTAINERS | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..cad7b0fff9f4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4537,6 +4537,7 @@ F: drivers/input/touchscreen/chipone_icn8505.c
>
> CHROME HARDWARE PLATFORM SUPPORT
> M: Benson Leung <bleung@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
> F: drivers/platform/chrome/
> @@ -4544,6 +4545,7 @@ F: drivers/platform/chrome/
> CHROMEOS EC CODEC DRIVER
> M: Cheng-Yi Chiang <cychiang@chromium.org>
> R: Guenter Roeck <groeck@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml
> F: sound/soc/codecs/cros_ec_codec.*
> @@ -4551,6 +4553,7 @@ F: sound/soc/codecs/cros_ec_codec.*
> CHROMEOS EC SUBDRIVERS
> M: Benson Leung <bleung@chromium.org>
> R: Guenter Roeck <groeck@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: drivers/power/supply/cros_usbpd-charger.c
> N: cros_ec
> @@ -4558,11 +4561,13 @@ N: cros-ec
>
> CHROMEOS EC USB TYPE-C DRIVER
> M: Prashant Malani <pmalani@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: drivers/platform/chrome/cros_ec_typec.c
>
> CHROMEOS EC USB PD NOTIFY DRIVER
> M: Prashant Malani <pmalani@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: drivers/platform/chrome/cros_usbpd_notify.c
> F: include/linux/platform_data/cros_usbpd_notify.h
> --
> 2.35.0.rc0.227.g00780c9af4-goog
>
^ permalink raw reply [relevance 6%]
* Re: [PATCH] MAINTAINERS: Add chrome-platform@lists.linux.dev to all Chrome OS entries
@ 2022-03-16 20:17 6% ` Benson Leung
2022-03-16 22:00 6% ` Guenter Roeck
0 siblings, 1 reply; 200+ results
From: Benson Leung @ 2022-03-16 20:17 UTC (permalink / raw)
To: Guenter Roeck; +Cc: chrome-platform, Benson Leung, Rajat Jain
[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]
Hi Guenter,
On Wed, Mar 16, 2022 at 11:49:45AM -0700, Guenter Roeck wrote:
> Add the chrome-platform@lists.linux.dev mailing list to all Chrome OS
> maintainer entries to ensure that people copy the list when submitting
> Chrome OS specific patches. This also helps ensuring that patches are
> available in a patchwork instance.
>
> Cc: Benson Leung <bleung@chromium.org>
> Cc: Rajat Jain <rajatja@google.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
I added this back in January.
https://lore.kernel.org/r/20220126222233.2852280-1-bleung@chromium.org
It should already be in linux-next:
https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git/commit/?h=for-next&id=664de6a26b7f17eebca896c3e18201b15d5c7b19
Let me know if it didn't show up there for you.
Benson
> ---
> MAINTAINERS | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e127c2fb08a7..bc275698e7c2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4541,6 +4541,7 @@ F: drivers/input/touchscreen/chipone_icn8505.c
>
> CHROME HARDWARE PLATFORM SUPPORT
> M: Benson Leung <bleung@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
> F: drivers/platform/chrome/
> @@ -4549,6 +4550,7 @@ CHROMEOS EC CODEC DRIVER
> M: Cheng-Yi Chiang <cychiang@chromium.org>
> M: Tzung-Bi Shih <tzungbi@google.com>
> R: Guenter Roeck <groeck@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml
> F: sound/soc/codecs/cros_ec_codec.*
> @@ -4556,6 +4558,7 @@ F: sound/soc/codecs/cros_ec_codec.*
> CHROMEOS EC SUBDRIVERS
> M: Benson Leung <bleung@chromium.org>
> R: Guenter Roeck <groeck@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: drivers/power/supply/cros_usbpd-charger.c
> N: cros_ec
> @@ -4563,11 +4566,13 @@ N: cros-ec
>
> CHROMEOS EC USB TYPE-C DRIVER
> M: Prashant Malani <pmalani@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: drivers/platform/chrome/cros_ec_typec.c
>
> CHROMEOS EC USB PD NOTIFY DRIVER
> M: Prashant Malani <pmalani@chromium.org>
> +L: chrome-platform@lists.linux.dev
> S: Maintained
> F: drivers/platform/chrome/cros_usbpd_notify.c
> F: include/linux/platform_data/cros_usbpd_notify.h
> --
> 2.35.1
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [relevance 6%]
* Re: [PATCH] MAINTAINERS: Add chrome-platform@lists.linux.dev to all Chrome OS entries
2022-03-16 20:17 6% ` Benson Leung
@ 2022-03-16 22:00 6% ` Guenter Roeck
0 siblings, 0 replies; 200+ results
From: Guenter Roeck @ 2022-03-16 22:00 UTC (permalink / raw)
To: Benson Leung; +Cc: chrome-platform, Benson Leung, Rajat Jain
On 3/16/22 13:17, Benson Leung wrote:
> Hi Guenter,
>
> On Wed, Mar 16, 2022 at 11:49:45AM -0700, Guenter Roeck wrote:
>> Add the chrome-platform@lists.linux.dev mailing list to all Chrome OS
>> maintainer entries to ensure that people copy the list when submitting
>> Chrome OS specific patches. This also helps ensuring that patches are
>> available in a patchwork instance.
>>
>> Cc: Benson Leung <bleung@chromium.org>
>> Cc: Rajat Jain <rajatja@google.com>
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>
> I added this back in January.
> https://lore.kernel.org/r/20220126222233.2852280-1-bleung@chromium.org
>
> It should already be in linux-next:
> https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git/commit/?h=for-next&id=664de6a26b7f17eebca896c3e18201b15d5c7b19
>
> Let me know if it didn't show up there for you.
>
Ah, I only checked mainline. Sorry for the noise.
Guenter
^ permalink raw reply [relevance 6%]
* Re: [sysadmin] Fwd: Bouncing messages from llvm@lists.linux.dev
@ 2022-07-11 18:19 6% ` Konstantin Ryabitsev
2022-07-11 18:30 6% ` Nick Desaulniers
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2022-07-11 18:19 UTC (permalink / raw)
To: Nick Desaulniers; +Cc: postmaster, clang-built-linux, Nathan Chancellor
On Mon, Jul 11, 2022 at 10:54:34AM -0700, 'Nick Desaulniers' via Systems Administrators wrote:
> Hi Post Master,
> Any idea what's up with the below message?
>
> To Fangrui, it sounded like his patch wasn't delivered to our list but
> the message Fangrui sent was indeed posted.
> https://lore.kernel.org/llvm/20220710071117.446112-1-maskray@google.com/
>
> Can the error be reworded possibly to elucidate what's going on?
This happens in a rare case when we mistakenly allow a spam message through,
which is this one:
https://lore.kernel.org/llvm/0.0.3.735.1D894A7973BDB9A.0@absceraw.gazzettait.com/
when we tried to deliver this message to maskray@google.com, Google's spam
filters rejected it, so we got back a bounce. When this happens, mlmmj follows
up with a probe email to make sure the address is still valid, which is the
message you received.
This behaviour is indeed a bit confusing, but it's not about the mail you sent
out, just the spam your MX refused to receive.
HTH,
Konstantin
>
> ---------- Forwarded message ---------
> From: Fangrui Song <maskray@google.com>
> Date: Mon, Jul 11, 2022 at 10:36 AM
> Subject: Fwd: Bouncing messages from llvm@lists.linux.dev
> To: Nick Desaulniers <ndesaulniers@google.com>
>
>
> ---------- Forwarded message ---------
> From: <llvm+owner@lists.linux.dev>
> Date: Sun, Jul 10, 2022 at 3:30 PM
> Subject: Bouncing messages from llvm@lists.linux.dev
> To: <maskray@google.com>
>
>
> Greetings!
>
> This is the mlmmj program managing the <llvm@lists.linux.dev> mailing list.
>
> Some messages to you could not be delivered. If you're seeing this
> message it means things are back to normal, and it's merely for your
> information.
>
> Here is the list of the bounced messages:
> - 11406
>
>
>
>
> --
> 宋方睿
>
>
> --
> Thanks,
> ~Nick Desaulniers
^ permalink raw reply [relevance 6%]
* Re: [sysadmin] Fwd: Bouncing messages from llvm@lists.linux.dev
2022-07-11 18:19 6% ` [sysadmin] " Konstantin Ryabitsev
@ 2022-07-11 18:30 6% ` Nick Desaulniers
2022-07-11 18:34 6% ` Fangrui Song
2022-07-11 19:27 6% ` Konstantin Ryabitsev
0 siblings, 2 replies; 200+ results
From: Nick Desaulniers @ 2022-07-11 18:30 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: postmaster, clang-built-linux, Nathan Chancellor
On Mon, Jul 11, 2022 at 11:19 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Mon, Jul 11, 2022 at 10:54:34AM -0700, 'Nick Desaulniers' via Systems Administrators wrote:
> > Hi Post Master,
> > Any idea what's up with the below message?
> >
> > To Fangrui, it sounded like his patch wasn't delivered to our list but
> > the message Fangrui sent was indeed posted.
> > https://lore.kernel.org/llvm/20220710071117.446112-1-maskray@google.com/
> >
> > Can the error be reworded possibly to elucidate what's going on?
>
> This happens in a rare case when we mistakenly allow a spam message through,
> which is this one:
>
> https://lore.kernel.org/llvm/0.0.3.735.1D894A7973BDB9A.0@absceraw.gazzettait.com/
>
> when we tried to deliver this message to maskray@google.com, Google's spam
> filters rejected it, so we got back a bounce. When this happens, mlmmj follows
> up with a probe email to make sure the address is still valid, which is the
> message you received.
>
> This behaviour is indeed a bit confusing, but it's not about the mail you sent
> out, just the spam your MX refused to receive.
Cool, thanks for the explanation.
Any chance the error message could say something like:
The message at
https://lore.kernel.org/llvm/0.0.3.735.1D894A7973BDB9A.0@absceraw.gazzettait.com/
could not be delivered to you; it may be spam but you might want to verify.
Since I suspect the message id will be in the lore URL?
>
> HTH,
> Konstantin
>
> >
> > ---------- Forwarded message ---------
> > From: Fangrui Song <maskray@google.com>
> > Date: Mon, Jul 11, 2022 at 10:36 AM
> > Subject: Fwd: Bouncing messages from llvm@lists.linux.dev
> > To: Nick Desaulniers <ndesaulniers@google.com>
> >
> >
> > ---------- Forwarded message ---------
> > From: <llvm+owner@lists.linux.dev>
> > Date: Sun, Jul 10, 2022 at 3:30 PM
> > Subject: Bouncing messages from llvm@lists.linux.dev
> > To: <maskray@google.com>
> >
> >
> > Greetings!
> >
> > This is the mlmmj program managing the <llvm@lists.linux.dev> mailing list.
> >
> > Some messages to you could not be delivered. If you're seeing this
> > message it means things are back to normal, and it's merely for your
> > information.
> >
> > Here is the list of the bounced messages:
> > - 11406
> >
> >
> >
> >
> > --
> > 宋方睿
> >
> >
> > --
> > Thanks,
> > ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [relevance 6%]
* Re: [sysadmin] Fwd: Bouncing messages from llvm@lists.linux.dev
2022-07-11 18:30 6% ` Nick Desaulniers
@ 2022-07-11 18:34 6% ` Fangrui Song
2022-07-11 19:27 6% ` Konstantin Ryabitsev
1 sibling, 0 replies; 200+ results
From: Fangrui Song @ 2022-07-11 18:34 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Konstantin Ryabitsev, postmaster, clang-built-linux,
Nathan Chancellor
On Mon, Jul 11, 2022 at 11:30 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Mon, Jul 11, 2022 at 11:19 AM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > On Mon, Jul 11, 2022 at 10:54:34AM -0700, 'Nick Desaulniers' via Systems Administrators wrote:
> > > Hi Post Master,
> > > Any idea what's up with the below message?
> > >
> > > To Fangrui, it sounded like his patch wasn't delivered to our list but
> > > the message Fangrui sent was indeed posted.
> > > https://lore.kernel.org/llvm/20220710071117.446112-1-maskray@google.com/
> > >
> > > Can the error be reworded possibly to elucidate what's going on?
> >
> > This happens in a rare case when we mistakenly allow a spam message through,
> > which is this one:
> >
> > https://lore.kernel.org/llvm/0.0.3.735.1D894A7973BDB9A.0@absceraw.gazzettait.com/
> >
> > when we tried to deliver this message to maskray@google.com, Google's spam
> > filters rejected it, so we got back a bounce. When this happens, mlmmj follows
> > up with a probe email to make sure the address is still valid, which is the
> > message you received.
> >
> > This behaviour is indeed a bit confusing, but it's not about the mail you sent
> > out, just the spam your MX refused to receive.
>
> Cool, thanks for the explanation.
Thanks, too. The bounce from the spam happened to be delivered to my
mailbox few hours after I posted the patch, so I got confused :)
> Any chance the error message could say something like:
>
> The message at
> https://lore.kernel.org/llvm/0.0.3.735.1D894A7973BDB9A.0@absceraw.gazzettait.com/
> could not be delivered to you; it may be spam but you might want to verify.
The wording looks great!
> Since I suspect the message id will be in the lore URL?
>
> >
> > HTH,
> > Konstantin
> >
> > >
> > > ---------- Forwarded message ---------
> > > From: Fangrui Song <maskray@google.com>
> > > Date: Mon, Jul 11, 2022 at 10:36 AM
> > > Subject: Fwd: Bouncing messages from llvm@lists.linux.dev
> > > To: Nick Desaulniers <ndesaulniers@google.com>
> > >
> > >
> > > ---------- Forwarded message ---------
> > > From: <llvm+owner@lists.linux.dev>
> > > Date: Sun, Jul 10, 2022 at 3:30 PM
> > > Subject: Bouncing messages from llvm@lists.linux.dev
> > > To: <maskray@google.com>
> > >
> > >
> > > Greetings!
> > >
> > > This is the mlmmj program managing the <llvm@lists.linux.dev> mailing list.
> > >
> > > Some messages to you could not be delivered. If you're seeing this
> > > message it means things are back to normal, and it's merely for your
> > > information.
> > >
> > > Here is the list of the bounced messages:
> > > - 11406
> > >
> > >
> > >
> > >
> > > --
> > > 宋方睿
> > >
> > >
> > > --
> > > Thanks,
> > > ~Nick Desaulniers
>
>
>
> --
> Thanks,
> ~Nick Desaulniers
>
--
宋方睿
^ permalink raw reply [relevance 6%]
* Re: [sysadmin] Fwd: Bouncing messages from llvm@lists.linux.dev
2022-07-11 18:30 6% ` Nick Desaulniers
2022-07-11 18:34 6% ` Fangrui Song
@ 2022-07-11 19:27 6% ` Konstantin Ryabitsev
2022-07-11 19:30 6% ` Nick Desaulniers
1 sibling, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2022-07-11 19:27 UTC (permalink / raw)
To: Nick Desaulniers; +Cc: postmaster, clang-built-linux, Nathan Chancellor
On Mon, Jul 11, 2022 at 11:30:31AM -0700, Nick Desaulniers wrote:
> Any chance the error message could say something like:
>
> The message at
> https://lore.kernel.org/llvm/0.0.3.735.1D894A7973BDB9A.0@absceraw.gazzettait.com/
> could not be delivered to you; it may be spam but you might want to verify.
Unfortunately, mlmmj doesn't give me access to the message-id of the bouncing
message (see http://mlmmj.org/docs/readme-listtexts/).
I will tweak the wording to offer a bit more explanation, though, something
like:
Some messages to you could not be delivered. This usually happens if we
have accepted a spam message that is being rejected by your mail host when
we try to deliver it, but may also be due to other reasons. Please review
the public list archives to check if you are missing any legitimate mail.
If you're seeing this message it usually means that things are back to
normal and no further action is required from you.
Here is the list of the bounced messages:
- %bouncenumbers%
-K
^ permalink raw reply [relevance 6%]
* Re: [sysadmin] Fwd: Bouncing messages from llvm@lists.linux.dev
2022-07-11 19:27 6% ` Konstantin Ryabitsev
@ 2022-07-11 19:30 6% ` Nick Desaulniers
2022-07-11 19:31 6% ` Fangrui Song
0 siblings, 1 reply; 200+ results
From: Nick Desaulniers @ 2022-07-11 19:30 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: postmaster, clang-built-linux, Nathan Chancellor
On Mon, Jul 11, 2022 at 12:27 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Mon, Jul 11, 2022 at 11:30:31AM -0700, Nick Desaulniers wrote:
> > Any chance the error message could say something like:
> >
> > The message at
> > https://lore.kernel.org/llvm/0.0.3.735.1D894A7973BDB9A.0@absceraw.gazzettait.com/
> > could not be delivered to you; it may be spam but you might want to verify.
>
> Unfortunately, mlmmj doesn't give me access to the message-id of the bouncing
> message (see http://mlmmj.org/docs/readme-listtexts/).
>
> I will tweak the wording to offer a bit more explanation, though, something
> like:
>
> Some messages to you could not be delivered. This usually happens if we
> have accepted a spam message that is being rejected by your mail host when
> we try to deliver it, but may also be due to other reasons. Please review
> the public list archives to check if you are missing any legitimate mail.
>
> If you're seeing this message it usually means that things are back to
> normal and no further action is required from you.
>
> Here is the list of the bounced messages:
> - %bouncenumbers%
>
> -K
LGTM; thanks Konstantin!
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [relevance 6%]
* Re: [sysadmin] Fwd: Bouncing messages from llvm@lists.linux.dev
2022-07-11 19:30 6% ` Nick Desaulniers
@ 2022-07-11 19:31 6% ` Fangrui Song
0 siblings, 0 replies; 200+ results
From: Fangrui Song @ 2022-07-11 19:31 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Nick Desaulniers, postmaster, clang-built-linux,
Nathan Chancellor
On Mon, Jul 11, 2022 at 12:30 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Mon, Jul 11, 2022 at 12:27 PM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > On Mon, Jul 11, 2022 at 11:30:31AM -0700, Nick Desaulniers wrote:
> > > Any chance the error message could say something like:
> > >
> > > The message at
> > > https://lore.kernel.org/llvm/0.0.3.735.1D894A7973BDB9A.0@absceraw.gazzettait.com/
> > > could not be delivered to you; it may be spam but you might want to verify.
> >
> > Unfortunately, mlmmj doesn't give me access to the message-id of the bouncing
> > message (see http://mlmmj.org/docs/readme-listtexts/).
> >
> > I will tweak the wording to offer a bit more explanation, though, something
> > like:
> >
> > Some messages to you could not be delivered. This usually happens if we
> > have accepted a spam message that is being rejected by your mail host when
> > we try to deliver it, but may also be due to other reasons. Please review
> > the public list archives to check if you are missing any legitimate mail.
> >
> > If you're seeing this message it usually means that things are back to
> > normal and no further action is required from you.
> >
> > Here is the list of the bounced messages:
> > - %bouncenumbers%
> >
> > -K
>
> LGTM; thanks Konstantin!
>
> --
> Thanks,
> ~Nick Desaulniers
LGTM. Thanks!
^ permalink raw reply [relevance 6%]
* Re: KernelCI at lists.linux.dev
@ 2022-07-15 5:12 6% ` Guillaume Tucker
2022-07-29 15:06 6% ` Guillaume Tucker
0 siblings, 1 reply; 200+ results
From: Guillaume Tucker @ 2022-07-15 5:12 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: helpdesk, kernelci@groups.io
On 14/07/2022 16:51, Konstantin Ryabitsev wrote:
> On Thu, Jul 14, 2022 at 10:26:57AM +0200, Guillaume Tucker wrote:
>> Hello,
>>
>> The KernelCI community has been using kernelci@groups.io for a
>> few years, however it's less than ideal as messages have to be
>> moderated for all non-members. Also we've been getting closer to
>> the kernel community over the years and it isn't a great fit for
>> that. Would it be possible to create a kernelci@lists.linux.dev
>> mailing list so we would then transition away from groups.io?
>
> For sure, I don't see why not. We can even import groups.io archives once the
> migration is decided. If you do decide to move, just follow the procedure
> described on
> https://subspace.kernel.org/lists.linux.dev.html#requesting-list-hosting
Thank you, I've just done that now.
Guillaume
^ permalink raw reply [relevance 6%]
* Re: KernelCI at lists.linux.dev
2022-07-15 5:12 6% ` Guillaume Tucker
@ 2022-07-29 15:06 6% ` Guillaume Tucker
0 siblings, 0 replies; 200+ results
From: Guillaume Tucker @ 2022-07-29 15:06 UTC (permalink / raw)
To: kernelci@groups.io; +Cc: helpdesk, Konstantin Ryabitsev
On 15/07/2022 07:12, Guillaume Tucker wrote:
> On 14/07/2022 16:51, Konstantin Ryabitsev wrote:
>> On Thu, Jul 14, 2022 at 10:26:57AM +0200, Guillaume Tucker wrote:
>>> Hello,
>>>
>>> The KernelCI community has been using kernelci@groups.io for a
>>> few years, however it's less than ideal as messages have to be
>>> moderated for all non-members. Also we've been getting closer to
>>> the kernel community over the years and it isn't a great fit for
>>> that. Would it be possible to create a kernelci@lists.linux.dev
>>> mailing list so we would then transition away from groups.io?
>>
>> For sure, I don't see why not. We can even import groups.io archives once the
>> migration is decided. If you do decide to move, just follow the procedure
>> described on
>> https://subspace.kernel.org/lists.linux.dev.html#requesting-list-hosting
>
> Thank you, I've just done that now.
As we would like to move to the new list and stop using
groups.io, it would seem useful to also import the list of
subscribers from groups.io. Please let me know if you don't want
to be subscribed to the new list by the end of next week (Aug 5).
I'll also send some messages on IRC and Slack to be sure everyone
knows about this.
Thanks,
Guillaume
^ permalink raw reply [relevance 6%]
* Purchase Requirement lists.linux.dev
@ 2023-02-14 11:29 6% Jessica Hernandez
0 siblings, 0 replies; 200+ results
From: Jessica Hernandez @ 2023-02-14 11:29 UTC (permalink / raw)
To: oe-kbuild-all
[-- Attachment #1.1: Type: text/plain, Size: 302 bytes --]
GoodDay,
We have an urgent requirement as per the included samples & specifications. Kindly give us your best price and let us know the information regarding the purchase.
Thank you and please let me know if you have any questions!
Let me know your feedback soon.
Thanks
Jessica Hernandez
[-- Attachment #1.2: Type: text/html, Size: 826 bytes --]
[-- Attachment #2: Invoice#0129.pdf --]
[-- Type: application/pdf, Size: 342466 bytes --]
^ permalink raw reply [relevance 6%]
* Re: dm-devel has migrated to lists.linux.dev
@ 2023-10-11 18:28 6% ` Konstantin Ryabitsev
1 sibling, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-10-11 18:28 UTC (permalink / raw)
To: Mike Snitzer; +Cc: dm-devel
On Fri, Oct 06, 2023 at 07:43:38PM -0400, Mike Snitzer wrote:
> The dm-devel list archive is now here:
> https://lore.kernel.org/dm-devel/
FYI, the archive migration should now be completed and will be tracking the
new list. This message is partly a test to ensure that it worked.
-K
^ permalink raw reply [relevance 6%]
* Re: dm-devel has migrated to lists.linux.dev
@ 2023-10-11 18:52 6% ` Konstantin Ryabitsev
2023-10-11 20:08 6% ` Mike Snitzer
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2023-10-11 18:52 UTC (permalink / raw)
To: Mike Snitzer; +Cc: dm-devel
On Wed, Oct 11, 2023 at 02:41:58PM -0400, Mike Snitzer wrote:
> [this is also test, to see if new list allows old list to email it]
It does, but I don't recommend doing this, because the messages forwarded this
way will arrive with broken DKIM signatures (redhat.com signs the List-ID
header, which we must modify).
So, even though the message sent to the old address will make it to the new
list and to the archive, it will likely be rejected by many subscribers.
I recommend doing this just for a week or two and then just doing a hard
bounce without a forward.
-K
^ permalink raw reply [relevance 6%]
* Re: dm-devel has migrated to lists.linux.dev
2023-10-11 18:52 6% ` Konstantin Ryabitsev
@ 2023-10-11 20:08 6% ` Mike Snitzer
0 siblings, 0 replies; 200+ results
From: Mike Snitzer @ 2023-10-11 20:08 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: dm-devel
On Wed, Oct 11 2023 at 2:52P -0400,
Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Wed, Oct 11, 2023 at 02:41:58PM -0400, Mike Snitzer wrote:
> > [this is also test, to see if new list allows old list to email it]
>
> It does, but I don't recommend doing this, because the messages forwarded this
> way will arrive with broken DKIM signatures (redhat.com signs the List-ID
> header, which we must modify).
>
> So, even though the message sent to the old address will make it to the new
> list and to the archive, it will likely be rejected by many subscribers.
>
> I recommend doing this just for a week or two and then just doing a hard
> bounce without a forward.
Agreed, this is purely to ease subscribers into the new list. Hard
bounce without forward in ~2 weeks is the plan.
Thanks,
Mike
^ permalink raw reply [relevance 6%]
* Re: lvm-devel has migrated to lists.linux.dev [was: Re: Welcome to the "lvm-devel" mailing list]
@ 2023-10-23 14:43 6% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-10-23 14:43 UTC (permalink / raw)
To: Mike Snitzer; +Cc: lvm-devel
On Fri, Oct 20, 2023 at 05:34:36PM -0400, Mike Snitzer wrote:
> The lvm-devel list archive will soon be migrating here:
> https://lore.kernel.org/lvm-devel/
This is now completed and the archives are available at the above address.
-K
^ permalink raw reply [relevance 6%]
* Re: PSA: this list is moving to virtualization@lists.linux.dev
@ 2023-11-07 18:10 6% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-07 18:10 UTC (permalink / raw)
To: virtualization
On Wed, 1 Nov 2023 at 14:17, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> As stated before [1], this list cannot stay on its current mailman-2 system, so I
> am proceeding with moving this list to lists.linux.dev. The current plan is to
> move it next week on November 7 around 10:30 AM PST (18:30 UTC).
This migration should be complete and this message is acting as part
of the test to make sure delivering to the old address still works.
To remind everyone:
> Here's the impact of this change:
>
> 1. *The old address will continue to work*, so any existing conversations can
> continue and any new patches sent to the old list address will be properly
> delivered to list subscribers. The new canonical list address will be
> virtualization@lists.linux.dev.
>
> 2. All subscribers will be automatically moved to the new system, so no action
> is required on anyone's part to keep their subscription.
>
> 3. The archive on https://lore.kernel.org/virtualization/ will be
> automatically updated to track the new list address.
>
> 4. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: Linux virtualization <virtualization.lists.linux-foundation.org>
> after: List-Id: <virtualization.lists.linux.dev>
>
> 5. The mailman footer will no longer be added to message bodies.
>
> 6. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, described at https://subspace.kernel.org/subscribing.html
I will follow up with a couple more test messages to ensure that
everything is functioning as expected. The archives on
lore.kernel.org/virtualization may lag a bit until they are repointed
at the new list, but no messages should be lost.
Best regards,
Konstantin
^ permalink raw reply [relevance 6%]
* The new list address is: virtualization@lists.linux.dev (old one still works)
@ 2023-11-07 18:41 6% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-07 18:41 UTC (permalink / raw)
To: virtualization
Hello:
This is a test of the new list address. Please update any of your address
books to reflect this change, but keep in mind that the old address should
continue to work for the foreseeable future.
-K
^ permalink raw reply [relevance 6%]
* Re: [Accel-config] PSA: the accel-config list will be moving to lists.linux.dev
@ 2023-12-18 22:44 6% ` Konstantin Ryabitsev
2023-12-21 19:57 6% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 22:44 UTC (permalink / raw)
To: accel-config
On Tue, 21 Nov 2023 at 15:47, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hello, all:
>
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> Some time next week, the accel-config list will be migrated to live on
> lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be accel-config@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/accel-config/ with
> all prior archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <accel-config.lists.linuxfoundation.org>
> after: List-Id: <accel-config.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [accel-config] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. Otherwise, I will
> follow up next week with the exact date and time of the move.
Hello:
This took a bit longer than expected due to other work, but the
migration of this list will take place this Thursday, at 11AM
US-Pacific (19:00 UTC). I will follow up once this work has been
completed.
-K
^ permalink raw reply [relevance 6%]
* Re: [diamon-discuss] PSA: the diamon-discuss list will be moving to lists.linux.dev
@ 2023-12-18 22:45 6% ` Konstantin Ryabitsev
2023-12-21 20:17 6% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 22:45 UTC (permalink / raw)
To: diamon-discuss
On Tue, 21 Nov 2023 at 15:43, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hello, all:
>
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> Some time next week, the diamon-discuss list will be migrated to live on
> lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be diamon-discuss@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/diamon-discuss/ with
> all prior archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <diamon-discuss.lists.linuxfoundation.org>
> after: List-Id: <diamon-discuss.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [diamon-discuss] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. Otherwise, I will
> follow up next week with the exact date and time of the move.
Hello:
This took a bit longer than expected due to other work, but the
migration of this list will take place this Thursday, December 21, at
11AM US-Pacific (19:00 UTC). I will follow up once this work has been
completed.
-K
^ permalink raw reply [relevance 6%]
* Re: [Fuego] PSA: the fuego list will be moving to lists.linux.dev
@ 2023-12-18 22:46 6% ` Konstantin Ryabitsev
2023-12-21 20:19 6% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 22:46 UTC (permalink / raw)
To: fuego
On Tue, 21 Nov 2023 at 15:57, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hello, all:
>
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> Some time next week, the fuego list will be migrated to live on
> lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be fuego@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/fuego/ with all prior
> archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <fuego.lists.linuxfoundation.org>
> after: List-Id: <fuego.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [fuego] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. Otherwise, I will
> follow up next week with the exact date and time of the move.
Hello:
This took a bit longer than expected due to other work, but the
migration of this list will take place this Thursday, December 21, at
11AM US-Pacific (19:00 UTC). I will follow up once this work has been
completed.
-K
^ permalink raw reply [relevance 6%]
* Re: [SPDK] PSA: the spdk list will be moving to lists.linux.dev
2023-12-21 20:33 6% ` Konstantin Ryabitsev
@ 2023-12-18 23:04 6% ` Konstantin Ryabitsev
1 sibling, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 23:04 UTC (permalink / raw)
To: spdk
On Tue, 21 Nov 2023 at 16:38, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hello, all:
>
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> Some time next week, the SPDK list will be migrated to live on
> lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be spdk@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/spdk/ with all prior
> archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <spdk.lists.linuxfoundation.org>
> after: List-Id: <spdk.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [SPDK] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. Otherwise, I will
> follow up next week with the exact date and time of the move.
Hello:
This took a bit longer than expected due to other work, but the
migration of this list will take place this Thursday, December 21, at
11AM US-Pacific (19:00 UTC). I will follow up once this work has been
completed.
-K
^ permalink raw reply [relevance 6%]
* Re: [Tpm2] PSA: the tpm2 list will be moving to lists.linux.dev
2023-12-21 20:36 6% ` Konstantin Ryabitsev
@ 2023-12-18 23:05 6% ` Konstantin Ryabitsev
1 sibling, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 23:05 UTC (permalink / raw)
To: tpm2
On Tue, 21 Nov 2023 at 16:21, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hello, all:
>
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> Some time next week, the tpm2 list will be migrated to live on
> lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be tpm2@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/tpm2/ with all prior
> archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <tpm2.lists.linuxfoundation.org>
> after: List-Id: <tpm2.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [tpm2] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. Otherwise, I will
> follow up next week with the exact date and time of the move.
Hello:
This took a bit longer than expected due to other work, but the
migration of this list will take place this Thursday, December 21, at
11AM US-Pacific (19:00 UTC). I will follow up once this work has been
completed.
-K
^ permalink raw reply [relevance 6%]
* Re: [Printing-architecture] PSA: this list is moving to lists.linux.dev (no action required)
2023-12-21 20:30 6% ` Konstantin Ryabitsev
@ 2023-12-18 23:46 6% ` Ira McDonald
1 sibling, 0 replies; 200+ results
From: Ira McDonald @ 2023-12-18 23:46 UTC (permalink / raw)
Cc: printing-architecture
[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]
FYI - old OpenPrinting address will work forever, but no inserted list
header in Subject line - see Konstantin's list of details below.
Cheers,
- Ira
On Mon, Dec 18, 2023, 6:02 PM Konstantin Ryabitsev <
konstantin@linuxfoundation.org> wrote:
>
> Hello, all:
>
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new
> homes.
>
> This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be
> migrated
> to live on lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be
> printing-architecture@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so
> any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no
> action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on
> https://lore.kernel.org/printing-architecture/
> with all prior archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message
> is
> sent:
>
> before: List-Id: <printing-architecture.lists.linuxfoundation.org>
> after: List-Id: <printing-architecture.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [Printing-architecture]
> (because this violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. I will follow up
> on Thursday after the migration has been completed.
>
> Best regards,
> -K
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>
[-- Attachment #2: Type: text/html, Size: 3721 bytes --]
^ permalink raw reply [relevance 6%]
* Re: [Accel-config] PSA: the accel-config list will be moving to lists.linux.dev
2023-12-18 22:44 6% ` Konstantin Ryabitsev
@ 2023-12-21 19:57 6% ` Konstantin Ryabitsev
2023-12-21 20:15 6% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 19:57 UTC (permalink / raw)
To: accel-config
On Mon, 18 Dec 2023 at 17:44, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> This took a bit longer than expected due to other work, but the
> migration of this list will take place this Thursday, at 11AM
> US-Pacific (19:00 UTC). I will follow up once this work has been
> completed.
Hello:
The list migration should be complete. This message acts as a test to
make sure that everything is working properly. The archives will be
ported some time later today.
-K
^ permalink raw reply [relevance 6%]
* Re: PSA: the accel-config list will be moving to lists.linux.dev
2023-12-21 19:57 6% ` Konstantin Ryabitsev
@ 2023-12-21 20:15 6% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:15 UTC (permalink / raw)
To: accel-config
On Thu, 21 Dec 2023 at 14:57, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> > This took a bit longer than expected due to other work, but the
> > migration of this list will take place this Thursday, at 11AM
> > US-Pacific (19:00 UTC). I will follow up once this work has been
> > completed.
>
> The list migration should be complete. This message acts as a test to
> make sure that everything is working properly. The archives will be
> ported some time later today.
The initial testing showed that the migration wasn't fully working, so
this is a re-test.
Sorry for all the noise, everyone.
-K
^ permalink raw reply [relevance 6%]
* Re: PSA: the diamon-discuss list will be moving to lists.linux.dev
2023-12-18 22:45 6% ` Konstantin Ryabitsev
@ 2023-12-21 20:17 6% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:17 UTC (permalink / raw)
To: diamon-discuss
On Mon, 18 Dec 2023 at 17:45, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> This took a bit longer than expected due to other work, but the
> migration of this list will take place this Thursday, December 21, at
> 11AM US-Pacific (19:00 UTC). I will follow up once this work has been
> completed.
This work is complete, and this message acts as a test to make sure
everything is working properly. The archives will be ported later in
the day.
-K
^ permalink raw reply [relevance 6%]
* Re: PSA: the fuego list will be moving to lists.linux.dev
2023-12-18 22:46 6% ` Konstantin Ryabitsev
@ 2023-12-21 20:19 6% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:19 UTC (permalink / raw)
To: fuego
On Mon, 18 Dec 2023 at 17:46, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> This took a bit longer than expected due to other work, but the
> migration of this list will take place this Thursday, December 21, at
> 11AM US-Pacific (19:00 UTC). I will follow up once this work has been
> completed.
Hello:
This work is complete and this message serves as a way to test that
everything is working properly. The archives will be ported later
today.
Best regards,
-K
^ permalink raw reply [relevance 6%]
* Re: PSA: this list is moving to lists.linux.dev (no action required)
@ 2023-12-21 20:21 6% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:21 UTC (permalink / raw)
To: lvfs-general
On Mon, 18 Dec 2023 at 17:54, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hello, all:
>
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
>
> This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
> to live on lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be lvfs-general@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/lvfs-general/ with
> all prior archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <lvfs-general.lists.linuxfoundation.org>
> after: List-Id: <lvfs-general.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [LVFS] (because this violates
> DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. I will follow up
> on Thursday after the migration has been completed.
Hello:
This work is complete and this message acts as a test to make sure
everything is working properly. The list archives will be moved later
today.
Best regards,
-K
^ permalink raw reply [relevance 6%]
* Re: PSA: this list is moving to lists.linux.dev (no action requried)
@ 2023-12-21 20:24 6% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:24 UTC (permalink / raw)
To: lvfs-announce
On Mon, 18 Dec 2023 at 17:58, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
>
> This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
> to live on lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be lvfs-announce@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/lvfs-announce/ with
> all prior archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <lvfs-announce.lists.linuxfoundation.org>
> after: List-Id: <lvfs-announce.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [Lvfs-announce] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. I will follow up
> on Thursday after the migration has been completed.
Hello:
This work is completed and this message acts as a test to ensure that
everything is working properly. The archives will be moved later
today.
Best regards,
Konstantin
^ permalink raw reply [relevance 6%]
* Re: [Opae] PSA: this list is moving to lists.linux.dev
@ 2023-12-21 20:25 6% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:25 UTC (permalink / raw)
To: opae
On Mon, 18 Dec 2023 at 18:00, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
>
> This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
> to live on lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be opae@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/opae/ with
> all prior archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <opae.lists.linuxfoundation.org>
> after: List-Id: <opae.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [Opae] (because this violates
> DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. I will follow up
> on Thursday after the migration has been completed.
Hello:
This work is completed and this message acts as a test to make sure
that everything is working properly. The list archives will be moved
later today.
Best regards,
-K
^ permalink raw reply [relevance 6%]
* Re: PSA: this list is moving to lists.linux.dev (no action required)
@ 2023-12-21 20:30 6% ` Konstantin Ryabitsev
2023-12-23 1:01 6% ` Till Kamppeter
2023-12-18 23:46 6% ` [Printing-architecture] " Ira McDonald
1 sibling, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:30 UTC (permalink / raw)
To: printing-architecture
On Mon, 18 Dec 2023 at 18:02, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
>
> This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
> to live on lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be printing-architecture@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/printing-architecture/
> with all prior archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <printing-architecture.lists.linuxfoundation.org>
> after: List-Id: <printing-architecture.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [Printing-architecture]
> (because this violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. I will follow up
> on Thursday after the migration has been completed.
Hello:
This work is complete and this message acts as a test to make sure
that everything is working properly. The list archives will be moved
later today.
Best regards,
Konstantin
^ permalink raw reply [relevance 6%]
* Re: PSA: the spdk list will be moving to lists.linux.dev
@ 2023-12-21 20:33 6% ` Konstantin Ryabitsev
2023-12-18 23:04 6% ` [SPDK] " Konstantin Ryabitsev
1 sibling, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:33 UTC (permalink / raw)
To: spdk
On Tue, 21 Nov 2023 at 16:38, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hello, all:
>
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> Some time next week, the SPDK list will be migrated to live on
> lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be spdk@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/spdk/ with all prior
> archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <spdk.lists.linuxfoundation.org>
> after: List-Id: <spdk.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [SPDK] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
Hello:
This work is complete and this message acts as a test to make sure
everything is working properly. The list archives will be moved later
today.
Best regards,
Konstantin
^ permalink raw reply [relevance 6%]
* Re: PSA: this list is moving to lists.linux.dev (no action required)
@ 2023-12-21 20:35 6% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:35 UTC (permalink / raw)
To: tech-board-discuss
On Mon, 18 Dec 2023 at 18:07, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
>
> This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
> to live on lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be tech-board-discuss@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/tech-board-discuss/ with
> all prior archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <tech-board-discuss.lists.linuxfoundation.org>
> after: List-Id: <tech-board-discuss.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [Tech-board-discuss] (because
> this violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
>
> Please let me know if you have any questions or concerns. I will follow up
> on Thursday after the migration has been completed.
Hello:
This work is complete and this message acts as a test to make sure
everything is working properly. The list archives will be moved later
today.
Best regards,
-K
^ permalink raw reply [relevance 6%]
* Re: PSA: the tpm2 list will be moving to lists.linux.dev
@ 2023-12-21 20:36 6% ` Konstantin Ryabitsev
2023-12-18 23:05 6% ` [Tpm2] " Konstantin Ryabitsev
1 sibling, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-21 20:36 UTC (permalink / raw)
To: tpm2
On Tue, 21 Nov 2023 at 16:21, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> Some time next week, the tpm2 list will be migrated to live on
> lists.linux.dev, but the impact of this move should be minor:
>
> 1. The new canonical list address will be tpm2@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/tpm2/ with all prior
> archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <tpm2.lists.linuxfoundation.org>
> after: List-Id: <tpm2.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after the migration date).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [tpm2] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
Hello:
This work is complete and this message acts as a test to make sure
that everything is working properly. The list archives will be moved
later today.
Best wishes,
-K
^ permalink raw reply [relevance 6%]
* Re: PSA: this list is moving to lists.linux.dev (no action required)
2023-12-21 20:30 6% ` Konstantin Ryabitsev
@ 2023-12-23 1:01 6% ` Till Kamppeter
0 siblings, 0 replies; 200+ results
From: Till Kamppeter @ 2023-12-23 1:01 UTC (permalink / raw)
To: Konstantin Ryabitsev, printing-architecture
On 21/12/2023 17:30, Konstantin Ryabitsev wrote:
>
> Hello:
>
> This work is complete and this message acts as a test to make sure
> that everything is working properly. The list archives will be moved
> later today.
>
> Best regards,
> Konstantin
>
Konstantin,
thank you very much for moving over the mailing list and its archives.
For testing, I am sending this e-mail to the new e-mail address.
I have updated the links in my December News:
https://openprinting.github.io/OpenPrinting-News-December-2023/#what-is-hot-on-the-openprinting-maiing-list
Till
^ permalink raw reply [relevance 6%]
* [kvm-unit-tests PATCH] arm/arm64: MAINTAINERS: Add reviewers
@ 2023-07-14 12:52 6% Andrew Jones
0 siblings, 0 replies; 200+ results
From: Andrew Jones @ 2023-07-14 12:52 UTC (permalink / raw)
To: kvmarm; +Cc: Alexandru Elisei, Eric Auger
I've recruited some review help!
Signed-off-by: Andrew Jones <andrew.jones@linux.dev>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index fe2c8418faf2..958735fbfd79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -76,6 +76,8 @@ Architecture Specific Code:
ARM
M: Andrew Jones <andrew.jones@linux.dev>
+R: Alexandru Elisei <alexandru.elisei@arm.com>
+R: Eric Auger <eric.auger@redhat.com>
S: Supported
L: kvmarm@lists.linux.dev
F: arm/
--
2.41.0
^ permalink raw reply related [relevance 6%]
* [PATCH 08/10] platform/chrome: cros_ec_typec: Add initial VDM support
@ 2022-12-28 0:45 6% ` Prashant Malani
0 siblings, 0 replies; 200+ results
From: Prashant Malani @ 2022-12-28 0:45 UTC (permalink / raw)
To: linux-kernel, chrome-platform
Cc: heikki.krogerus, Prashant Malani, Benson Leung, Daisuke Nojiri,
Dustin L. Howett, Evan Green, Greg Kroah-Hartman, Guenter Roeck,
Gustavo A. R. Silva, Lee Jones, Lee Jones, Stephen Boyd,
Tinghan Shen, Tzung-Bi Shih, Xiang wangx
Add ops to support USB PD VDM (Vendor Defined Message) from the port
driver. This enables the port driver to interface with alternate mode
drivers and communicate with connected peripherals.
The initial support just contains an implementation of the Enter
Mode command.
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
---
MAINTAINERS | 1 +
drivers/platform/chrome/Makefile | 2 +-
drivers/platform/chrome/cros_ec_typec.c | 3 ++
drivers/platform/chrome/cros_typec_vdm.c | 43 ++++++++++++++++++++++++
drivers/platform/chrome/cros_typec_vdm.h | 10 ++++++
5 files changed, 58 insertions(+), 1 deletion(-)
create mode 100644 drivers/platform/chrome/cros_typec_vdm.c
create mode 100644 drivers/platform/chrome/cros_typec_vdm.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8219b646ab50..cfccbbbb083f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5000,6 +5000,7 @@ L: chrome-platform@lists.linux.dev
S: Maintained
F: drivers/platform/chrome/cros_ec_typec.*
F: drivers/platform/chrome/cros_typec_switch.c
+F: drivers/platform/chrome/cros_typec_vdm.*
CHROMEOS EC USB PD NOTIFY DRIVER
M: Prashant Malani <pmalani@chromium.org>
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index fd29fa74ba33..dae0ed3c8656 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_CROS_TYPEC_SWITCH) += cros_typec_switch.o
obj-$(CONFIG_CROS_EC_RPMSG) += cros_ec_rpmsg.o
obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
cros_ec_lpcs-objs := cros_ec_lpc.o cros_ec_lpc_mec.o
-cros-ec-typec-objs := cros_ec_typec.o
+cros-ec-typec-objs := cros_ec_typec.o cros_typec_vdm.o
obj-$(CONFIG_CROS_EC_TYPEC) += cros-ec-typec.o
obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpcs.o
obj-$(CONFIG_CROS_EC_PROTO) += cros_ec_proto.o cros_ec_trace.o
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
index a4eff590ca56..1e28d56b094d 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -17,6 +17,7 @@
#include <linux/usb/typec_tbt.h>
#include "cros_ec_typec.h"
+#include "cros_typec_vdm.h"
#define DRV_NAME "cros-ec-typec"
@@ -272,6 +273,7 @@ static int cros_typec_register_port_altmodes(struct cros_typec_data *typec,
return PTR_ERR(amode);
port->port_altmode[CROS_EC_ALTMODE_DP] = amode;
typec_altmode_set_drvdata(amode, port);
+ amode->ops = &port_amode_ops;
/*
* Register TBT compatibility alt mode. The EC will not enter the mode
@@ -286,6 +288,7 @@ static int cros_typec_register_port_altmodes(struct cros_typec_data *typec,
return PTR_ERR(amode);
port->port_altmode[CROS_EC_ALTMODE_TBT] = amode;
typec_altmode_set_drvdata(amode, port);
+ amode->ops = &port_amode_ops;
port->state.alt = NULL;
port->state.mode = TYPEC_STATE_USB;
diff --git a/drivers/platform/chrome/cros_typec_vdm.c b/drivers/platform/chrome/cros_typec_vdm.c
new file mode 100644
index 000000000000..df0102ca3a18
--- /dev/null
+++ b/drivers/platform/chrome/cros_typec_vdm.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * USB Power Delivery Vendor Defined Message (VDM) support code.
+ *
+ * Copyright 2023 Google LLC
+ * Author: Prashant Malani <pmalani@chromium.org>
+ */
+
+#include <linux/module.h>
+#include <linux/platform_data/cros_ec_commands.h>
+#include <linux/usb/pd_vdo.h>
+
+#include "cros_ec_typec.h"
+#include "cros_typec_vdm.h"
+
+static int cros_typec_port_amode_enter(struct typec_altmode *amode, u32 *vdo)
+{
+ struct cros_typec_port *port = typec_altmode_get_drvdata(amode);
+ struct ec_params_typec_control req = {
+ .port = port->port_num,
+ .command = TYPEC_CONTROL_COMMAND_SEND_VDM_REQ,
+ };
+ struct typec_vdm_req vdm_req = {};
+ u32 hdr;
+
+ hdr = VDO(amode->svid, 1, SVDM_VER_2_0, CMD_ENTER_MODE);
+ hdr |= VDO_OPOS(amode->mode);
+
+ vdm_req.vdm_data[0] = hdr;
+ vdm_req.vdm_data_objects = 1;
+ vdm_req.partner_type = TYPEC_PARTNER_SOP;
+ req.vdm_req_params = vdm_req;
+
+ dev_dbg(port->typec_data->dev, "Sending EnterMode VDM, hdr: %x, port: %d\n",
+ hdr, port->port_num);
+
+ return cros_ec_cmd(port->typec_data->ec, 0, EC_CMD_TYPEC_CONTROL, &req,
+ sizeof(req), NULL, 0);
+}
+
+struct typec_altmode_ops port_amode_ops = {
+ .enter = cros_typec_port_amode_enter,
+};
diff --git a/drivers/platform/chrome/cros_typec_vdm.h b/drivers/platform/chrome/cros_typec_vdm.h
new file mode 100644
index 000000000000..7e282d168a98
--- /dev/null
+++ b/drivers/platform/chrome/cros_typec_vdm.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __CROS_TYPEC_VDM__
+#define __CROS_TYPEC_VDM__
+
+#include <linux/usb/typec_altmode.h>
+
+extern struct typec_altmode_ops port_amode_ops;
+
+#endif /* __CROS_TYPEC_VDM__ */
--
2.39.0.314.g84b9a713c41-goog
^ permalink raw reply related [relevance 6%]
* [PATCH 5/8] Docs/mm/damon: add a maintainer-profile for DAMON
2023-01-10 19:03 6% ` [PATCH 6/8] MAINTAINERS/DAMON: link maintainer profile, git trees, and website SeongJae Park
@ 2023-01-10 19:03 6% ` SeongJae Park
1 sibling, 0 replies; 200+ results
From: SeongJae Park @ 2023-01-10 19:03 UTC (permalink / raw)
To: Andrew Morton
Cc: SeongJae Park, Jonathan Corbet, damon, linux-mm, linux-doc,
linux-kernel
Document the basic policies and expectations for DAMON development.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/mm/damon/index.rst | 1 +
Documentation/mm/damon/maintainer-profile.rst | 62 +++++++++++++++++++
2 files changed, 63 insertions(+)
create mode 100644 Documentation/mm/damon/maintainer-profile.rst
diff --git a/Documentation/mm/damon/index.rst b/Documentation/mm/damon/index.rst
index 2983699c12ea..5e0a50583500 100644
--- a/Documentation/mm/damon/index.rst
+++ b/Documentation/mm/damon/index.rst
@@ -32,3 +32,4 @@ operations with no code but simple configurations.
faq
design
api
+ maintainer-profile
diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst
new file mode 100644
index 000000000000..24a202f03de8
--- /dev/null
+++ b/Documentation/mm/damon/maintainer-profile.rst
@@ -0,0 +1,62 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+DAMON Maintainer Entry Profile
+==============================
+
+The DAMON subsystem covers the files that listed in 'DATA ACCESS MONITOR'
+section of 'MAINTAINERS' file.
+
+The mailing lists for the subsystem are damon@lists.linux.dev and
+linux-mm@kvack.org. Patches should be made against the mm-unstable tree [1]_
+whenever possible and posted to the mailing lists.
+
+SCM Trees
+---------
+
+There are multiple Linux trees for DAMON development. Patches under
+development or testing are queued in damon/next [2]_ by the DAMON maintainer.
+Suffieicntly reviewed patches will be queued in mm-unstable [1]_ by the memory
+management subsystem maintainer. After more sufficient tests, the patches will
+be queued in mm-stable [3]_ , and finally pull-requested to the mainline by the
+memory management subsystem maintainer.
+
+Note again the patches for review should be made against the mm-unstable
+tree[1] whenever possible. damon/next is only for preview of others' works in
+progress.
+
+Submit checklist addendum
+-------------------------
+
+When making DAMON changes, you should do below.
+
+- Build changes related outputs including kernel and documents.
+- Ensure the builds introduce no new errors or warnings.
+- Run and ensure no new failures for DAMON selftests [4]_ and kunittests [5]_ .
+
+Further doing below and putting the results will be helpful.
+
+- Run damon-tests/corr [6]_ for normal changes.
+- Run damon-tests/perf [7]_ for performance changes.
+
+Key cycle dates
+---------------
+
+Patches can be sent anytime. Key cycle dates of the mm-unstable[1] and
+mm-stable[3] trees depend on the memory management subsystem maintainer.
+
+Review cadence
+--------------
+
+The DAMON maintainer does the work on the usual work hour (09:00 to 17:00,
+Mon-Fri) in PST. The response to patches will occasionally be slow. Do not
+hesitate to send a ping if you have not heard back within a week of sending a
+patch.
+
+
+.. [1] https://git.kernel.org/akpm/mm/h/mm-unstable
+.. [2] https://git.kernel.org/sj/h/damon/next
+.. [3] https://git.kernel.org/akpm/mm/h/mm-stable
+.. [4] https://github.com/awslabs/damon-tests/blob/master/corr/run.sh#L49
+.. [5] https://github.com/awslabs/damon-tests/blob/master/corr/tests/kunit.sh
+.. [6] https://github.com/awslabs/damon-tests/tree/master/corr
+.. [7] https://github.com/awslabs/damon-tests/tree/master/perf
--
2.25.1
^ permalink raw reply related [relevance 6%]
* [PATCH 3/3] Documentation/llvm: Update IRC location
2021-08-25 21:18 8% ` [PATCH 2/3] Documentation/llvm: Update " Nathan Chancellor
@ 2021-08-25 21:18 6% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-08-25 21:18 UTC (permalink / raw)
To: Andrew Morton, Masahiro Yamada, Kees Cook
Cc: Sami Tolvanen, Nick Desaulniers, linux-kernel, llvm,
clang-built-linux, Nathan Chancellor
This should have been done with commit 91ed3ed0f798 ("MAINTAINERS:
update ClangBuiltLinux IRC chat") but I did not realize it was in two
separate spots.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Documentation/kbuild/llvm.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
index 06b8f826e1a3..683f8b7cca0b 100644
--- a/Documentation/kbuild/llvm.rst
+++ b/Documentation/kbuild/llvm.rst
@@ -114,7 +114,7 @@ Getting Help
- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev>
- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_
- `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_
-- IRC: #clangbuiltlinux on chat.freenode.net
+- IRC: #clangbuiltlinux on irc.libera.chat
- `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux
- `Wiki <https://github.com/ClangBuiltLinux/linux/wiki>`_
- `Beginner Bugs <https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22>`_
--
2.33.0
^ permalink raw reply related [relevance 6%]
* Re: Is the data rate estimation for 5GHz channels overly pessimistic?
@ 2023-10-24 15:19 6% ` Simonas Kazlauskas
0 siblings, 0 replies; 200+ results
From: Simonas Kazlauskas @ 2023-10-24 15:19 UTC (permalink / raw)
To: Denis Kenzior; +Cc: James Prestwood, iwd
Denis Kenzior wrote:
>On 10/24/23 07:32, James Prestwood wrote:
>>So you could set:
>>[Rank].LowSignalRateThreshold=-90
>>
>>Any RSSI between -82 and -90 would use -82 for the rank calculation.
>>No idea how this would play out in practice, but its at least simple
>>and not tied to any given hardware.
>
>No, I was more thinking about:
>/* Added to the rssi value prior to looking up in the ht_vht_he_base_rssi */
>SensitivityFudgeFactor=4
>/* Width penalty */
>SensitivityWidthPenalty=0 (3 today)
>/* NSS penalty */
>SensitivityNSSPenalty=3
>/* Same as SensitivityFudgeFactor, but for HE */
>SensitivityHEFudgeFactor=10
My main worry then would be finding good defaults for these values. Ultimately,
unless `iwd` ends up in a place where people install it and get a great
experience in anything that involves ranking (roaming, initial association,
etc.), the WiFi experience on Linux may have a hard time shaking off its stigma.
If many has to modify some config variables to get a good experience, the
experience will continue staying subpar for the large majority still. Although
having the knobs will at least enable a minority to extract a reasonably good
experience.
What worries me in parituclar here is that if we tune these defaults too high
(i.e. estimate rate better than it might end up being in practice) then we might
end up associating with the AP that is too far away/weak to provide a
serviceable connection.
I wonder if there’s any place in here for some dynamic component that would
monitor how the NSS, MCS and other bandwidth affecting parameters behave for a
given SSID/BSSID/etc. as the RSSI varies, and transparently learn these
parameters throughout a… session (is that a term?) That way even if the
estimation for the very first association is too pessimistic, `iwd` can do
better when it needs to estimate again for e.g. a romaing decision or a new
association after a sleep.
With such a scheme in place “training” IWD would also be pretty easy to explain
to the users (walk around the area with your device connected to the network) if
they encountered problems with a particular AP.
S.
^ permalink raw reply [relevance 6%]
* [merged mm-stable] docs-mm-damon-maintainer-profile-fix-typos-and-grammar-errors.patch removed from -mm tree
@ 2023-06-09 23:29 6% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2023-06-09 23:29 UTC (permalink / raw)
To: mm-commits, corbet, sj, akpm
The quilt patch titled
Subject: Docs/mm/damon/maintainer-profile: fix typos and grammar errors
has been removed from the -mm tree. Its filename was
docs-mm-damon-maintainer-profile-fix-typos-and-grammar-errors.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: Docs/mm/damon/maintainer-profile: fix typos and grammar errors
Date: Thu, 25 May 2023 21:43:06 +0000
Fix a few typos and grammar erros in DAMON Maintainer Profile document.
Link: https://lkml.kernel.org/r/20230525214314.5204-3-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/mm/damon/maintainer-profile.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/Documentation/mm/damon/maintainer-profile.rst~docs-mm-damon-maintainer-profile-fix-typos-and-grammar-errors
+++ a/Documentation/mm/damon/maintainer-profile.rst
@@ -3,7 +3,7 @@
DAMON Maintainer Entry Profile
==============================
-The DAMON subsystem covers the files that listed in 'DATA ACCESS MONITOR'
+The DAMON subsystem covers the files that are listed in 'DATA ACCESS MONITOR'
section of 'MAINTAINERS' file.
The mailing lists for the subsystem are damon@lists.linux.dev and
@@ -15,7 +15,7 @@ SCM Trees
There are multiple Linux trees for DAMON development. Patches under
development or testing are queued in damon/next [2]_ by the DAMON maintainer.
-Suffieicntly reviewed patches will be queued in mm-unstable [1]_ by the memory
+Sufficiently reviewed patches will be queued in mm-unstable [1]_ by the memory
management subsystem maintainer. After more sufficient tests, the patches will
be queued in mm-stable [3]_ , and finally pull-requested to the mainline by the
memory management subsystem maintainer.
_
Patches currently in -mm which might be from sj@kernel.org are
^ permalink raw reply [relevance 6%]
* [RFC PATCH 5/5] PCI/TSM: Authenticate devices via platform TSM
@ 2024-01-30 9:24 6% ` Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2024-01-30 9:24 UTC (permalink / raw)
To: linux-coco
Cc: Wu Hao, Yilun Xu, Lukas Wunner, Samuel Ortiz,
Alexey Kardashevskiy, Bjorn Helgaas, linux-pci, gregkh
The PCIe 6.1 specification, section 11, introduces the Trusted
Execution Environment (TEE) Device Interface Security Protocol (TDISP).
This interface definition builds upon CMA, component measurement and
authentication, and IDE, link integrity and data encryption. It adds
support for establishing virtual functions within a device that can be
assigned to a confidential VM such that the assigned device is enabled
to access guest private memory protected by technologies like Intel TDX,
AMD SEV-SNP, RISCV COVE, or ARM CCA.
The "TSM" (TEE Security Manager) is a concept in the TDISP specification
of an agent that mediates between a device security manager (DSM) and
system software in both a VMM and a VM. From a Linux perspective the TSM
abstracts many of the details of TDISP, IDE, and CMA. Some of those
details leak through at times, but for the most part TDISP is an
internal implementation detail of the TSM.
Similar to the PCI core extensions to support CONFIG_PCI_CMA,
CONFIG_PCI_TSM builds upon that to reuse the "authenticated" sysfs
attribute, and add more properties + controls in a tsm/ subdirectory of
the PCI device sysfs interface. Unlike CMA that can depend on a local to
the PCI core implementation, PCI_TSM needs to be prepared for late
loading of the platform TSM driver. Consider that the TSM driver may
itself be a PCI driver. Userspace can depend on the common TSM device
uevent to know when the PCI core has TSM services enabled. The PCI
device tsm/ subdirectory is supplemented by the TSM device pci/
directory for platform global TSM properties + controls.
All vendor TSM implementations share the property of asking the VMM to
perform DOE mailbox operations on behalf of the TSM. That common
capability is centralized in PCI core code that invokes an ->exec()
operation callback potentially multiple times to service a given request
(struct pci_tsm_req). Future operations / verbs will be handled
similarly with the "request + exec" model. For now, only "connect" and
"disconnect" are implemented which at a minimum is expected to establish
IDE for the link.
In addition to requests the low-level TSM implementation is notified of
device arrival and departure events so that it can filter devices that
the TSM is not prepared to support, or otherwise setup and teardown
per-device context.
Cc: Wu Hao <hao.wu@intel.com>
Cc: Yilun Xu <yilun.xu@intel.com>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Samuel Ortiz <sameo@rivosinc.com>
Cc: Alexey Kardashevskiy <aik@amd.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Documentation/ABI/testing/sysfs-bus-pci | 43 +++-
Documentation/ABI/testing/sysfs-class-tsm | 23 ++
drivers/pci/Kconfig | 15 +
drivers/pci/Makefile | 2
drivers/pci/cma.c | 5
drivers/pci/pci-sysfs.c | 3
drivers/pci/pci.h | 14 +
drivers/pci/probe.c | 1
drivers/pci/remove.c | 1
drivers/pci/tsm.c | 346 +++++++++++++++++++++++++++++
drivers/virt/coco/tsm/Makefile | 1
drivers/virt/coco/tsm/class.c | 22 +-
drivers/virt/coco/tsm/pci.c | 83 +++++++
drivers/virt/coco/tsm/tsm.h | 28 ++
include/linux/pci.h | 3
include/linux/tsm.h | 77 ++++++
include/uapi/linux/pci_regs.h | 3
17 files changed, 662 insertions(+), 8 deletions(-)
create mode 100644 drivers/pci/tsm.c
create mode 100644 drivers/virt/coco/tsm/pci.c
create mode 100644 drivers/virt/coco/tsm/tsm.h
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index 35b0e11fd0e6..0eef2128cf09 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -508,11 +508,16 @@ Description:
This file contains "native" if the device authenticated
successfully with CMA-SPDM (PCIe r6.1 sec 6.31). It contains
"none" if the device failed authentication (and may thus be
- malicious).
+ malicious). It transitions from "native" to "tsm" after
+ successful connection to a tsm, see the "connect" attribute
+ below.
Writing "native" to this file causes reauthentication with
kernel-selected keys and the kernel's certificate chain. That
- may be opportune after updating the .cma keyring.
+ may be opportune after updating the .cma keyring. Note
+ that once connected to a tsm this returns -EBUSY to attempts to
+ write "native", i.e. first disconnect from the tsm to retrigger
+ native authentication.
The file is not visible if authentication is unsupported
by the device.
@@ -529,3 +534,37 @@ Description:
The reason why authentication support could not be determined
is apparent from "dmesg". To probe for authentication support
again, exercise the "remove" and "rescan" attributes.
+
+What: /sys/bus/pci/devices/.../tsm/
+Date: January 2024
+Contact: linux-coco@lists.linux.dev
+Description:
+ This directory only appears if a device supports CMA and IDE,
+ and only after a TSM driver has loaded and accepted / setup this
+ PCI device. Similar to the 'authenticated' attribute, trigger
+ "remove" and "rescan" to retry the initialization. See
+ Documentation/ABI/testing/sysfs-class-tsm for enumerating the
+ platform's TSM capabilities.
+
+What: /sys/bus/pci/devices/.../tsm/connect
+Date: January 2024
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RW) Writing "1" to this file triggers the TSM to establish a
+ secure connection with the device. This typically includes an
+ SPDM (DMTF Security Protocols and Data Models) session over PCIe
+ DOE (Data Object Exchange) and PCIe IDE (Integrity and Data
+ Encryption) establishment. For TSMs and devices that support
+ both modes of IDE ("link" and "selective") the "connect_mode"
+ attribute selects the mode.
+
+What: /sys/bus/pci/devices/.../tsm/connect_mode
+Date: January 2024
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Returns the available connection modes optionally with
+ brackets around the currently active mode if the device is
+ connected. For example it may show "link selective" for a
+ disconnected device, "link [selective]" for a selective
+ connected device, and it may hide a mode that is not supported
+ by the device or TSM.
diff --git a/Documentation/ABI/testing/sysfs-class-tsm b/Documentation/ABI/testing/sysfs-class-tsm
index 304b50b53e65..77957882738a 100644
--- a/Documentation/ABI/testing/sysfs-class-tsm
+++ b/Documentation/ABI/testing/sysfs-class-tsm
@@ -10,3 +10,26 @@ Description:
For software TSMs instantiated by a software module, @host is a
directory with attributes for that TSM, and those attributes are
documented below.
+
+
+What: /sys/class/tsm/tsm0/pci/link_capable
+Date: January, 2024
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) When present this returns "1\n" to indicate that the TSM
+ supports establishing Link IDE with a given root-port attached
+ device. See "tsm/connect_mode" in
+ Documentation/ABI/testing/sysfs-bus-pci
+
+
+What: /sys/class/tsm/tsm0/pci/selective_streams
+Date: January, 2024
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) When present this returns the number of currently available
+ selective IDE streams available to the TSM. When a stream id is
+ allocated this number is decremented and a link to the PCI
+ device(s) consuming the stream(s) appears alonside this
+ attribute in the /sys/class/tsm/tsm0/pci/ directory. See
+ "tsm/connect" and "tsm/connect_mode" in
+ Documentation/ABI/testing/sysfs-bus-pci.
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index a5c3cadddd6f..11d788038d19 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -129,6 +129,21 @@ config PCI_CMA
A PCI DOE mailbox is used as transport for DMTF SPDM based
authentication, measurement and secure channel establishment.
+config PCI_TSM
+ bool "TEE Security Manager for Device Security"
+ depends on PCI_CMA
+ depends on TSM
+ help
+ The TEE (Trusted Execution Environment) Device Interface
+ Security Protocol (TDISP) defines a "TSM" as a platform agent
+ that manages device authentication, link encryption, link
+ integrity protection, and assignment of PCI device functions
+ (virtual or physical) to confidential computing VMs that can
+ access (DMA) guest private memory.
+
+ Say Y to enable the PCI subsystem to enable the IDE and
+ TDISP capabilities of devices via TSM semantics.
+
config PCI_DOE
bool
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index cc8b5d1d15b9..c4117d67ea83 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -38,6 +38,8 @@ obj-$(CONFIG_PCI_CMA) += cma.o cma.asn1.o
$(obj)/cma.o: $(obj)/cma.asn1.h
$(obj)/cma.asn1.o: $(obj)/cma.asn1.c $(obj)/cma.asn1.h
+obj-$(CONFIG_PCI_TSM) += tsm.o
+
# Endpoint library must be initialized before its users
obj-$(CONFIG_PCI_ENDPOINT) += endpoint/
diff --git a/drivers/pci/cma.c b/drivers/pci/cma.c
index be7d2bb21b4c..5a69e9919589 100644
--- a/drivers/pci/cma.c
+++ b/drivers/pci/cma.c
@@ -39,6 +39,9 @@ static ssize_t authenticated_store(struct device *dev,
if (!sysfs_streq(buf, "native"))
return -EINVAL;
+ if (pci_tsm_authenticated(pdev))
+ return -EBUSY;
+
rc = pci_cma_reauthenticate(pdev);
if (rc)
return rc;
@@ -55,6 +58,8 @@ static ssize_t authenticated_show(struct device *dev,
(pdev->cma_init_failed || pdev->doe_init_failed))
return -ENOTTY;
+ if (pci_tsm_authenticated(pdev))
+ return sysfs_emit(buf, "tsm\n");
if (spdm_authenticated(pdev->spdm_state))
return sysfs_emit(buf, "native\n");
return sysfs_emit(buf, "none\n");
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 368c4f71cc55..4327f8c2e6b5 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1654,6 +1654,9 @@ const struct attribute_group *pci_dev_attr_groups[] = {
#endif
#ifdef CONFIG_PCI_CMA
&pci_cma_attr_group,
+#endif
+#ifdef CONFIG_PCI_TSM
+ &pci_tsm_attr_group,
#endif
NULL,
};
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 2b7d8d0b2e21..daa20866bc90 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -350,6 +350,20 @@ static inline int pci_cma_reauthenticate(struct pci_dev *pdev)
}
#endif
+#ifdef CONFIG_PCI_TSM
+void pci_tsm_init(struct pci_dev *pdev);
+void pci_tsm_destroy(struct pci_dev *pdev);
+extern const struct attribute_group pci_tsm_attr_group;
+bool pci_tsm_authenticated(struct pci_dev *pdev);
+#else
+static inline void pci_tsm_init(struct pci_dev *pdev) { }
+static inline void pci_tsm_destroy(struct pci_dev *pdev) { }
+static inline bool pci_tsm_authenticated(struct pci_dev *pdev)
+{
+ return false;
+}
+#endif
+
/**
* pci_dev_set_io_state - Set the new error state if possible.
*
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6b09c962c0b8..f60d6c3c8c48 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2542,6 +2542,7 @@ static void pci_init_capabilities(struct pci_dev *dev)
pci_rcec_init(dev); /* Root Complex Event Collector */
pci_doe_init(dev); /* Data Object Exchange */
pci_cma_init(dev); /* Component Measurement & Auth */
+ pci_tsm_init(dev); /* TEE Security Manager connection */
pcie_report_downtraining(dev);
pci_init_reset_methods(dev);
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index f009ac578997..228fa6ccf911 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -39,6 +39,7 @@ static void pci_destroy_dev(struct pci_dev *dev)
list_del(&dev->bus_list);
up_write(&pci_bus_sem);
+ pci_tsm_destroy(dev);
pci_cma_destroy(dev);
pci_doe_destroy(dev);
pcie_aspm_exit_link_state(dev);
diff --git a/drivers/pci/tsm.c b/drivers/pci/tsm.c
new file mode 100644
index 000000000000..f74de0ee49a0
--- /dev/null
+++ b/drivers/pci/tsm.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TEE Security Manager for the TEE Device Interface Security Protocol
+ * (TDISP, PCIe r6.1 sec 11)
+ *
+ * Copyright(c) 2024 Intel Corporation. All rights reserved.
+ */
+
+#define dev_fmt(fmt) "TSM: " fmt
+
+#include <linux/pci.h>
+#include <linux/tsm.h>
+#include <linux/sysfs.h>
+#include <linux/xarray.h>
+#include "pci.h"
+
+/* collect tsm capable devices to rendezvous with the tsm driver */
+static DEFINE_XARRAY(pci_tsm_devs);
+
+/*
+ * Provide a read/write lock against the init / exit of pdev tsm
+ * capabilities and arrival/departure of a tsm instance
+ */
+static DECLARE_RWSEM(pci_tsm_rwsem);
+static const struct tsm_pci_ops *tsm_ops;
+
+void generic_pci_tsm_req_free(struct pci_tsm_req *req)
+{
+ kfree(req);
+}
+EXPORT_SYMBOL_GPL(generic_pci_tsm_req_free);
+
+struct pci_tsm_req *generic_pci_tsm_req_alloc(struct pci_dev *pdev, enum pci_tsm_op op)
+{
+ struct pci_tsm_req *req = kzalloc(sizeof(*req), GFP_KERNEL);
+
+ if (!req)
+ return NULL;
+ req->op = op;
+ return req;
+}
+EXPORT_SYMBOL_GPL(generic_pci_tsm_req_alloc);
+
+DEFINE_FREE(req_free, struct pci_tsm_req *, if (_T) tsm_ops->req_free(_T))
+
+static int pci_tsm_disconnect(struct pci_dev *pdev)
+{
+ struct pci_tsm_req *req __free(req_free) = NULL;
+
+ /* opportunistic state checks to skip allocating a request */
+ if (pdev->tsm->state < PCI_TSM_CONNECT)
+ return 0;
+
+ req = tsm_ops->req_alloc(pdev, PCI_TSM_OP_DISCONNECT);
+ if (!req)
+ return -ENOMEM;
+
+ scoped_cond_guard(mutex_intr, return -EINTR, tsm_ops->lock) {
+ enum pci_tsm_op_status status;
+
+ /* revalidate state */
+ if (pdev->tsm->state < PCI_TSM_CONNECT)
+ return 0;
+ if (pdev->tsm->state < PCI_TSM_INIT)
+ return -ENXIO;
+
+ do {
+ status = tsm_ops->exec(pdev, req);
+ req->seq++;
+ /* TODO: marshal SPDM request */
+ } while (status == PCI_TSM_SPDM_REQ);
+
+ if (status == PCI_TSM_FAIL)
+ return -EIO;
+ pdev->tsm->state = PCI_TSM_INIT;
+ }
+ return 0;
+}
+
+static int pci_tsm_connect(struct pci_dev *pdev)
+{
+ struct pci_tsm_req *req __free(req_free) = NULL;
+
+ /* opportunistic state checks to skip allocating a request */
+ if (pdev->tsm->state >= PCI_TSM_CONNECT)
+ return 0;
+
+ req = tsm_ops->req_alloc(pdev, PCI_TSM_OP_CONNECT);
+ if (!req)
+ return -ENOMEM;
+
+ scoped_cond_guard(mutex_intr, return -EINTR, tsm_ops->lock) {
+ enum pci_tsm_op_status status;
+
+ /* revalidate state */
+ if (pdev->tsm->state >= PCI_TSM_CONNECT)
+ return 0;
+ if (pdev->tsm->state < PCI_TSM_INIT)
+ return -ENXIO;
+
+ do {
+ status = tsm_ops->exec(pdev, req);
+ req->seq++;
+ } while (status == PCI_TSM_SPDM_REQ);
+
+ if (status == PCI_TSM_FAIL)
+ return -EIO;
+ pdev->tsm->state = PCI_TSM_CONNECT;
+ }
+ return 0;
+}
+
+static ssize_t connect_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ bool connect;
+ int rc = kstrtobool(buf, &connect);
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (rc)
+ return rc;
+
+ if (connect) {
+ if (!spdm_authenticated(pdev->spdm_state)) {
+ pci_dbg(pdev, "SPDM authentication pre-requisite not met.\n");
+ return -ENXIO;
+ }
+ rc = pci_tsm_connect(pdev);
+ if (rc)
+ return rc;
+ return len;
+ }
+
+ rc = pci_tsm_disconnect(pdev);
+ if (rc)
+ return rc;
+ return len;
+}
+
+static ssize_t connect_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ return sysfs_emit(buf, "%d\n", pdev->tsm->state >= PCI_TSM_CONNECT);
+}
+static DEVICE_ATTR_RW(connect);
+
+static const char *const pci_tsm_modes[] = {
+ [PCI_TSM_MODE_LINK] = "link",
+ [PCI_TSM_MODE_SELECTIVE] = "selective",
+};
+
+static ssize_t connect_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ int i;
+
+ guard(mutex)(tsm_ops->lock);
+ if (pdev->tsm->state >= PCI_TSM_CONNECT)
+ return -EBUSY;
+ for (i = 0; i < ARRAY_SIZE(pci_tsm_modes); i++)
+ if (sysfs_streq(buf, pci_tsm_modes[i]))
+ break;
+ if (i == PCI_TSM_MODE_LINK) {
+ if (pdev->tsm->link_capable)
+ pdev->tsm->mode = PCI_TSM_MODE_LINK;
+ return -EOPNOTSUPP;
+ } else if (i == PCI_TSM_MODE_SELECTIVE) {
+ if (pdev->tsm->selective_capable)
+ pdev->tsm->mode = PCI_TSM_MODE_SELECTIVE;
+ return -EOPNOTSUPP;
+ } else
+ return -EINVAL;
+ return len;
+}
+
+static ssize_t connect_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ ssize_t count = 0;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(pci_tsm_modes); i++) {
+ if (i == PCI_TSM_MODE_LINK) {
+ if (!pdev->tsm->link_capable)
+ continue;
+ } else if (i == PCI_TSM_MODE_SELECTIVE) {
+ if (!pdev->tsm->selective_capable)
+ continue;
+ }
+
+ if (i == pdev->tsm->mode)
+ count += sysfs_emit_at(buf, count, "[%s] ",
+ pci_tsm_modes[i]);
+ else
+ count += sysfs_emit_at(buf, count, "%s ",
+ pci_tsm_modes[i]);
+ }
+
+ if (count)
+ buf[count - 1] = '\n';
+
+ return count;
+}
+static DEVICE_ATTR_RW(connect_mode);
+
+static umode_t pci_tsm_attr_visible(struct kobject *kobj, struct attribute *a, int n)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (a == &dev_attr_connect_mode.attr) {
+ if (pdev->tsm->link_capable || pdev->tsm->selective_capable)
+ return a->mode;
+ return 0;
+ }
+
+ return a->mode;
+}
+
+static bool pci_tsm_group_visible(struct kobject *kobj)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (pdev->tsm && pdev->tsm->state > PCI_TSM_IDLE)
+ return true;
+ return false;
+}
+DEFINE_SYSFS_GROUP_VISIBLE(pci_tsm);
+
+static struct attribute *pci_tsm_attrs[] = {
+ &dev_attr_connect.attr,
+ &dev_attr_connect_mode.attr,
+ NULL,
+};
+
+const struct attribute_group pci_tsm_attr_group = {
+ .name = "tsm",
+ .attrs = pci_tsm_attrs,
+ .is_visible = SYSFS_GROUP_VISIBLE(pci_tsm),
+};
+
+static int pci_tsm_add(struct pci_dev *pdev)
+{
+ lockdep_assert_held(&pci_tsm_rwsem);
+ if (!tsm_ops)
+ return 0;
+ scoped_guard(mutex, tsm_ops->lock) {
+ if (pdev->tsm->state < PCI_TSM_INIT) {
+ int rc = tsm_ops->add(pdev);
+
+ if (rc)
+ return rc;
+ }
+ pdev->tsm->state = PCI_TSM_INIT;
+ }
+ return sysfs_update_group(&pdev->dev.kobj, &pci_tsm_attr_group);
+}
+
+static void pci_tsm_del(struct pci_dev *pdev)
+{
+ lockdep_assert_held(&pci_tsm_rwsem);
+ /* shutdown sysfs operations before tsm delete */
+ pdev->tsm->state = PCI_TSM_IDLE;
+ sysfs_update_group(&pdev->dev.kobj, &pci_tsm_attr_group);
+ guard(mutex)(tsm_ops->lock);
+ tsm_ops->del(pdev);
+}
+
+int pci_tsm_register(const struct tsm_pci_ops *ops)
+{
+ struct pci_dev *pdev;
+ unsigned long index;
+
+ guard(rwsem_write)(&pci_tsm_rwsem);
+ if (tsm_ops)
+ return -EBUSY;
+ tsm_ops = ops;
+ xa_for_each(&pci_tsm_devs, index, pdev)
+ pci_tsm_add(pdev);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pci_tsm_register);
+
+void pci_tsm_unregister(const struct tsm_pci_ops *ops)
+{
+ struct pci_dev *pdev;
+ unsigned long index;
+
+ guard(rwsem_write)(&pci_tsm_rwsem);
+ if (ops != tsm_ops)
+ return;
+ xa_for_each(&pci_tsm_devs, index, pdev)
+ pci_tsm_del(pdev);
+ tsm_ops = NULL;
+}
+EXPORT_SYMBOL_GPL(pci_tsm_unregister);
+
+void pci_tsm_init(struct pci_dev *pdev)
+{
+ u16 ide_cap;
+ int rc;
+
+ if (!pdev->cma_capable)
+ return;
+
+ ide_cap = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_IDE);
+ if (!ide_cap)
+ return;
+
+ struct pci_tsm *tsm __free(kfree) = kzalloc(sizeof(*tsm), GFP_KERNEL);
+ if (!tsm)
+ return;
+
+ tsm->ide_cap = ide_cap;
+
+ rc = xa_insert(&pci_tsm_devs, (unsigned long)pdev, pdev, GFP_KERNEL);
+ if (rc) {
+ pci_dbg(pdev, "failed to register tsm capable device\n");
+ return;
+ }
+
+ guard(rwsem_write)(&pci_tsm_rwsem);
+ pdev->tsm = no_free_ptr(tsm);
+ pci_tsm_add(pdev);
+}
+
+void pci_tsm_destroy(struct pci_dev *pdev)
+{
+ guard(rwsem_write)(&pci_tsm_rwsem);
+ pci_tsm_del(pdev);
+ xa_erase(&pci_tsm_devs, (unsigned long)pdev);
+ kfree(pdev->tsm);
+ pdev->tsm = NULL;
+}
+
+bool pci_tsm_authenticated(struct pci_dev *pdev)
+{
+ guard(rwsem_read)(&pci_tsm_rwsem);
+ return pdev->tsm && pdev->tsm->state >= PCI_TSM_CONNECT;
+}
diff --git a/drivers/virt/coco/tsm/Makefile b/drivers/virt/coco/tsm/Makefile
index f7561169faed..a4f0d07d7d97 100644
--- a/drivers/virt/coco/tsm/Makefile
+++ b/drivers/virt/coco/tsm/Makefile
@@ -7,3 +7,4 @@ tsm_reports-y := reports.o
obj-$(CONFIG_TSM) += tsm.o
tsm-y := class.o
+tsm-$(CONFIG_PCI_TSM) += pci.o
diff --git a/drivers/virt/coco/tsm/class.c b/drivers/virt/coco/tsm/class.c
index a569fa6b09eb..a459e51c0892 100644
--- a/drivers/virt/coco/tsm/class.c
+++ b/drivers/virt/coco/tsm/class.c
@@ -8,13 +8,11 @@
#include <linux/device.h>
#include <linux/module.h>
#include <linux/cleanup.h>
+#include "tsm.h"
static DECLARE_RWSEM(tsm_core_rwsem);
-struct class *tsm_class;
-struct tsm_subsys {
- struct device dev;
- const struct tsm_info *info;
-} *tsm_subsys;
+static struct class *tsm_class;
+static struct tsm_subsys *tsm_subsys;
int tsm_register(const struct tsm_info *info)
{
@@ -52,6 +50,10 @@ int tsm_register(const struct tsm_info *info)
dev = NULL;
tsm_subsys = subsys;
+ rc = tsm_pci_init(info);
+ if (rc)
+ pr_err("PCI initialization failure: %d\n", rc);
+
return 0;
}
EXPORT_SYMBOL_GPL(tsm_register);
@@ -65,6 +67,8 @@ void tsm_unregister(const struct tsm_info *info)
return;
}
+ tsm_pci_destroy(info);
+
if (info->host)
sysfs_remove_link(&tsm_subsys->dev.kobj, "host");
device_unregister(&tsm_subsys->dev);
@@ -79,6 +83,13 @@ static void tsm_release(struct device *dev)
kfree(subsys);
}
+static const struct attribute_group *tsm_attr_groups[] = {
+#ifdef CONFIG_PCI_TSM
+ &tsm_pci_attr_group,
+#endif
+ NULL,
+};
+
static int __init tsm_init(void)
{
tsm_class = class_create("tsm");
@@ -86,6 +97,7 @@ static int __init tsm_init(void)
return PTR_ERR(tsm_class);
tsm_class->dev_release = tsm_release;
+ tsm_class->dev_groups = tsm_attr_groups;
return 0;
}
module_init(tsm_init)
diff --git a/drivers/virt/coco/tsm/pci.c b/drivers/virt/coco/tsm/pci.c
new file mode 100644
index 000000000000..b3684ad7114f
--- /dev/null
+++ b/drivers/virt/coco/tsm/pci.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright(c) 2024 Intel Corporation. All rights reserved. */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/tsm.h>
+#include <linux/device.h>
+#include "tsm.h"
+
+static ssize_t link_capable_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct tsm_subsys *subsys = container_of(dev, typeof(*subsys), dev);
+
+ return sysfs_emit(buf, "%u\n", subsys->info->link_stream_capable);
+}
+static DEVICE_ATTR_RO(link_capable);
+
+static ssize_t selective_streams_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct tsm_subsys *subsys = container_of(dev, typeof(*subsys), dev);
+
+ return sysfs_emit(buf, "%u\n", subsys->info->nr_selective_streams);
+}
+static DEVICE_ATTR_RO(selective_streams);
+
+static umode_t tsm_pci_attr_visible(struct kobject *kobj, struct attribute *a, int n)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct tsm_subsys *subsys = container_of(dev, typeof(*subsys), dev);
+ const struct tsm_info *info = subsys->info;
+
+ if (a == &dev_attr_link_capable.attr) {
+ if (info->link_stream_capable)
+ return a->mode;
+ return 0;
+ }
+
+ if (a == &dev_attr_selective_streams.attr) {
+ if (info->nr_selective_streams)
+ return a->mode;
+ return 0;
+ }
+
+ return a->mode;
+}
+
+static bool tsm_pci_group_visible(struct kobject *kobj)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct tsm_subsys *subsys = container_of(dev, typeof(*subsys), dev);
+
+ if (subsys->info->pci_ops)
+ return true;
+ return false;
+}
+DEFINE_SYSFS_GROUP_VISIBLE(tsm_pci);
+
+static struct attribute *tsm_pci_attrs[] = {
+ &dev_attr_link_capable.attr,
+ &dev_attr_selective_streams.attr,
+ NULL,
+};
+
+const struct attribute_group tsm_pci_attr_group = {
+ .name = "pci",
+ .attrs = tsm_pci_attrs,
+ .is_visible = SYSFS_GROUP_VISIBLE(tsm_pci),
+};
+
+int tsm_pci_init(const struct tsm_info *info)
+{
+ if (!info->pci_ops)
+ return 0;
+
+ return pci_tsm_register(info->pci_ops);
+}
+
+void tsm_pci_destroy(const struct tsm_info *info)
+{
+ pci_tsm_unregister(info->pci_ops);
+}
diff --git a/drivers/virt/coco/tsm/tsm.h b/drivers/virt/coco/tsm/tsm.h
new file mode 100644
index 000000000000..407c388a109b
--- /dev/null
+++ b/drivers/virt/coco/tsm/tsm.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __TSM_CORE_H
+#define __TSM_CORE_H
+
+#include <linux/device.h>
+
+struct tsm_info;
+struct tsm_subsys {
+ struct device dev;
+ const struct tsm_info *info;
+};
+
+#ifdef CONFIG_PCI_TSM
+int tsm_pci_init(const struct tsm_info *info);
+void tsm_pci_destroy(const struct tsm_info *info);
+extern const struct attribute_group tsm_pci_attr_group;
+#else
+static inline int tsm_pci_init(const struct tsm_info *info)
+{
+ return 0;
+}
+static inline void tsm_pci_destroy(const struct tsm_info *info)
+{
+}
+#endif
+
+#endif /* TSM_CORE_H */
+
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 4a04ce7685e7..132962b21e04 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -522,6 +522,9 @@ struct pci_dev {
struct spdm_state *spdm_state; /* Security Protocol and Data Model */
unsigned int cma_capable:1; /* Authentication supported */
unsigned int cma_init_failed:1;
+#endif
+#ifdef CONFIG_PCI_TSM
+ struct pci_tsm *tsm; /* TSM operation state */
#endif
u16 acs_cap; /* ACS Capability offset */
phys_addr_t rom; /* Physical address if not from BAR */
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index 8cb8a661ba41..f5dbdfa65d8d 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -4,11 +4,15 @@
#include <linux/sizes.h>
#include <linux/types.h>
+#include <linux/mutex.h>
struct tsm_info {
const char *name;
struct device *host;
const struct attribute_group **groups;
+ const struct tsm_pci_ops *pci_ops;
+ unsigned int nr_selective_streams;
+ unsigned int link_stream_capable:1;
};
#define TSM_REPORT_INBLOB_MAX 64
@@ -74,4 +78,77 @@ int tsm_report_register(const struct tsm_report_ops *ops, void *priv,
int tsm_report_unregister(const struct tsm_report_ops *ops);
int tsm_register(const struct tsm_info *info);
void tsm_unregister(const struct tsm_info *info);
+
+enum pci_tsm_op_status {
+ PCI_TSM_FAIL = -1,
+ PCI_TSM_OK,
+ PCI_TSM_SPDM_REQ,
+};
+
+enum pci_tsm_op {
+ PCI_TSM_OP_CONNECT,
+ PCI_TSM_OP_DISCONNECT,
+};
+
+struct pci_tsm_req {
+ enum pci_tsm_op op;
+ unsigned int seq;
+};
+
+struct pci_dev;
+/**
+ * struct tsm_pci_ops - Low-level TSM-exported interface to the PCI core
+ * @add: accept device for tsm operation, locked
+ * @del: teardown tsm context for @pdev, locked
+ * @req_alloc: setup context for given operation, unlocked
+ * @req_free: teardown context for given request, unlocked
+ * @exec: run @req, may be invoked multiple times per @req, locked
+ * @lock: tsm work is one device and one op at a time
+ */
+struct tsm_pci_ops {
+ int (*add)(struct pci_dev *pdev);
+ void (*del)(struct pci_dev *pdev);
+ struct pci_tsm_req *(*req_alloc)(struct pci_dev *pdev,
+ enum pci_tsm_op op);
+ struct pci_tsm_req *(*req_free)(struct pci_tsm_req *req);
+ enum pci_tsm_op_status (*exec)(struct pci_dev *pdev,
+ struct pci_tsm_req *req);
+ struct mutex *lock;
+};
+
+enum pci_tsm_state {
+ PCI_TSM_IDLE,
+ PCI_TSM_INIT,
+ PCI_TSM_CONNECT,
+};
+
+enum pci_tsm_mode {
+ PCI_TSM_MODE_LINK,
+ PCI_TSM_MODE_SELECTIVE,
+};
+
+struct pci_tsm {
+ enum pci_tsm_state state;
+ enum pci_tsm_mode mode;
+ u16 ide_cap;
+ unsigned int link_capable:1;
+ unsigned int selective_capable:1;
+ void *tsm_data;
+};
+
+#ifdef CONFIG_PCI_TSM
+int pci_tsm_register(const struct tsm_pci_ops *ops);
+void pci_tsm_unregister(const struct tsm_pci_ops *ops);
+void generic_pci_tsm_req_free(struct pci_tsm_req *req);
+struct pci_tsm_req *generic_pci_tsm_req_alloc(struct pci_dev *pdev,
+ enum pci_tsm_op op);
+#else
+static inline int pci_tsm_register(const struct tsm_pci_ops *ops)
+{
+ return 0;
+}
+static inline void pci_tsm_unregister(const struct tsm_pci_ops *ops)
+{
+}
+#endif
#endif /* __TSM_H */
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index a39193213ff2..1219d50f8e89 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -742,7 +742,8 @@
#define PCI_EXT_CAP_ID_PL_16GT 0x26 /* Physical Layer 16.0 GT/s */
#define PCI_EXT_CAP_ID_PL_32GT 0x2A /* Physical Layer 32.0 GT/s */
#define PCI_EXT_CAP_ID_DOE 0x2E /* Data Object Exchange */
-#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_DOE
+#define PCI_EXT_CAP_ID_IDE 0x30 /* Integrity and Data Encryption */
+#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_IDE
#define PCI_EXT_CAP_DSN_SIZEOF 12
#define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
^ permalink raw reply related [relevance 6%]
* [PATCH 3/5] fstests/MAINTAINERS: add supported mailing list
2023-04-04 17:14 6% ` [f2fs-dev] " Zorro Lang
@ 2023-04-04 17:14 6% ` Zorro Lang
1 sibling, 0 replies; 200+ results
From: Zorro Lang @ 2023-04-04 17:14 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, ceph-devel, linux-cifs, linux-ext4, linux-f2fs-devel,
linux-fsdevel, linux-nfs, ocfs2-devel, linux-unionfs, jack,
linux-xfs, fdmanana, ebiggers, brauner, amir73il, djwong,
anand.jain
The fstests supports different kind of fs testing, better to cc
specific fs mailing list for specific fs testing, to get better
reviewing points. So record these mailing lists and files related
with them in MAINTAINERS file.
Signed-off-by: Zorro Lang <zlang@kernel.org>
---
If someone mailing list doesn't want to be in cc list of related fstests
patch, please reply this email, I'll remove that line.
Or if I missed someone mailing list, please feel free to tell me.
Thanks,
Zorro
MAINTAINERS | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 09b1a5a3..620368cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -107,6 +107,83 @@ Maintainers List
should send patch to fstests@ at least. Other relevant mailing list
or reviewer or co-maintainer can be in cc list.
+BTRFS
+L: linux-btrfs@vger.kernel.org
+S: Supported
+F: tests/btrfs/
+F: common/btrfs
+
+CEPH
+L: ceph-devel@vger.kernel.org
+S: Supported
+F: tests/ceph/
+F: common/ceph
+
+CIFS
+L: linux-cifs@vger.kernel.org
+S: Supported
+F: tests/cifs
+
+EXT4
+L: linux-ext4@vger.kernel.org
+S: Supported
+F: tests/ext4/
+F: common/ext4
+
+F2FS
+L: linux-f2fs-devel@lists.sourceforge.net
+S: Supported
+F: tests/f2fs/
+F: common/f2fs
+
+FSVERITY
+L: fsverity@lists.linux.dev
+S: Supported
+F: common/verity
+
+FSCRYPT
+L: linux-fscrypt@vger.kernel.org
+S: Supported
+F: common/encrypt
+
+FS-IDMAPPED
+L: linux-fsdevel@vger.kernel.org
+S: Supported
+F: src/vfs/
+
+NFS
+L: linux-nfs@vger.kernel.org
+S: Supported
+F: tests/nfs/
+F: common/nfs
+
+OCFS2
+L: ocfs2-devel@oss.oracle.com
+S: Supported
+F: tests/ocfs2/
+
+OVERLAYFS
+L: linux-unionfs@vger.kernel.org
+S: Supported
+F: tests/overlay
+F: common/overlay
+
+UDF
+R: Jan Kara <jack@suse.com>
+S: Supported
+F: tests/udf/
+
+XFS
+L: linux-xfs@vger.kernel.org
+S: Supported
+F: common/dump
+F: common/fuzzy
+F: common/inject
+F: common/populate
+F: common/repair
+F: common/xfs
+F: tests/xfs/
+
ALL
M: Zorro Lang <zlang@kernel.org>
L: fstests@vger.kernel.org
--
2.39.2
^ permalink raw reply related [relevance 6%]
* + maintainers-change-vmwarecom-addresses-to-broadcomcom.patch added to mm-hotfixes-unstable branch
@ 2024-04-03 21:31 6% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-04-03 21:31 UTC (permalink / raw)
To: mm-commits, vishnu.dasa, vishal.bhakta, ronak.doshi, nick.shi,
gregkh, florian.fainelli, bryan-bt.tan, ajay.kaher,
alexey.makhalov, akpm
The patch titled
Subject: MAINTAINERS: change vmware.com addresses to broadcom.com
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
maintainers-change-vmwarecom-addresses-to-broadcomcom.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/maintainers-change-vmwarecom-addresses-to-broadcomcom.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Alexey Makhalov <alexey.makhalov@broadcom.com>
Subject: MAINTAINERS: change vmware.com addresses to broadcom.com
Date: Tue, 2 Apr 2024 16:23:34 -0700
Update all remaining vmware.com email addresses to actual broadcom.com.
Add corresponding .mailmap entries for maintainers who contributed in the
past as the vmware.com address will start bouncing soon.
Maintainership update. Jeff Sipek has left VMware, Nick Shi will be
maintaining VMware PTP.
Link: https://lkml.kernel.org/r/20240402232334.33167-1-alexey.makhalov@broadcom.com
Signed-off-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Ajay Kaher <ajay.kaher@broadcom.com>
Acked-by: Ronak Doshi <ronak.doshi@broadcom.com>
Acked-by: Nick Shi <nick.shi@broadcom.com>
Acked-by: Bryan Tan <bryan-bt.tan@broadcom.com>
Acked-by: Vishnu Dasa <vishnu.dasa@broadcom.com>
Acked-by: Vishal Bhakta <vishal.bhakta@broadcom.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
.mailmap | 5 +++++
MAINTAINERS | 46 +++++++++++++++++++++++-----------------------
2 files changed, 28 insertions(+), 23 deletions(-)
--- a/.mailmap~maintainers-change-vmwarecom-addresses-to-broadcomcom
+++ a/.mailmap
@@ -20,6 +20,7 @@ Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.com>
Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com>
Adrian Bunk <bunk@stusta.de>
+Ajay Kaher <ajay.kaher@broadcom.com> <akaher@vmware.com>
Akhil P Oommen <quic_akhilpo@quicinc.com> <akhilpo@codeaurora.org>
Alan Cox <alan@lxorguk.ukuu.org.uk>
Alan Cox <root@hraefn.swansea.linux.org.uk>
@@ -36,6 +37,7 @@ Alexei Avshalom Lazar <quic_ailizaro@qui
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
+Alexey Makhalov <alexey.amakhalov@broadcom.com> <amakhalov@vmware.com>
Alex Hung <alexhung@gmail.com> <alex.hung@canonical.com>
Alex Shi <alexs@kernel.org> <alex.shi@intel.com>
Alex Shi <alexs@kernel.org> <alex.shi@linaro.org>
@@ -110,6 +112,7 @@ Brendan Higgins <brendan.higgins@linux.d
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com>
+Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com>
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org>
Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org>
@@ -529,6 +532,7 @@ Rocky Liao <quic_rjliao@quicinc.com> <rj
Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com>
Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com>
Roman Gushchin <roman.gushchin@linux.dev> <klamm@yandex-team.ru>
+Ronak Doshi <ronak.doshi@broadcom.com> <doshir@vmware.com>
Muchun Song <muchun.song@linux.dev> <songmuchun@bytedance.com>
Muchun Song <muchun.song@linux.dev> <smuchun@gmail.com>
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
@@ -651,6 +655,7 @@ Viresh Kumar <vireshk@kernel.org> <vires
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.org>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.com>
+Vishnu Dasa <vishnu.dasa@broadcom.com> <vdasa@vmware.com>
Vivek Aknurwar <quic_viveka@quicinc.com> <viveka@codeaurora.org>
Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
--- a/MAINTAINERS~maintainers-change-vmwarecom-addresses-to-broadcomcom
+++ a/MAINTAINERS
@@ -16731,9 +16731,9 @@ F: include/uapi/linux/ppdev.h
PARAVIRT_OPS INTERFACE
M: Juergen Gross <jgross@suse.com>
-R: Ajay Kaher <akaher@vmware.com>
-R: Alexey Makhalov <amakhalov@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+R: Ajay Kaher <ajay.kaher@broadcom.com>
+R: Alexey Makhalov <alexey.amakhalov@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: virtualization@lists.linux.dev
L: x86@kernel.org
S: Supported
@@ -23652,9 +23652,9 @@ S: Supported
F: drivers/misc/vmw_balloon.c
VMWARE HYPERVISOR INTERFACE
-M: Ajay Kaher <akaher@vmware.com>
-M: Alexey Makhalov <amakhalov@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Ajay Kaher <ajay.kaher@broadcom.com>
+M: Alexey Makhalov <alexey.amakhalov@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: virtualization@lists.linux.dev
L: x86@kernel.org
S: Supported
@@ -23663,34 +23663,34 @@ F: arch/x86/include/asm/vmware.h
F: arch/x86/kernel/cpu/vmware.c
VMWARE PVRDMA DRIVER
-M: Bryan Tan <bryantan@vmware.com>
-M: Vishnu Dasa <vdasa@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Bryan Tan <bryan-bt.tan@broadcom.com>
+M: Vishnu Dasa <vishnu.dasa@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-rdma@vger.kernel.org
S: Supported
F: drivers/infiniband/hw/vmw_pvrdma/
VMWARE PVSCSI DRIVER
-M: Vishal Bhakta <vbhakta@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Vishal Bhakta <vishal.bhakta@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-scsi@vger.kernel.org
S: Supported
F: drivers/scsi/vmw_pvscsi.c
F: drivers/scsi/vmw_pvscsi.h
VMWARE VIRTUAL PTP CLOCK DRIVER
-M: Jeff Sipek <jsipek@vmware.com>
-R: Ajay Kaher <akaher@vmware.com>
-R: Alexey Makhalov <amakhalov@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Nick Shi <nick.shi@broadcom.com>
+R: Ajay Kaher <ajay.kaher@broadcom.com>
+R: Alexey Makhalov <alexey.amakhalov@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/ptp/ptp_vmw.c
VMWARE VMCI DRIVER
-M: Bryan Tan <bryantan@vmware.com>
-M: Vishnu Dasa <vdasa@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Bryan Tan <bryan-bt.tan@broadcom.com>
+M: Vishnu Dasa <vishnu.dasa@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-kernel@vger.kernel.org
S: Supported
F: drivers/misc/vmw_vmci/
@@ -23705,16 +23705,16 @@ F: drivers/input/mouse/vmmouse.c
F: drivers/input/mouse/vmmouse.h
VMWARE VMXNET3 ETHERNET DRIVER
-M: Ronak Doshi <doshir@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Ronak Doshi <ronak.doshi@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/vmxnet3/
VMWARE VSOCK VMCI TRANSPORT DRIVER
-M: Bryan Tan <bryantan@vmware.com>
-M: Vishnu Dasa <vdasa@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Bryan Tan <bryan-bt.tan@broadcom.com>
+M: Vishnu Dasa <vishnu.dasa@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-kernel@vger.kernel.org
S: Supported
F: net/vmw_vsock/vmci_transport*
_
Patches currently in -mm which might be from alexey.makhalov@broadcom.com are
maintainers-change-vmwarecom-addresses-to-broadcomcom.patch
^ permalink raw reply [relevance 6%]
* Re: add volatile flag to PV/LVs (for cache) to avoid degraded state on reboot
@ 2024-01-20 20:29 6% ` lists.linux.dev
0 siblings, 0 replies; 200+ results
From: lists.linux.dev @ 2024-01-20 20:29 UTC (permalink / raw)
To: Zdenek Kabelac; +Cc: linux-lvm
On Thu, Jan 18, 2024 at 04:40:47PM +0100, Zdenek Kabelac wrote:
> Cache can contain blocks that are still being 'synchronized' to the cache
> origin. So while the 'writing' process doesn't get ACK for writes - the
> cache
> may have valid blocks that are 'dirty' in terms of being synchronized to
> origin device.
>
> And while this is usually not a problem when system works properly,
> it's getting into weird 'state machine' model when i.e. origin device has
> errors - which might be even 'transient' with all the variety of storage
> types and raid arrays with integrity and self-healing and so on...
>
> So while it's usually not a problem for a laptop with 2 disks, the world is
> more complex...
Ehm, but wouldn't anything other than discarding that block from the cache and using whatever is on the backing storage introduce unpredictable errors?
As like you already said it was never ACKed, so the software that tried to write it never expected it to be written.
Why exactly are we allowed to use the data from the write-through cache to modify the data on the backing storage in such cases?
I.E. Why can we safely consider it as valid data?
> metadata - so if there is again some 'reboot' and PV with cache appears back
> - it will not interfere with the system (aka providing some historical
> cached blocks, so just like mirrored leg needs some care...)
Same here, why do we have to consider these blocks at all and can't discard them? We know when a drive re-appears, so we could just not use it without validation, or in the case the volatile flag I suggested would be used, just wipe it and start over...
After all I don't know anyone that designs their storage systems with the assumption that the write-through cache has to be redundant.
Even more, I know enough people in data center environments that reuse their "failing but still kinda good" SSDs and NVMEs for write-through caches using the assumption that them failing at most impacts read performance but not data security.
Is there some common missconception at play? Or what exaclty am I missing here?
Sincerely,
Klaus Frank
^ permalink raw reply [relevance 6%]
* [PATCH v3 1/2] docs: add a document about regression handling
@ 2022-01-25 11:44 6% ` Thorsten Leemhuis
0 siblings, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2022-01-25 11:44 UTC (permalink / raw)
To: linux-doc, Linus Torvalds
Cc: workflows, Linux Kernel Mailing List, Jonathan Corbet,
Randy Dunlap, regressions, Greg Kroah-Hartman, Lukas Bulwahn
Create a document explaining various aspects around regression handling
and tracking both for users and developers. Among others describe the
first rule of Linux kernel development and what it means in practice.
Also explain what a regression actually is and how to report one
properly. The text additionally provides a brief introduction to the bot
the kernel's regression tracker uses to facilitate his work. To sum
things up, provide a few quotes from Linus to show how serious he takes
regressions.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/admin-guide/index.rst | 1 +
Documentation/admin-guide/regressions.rst | 911 ++++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 913 insertions(+)
create mode 100644 Documentation/admin-guide/regressions.rst
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 1bedab498104..17157ee5a416 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -36,6 +36,7 @@ problems and bugs in particular.
reporting-issues
security-bugs
+ regressions
bug-hunting
bug-bisect
tainted-kernels
diff --git a/Documentation/admin-guide/regressions.rst b/Documentation/admin-guide/regressions.rst
new file mode 100644
index 000000000000..837b1658d149
--- /dev/null
+++ b/Documentation/admin-guide/regressions.rst
@@ -0,0 +1,911 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+..
+ If you want to distribute this text under CC-BY-4.0 only, please use 'The
+ Linux kernel developers' for author attribution and link this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/regressions.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
+
+
+Regressions
++++++++++++
+
+The first rule of Linux kernel development: '*We don't cause regressions*'.
+Linux founder and lead developer Linus Torvalds strictly enforces the rule
+himself. This document describes what it means in practice and how the Linux
+kernel's development model ensures all reported regressions are addressed.
+The text covers aspects relevant for both users and developers.
+
+The important bits for people affected by regressions
+=====================================================
+
+It's a regression if something running fine with one Linux kernel works worse or
+not at all with a newer version. Note, the newer kernel has to be compiled using
+a similar configuration -- for this and other fine print, check out below
+section "What is a 'regression' and what is the 'no regressions rule'?".
+
+Report your regression as outlined in
+`Documentation/admin-guide/reporting-issues.rst`, it already covers all aspects
+important for regressions. Below section "How do I report a regression?"
+highlights them for convenience.
+
+The most important aspect: CC or forward the report to `the regression mailing
+list <https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev).
+When doing so, consider mentioning the version range where the regression
+started using a paragraph like this::
+
+ #regzbot introduced v5.13..v5.14-rc1
+
+The Linux kernel regression tracking bot 'regzbot' will then start to track the
+issue. This is in your interest, as it brings the report on the radar of people
+ensuring all regressions are acted upon in a timely manner.
+
+The important bits for people fixing regressions
+================================================
+
+When submitting fixes for regressions, add "Link:" tags pointing to all places
+where the issue was reported, as tools like the Linux kernel regression bot
+'regzbot' heavily rely on them. These pointers are also of great value when
+looking into the issue months or years later, that's why
+`Documentation/process/submitting-patches.rst` and
+:ref:`Documentation/process/5.Posting.rst <development_posting>` mandate their
+use::
+
+ Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
+
+Let the Linux kernel's regression tracker and all other subscribers of the
+`regression mailing list <https://lore.kernel.org/regressions/>`_
+(regressions@lists.linux.dev) quickly know about newly reported regressions:
+
+ * When you receive a mailed report that did not CC the list, immediately send
+ at least a brief "Reply-all" which get the list into the loop; also ensure
+ it's CCed on all future replies.
+
+ * If you get a report from a bug tracker, forward or bounce the report to the
+ list, unless the reporter did that already as outlined by
+ `Documentation/admin-guide/reporting-issues.rst`.
+
+Ensure regzbot tracks the issue (this is optional, but recommended):
+
+ * For mailed reports, check if the reporter included a 'regzbot command' like
+ the ``#regzbot introduced v5.13..v5.14-rc1`` described above. If not, send a
+ reply (with the regressions list in CC) with a paragraph like the following,
+ which brings regzbot into the loop by specifying the version range or commit
+ when the issue started to happen::
+
+ #regzbot ^introduced 1f2e3d4c5b6a
+
+ * When receiving a report from a bug tracker and forwarding it to the
+ regressions list (see above), include a paragraph like the following, which
+ brings regzbot into the loop by specifying the version range or commit when
+ the issue started to happen::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+ #regzbot from: Some N. Ice Human <some.human@example.com>
+ #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
+
+All the details on handling Linux kernel regressions
+====================================================
+
+The important basics
+--------------------
+
+What is a 'regression' and what is the 'no regressions rule'?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's a regression if some application or practical use case running fine with
+one Linux kernel works worse or not at all with a newer version compiled using a
+similar configuration. The 'no regressions rule' forbids this to take place; if
+it happens by accident, developers that caused it are expected to quickly fix
+the issue.
+
+It thus is a regression when a WiFi driver from Linux 5.13 works fine, but with
+5.14 doesn't work at all, works significantly slower, or misbehaves somehow.
+It's also a regression if a perfectly working application suddenly shows erratic
+behavior with a newer kernel version, which can be caused by changes in procfs,
+sysfs, or one of the many other interfaces Linux provides to userland software.
+But keep in mind, as mentioned earlier: 5.14 in this example needs to be built
+from a configuration similar to the one from 5.13. This can be achieved using
+``make olddefconfig``, as explained in more detail below.
+
+Note the 'practical use case' in the first sentence of this section: developers
+despite the 'no regressions' rule are free to change any aspect of the kernel
+and even APIs or ABIs to userland, as long as no existing application or use
+case breaks.
+
+Also be aware the 'no regressions' rule covers only interfaces the kernel
+provides to the userland. It thus does not apply to kernel-internal interfaces
+like the module API, which some externally developed drivers use to hook into
+the kernel.
+
+What is the goal of the 'no regressions rule'?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Users should feel safe when updating kernel versions and not have to worry
+something might break. This is in the interest of the kernel developers to make
+updating attractive: they don't want users to stay on stable or longterm Linux
+series that are either abandoned or more than one and a half year old. That's in
+everybody's interest, as `those series might have known bugs, security issues,
+or other problematic aspects already fixed in later versions
+<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_.
+Additionally, the kernel developers want to make it simple and appealing for
+users to test the latest pre-release or regular release. That's also in
+everybody's interest, as it's a lot easier to track down and fix problems, if
+they are reported shortly after being introduced.
+
+
+How hard is the rule enforced?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Extraordinarily strict, as can be seen by many mailing list posts from Linux
+creator and lead developer Linus Torvalds, some of which are quoted at the end
+of this document.
+
+Exceptions to this rule are extremely rare; in the past developers almost always
+turned out to be wrong when they assumed a particular situation was warranting
+an exception.
+
+How is the rule enforced?
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's the duty of the subsystem maintainers, which are watched and supported by
+Linus Torvalds for mainline or stable/longterm tree maintainers like Greg
+Kroah-Hartman. All of them are supported by Thorsten Leemhuis: he's acting as
+'regressions tracker' for the Linux kernel and trying to ensure all regression
+reports are acted upon in a timely manner.
+
+The distributed and slightly unstructured nature of the Linux kernel's
+development makes tracking regressions hard. That's why Thorsten relies on the
+help of his Linux kernel regression tracking robot 'regzbot'. It watches mailing
+lists and git trees to semi-automatically associate regression reports with
+patch submissions and commits fixing the issue, as this provides all necessary
+insights into the fixing progress.
+
+Note, the regression tracker can only ensure no regression falls through the
+cracks, if someone tells him or his bot about every regression found. That's why
+each report needs to be CCed or forwarded to the regressions mailing list
+(ideally with a 'regzbot command' in the mail), as explained in the next
+section.
+
+How do I report a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Just report the issue as outlined in
+`Documentation/admin-guide/reporting-issues.rst`, it already describes the
+important points. The following aspects described there are especially relevant
+for regressions:
+
+ * When checking for existing reports to join, first check the `archives of the
+ Linux regressions mailing list <https://lore.kernel.org/regressions/>`_ and
+ `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_.
+
+ * In your report, mention the last kernel version that worked fine and the
+ first broken one. Even better: try to find the commit causing the regression
+ using a bisection.
+
+ * Remember to let the Linux regressions mailing list
+ (regressions@lists.linux.dev) know about your report:
+
+ * If you report the regression by mail, CC the regressions list.
+
+ * If you report your regression to some bug tracker, forward the filed report
+ by mail to the regressions list while CCing the maintainer and the mailing
+ list for the subsystem in question.
+
+Additionally, you in both cases should directly tell the aforementioned Linux
+kernel regression tracking bot about your report. To do that, include a
+paragraph like this in your report to tell the bot when the regression started
+to happen::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+
+In this example, v5.13 was the last version that worked, while v5.14-rc1 was the
+first broken one. The smaller the range, the better, as that makes it easier to
+find out what's wrong and who's responsible. That's why you ideally should
+perform a bisection to find the commit causing the regression (the 'culprit').
+If you did, specify it instead::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+Placing such a 'regzbot command' is in your interest, as it will ensure the
+report won't fall through the cracks unnoticed. If you omit this, the Linux
+kernel's regressions tracker will take care of telling regzbot about your
+regression, as long as you send a copy to the regressions mailing lists. But the
+regression tracker is just one human which sometimes has to rest or occasionally
+might even enjoy some time away from computers (as crazy as that might sound).
+Relying on this person thus will result in an unnecessary delay before the
+regressions becomes mentioned `on the list of tracked and unresolved Linux
+kernel regressions <https://linux-regtracking.leemhuis.info/regzbot/>`_ and the
+weekly regression reports sent by regzbot. Such delays can result in Linus
+Torvalds being unaware of important regressions when deciding between 'continue
+development or call this finished and release the final?'.
+
+How to add a regression to regzbot's tracking somebody else reported?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It depends on the report:
+
+ * If the regression was reported by mail, reply using your mailers 'Reply-all'
+ function with the regressions mailing list (regressions@lists.linux.dev) in
+ CC. In your reply, include a paragraph with a regzbot command like this::
+
+ #regzbot ^introduced: v5.13..v5.14-rc1
+
+ The caret (^) before the 'introduced' tells regzbot to treat the parent mail
+ (the one you reply to) as the initial report for the regression you want to
+ see tracked; regzbot then will automatically associate any patches with this
+ regression that point to the report using 'Link:' tags.
+
+ * If the regressions was reported to a bug tracker, forward it to the
+ regressions list and include a paragraph with these regzbot commands::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+ #regzbot from: Some N. Ice Human <some.human@example.com>
+ #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
+
+ Regzbot will automatically associate patches with the report that use 'Link:'
+ tags pointing to your mail or the mentioned ticket.
+
+In both cases you can specify a commit-id instead of a version range, as the
+previous section outlines in more detail.
+
+In case you are having trouble, simply forward the report or a pointer to it
+without further ado to Thorsten Leemhuis (regressions@leemhuis.info), he then
+will handle things.
+
+Are really all regressions fixed?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Nearly all of them are, as long as the change causing the regression (the
+'culprit commit') is reliably identified. Some regressions can be fixed without
+this, but often it's required.
+
+Who needs to find the commit causing a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's the reporter's duty to find the culprit, but developers of the affected
+subsystem should offer advice and reasonably help where they can.
+
+How can I find the change causing a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Perform a bisection, as roughly outlined in `Documentation/admin-guide/reporting-issues.rst`
+and described in more detail by `Documentation/admin-guide/bug-bisect.rst`.
+It might sound like a lot of work, but in many cases finds the culprit
+relatively quickly. If it's hard or time-consuming to reliably reproduce the
+issue, consider teaming up with others affected by the problem to narrow down
+the search range together.
+
+Who can I ask for advice when it comes to regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
+CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the
+issue might better be dealt with in private, feel free to omit the list.
+
+
+More details about regressions relevant for reporters
+-----------------------------------------------------
+
+Does a regression need to be fixed, if it can be avoided by updating some other software?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Almost always: yes. If a developer tells you otherwise, ask the regression
+tracker for advice as outlined above.
+
+Does it qualify as a regression if a newer kernel works slower or makes the system consume more energy?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but the difference has to be significant. A five percent slow-down in a
+micro-benchmark thus is unlikely to qualify as regression, unless it also
+influences the results of a broad benchmark by more than one percent. If in
+doubt, ask for advice.
+
+Is it a regression, if an externally developed kernel module is incompatible with a newer kernel?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+No, as the 'no regression' rule is about interfaces and services the Linux
+kernel provides to the userland. It thus does not cover building or running
+externally developed kernel modules, as they run in kernel-space and hook into
+the kernel using internal interfaces occasionally changed.
+
+How are regressions handled that are caused by a fix for security vulnerability?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In extremely rare situations security issues can't be fixed without causing
+regressions; those are given way, as they are the lesser evil in the end.
+Luckily this almost always can be avoided, as key developers for the affected
+area and often Linus Torvalds himself try very hard to fix security issues
+without causing regressions.
+
+If you nevertheless face such a case, check the mailing list archives if people
+tried their best to avoid the regression; if in doubt, ask for advice as
+outlined above.
+
+What happens if fixing a regression is impossible without causing another regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sadly these things happen, but luckily not very often; if they occur, expert
+developers of the affected code area should look into the issue to find a fix
+that avoids regressions or at least their impact. If you run into such a
+situation, do what was outlined already for regressions caused by security
+fixes: check earlier discussions if people already tried their best and ask for
+advice if in doubt.
+
+A quick note while at it: these situations could be avoided, if people would
+regularly give mainline pre-releases (say v5.15-rc1 or -rc3) from each cycle a
+test run. This is best explained by imagining a change integrated between Linux
+v5.14 and v5.15-rc1 which causes a regression, but at the same time is a hard
+requirement for some other improvement applied for 5.15-rc1. All these changes
+often can simply be reverted and the regression thus solved, if someone finds
+and reports it before 5.15 is released. A few days or weeks later this solution
+can become impossible, as some software might have started to rely on aspects
+introduced by one of the follow-up changes: reverting all changes would then
+cause a regression for users of said software and thus is out of the question.
+
+A feature I relied on was removed months ago, but I only noticed now. Does that qualify as regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but often it's hard to fix them due to the aspects outlined in the
+previous section. It hence needs to be dealt with on a case-by-case basis. This
+is another reason why it's in everybody's interest to regularly test mainline
+pre-releases.
+
+Does the 'no regression' rule apply if I seem to be the only person in the world that is affected by a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but only for practical usage: the Linux developers want to be free to
+remove support for hardware only to be found in attics and museums anymore.
+
+Note, sometimes regressions can't be avoided to make progress -- and the latter
+is needed to prevent Linux from stagnation. Hence, if only very few users seem
+to be affected by a regression, it for the greater good might be in their and
+everyone else's interest to not insist on the rule. Especially if there is an
+easy way to circumvent the regression somehow, for example by updating some
+software or using a kernel parameter created just for this purpose.
+
+Does the regression rule apply for code in the staging tree as well?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Not according to the `help text for the configuration option covering all
+staging code <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_,
+which since its early days states::
+
+ Please note that these drivers are under heavy development, may or
+ may not work, and may contain userspace interfaces that most likely
+ will be changed in the near future.
+
+The staging developers nevertheless often adhere to the 'no regressions' rule,
+but sometimes bend it to make progress. That's for example why some users had to
+deal with (often negligible) regressions when a WiFi driver from the staging
+tree was replaced by a totally different one written from scratch.
+
+Why do later versions have to be 'compiled with a similar configuration'?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Because the Linux kernel developers sometimes integrate changes known to cause
+regressions, but make them optional and disable them in the kernel's default
+configuration. This trick allows progress, as the 'no regressions' rule
+otherwise would lead to stagnation.
+
+Consider for example a new security feature blocking access to some kernel
+interfaces often abused by malware, which at the same time are required to run a
+few rarely used applications. The outlined approach makes both camps happy:
+people using these applications can leave the new security feature off, while
+everyone else can enable it without running into trouble.
+
+How to create a configuration similar to the one of an older kernel?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Start a known-good kernel and configure the newer Linux version with ``make
+olddefconfig``. This makes the kernel's build scripts pick up the configuration
+file (the `.config` file) from the running kernel as base for the new one you
+are about to compile; afterwards they set all new configuration options to their
+default value, which should disable new features that might cause regressions.
+
+Can I report a regression to the upstream developers I found in a pre-compiled vanilla kernel?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You need to ensure the newer kernel was compiled with a similar configuration
+file as the older one (see above), as the one that built them might have enabled
+some known-to-be incompatible feature for the newer kernel. If in a doubt,
+report this problem to the kernel's provider and ask for advice.
+
+
+More details about regressions relevant for developers
+------------------------------------------------------
+
+What should I do, if I suspect a change I'm working on might cause regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Evaluate how big the risk of regressions is, for example by performing a code
+search in Linux distributions and Git forges. Also consider asking other
+developers or projects likely to be affected to evaluate or even test the
+proposed change; if problems surface, maybe some middle ground acceptable for
+all can be found.
+
+If the risk of regressions in the end seems to be relatively small, go ahead
+with the change, but let all involved parties know about the risk. Hence, make
+sure your patch description makes this aspect obvious. Once the change is
+merged, tell the Linux kernel's regression tracker and the regressions mailing
+list about the risk, so everyone has the change on the radar in case reports
+trickle in. Depending on the risk, you also might want to ask the subsystem
+maintainer to mention the issue in his mainline pull request.
+
+
+Everything developers need to know about regression tracking
+------------------------------------------------------------
+
+Do I have to use regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's in the interest of everyone if you do, as kernel maintainers like Linus
+Torvalds partly rely on regzbot's tracking in their work -- for example when
+deciding to release a new version or extend the development phase. For this they
+need to be aware of all unfixed regression; to do that, Linus is known to look
+into the weekly reports sent by regzbot.
+
+Do I have to tell regzbot about every regression I stumble upon?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ideally yes: we are all humans and easily forget problems when something more
+important unexpectedly comes up -- for example a bigger problem in the Linux
+kernel or something in real life that's keeping us away from keyboards for a
+while. Hence, it's best to tell regzbot about every regression, except when you
+immediately write a fix and commit it to a tree regularly merged to the affected
+kernel series.
+
+Why does the Linux kernel need a regression tracker, and why does he utilize regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Rules like 'no regressions' need someone to enforce them, otherwise they are
+broken either accidentally or on purpose. History has shown that this is true
+for the Linux kernel as well. That's why Thorsten volunteered to keep an eye on
+things.
+
+Tracking regressions completely manually has proven to be exhausting and
+demotivating, which is why earlier attempts to establish it failed after a
+while. To prevent this from happening again, Thorsten developed regzbot to
+facilitate the work, with the long term goal to automate regression tracking as
+much as possible for everyone involved.
+
+How does regression tracking work with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bot keeps track of all the reports and monitors their fixing progress. It
+tries to do that with as little overhead as possible for both reporters and
+developers.
+
+In fact, only reporters or someone helping them are burdened with an extra duty:
+they need to tell regzbot about the regression report using one of the
+``#regzbot introduced`` commands outlined above.
+
+For developers there normally is no extra work involved, they just need to do
+something that's expected from them already: add 'Link:' tags to the patch
+description pointing to all reports about the issue fixed.
+
+Thanks to these tags regzbot can associate regression reports with patches to
+fix the issue, whenever they are posted for review or applied to a git tree. The
+bot additionally watches out for replies to the report. All this data combined
+provides a good impression about the current status of the fixing process.
+
+How to see which regressions regzbot tracks currently?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_
+for the latest info; alternatively, `search for the latest regression report
+<https://lore.kernel.org/lkml/?q=%22Linux+regressions+report%22+f%3Aregzbot>`_,
+which regzbot normally sends out once a week on Sunday evening (UTC), which is a
+few hours before Linus usually publishes new (pre-)releases.
+
+What places is regzbot monitoring?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Regzbot is watching the most important Linux mailing lists as well as the
+linux-next, mainline and stable/longterm git repositories.
+
+How to interact with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Everyone can interact with the bot using mails containing 'regzbot commands',
+which need to be in their own paragraph (IOW: they need to be separated from the
+rest of the mail using blank lines). One such command is ``#regzbot introduced
+<version or commit>``, which adds a report to the tracking, as already described
+above; ``#regzbot ^introduced <version or commit>`` is another such command,
+which makes regzbot consider the parent mail as a report for a regression which
+it starts to track.
+
+Once one of those two commands has been utilized, other regzbot commands can be
+used. You can write them below one of the `introduced` commands or in replies to
+the mail that used one of them or itself is a reply to that mail:
+
+ * Set or update the title::
+
+ #regzbot title: foo
+
+ * Link to a related discussion (for example the posting of a patch to fix the
+ issue) and monitor it::
+
+ #regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ Monitoring only works for lore.kernel.org; regzbot will consider all messages
+ in that thread as related to the fixing process.
+
+ * Point to a place with further details, like a bug tracker or a related
+ mailing list post::
+
+ #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * Mark a regression as fixed by a commit that is heading upstream or already
+ landed::
+
+ #regzbot fixed-by: 1f2e3d4c5d
+
+ * Mark a regression as a duplicate of another one already tracked by regzbot::
+
+ #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ * Mark a regression as invalid::
+
+ #regzbot invalid: wasn't a regression, problem has always existed
+
+Is there more to tell about regzbot and its commands?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+More detailed and up-to-date information about the Linux
+kernel's regression tracking bot can be found on its
+`project page <https://gitlab.com/knurd42/regzbot>`_, which among others
+contains a `getting started guide <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
+and `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
+which both cover more details than above section.
+
+
+Quotes from Linus about regression
+----------------------------------
+
+Find below a few real life examples of how Linus Torvalds expects regressions to
+be handled:
+
+ * From `2017-10-26 (1/2)
+ <https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_::
+
+ If you break existing user space setups THAT IS A REGRESSION.
+
+ It's not ok to say "but we'll fix the user space setup".
+
+ Really. NOT OK.
+
+ [...]
+
+ The first rule is:
+
+ - we don't cause regressions
+
+ and the corollary is that when regressions *do* occur, we admit to
+ them and fix them, instead of blaming user space.
+
+ The fact that you have apparently been denying the regression now for
+ three weeks means that I will revert, and I will stop pulling apparmor
+ requests until the people involved understand how kernel development
+ is done.
+
+ * From `2017-10-26 (2/2)
+ <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_::
+
+ People should basically always feel like they can update their kernel
+ and simply not have to worry about it.
+
+ I refuse to introduce "you can only update the kernel if you also
+ update that other program" kind of limitations. If the kernel used to
+ work for you, the rule is that it continues to work for you.
+
+ There have been exceptions, but they are few and far between, and they
+ generally have some major and fundamental reasons for having happened,
+ that were basically entirely unavoidable, and people _tried_hard_ to
+ avoid them. Maybe we can't practically support the hardware any more
+ after it is decades old and nobody uses it with modern kernels any
+ more. Maybe there's a serious security issue with how we did things,
+ and people actually depended on that fundamentally broken model. Maybe
+ there was some fundamental other breakage that just _had_ to have a
+ flag day for very core and fundamental reasons.
+
+ And notice that this is very much about *breaking* peoples environments.
+
+ Behavioral changes happen, and maybe we don't even support some
+ feature any more. There's a number of fields in /proc/<pid>/stat that
+ are printed out as zeroes, simply because they don't even *exist* in
+ the kernel any more, or because showing them was a mistake (typically
+ an information leak). But the numbers got replaced by zeroes, so that
+ the code that used to parse the fields still works. The user might not
+ see everything they used to see, and so behavior is clearly different,
+ but things still _work_, even if they might no longer show sensitive
+ (or no longer relevant) information.
+
+ But if something actually breaks, then the change must get fixed or
+ reverted. And it gets fixed in the *kernel*. Not by saying "well, fix
+ your user space then". It was a kernel change that exposed the
+ problem, it needs to be the kernel that corrects for it, because we
+ have a "upgrade in place" model. We don't have a "upgrade with new
+ user space".
+
+ And I seriously will refuse to take code from people who do not
+ understand and honor this very simple rule.
+
+ This rule is also not going to change.
+
+ And yes, I realize that the kernel is "special" in this respect. I'm
+ proud of it.
+
+ I have seen, and can point to, lots of projects that go "We need to
+ break that use case in order to make progress" or "you relied on
+ undocumented behavior, it sucks to be you" or "there's a better way to
+ do what you want to do, and you have to change to that new better
+ way", and I simply don't think that's acceptable outside of very early
+ alpha releases that have experimental users that know what they signed
+ up for. The kernel hasn't been in that situation for the last two
+ decades.
+
+ We do API breakage _inside_ the kernel all the time. We will fix
+ internal problems by saying "you now need to do XYZ", but then it's
+ about internal kernel API's, and the people who do that then also
+ obviously have to fix up all the in-kernel users of that API. Nobody
+ can say "I now broke the API you used, and now _you_ need to fix it
+ up". Whoever broke something gets to fix it too.
+
+ And we simply do not break user space.
+
+ * From `2020-05-21
+ <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_::
+
+ The rules about regressions have never been about any kind of
+ documented behavior, or where the code lives.
+
+ The rules about regressions are always about "breaks user workflow".
+
+ Users are literally the _only_ thing that matters.
+
+ No amount of "you shouldn't have used this" or "that behavior was
+ undefined, it's your own fault your app broke" or "that used to work
+ simply because of a kernel bug" is at all relevant.
+
+ Now, reality is never entirely black-and-white. So we've had things
+ like "serious security issue" etc that just forces us to make changes
+ that may break user space. But even then the rule is that we don't
+ really have other options that would allow things to continue.
+
+ And obviously, if users take years to even notice that something
+ broke, or if we have sane ways to work around the breakage that
+ doesn't make for too much trouble for users (ie "ok, there are a
+ handful of users, and they can use a kernel command line to work
+ around it" kind of things) we've also been a bit less strict.
+
+ But no, "that was documented to be broken" (whether it's because the
+ code was in staging or because the man-page said something else) is
+ irrelevant. If staging code is so useful that people end up using it,
+ that means that it's basically regular kernel code with a flag saying
+ "please clean this up".
+
+ The other side of the coin is that people who talk about "API
+ stability" are entirely wrong. API's don't matter either. You can make
+ any changes to an API you like - as long as nobody notices.
+
+ Again, the regression rule is not about documentation, not about
+ API's, and not about the phase of the moon.
+
+ It's entirely about "we caused problems for user space that used to work".
+
+ * From `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_::
+
+ > Now this got me wondering if Debian _unstable_ actually qualifies as a
+ > standard distro userspace.
+
+ Oh, if the kernel breaks some standard user space, that counts. Tons
+ of people run Debian unstable (and from my limited interactions with
+ it, for damn good reasons: -stable tends to run so old versions of
+ everything that you have to sometimes deal with cuneiform writing when
+ using it)
+
+ * From `2017-11-05
+ <https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_::
+
+ And our regression rule has never been "behavior doesn't change".
+ That would mean that we could never make any changes at all.
+
+ For example, we do things like add new error handling etc all the
+ time, which we then sometimes even add tests for in our kselftest
+ directory.
+
+ So clearly behavior changes all the time and we don't consider that a
+ regression per se.
+
+ The rule for a regression for the kernel is that some real user
+ workflow breaks. Not some test. Not a "look, I used to be able to do
+ X, now I can't".
+
+ * From `2018-08-03
+ <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_::
+
+ YOU ARE MISSING THE #1 KERNEL RULE.
+
+ We do not regress, and we do not regress exactly because your are 100% wrong.
+
+ And the reason you state for your opinion is in fact exactly *WHY* you
+ are wrong.
+
+ Your "good reasons" are pure and utter garbage.
+
+ The whole point of "we do not regress" is so that people can upgrade
+ the kernel and never have to worry about it.
+
+ > Kernel had a bug which has been fixed
+
+ That is *ENTIRELY* immaterial.
+
+ Guys, whether something was buggy or not DOES NOT MATTER.
+
+ Why?
+
+ Bugs happen. That's a fact of life. Arguing that "we had to break
+ something because we were fixing a bug" is completely insane. We fix
+ tens of bugs every single day, thinking that "fixing a bug" means that
+ we can break something is simply NOT TRUE.
+
+ So bugs simply aren't even relevant to the discussion. They happen,
+ they get found, they get fixed, and it has nothing to do with "we
+ break users".
+
+ Because the only thing that matters IS THE USER.
+
+ How hard is that to understand?
+
+ Anybody who uses "but it was buggy" as an argument is entirely missing
+ the point. As far as the USER was concerned, it wasn't buggy - it
+ worked for him/her.
+
+ Maybe it worked *because* the user had taken the bug into account,
+ maybe it worked because the user didn't notice - again, it doesn't
+ matter. It worked for the user.
+
+ Breaking a user workflow for a "bug" is absolutely the WORST reason
+ for breakage you can imagine.
+
+ It's basically saying "I took something that worked, and I broke it,
+ but now it's better". Do you not see how f*cking insane that statement
+ is?
+
+ And without users, your program is not a program, it's a pointless
+ piece of code that you might as well throw away.
+
+ Seriously. This is *why* the #1 rule for kernel development is "we
+ don't break users". Because "I fixed a bug" is absolutely NOT AN
+ ARGUMENT if that bug fix broke a user setup. You actually introduced a
+ MUCH BIGGER bug by "fixing" something that the user clearly didn't
+ even care about.
+
+ And dammit, we upgrade the kernel ALL THE TIME without upgrading any
+ other programs at all. It is absolutely required, because flag-days
+ and dependencies are horribly bad.
+
+ And it is also required simply because I as a kernel developer do not
+ upgrade random other tools that I don't even care about as I develop
+ the kernel, and I want any of my users to feel safe doing the same
+ time.
+
+ So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel
+ without upgrading some other random binary, then we have a problem.
+
+ * From `2021-06-05
+ <https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_::
+
+ THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS.
+
+ Honestly, security people need to understand that "not working" is not
+ a success case of security. It's a failure case.
+
+ Yes, "not working" may be secure. But security in that case is *pointless*.
+
+ * From `2021-07-30
+ <https://lore.kernel.org/lkml/CAHk-=witY33b-vqqp=ApqyoFDpx9p+n4PwG9N-TvF8bq7-tsHw@mail.gmail.com/>`_::
+
+ But we have the policy that regressions aren't about documentation or
+ even sane behavior.
+
+ Regressions are about whether a user application broke in a noticeable way.
+
+ * From `2011-05-06 (1/3)
+ <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_::
+
+ Binary compatibility is more important.
+
+ And if binaries don't use the interface to parse the format (or just
+ parse it wrongly - see the fairly recent example of adding uuid's to
+ /proc/self/mountinfo), then it's a regression.
+
+ And regressions get reverted, unless there are security issues or
+ similar that makes us go "Oh Gods, we really have to break things".
+
+ I don't understand why this simple logic is so hard for some kernel
+ developers to understand. Reality matters. Your personal wishes matter
+ NOT AT ALL.
+
+ If you made an interface that can be used without parsing the
+ interface description, then we're stuck with the interface. Theory
+ simply doesn't matter.
+
+ You could help fix the tools, and try to avoid the compatibility
+ issues that way. There aren't that many of them.
+
+ * From `2011-05-06 (2/3)
+ <https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_::
+
+ it's clearly NOT an internal tracepoint. By definition. It's being
+ used by powertop.
+
+ * From `2011-05-06 (3/3)
+ <https://lore.kernel.org/all/BANLkTinazaXRdGovYL7rRVp+j6HbJ7pzhg@mail.gmail.com/>`_::
+
+ We have programs that use that ABI and thus it's a regression if they break.
+
+ * From `2006-02-21
+ <https://lore.kernel.org/lkml/Pine.LNX.4.64.0602211631310.30245@g5.osdl.org/>`_::
+
+ The fact is, if changing the kernel breaks user-space, it's a regression.
+ IT DOES NOT MATTER WHETHER IT'S IN /sbin/hotplug OR ANYTHING ELSE. If it
+ was installed by a distribution, it's user-space. If it got installed by
+ "vmlinux", it's the kernel.
+
+ The only piece of user-space code we ship with the kernel is the system
+ call trampoline etc that the kernel sets up. THOSE interfaces we can
+ really change, because it changes with the kernel.
+
+ * From `2019-09-15
+ <https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_::
+
+ One _particularly_ last-minute revert is the top-most commit (ignoring
+ the version change itself) done just before the release, and while
+ it's very annoying, it's perhaps also instructive.
+
+ What's instructive about it is that I reverted a commit that wasn't
+ actually buggy. In fact, it was doing exactly what it set out to do,
+ and did it very well. In fact it did it _so_ well that the much
+ improved IO patterns it caused then ended up revealing a user-visible
+ regression due to a real bug in a completely unrelated area.
+
+ The actual details of that regression are not the reason I point that
+ revert out as instructive, though. It's more that it's an instructive
+ example of what counts as a regression, and what the whole "no
+ regressions" kernel rule means. The reverted commit didn't change any
+ API's, and it didn't introduce any new bugs. But it ended up exposing
+ another problem, and as such caused a kernel upgrade to fail for a
+ user. So it got reverted.
+
+ The point here being that we revert based on user-reported _behavior_,
+ not based on some "it changes the ABI" or "it caused a bug" concept.
+ The problem was really pre-existing, and it just didn't happen to
+ trigger before. The better IO patterns introduced by the change just
+ happened to expose an old bug, and people had grown to depend on the
+ previously benign behavior of that old issue.
+
+ And never fear, we'll re-introduce the fix that improved on the IO
+ patterns once we've decided just how to handle the fact that we had a
+ bad interaction with an interface that people had then just happened
+ to rely on incidental behavior for before. It's just that we'll have
+ to hash through how to do that (there are no less than three different
+ patches by three different developers being discussed, and there might
+ be more coming...). In the meantime, I reverted the thing that exposed
+ the problem to users for this release, even if I hope it will be
+ re-introduced (perhaps even backported as a stable patch) once we have
+ consensus about the issue it exposed.
+
+ Take-away from the whole thing: it's not about whether you change the
+ kernel-userspace ABI, or fix a bug, or about whether the old code
+ "should never have worked in the first place". It's about whether
+ something breaks existing users' workflow.
+
+ Anyway, that was my little aside on the whole regression thing. Since
+ it's that "first rule of kernel programming", I felt it is perhaps
+ worth just bringing it up every once in a while.
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..03bb629302cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10438,6 +10438,7 @@ KERNEL REGRESSIONS
M: Thorsten Leemhuis <linux@leemhuis.info>
L: regressions@lists.linux.dev
S: Supported
+F: Documentation/admin-guide/regressions.rst
KERNEL SELFTEST FRAMEWORK
M: Shuah Khan <shuah@kernel.org>
--
2.31.1
^ permalink raw reply related [relevance 6%]
* [f2fs-dev] [PATCH 3/5] fstests/MAINTAINERS: add supported mailing list
@ 2023-04-04 17:14 6% ` Zorro Lang
0 siblings, 0 replies; 200+ results
From: Zorro Lang @ 2023-04-04 17:14 UTC (permalink / raw)
To: fstests
Cc: brauner, linux-cifs, linux-nfs, ebiggers, djwong, amir73il,
linux-unionfs, anand.jain, linux-f2fs-devel, linux-xfs, fdmanana,
ocfs2-devel, jack, linux-fsdevel, ceph-devel, linux-ext4,
linux-btrfs
The fstests supports different kind of fs testing, better to cc
specific fs mailing list for specific fs testing, to get better
reviewing points. So record these mailing lists and files related
with them in MAINTAINERS file.
Signed-off-by: Zorro Lang <zlang@kernel.org>
---
If someone mailing list doesn't want to be in cc list of related fstests
patch, please reply this email, I'll remove that line.
Or if I missed someone mailing list, please feel free to tell me.
Thanks,
Zorro
MAINTAINERS | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 09b1a5a3..620368cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -107,6 +107,83 @@ Maintainers List
should send patch to fstests@ at least. Other relevant mailing list
or reviewer or co-maintainer can be in cc list.
+BTRFS
+L: linux-btrfs@vger.kernel.org
+S: Supported
+F: tests/btrfs/
+F: common/btrfs
+
+CEPH
+L: ceph-devel@vger.kernel.org
+S: Supported
+F: tests/ceph/
+F: common/ceph
+
+CIFS
+L: linux-cifs@vger.kernel.org
+S: Supported
+F: tests/cifs
+
+EXT4
+L: linux-ext4@vger.kernel.org
+S: Supported
+F: tests/ext4/
+F: common/ext4
+
+F2FS
+L: linux-f2fs-devel@lists.sourceforge.net
+S: Supported
+F: tests/f2fs/
+F: common/f2fs
+
+FSVERITY
+L: fsverity@lists.linux.dev
+S: Supported
+F: common/verity
+
+FSCRYPT
+L: linux-fscrypt@vger.kernel.org
+S: Supported
+F: common/encrypt
+
+FS-IDMAPPED
+L: linux-fsdevel@vger.kernel.org
+S: Supported
+F: src/vfs/
+
+NFS
+L: linux-nfs@vger.kernel.org
+S: Supported
+F: tests/nfs/
+F: common/nfs
+
+OCFS2
+L: ocfs2-devel@oss.oracle.com
+S: Supported
+F: tests/ocfs2/
+
+OVERLAYFS
+L: linux-unionfs@vger.kernel.org
+S: Supported
+F: tests/overlay
+F: common/overlay
+
+UDF
+R: Jan Kara <jack@suse.com>
+S: Supported
+F: tests/udf/
+
+XFS
+L: linux-xfs@vger.kernel.org
+S: Supported
+F: common/dump
+F: common/fuzzy
+F: common/inject
+F: common/populate
+F: common/repair
+F: common/xfs
+F: tests/xfs/
+
ALL
M: Zorro Lang <zlang@kernel.org>
L: fstests@vger.kernel.org
--
2.39.2
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply related [relevance 6%]
* [Ocfs2-devel] [PATCH 3/5] fstests/MAINTAINERS: add supported mailing list
@ 2023-04-04 17:14 6% ` Zorro Lang
0 siblings, 0 replies; 200+ results
From: Zorro Lang via Ocfs2-devel @ 2023-04-04 17:14 UTC (permalink / raw)
To: fstests
Cc: brauner, linux-cifs, linux-nfs, ebiggers, amir73il, linux-unionfs,
anand.jain, linux-f2fs-devel, linux-xfs, fdmanana, ocfs2-devel,
jack, linux-fsdevel, ceph-devel, linux-ext4, linux-btrfs
The fstests supports different kind of fs testing, better to cc
specific fs mailing list for specific fs testing, to get better
reviewing points. So record these mailing lists and files related
with them in MAINTAINERS file.
Signed-off-by: Zorro Lang <zlang@kernel.org>
---
If someone mailing list doesn't want to be in cc list of related fstests
patch, please reply this email, I'll remove that line.
Or if I missed someone mailing list, please feel free to tell me.
Thanks,
Zorro
MAINTAINERS | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 09b1a5a3..620368cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -107,6 +107,83 @@ Maintainers List
should send patch to fstests@ at least. Other relevant mailing list
or reviewer or co-maintainer can be in cc list.
+BTRFS
+L: linux-btrfs@vger.kernel.org
+S: Supported
+F: tests/btrfs/
+F: common/btrfs
+
+CEPH
+L: ceph-devel@vger.kernel.org
+S: Supported
+F: tests/ceph/
+F: common/ceph
+
+CIFS
+L: linux-cifs@vger.kernel.org
+S: Supported
+F: tests/cifs
+
+EXT4
+L: linux-ext4@vger.kernel.org
+S: Supported
+F: tests/ext4/
+F: common/ext4
+
+F2FS
+L: linux-f2fs-devel@lists.sourceforge.net
+S: Supported
+F: tests/f2fs/
+F: common/f2fs
+
+FSVERITY
+L: fsverity@lists.linux.dev
+S: Supported
+F: common/verity
+
+FSCRYPT
+L: linux-fscrypt@vger.kernel.org
+S: Supported
+F: common/encrypt
+
+FS-IDMAPPED
+L: linux-fsdevel@vger.kernel.org
+S: Supported
+F: src/vfs/
+
+NFS
+L: linux-nfs@vger.kernel.org
+S: Supported
+F: tests/nfs/
+F: common/nfs
+
+OCFS2
+L: ocfs2-devel@oss.oracle.com
+S: Supported
+F: tests/ocfs2/
+
+OVERLAYFS
+L: linux-unionfs@vger.kernel.org
+S: Supported
+F: tests/overlay
+F: common/overlay
+
+UDF
+R: Jan Kara <jack@suse.com>
+S: Supported
+F: tests/udf/
+
+XFS
+L: linux-xfs@vger.kernel.org
+S: Supported
+F: common/dump
+F: common/fuzzy
+F: common/inject
+F: common/populate
+F: common/repair
+F: common/xfs
+F: tests/xfs/
+
ALL
M: Zorro Lang <zlang@kernel.org>
L: fstests@vger.kernel.org
--
2.39.2
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply related [relevance 6%]
* [PATCH] MAINTAINERS: Add Oliver Upton as co-maintainer of KVM/arm64
@ 2023-01-23 21:02 6% ` Oliver Upton
0 siblings, 0 replies; 200+ results
From: Oliver Upton @ 2023-01-23 21:02 UTC (permalink / raw)
To: maz
Cc: linux-kernel, pbonzini, seanjc, kvm, kvmarm, james.morse,
suzuki.poulose, yuzenghui, catalin.marinas, will,
linux-arm-kernel, Oliver Upton
Going forward I intend to help Marc with maintaining KVM/arm64. We've
spoken about this quite a bit and he has been a tremendous help in
ramping up to the task (thank you!). We haven't worked out the exact
details of how the process will work, but the goal is to even out the
maintenance responsibilities to give us both ample time for development.
To that end, updating the maintainers entry to reflect the change.
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 42fc47c6edfd..7323efcc1270 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11355,9 +11355,9 @@ F: virt/kvm/*
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
M: Marc Zyngier <maz@kernel.org>
+M: Oliver Upton <oliver.upton@linux.dev>
R: James Morse <james.morse@arm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
-R: Oliver Upton <oliver.upton@linux.dev>
R: Zenghui Yu <yuzenghui@huawei.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: kvmarm@lists.linux.dev
base-commit: 5dc4c995db9eb45f6373a956eb1f69460e69e6d4
--
2.39.1.405.gd4c25cc71f-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 6%]
* [PULL 09/60] docs/system: Add vhost-user-input documentation
@ 2024-02-14 11:13 6% ` Michael S. Tsirkin
0 siblings, 0 replies; 200+ results
From: Michael S. Tsirkin @ 2024-02-14 11:13 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Leo Yan, Alex Bennée, Gerd Hoffmann
From: Leo Yan <leo.yan@linaro.org>
This adds basic documentation for vhost-user-input.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Message-Id: <20231120043721.50555-3-leo.yan@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-10-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
MAINTAINERS | 1 +
docs/system/device-emulation.rst | 1 +
docs/system/devices/vhost-user-input.rst | 45 ++++++++++++++++++++++++
docs/system/devices/vhost-user.rst | 4 ++-
4 files changed, 50 insertions(+), 1 deletion(-)
create mode 100644 docs/system/devices/vhost-user-input.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index aff5342cb4..66c9e81c55 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2289,6 +2289,7 @@ L: virtio-fs@lists.linux.dev
virtio-input
M: Gerd Hoffmann <kraxel@redhat.com>
S: Odd Fixes
+F: docs/system/devices/vhost-user-input.rst
F: hw/input/vhost-user-input.c
F: hw/input/virtio-input*.c
F: include/hw/virtio/virtio-input.h
diff --git a/docs/system/device-emulation.rst b/docs/system/device-emulation.rst
index d1f3277cb0..f19777411c 100644
--- a/docs/system/device-emulation.rst
+++ b/docs/system/device-emulation.rst
@@ -94,6 +94,7 @@ Emulated Devices
devices/virtio-gpu.rst
devices/virtio-pmem.rst
devices/virtio-snd.rst
+ devices/vhost-user-input.rst
devices/vhost-user-rng.rst
devices/canokey.rst
devices/usb-u2f.rst
diff --git a/docs/system/devices/vhost-user-input.rst b/docs/system/devices/vhost-user-input.rst
new file mode 100644
index 0000000000..118eb78101
--- /dev/null
+++ b/docs/system/devices/vhost-user-input.rst
@@ -0,0 +1,45 @@
+.. _vhost_user_input:
+
+QEMU vhost-user-input - Input emulation
+=======================================
+
+This document describes the setup and usage of the Virtio input device.
+The Virtio input device is a paravirtualized device for input events.
+
+Description
+-----------
+
+The vhost-user-input device implementation was designed to work with a daemon
+polling on input devices and passes input events to the guest.
+
+QEMU provides a backend implementation in contrib/vhost-user-input.
+
+Linux kernel support
+--------------------
+
+Virtio input requires a guest Linux kernel built with the
+``CONFIG_VIRTIO_INPUT`` option.
+
+Examples
+--------
+
+The backend daemon should be started first:
+
+::
+
+ host# vhost-user-input --socket-path=input.sock \
+ --evdev-path=/dev/input/event17
+
+The QEMU invocation needs to create a chardev socket to communicate with the
+backend daemon and access the VirtIO queues with the guest over the
+:ref:`shared memory <shared_memory_object>`.
+
+::
+
+ host# qemu-system \
+ -chardev socket,path=/tmp/input.sock,id=mouse0 \
+ -device vhost-user-input-pci,chardev=mouse0 \
+ -m 4096 \
+ -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
+ -numa node,memdev=mem \
+ ...
diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
index c6afc4836f..9b2da106ce 100644
--- a/docs/system/devices/vhost-user.rst
+++ b/docs/system/devices/vhost-user.rst
@@ -42,7 +42,7 @@ platform details for what sort of virtio bus to use.
- See https://github.com/rust-vmm/vhost-device
* - vhost-user-input
- Generic input driver
- - See contrib/vhost-user-input
+ - :ref:`vhost_user_input`
* - vhost-user-rng
- Entropy driver
- :ref:`vhost_user_rng`
@@ -91,6 +91,8 @@ following the :ref:`vhost_user_proto`. There are a number of daemons
that can be built when enabled by the project although any daemon that
meets the specification for a given device can be used.
+.. _shared_memory_object:
+
Shared memory object
====================
--
MST
^ permalink raw reply related [relevance 6%]
* [PATCH] MAINTAINERS: Add Oliver Upton as co-maintainer of KVM/arm64
@ 2023-01-23 21:02 6% ` Oliver Upton
0 siblings, 0 replies; 200+ results
From: Oliver Upton @ 2023-01-23 21:02 UTC (permalink / raw)
To: maz
Cc: linux-kernel, pbonzini, seanjc, kvm, kvmarm, james.morse,
suzuki.poulose, yuzenghui, catalin.marinas, will,
linux-arm-kernel, Oliver Upton
Going forward I intend to help Marc with maintaining KVM/arm64. We've
spoken about this quite a bit and he has been a tremendous help in
ramping up to the task (thank you!). We haven't worked out the exact
details of how the process will work, but the goal is to even out the
maintenance responsibilities to give us both ample time for development.
To that end, updating the maintainers entry to reflect the change.
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 42fc47c6edfd..7323efcc1270 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11355,9 +11355,9 @@ F: virt/kvm/*
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
M: Marc Zyngier <maz@kernel.org>
+M: Oliver Upton <oliver.upton@linux.dev>
R: James Morse <james.morse@arm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
-R: Oliver Upton <oliver.upton@linux.dev>
R: Zenghui Yu <yuzenghui@huawei.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: kvmarm@lists.linux.dev
base-commit: 5dc4c995db9eb45f6373a956eb1f69460e69e6d4
--
2.39.1.405.gd4c25cc71f-goog
^ permalink raw reply related [relevance 6%]
* [RFC PATCH v2 1/2] docs: add a document about regression handling
@ 2022-01-07 14:21 7% ` Thorsten Leemhuis
0 siblings, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2022-01-07 14:21 UTC (permalink / raw)
To: linux-doc, Linus Torvalds
Cc: workflows, Linux Kernel Mailing List, Jonathan Corbet,
Randy Dunlap, Greg Kroah-Hartman, Lukas Bulwahn
Create a document explaining various aspects around regression handling
and tracking both for users and developers. Among others describe the
first rule of Linux kernel development and what it means in practice.
Also explain what a regression actually is and how to report one
properly. The text additionally provides a brief introduction to the bot
the kernel's regression tracker uses to facilitate his work. To sum
things up, provide a few quotes from Linus to show how serious he takes
regressions.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
Documentation/admin-guide/index.rst | 1 +
Documentation/admin-guide/regressions.rst | 886 ++++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 888 insertions(+)
create mode 100644 Documentation/admin-guide/regressions.rst
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 1bedab498104..17157ee5a416 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -36,6 +36,7 @@ problems and bugs in particular.
reporting-issues
security-bugs
+ regressions
bug-hunting
bug-bisect
tainted-kernels
diff --git a/Documentation/admin-guide/regressions.rst b/Documentation/admin-guide/regressions.rst
new file mode 100644
index 000000000000..6eb8d9784a1f
--- /dev/null
+++ b/Documentation/admin-guide/regressions.rst
@@ -0,0 +1,886 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+..
+ If you want to distribute this text under CC-BY-4.0 only, please use 'The
+ Linux kernel developers' for author attribution and link this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/regressions.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
+
+
+Regressions
++++++++++++
+
+The first rule of Linux kernel development: '*We don't cause regressions*'.
+Linux founder and lead developer Linus Torvalds strictly enforces the rule
+himself. This document describes what this means in practice and how the Linux
+kernel's development model ensures all reported regressions are addressed; it
+covers aspects relevant for both users and developers.
+
+The important bits for people affected by regressions
+=====================================================
+
+It's a regression if something running fine with one Linux kernel works worse or
+not at all with a newer version. Note, the newer kernel has to be compiled using
+a similar configuration -- for this and other fine print, check out below
+section "What is a 'regression' and what is the 'no regressions rule'?".
+
+Report your regression as outlined in
+`Documentation/admin-guide/reporting-issues.rst`, it already covers all aspects
+important for regressions. Below section "How do I report a regression?"
+highlights them for convenience.
+
+The most important aspect: CC or forward the report to `the regression mailing
+list <https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev).
+When doing so, consider mentioning the version range where the regression
+started using a paragraph like this::
+
+ #regzbot introduced v5.13..v5.14-rc1
+
+The Linux kernel regression tracking bot 'regzbot' will then add the report to
+the list of tracked regressions. This is in your interest, as it brings the
+report on the radar of people ensuring all regressions are acted upon in a
+timely manner.
+
+The important bits for people fixing regressions
+================================================
+
+When receiving regression reports by mail, check if the reporter CCed `the
+regression mailing list <https://lore.kernel.org/regressions/>`_
+(regressions@lists.linux.dev). If not, forward or bounce the report to the Linux
+kernel's regression tracker (regressions@leemhuis.info), unless you plan on
+sending a reply to the report anyway. In that case simply CC the list in a
+direct reply to the report. Also check, if the report included a 'regzbot
+command' like ``#regzbot introduced v5.13..v5.14-rc1`` (see above); if not,
+please include a paragraph like the following, as the Linux kernel regression
+tracking bot 'regzbot' will then immediately start tracking the regression::
+
+ #regzbot ^introduced v5.13..v5.14-rc1
+
+If the report was filed in a public bug tracker, forward it to the regression
+list; add the aforementioned paragraph, just omit the caret (the ^) before the
+``introduced``, which makes regzbot treat your mail (and not the one you reply
+to) as the report.
+
+When submitting fixes for regressions, always include 'Link:' tags in the commit
+message that point to all places where the issue was reported, as explained in
+`Documentation/process/submitting-patches.rst` and
+:ref:`Documentation/process/5.Posting.rst <development_posting>`. Hence, link to
+any mails in the archive with reports about the issue as well as all bug tracker
+entries::
+
+ Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=215375
+
+This is important for regression tracking, as this allows regzbot to
+automatically associate tracked regression reports with patch postings and
+commits fixing it.
+
+
+All the details on handling Linux kernel regressions
+====================================================
+
+The important basics
+--------------------
+
+What is a 'regression' and what is the 'no regressions rule'?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's a regression if some application or practical use case running fine on one
+Linux kernel works worse or not at all with a newer version compiled using a
+similar configuration. The 'no regressions rule' forbids this to happen. If a
+regression happens by accident, developers that caused it are expected to
+quickly fix the issue.
+
+It thus is a regression when a WiFi driver from Linux 5.13 works fine, but with
+5.14 doesn't work at all, works significantly slower, or misbehaves somehow.
+It's also a regression if a perfectly working application suddenly shows erratic
+behavior with a newer kernel version, which can be caused by changes in procfs,
+sysfs, or one of the many other interfaces Linux provides to userland software.
+But keep in mind, as mentioned earlier: 5.14 in this example needs to be built
+from a configuration similar to the one from 5.13. This can be achieved using
+``make olddefconfig``, as explained in more detail below.
+
+Note the 'practical use case' in the first sentence of this section: developers
+despite the 'no regressions' rule are free to change any aspect of the kernel
+and even APIs or ABIs to userland, as long as no existing application or use
+case breaks.
+
+Also be aware the 'no regressions' rule covers only interfaces the kernel
+provides to the userland. It thus does not apply to kernel-internal interfaces
+like the module API, which some externally developed drivers use to hook into
+the kernel.
+
+What is the goal of the 'no regressions rule'?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Users should feel safe when updating kernel versions and not have to worry
+something might break. This is in the interest of the kernel developers to make
+updating attractive: they don't want users to stay on stable or longterm Linux
+series either abandoned or more than one and a half year old, as `those might
+have known problems, security issues, or other aspects already improved in later
+versions <http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_.
+The kernel developers also want to make it simple and appealing for users to
+test the latest pre-release or regular release, as it's a lot easier to track
+down and fix problems, if they are reported shortly after being introduced.
+
+
+How hard is the rule enforced?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Extraordinarily strict, as can be seen by many mailing list posts from Linux
+creator and lead developer Linus Torvalds, some of which are quoted at the end
+of this document.
+
+Exceptions to this rule are extremely rare; in the past developers almost always
+turned out to be wrong when they assumed a particular situation was warranting
+an exception.
+
+How is the rule enforced?
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's the duty of the subsystem maintainers, which are watched and supported by
+Linus Torvalds for mainline or stable/longterm tree maintainers like Greg
+Kroah-Hartman. All of them are supported by Thorsten Leemhuis: he's acting as
+'regressions tracker' for the Linux kernel and trying to ensure all regression
+reports are acted upon in a timely manner.
+
+The distributed and slightly unstructured nature of the Linux kernel's
+development makes tracking regressions hard. That's why Thorsten relies on the
+help of his Linux kernel regression tracking robot 'regzbot'. It watches mailing
+lists and git trees to semi-automatically associate regression reports to patch
+submissions and commits fixing the issue, as this provides all necessary
+insights into the fixing progress.
+
+Note, the regression tracker can only ensure no regression falls through the
+cracks, if someone tells him or his bot about every regression found. That's why
+the report needs to be sent to the regressions mailing list (ideally with a
+'regzbot command' in the mail), as explained in the next section.
+
+How do I report a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Just report the issue as outlined in
+`Documentation/admin-guide/reporting-issues.rst`, it already describes the
+important points. The following aspects described there are especially relevant
+for regressions:
+
+ * When checking for existing reports to join, first check the `archives of the
+ Linux regressions mailing list <https://lore.kernel.org/regressions/>`_ and
+ `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_.
+
+ * In your report, mention the last kernel version that worked fine and the
+ first broken one. Even better: try to find the commit causing the regression
+ using a bisection.
+
+ * Remember to let the Linux regressions mailing list
+ (regressions@lists.linux.dev) known about your report:
+
+ * If you report the regression by mail, CC the regressions list.
+
+ * If you report your regression to some bug tracker, forward the filed report
+ by mail to the regressions list while CCing the maintainer and the mailing
+ list for the subsystem in question.
+
+Additionally, you in both cases should directly tell the aforementioned Linux
+kernel regression tracking bot about your report. To do that, include a
+paragraph like this in your report to tell the bot when the regression started
+to happen::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+
+In this example, v5.13 was the last version that worked, while v5.14-rc1 was the
+first broken one. The smaller the range, the better, as that makes it easier to
+find out what's wrong and who's responsible. That's why you ideally should
+perform a bisection to find the commit causing the regression (the 'culprit').
+If you did, specify it instead::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+Placing such a 'regzbot command' is in your interest, as it will ensure the
+report won't fall through the cracks unnoticed. If you omit this, the Linux
+kernel's regressions tracker will take care of telling regzbot about your
+regression, as long as you send a copy to the regressions mailing lists. But the
+regression tracker is just one human which sometimes has to rest or occasionally
+might even enjoy some time away from computers (as crazy as that might sound).
+Relying on this person thus will result in an unnecessary delay before the
+regressions becomes mentioned `on the list of tracked and unresolved Linux
+kernel regressions <https://linux-regtracking.leemhuis.info/regzbot/>`_ and the
+weekly regression reports sent by regzbot. Such delays can result in Linus
+Torvalds being unaware of important regressions when deciding between 'continue
+development or call this finished by performing a release?'.
+
+How to add a regression to regzbot's tracking somebody else reported?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Use your mailers 'Reply-all' function to send a reply where you CC the
+regressions list (regressions@lists.linux.dev). In that reply create a new
+paragraph with a regzbot command like this::
+
+ #regzbot ^introduced: v5.13..v5.14-rc1
+
+The caret (^) before the 'introduced' makes regzbot treat the parent mail (the
+one you reply to) as the report for the regression you want to see tracked.
+Instead of a version range you can also specify the commit causing the
+regression, as outlined in the previous section.
+
+If the report came in private from a bug tracker, forward it to the list;
+include the aforementioned line, just omit the caret (the ^) before the
+'introduced'; consider adding a line with the line '#regzbot link: <url>' (see
+below) pointing to the place with the initial report.
+
+Alternatively to all the above you can just forward or bounce the report to the
+Linux kernel's regression tracker, but consider the downsides already outlined
+in the previous section.
+
+Are really all regressions fixed?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Nearly all of them are, as long as the change causing the regression (the
+'culprit commit') is reliably identified. Some regressions can be fixed without
+this, but often it's required.
+
+Who needs to find the commit causing a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's the reporter's duty to find the culprit, but developers of the affected
+subsystem should offer advice and reasonably help where they can.
+
+How can I find the change causing a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Perform a bisection, as roughly outlined in `Documentation/admin-guide/reporting-issues.rst`
+and described in more detail by `Documentation/admin-guide/bug-bisect.rst`.
+It might sound like a lot of work, but in many cases finds the culprit
+relatively quickly. If it's hard or time-consuming to reliably reproduce the
+issue, consider teaming up with others affected by the problem to narrow down
+the search range together.
+
+Who can I ask for advice when it comes to regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
+CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the
+issue might better be dealt with in private, feel free to omit the list.
+
+
+More details about regressions relevant for reporters
+-----------------------------------------------------
+
+Does a regression need to be fixed, if it can be avoided by updating some other software?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Almost always: yes. If a developer tells you otherwise, ask the regression
+tracker for advice as outlined above.
+
+Does it qualify as a regression if a newer kernel works slower or makes the system consume more energy?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but the difference has to be significant. A five percent slow-down in a
+micro-benchmark thus is unlikely to qualify as regression, unless it also
+influences the results of a broad benchmark by more than one percent. If in
+doubt, ask for advice.
+
+Is it a regression, if an externally developed kernel module is incompatible with a newer kernel?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+No, as the 'no regression' rule is about interfaces and services the Linux
+kernel provides to the userland. It thus does not cover building or running
+externally developed kernel modules, as they run in kernel-space and use
+occasionally changed internal interfaces to hook into the kernel.
+
+How are regressions handled that are caused by a fix for security vulnerability?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In extremely rare situations security issues can't be fixed without causing
+regressions; those are given way, as they are the lesser evil in the end.
+Luckily this almost always can be avoided, as key developers for the affected
+area and often Linus Torvalds himself try very hard to fix security issues
+without causing regressions.
+
+If you nevertheless face such a case, check the mailing list archives if people
+tried their best to avoid the regression; if in doubt, ask for advice as
+outlined above.
+
+What happens if fixing a regression is impossible without causing another regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sadly these things happen, but luckily not very often; if they occur, expert
+developers of the affected code area should look into the issue to find a fix
+that avoids regressions or at least their impact. If you run into such a
+situation you thus do what was outlined already for regressions caused by
+security fixes: check earlier discussions if people already tried their best and
+ask for advice if in doubt.
+
+A quick note while at it: these situations could be avoided, if you would
+regularly give mainline pre-releases (say v5.15-rc1 or -rc3) from each cycle a
+test run. This is best explained by imagining a change integrated between Linux
+v5.14 and v5.15-rc1 which causes a regression, but at the same time is a hard
+requirement for some other improvement applied for 5.15-rc1. All these changes
+often can simply be reverted and the regression thus solved, if someone finds
+and reports it before 5.15 is released. A few days or weeks later after the
+release this solution might become impossible, if some software starts to rely
+on aspects introduced by one of the follow-up changes: reverting all changes
+would cause regressions for users of said software and thus out of the question.
+
+A feature I relied on was removed months ago, but I only noticed now. Does that qualify as regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but often it's hard to fix them due to the aspects outlined in the
+previous section. It hence needs to be dealt with on a case-by-case basis; this
+is another reason why it's in your interest to regularly test mainline releases.
+
+Does the 'no regression' rule apply if I seem to be the only person in the world that is affected by a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but only for practical usage: the Linux developers want to be free to
+remove support for hardware only to be found in attics and museums anymore.
+
+Note, sometimes regressions can't be avoided to make progress -- and the latter
+is needed to prevent Linux from stagnation. Hence, if only very few users seem
+to be affected by a regression, it for the greater good might be in their and
+everyone else's interest to not insist on the rule. Especially if there is an
+easy way to circumvent the regression somehow, for example by updating some
+software or using a kernel parameter created just for this purpose.
+
+Does the regression rule apply for code in the staging tree as well?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Not according to the `help text for the configuration option covering all
+staging code <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_,
+which since its early days states::
+
+ Please note that these drivers are under heavy development, may or
+ may not work, and may contain userspace interfaces that most likely
+ will be changed in the near future.
+
+The staging developers nevertheless often adhere to the 'no regressions' rule,
+but sometimes bend it to make progress. That's for example why some users had to
+deal with (often negligible) regressions when a WiFi driver from the staging
+tree was replaced by a totally different one written from scratch.
+
+Why do later versions have to be 'compiled with a similar configuration'?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Because the Linux kernel developers sometimes integrate changes known to cause
+regressions, but make them optional and disable them in the kernel's default
+configuration. This trick allows progress, as the 'no regressions' rule
+otherwise would lead to stagnation. Consider for example a new security feature
+which blocks access to some kernel interfaces often abused by malware, but at
+the same time are required to run a few rarely used applications. The outlined
+trick makes both camps happy: people using these applications can leave the new
+security feature off, while everyone else can enable it without running into
+trouble.
+
+How to create a configuration similar to the one of an older kernel?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Start a known-good kernel and configure the newer Linux version with ``make
+olddefconfig``. This makes the kernel's build scripts pick up the configuration
+file (the `.config` file) from the running kernel as base for the new one you
+are about to compile; afterwards they set all new configuration options to their
+default value, which disables new features that might cause regressions.
+
+Can I report a regression with vanilla kernels provided by someone else to the upstream Linux kernel developers?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Only if the newer kernel was compiled with a similar configuration file as the
+older one (see above), as your provider might have enabled some known-to-be
+incompatible feature in the newer kernel. If in a doubt, report this problem to
+the provider and ask for advice.
+
+
+More details about regressions relevant for developers
+------------------------------------------------------
+
+What should I do, if I suspect a change I'm working on might cause regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Evaluate how big the risk of regressions is, for example by performing a code
+search in Linux distributions and Git forges. Also consider asking other
+developers or projects likely to be affected to evaluate or even test the
+proposed change; if problems surface, maybe some middle ground acceptable for
+all can be found.
+
+If the risk of regressions in the end seems to be relatively small, go ahead
+with the change, but let all involved parties know about the risk. Hence, make
+sure your patch description makes this aspect obvious. Once the change is
+merged, tell the Linux kernel's regression tracker and the regressions mailing
+list about the risk, so everyone has the change on the radar in case reports
+trickle in. Depending on the risk, you also might want to ask the subsystem
+maintainer to mention the issue in his mainline pull request.
+
+
+Everything developers need to know about regression tracking
+------------------------------------------------------------
+
+Do I have to use regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's in the interest of everyone if you do, as kernel maintainers like Linus
+Torvalds partly rely on regzbot's tracking in their work -- for example when
+deciding to release a new version or extend the development phase. For this they
+need to be aware of all unfixed regression; to do that, Linus is known to look
+into the weekly reports sent by regzbot.
+
+Do I have to tell regzbot about every regression I stumble upon?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ideally yes: we are all humans and easily forget problems when something more
+important unexpectedly comes up -- for example a bigger problem in the Linux
+kernel or something in real life that's keeping us away from keyboards for a
+while. Hence, it's best to tell regzbot about every regression, except when you
+immediately write a fix and commit it to a tree regularly merged to the affected
+kernel series.
+
+Why does the Linux kernel need a regression tracker, and why does he utilize regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Rules like 'no regressions' need someone to enforce them, otherwise they are
+broken either accidentally or on purpose. History has shown that this is true
+for the Linux kernel as well. That's why Thorsten volunteered to keep an eye on
+things.
+
+Tracking regressions completely manually has proven to be exhausting and
+demotivating, which is why earlier attempts to establish it failed after a
+while. To prevent this from happening again, Thorsten developed Regzbot to
+facilitate the work, with the long term goal to automate regression tracking as
+much as possible for everyone involved.
+
+How does regression tracking work with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bot keeps track of all the reports and monitors their fixing progress. It
+tries to do that with as little overhead as possible for both reporters and
+developers.
+
+In fact, only reporters or someone helping them are burdened with an extra duty:
+they need to tell regzbot about the regression report using one of the
+``#regzbot introduced`` commands outlined above.
+
+For developers there normally is no extra work involved, they just need to do
+something that's expected from them already: add 'Link:' tags to the patch
+description pointing to all reports about the issue fixed.
+
+Thanks to these tags regzbot can associate regression reports with patches to
+fix the issue, whenever they are posted for review or applied to a git tree. The
+bot additionally watches out for replies to the report. All this data combined
+provides a good impression about the current status of the fixing process.
+
+How to see which regressions regzbot tracks currently?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_
+for the latest info; alternatively, `search for the latest regression report
+<https://lore.kernel.org/lkml/?q=%22Linux+regressions+report%22+f%3Aregzbot>`_,
+which regzbot normally sends out once a week on Sunday evening (UTC), which is a
+few hours before Linus usually publishes new (pre-)releases.
+
+What places is regzbot monitoring?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Regzbot is watching the most important Linux mailing lists as well as the
+linux-next, mainline and stable/longterm git repositories.
+
+How to interact with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Everyone can interact with the bot using mails containing `regzbot commands`,
+which need to be in their own paragraph (IOW: they need to be separated from the
+rest of the mail using blank lines). One such command is ``#regzbot introduced
+<version or commit>``, which adds a report to the tracking, as already described
+above; ``#regzbot ^introduced <version or commit>`` is another such command,
+which makes regzbot consider the parent mail as a report for a regression which
+it starts to track.
+
+Once one of those two commands has been utilized, other regzbot commands can be
+used. You can write them below one of the `introduced` commands or in replies to
+the mail that used one of them or itself is a reply to that mail:
+
+ * Set or update the title::
+
+ #regzbot title: foo
+
+ * Link to a related discussion (for example the posting of a patch to fix the
+ issue) and monitor it::
+
+ #regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ Monitoring only works for lore.kernel.org; regzbot will consider all messages
+ in that thread as related to the fixing process.
+
+ * Point to a place with further details, like a bug tracker or a related
+ mailing list post::
+
+ #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * Mark a regression as fixed by a commit that is heading upstream or already
+ landed::
+
+ #regzbot fixed-by: 1f2e3d4c5d
+
+ * Mark a regression as a duplicate of another one already tracked by regzbot::
+
+ #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ * Mark a regression as invalid::
+
+ #regzbot invalid: wasn't a regression, problem has always existed
+
+Is there more to tell about regzbot and its commands?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+More detailed and up-to-date information about the Linux kernels regression
+tracking bot can be found on its `project page <https://gitlab.com/knurd42/regzbot>`_,
+which among others contains a `getting started guide <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
+and `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
+which both are more in-depth.
+
+
+Quotes from Linus about regression
+----------------------------------
+
+Find below a few real life examples of how Linus Torvalds expects regressions to
+be handled:
+
+ * From `2017-10-26 (1/2)
+ <https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_::
+
+ If you break existing user space setups THAT IS A REGRESSION.
+
+ It's not ok to say "but we'll fix the user space setup".
+
+ Really. NOT OK.
+
+ [...]
+
+ The first rule is:
+
+ - we don't cause regressions
+
+ and the corollary is that when regressions *do* occur, we admit to
+ them and fix them, instead of blaming user space.
+
+ The fact that you have apparently been denying the regression now for
+ three weeks means that I will revert, and I will stop pulling apparmor
+ requests until the people involved understand how kernel development
+ is done.
+
+ * From `2017-10-26 (2/2)
+ <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_::
+
+ People should basically always feel like they can update their kernel
+ and simply not have to worry about it.
+
+ I refuse to introduce "you can only update the kernel if you also
+ update that other program" kind of limitations. If the kernel used to
+ work for you, the rule is that it continues to work for you.
+
+ There have been exceptions, but they are few and far between, and they
+ generally have some major and fundamental reasons for having happened,
+ that were basically entirely unavoidable, and people _tried_hard_ to
+ avoid them. Maybe we can't practically support the hardware any more
+ after it is decades old and nobody uses it with modern kernels any
+ more. Maybe there's a serious security issue with how we did things,
+ and people actually depended on that fundamentally broken model. Maybe
+ there was some fundamental other breakage that just _had_ to have a
+ flag day for very core and fundamental reasons.
+
+ And notice that this is very much about *breaking* peoples environments.
+
+ Behavioral changes happen, and maybe we don't even support some
+ feature any more. There's a number of fields in /proc/<pid>/stat that
+ are printed out as zeroes, simply because they don't even *exist* in
+ the kernel any more, or because showing them was a mistake (typically
+ an information leak). But the numbers got replaced by zeroes, so that
+ the code that used to parse the fields still works. The user might not
+ see everything they used to see, and so behavior is clearly different,
+ but things still _work_, even if they might no longer show sensitive
+ (or no longer relevant) information.
+
+ But if something actually breaks, then the change must get fixed or
+ reverted. And it gets fixed in the *kernel*. Not by saying "well, fix
+ your user space then". It was a kernel change that exposed the
+ problem, it needs to be the kernel that corrects for it, because we
+ have a "upgrade in place" model. We don't have a "upgrade with new
+ user space".
+
+ And I seriously will refuse to take code from people who do not
+ understand and honor this very simple rule.
+
+ This rule is also not going to change.
+
+ And yes, I realize that the kernel is "special" in this respect. I'm
+ proud of it.
+
+ I have seen, and can point to, lots of projects that go "We need to
+ break that use case in order to make progress" or "you relied on
+ undocumented behavior, it sucks to be you" or "there's a better way to
+ do what you want to do, and you have to change to that new better
+ way", and I simply don't think that's acceptable outside of very early
+ alpha releases that have experimental users that know what they signed
+ up for. The kernel hasn't been in that situation for the last two
+ decades.
+
+ We do API breakage _inside_ the kernel all the time. We will fix
+ internal problems by saying "you now need to do XYZ", but then it's
+ about internal kernel API's, and the people who do that then also
+ obviously have to fix up all the in-kernel users of that API. Nobody
+ can say "I now broke the API you used, and now _you_ need to fix it
+ up". Whoever broke something gets to fix it too.
+
+ And we simply do not break user space.
+
+ * From `2020-05-21
+ <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_::
+
+ The rules about regressions have never been about any kind of
+ documented behavior, or where the code lives.
+
+ The rules about regressions are always about "breaks user workflow".
+
+ Users are literally the _only_ thing that matters.
+
+ No amount of "you shouldn't have used this" or "that behavior was
+ undefined, it's your own fault your app broke" or "that used to work
+ simply because of a kernel bug" is at all relevant.
+
+ Now, reality is never entirely black-and-white. So we've had things
+ like "serious security issue" etc that just forces us to make changes
+ that may break user space. But even then the rule is that we don't
+ really have other options that would allow things to continue.
+
+ And obviously, if users take years to even notice that something
+ broke, or if we have sane ways to work around the breakage that
+ doesn't make for too much trouble for users (ie "ok, there are a
+ handful of users, and they can use a kernel command line to work
+ around it" kind of things) we've also been a bit less strict.
+
+ But no, "that was documented to be broken" (whether it's because the
+ code was in staging or because the man-page said something else) is
+ irrelevant. If staging code is so useful that people end up using it,
+ that means that it's basically regular kernel code with a flag saying
+ "please clean this up".
+
+ The other side of the coin is that people who talk about "API
+ stability" are entirely wrong. API's don't matter either. You can make
+ any changes to an API you like - as long as nobody notices.
+
+ Again, the regression rule is not about documentation, not about
+ API's, and not about the phase of the moon.
+
+ It's entirely about "we caused problems for user space that used to work".
+
+ * From `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_::
+
+ > Now this got me wondering if Debian _unstable_ actually qualifies as a
+ > standard distro userspace.
+
+ Oh, if the kernel breaks some standard user space, that counts. Tons
+ of people run Debian unstable (and from my limited interactions with
+ it, for damn good reasons: -stable tends to run so old versions of
+ everything that you have to sometimes deal with cuneiform writing when
+ using it)
+
+ * From `2017-11-05
+ <https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_::
+
+ And our regression rule has never been "behavior doesn't change".
+ That would mean that we could never make any changes at all.
+
+ For example, we do things like add new error handling etc all the
+ time, which we then sometimes even add tests for in our kselftest
+ directory.
+
+ So clearly behavior changes all the time and we don't consider that a
+ regression per se.
+
+ The rule for a regression for the kernel is that some real user
+ workflow breaks. Not some test. Not a "look, I used to be able to do
+ X, now I can't".
+
+ * From `2018-08-03
+ <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_::
+
+ YOU ARE MISSING THE #1 KERNEL RULE.
+
+ We do not regress, and we do not regress exactly because your are 100% wrong.
+
+ And the reason you state for your opinion is in fact exactly *WHY* you
+ are wrong.
+
+ Your "good reasons" are pure and utter garbage.
+
+ The whole point of "we do not regress" is so that people can upgrade
+ the kernel and never have to worry about it.
+
+ > Kernel had a bug which has been fixed
+
+ That is *ENTIRELY* immaterial.
+
+ Guys, whether something was buggy or not DOES NOT MATTER.
+
+ Why?
+
+ Bugs happen. That's a fact of life. Arguing that "we had to break
+ something because we were fixing a bug" is completely insane. We fix
+ tens of bugs every single day, thinking that "fixing a bug" means that
+ we can break something is simply NOT TRUE.
+
+ So bugs simply aren't even relevant to the discussion. They happen,
+ they get found, they get fixed, and it has nothing to do with "we
+ break users".
+
+ Because the only thing that matters IS THE USER.
+
+ How hard is that to understand?
+
+ Anybody who uses "but it was buggy" as an argument is entirely missing
+ the point. As far as the USER was concerned, it wasn't buggy - it
+ worked for him/her.
+
+ Maybe it worked *because* the user had taken the bug into account,
+ maybe it worked because the user didn't notice - again, it doesn't
+ matter. It worked for the user.
+
+ Breaking a user workflow for a "bug" is absolutely the WORST reason
+ for breakage you can imagine.
+
+ It's basically saying "I took something that worked, and I broke it,
+ but now it's better". Do you not see how f*cking insane that statement
+ is?
+
+ And without users, your program is not a program, it's a pointless
+ piece of code that you might as well throw away.
+
+ Seriously. This is *why* the #1 rule for kernel development is "we
+ don't break users". Because "I fixed a bug" is absolutely NOT AN
+ ARGUMENT if that bug fix broke a user setup. You actually introduced a
+ MUCH BIGGER bug by "fixing" something that the user clearly didn't
+ even care about.
+
+ And dammit, we upgrade the kernel ALL THE TIME without upgrading any
+ other programs at all. It is absolutely required, because flag-days
+ and dependencies are horribly bad.
+
+ And it is also required simply because I as a kernel developer do not
+ upgrade random other tools that I don't even care about as I develop
+ the kernel, and I want any of my users to feel safe doing the same
+ time.
+
+ So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel
+ without upgrading some other random binary, then we have a problem.
+
+ * From `2021-06-05
+ <https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_::
+
+ THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS.
+
+ Honestly, security people need to understand that "not working" is not
+ a success case of security. It's a failure case.
+
+ Yes, "not working" may be secure. But security in that case is *pointless*.
+
+ * From `2021-07-30
+ <https://lore.kernel.org/lkml/CAHk-=witY33b-vqqp=ApqyoFDpx9p+n4PwG9N-TvF8bq7-tsHw@mail.gmail.com/>`_::
+
+ But we have the policy that regressions aren't about documentation or
+ even sane behavior.
+
+ Regressions are about whether a user application broke in a noticeable way.
+
+ * From `2011-05-06 (1/3)
+ <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_::
+
+ Binary compatibility is more important.
+
+ And if binaries don't use the interface to parse the format (or just
+ parse it wrongly - see the fairly recent example of adding uuid's to
+ /proc/self/mountinfo), then it's a regression.
+
+ And regressions get reverted, unless there are security issues or
+ similar that makes us go "Oh Gods, we really have to break things".
+
+ I don't understand why this simple logic is so hard for some kernel
+ developers to understand. Reality matters. Your personal wishes matter
+ NOT AT ALL.
+
+ If you made an interface that can be used without parsing the
+ interface description, then we're stuck with the interface. Theory
+ simply doesn't matter.
+
+ You could help fix the tools, and try to avoid the compatibility
+ issues that way. There aren't that many of them.
+
+ * From `2011-05-06 (2/3)
+ <https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_::
+
+ it's clearly NOT an internal tracepoint. By definition. It's being
+ used by powertop.
+
+ * From `2011-05-06 (3/3)
+ <https://lore.kernel.org/all/BANLkTinazaXRdGovYL7rRVp+j6HbJ7pzhg@mail.gmail.com/>`_::
+
+ We have programs that use that ABI and thus it's a regression if they break.
+
+ * From `2006-02-21
+ <https://lore.kernel.org/lkml/Pine.LNX.4.64.0602211631310.30245@g5.osdl.org/>`_::
+
+ The fact is, if changing the kernel breaks user-space, it's a regression.
+ IT DOES NOT MATTER WHETHER IT'S IN /sbin/hotplug OR ANYTHING ELSE. If it
+ was installed by a distribution, it's user-space. If it got installed by
+ "vmlinux", it's the kernel.
+
+ The only piece of user-space code we ship with the kernel is the system
+ call trampoline etc that the kernel sets up. THOSE interfaces we can
+ really change, because it changes with the kernel.
+
+ * From `2019-09-15
+ <https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_::
+
+ One _particularly_ last-minute revert is the top-most commit (ignoring
+ the version change itself) done just before the release, and while
+ it's very annoying, it's perhaps also instructive.
+
+ What's instructive about it is that I reverted a commit that wasn't
+ actually buggy. In fact, it was doing exactly what it set out to do,
+ and did it very well. In fact it did it _so_ well that the much
+ improved IO patterns it caused then ended up revealing a user-visible
+ regression due to a real bug in a completely unrelated area.
+
+ The actual details of that regression are not the reason I point that
+ revert out as instructive, though. It's more that it's an instructive
+ example of what counts as a regression, and what the whole "no
+ regressions" kernel rule means. The reverted commit didn't change any
+ API's, and it didn't introduce any new bugs. But it ended up exposing
+ another problem, and as such caused a kernel upgrade to fail for a
+ user. So it got reverted.
+
+ The point here being that we revert based on user-reported _behavior_,
+ not based on some "it changes the ABI" or "it caused a bug" concept.
+ The problem was really pre-existing, and it just didn't happen to
+ trigger before. The better IO patterns introduced by the change just
+ happened to expose an old bug, and people had grown to depend on the
+ previously benign behavior of that old issue.
+
+ And never fear, we'll re-introduce the fix that improved on the IO
+ patterns once we've decided just how to handle the fact that we had a
+ bad interaction with an interface that people had then just happened
+ to rely on incidental behavior for before. It's just that we'll have
+ to hash through how to do that (there are no less than three different
+ patches by three different developers being discussed, and there might
+ be more coming...). In the meantime, I reverted the thing that exposed
+ the problem to users for this release, even if I hope it will be
+ re-introduced (perhaps even backported as a stable patch) once we have
+ consensus about the issue it exposed.
+
+ Take-away from the whole thing: it's not about whether you change the
+ kernel-userspace ABI, or fix a bug, or about whether the old code
+ "should never have worked in the first place". It's about whether
+ something breaks existing users' workflow.
+
+ Anyway, that was my little aside on the whole regression thing. Since
+ it's that "first rule of kernel programming", I felt it is perhaps
+ worth just bringing it up every once in a while.
diff --git a/MAINTAINERS b/MAINTAINERS
index 27a83bb940d4..1b740c922867 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10351,6 +10351,7 @@ KERNEL REGRESSIONS
M: Thorsten Leemhuis <linux@leemhuis.info>
L: regressions@lists.linux.dev
S: Supported
+F: Documentation/admin-guide/regressions.rst
KERNEL SELFTEST FRAMEWORK
M: Shuah Khan <shuah@kernel.org>
--
2.31.1
^ permalink raw reply related [relevance 7%]
* [PATCH 02/10] Docs/mm/damon/maintainer-profile: fix typos and grammar errors
@ 2023-05-25 21:43 7% ` SeongJae Park
0 siblings, 0 replies; 200+ results
From: SeongJae Park @ 2023-05-25 21:43 UTC (permalink / raw)
To: Andrew Morton
Cc: SeongJae Park, Jonathan Corbet, damon, linux-mm, linux-doc,
linux-kernel
Fix a few typos and grammar erros in DAMON Maintainer Profile document.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/mm/damon/maintainer-profile.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst
index 24a202f03de8..a84c14e59053 100644
--- a/Documentation/mm/damon/maintainer-profile.rst
+++ b/Documentation/mm/damon/maintainer-profile.rst
@@ -3,7 +3,7 @@
DAMON Maintainer Entry Profile
==============================
-The DAMON subsystem covers the files that listed in 'DATA ACCESS MONITOR'
+The DAMON subsystem covers the files that are listed in 'DATA ACCESS MONITOR'
section of 'MAINTAINERS' file.
The mailing lists for the subsystem are damon@lists.linux.dev and
@@ -15,7 +15,7 @@ SCM Trees
There are multiple Linux trees for DAMON development. Patches under
development or testing are queued in damon/next [2]_ by the DAMON maintainer.
-Suffieicntly reviewed patches will be queued in mm-unstable [1]_ by the memory
+Sufficiently reviewed patches will be queued in mm-unstable [1]_ by the memory
management subsystem maintainer. After more sufficient tests, the patches will
be queued in mm-stable [3]_ , and finally pull-requested to the mainline by the
memory management subsystem maintainer.
--
2.25.1
^ permalink raw reply related [relevance 7%]
* [PATCH] docs/zh_CN: Add a new translation of reporting-regressions.rst
@ 2022-06-25 2:10 7% Wu XiangCheng
2022-07-07 14:30 7% ` [PATCH v2] " Wu XiangCheng
0 siblings, 1 reply; 200+ results
From: Wu XiangCheng @ 2022-06-25 2:10 UTC (permalink / raw)
To: Alex Shi, Yanteng Si
Cc: Jonathan Corbet, xu xin, Yang Yang, Junhua Huang, Tang Yizhou,
Binbin Zhou, linux-doc
Last English version used:
commit d2b40ba2cce2 ("docs: *-regressions.rst: explain how quickly
issues should be handled")
Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
---
.../translations/zh_CN/admin-guide/index.rst | 2 +-
.../admin-guide/reporting-regressions.rst | 373 ++++++++++++++++++
2 files changed, 374 insertions(+), 1 deletion(-)
create mode 100644 Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst
index be535ffaf4b0..2f6970d0a032 100644
--- a/Documentation/translations/zh_CN/admin-guide/index.rst
+++ b/Documentation/translations/zh_CN/admin-guide/index.rst
@@ -36,6 +36,7 @@ Todolist:
:maxdepth: 1
reporting-issues
+ reporting-regressions
security-bugs
bug-hunting
bug-bisect
@@ -44,7 +45,6 @@ Todolist:
Todolist:
-* reporting-bugs
* ramoops
* dynamic-debug-howto
* kdump/index
diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst b/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
new file mode 100644
index 000000000000..9bf24ec6327d
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
@@ -0,0 +1,373 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+.. [see the bottom of this file for redistribution information]
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/admin-guide/reporting-regressions.rst
+
+:译者:
+
+ 吴想成 Wu XiangCheng <bobwxc@email.cn>
+
+
+============
+报告回归问题
+============
+
+“*我们拒绝出现回归*”是Linux内核开发的首要规则；Linux的发起者和领军开发者Linus
+Torvalds立下了此规则并确保它被落实。
+
+本文档描述了这条规则对用户的意义，以及Linux内核开发模型如何确保解决所有被报告
+的回归；关于内核开发者如何处理的方面参见 Documentation/process/handling-regressions.rst 。
+
+
+本文重点（亦即“太长不看”）
+==========================
+
+#. 如果某程序在原先的Linux内核上运行良好，但在较新版本上效果更差、或者根本不
+ 能用，那么你就碰见回归问题了。注意，新内核需要使用类似配置编译；更多相关细
+ 节参见下方。
+
+#. 按照 Documentation/admin-guide/reporting-issues.rst 中所说的报告你的问题，
+ 该文档已经包含了所有关于回归的重要方面，为了方便起见也复制到了下面。两个
+ 重点：在报告主题中使用“[REGRESSION]”开头并抄送或转发到 `回归邮件列表
+ <https://lore.kernel.org/regressions/>`_ （regressions@lists.linux.dev）。
+
+#. 可选但是建议：在发送或转发报告时，指明该回归发生的起点，以便Linux内核回归
+ 追踪机器人“regzbot”可以追踪此问题::
+
+ #regzbot introduced v5.13..v5.14-rc1
+
+
+有关用户的所有Linux内核回归细节
+===============================
+
+
+基本重点
+--------
+
+
+什么是“回归”以及为什么“拒绝出现回归”？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+如果某程序/实例在原先的Linux内核上运行良好，但在较新版本上效果更差、或者根本
+不能用，那么你就碰见回归问题了。“拒绝回归规则”不允许出现这种情况。如果偶然发
+生了，导致问题的开发者应当迅速修复问题。
+
+也就是说，若Linux 5.13中的WiFi驱动程序运行良好，但是在5.14版本上却不能用、速
+度明显变慢或出现错误，那就出现了回归。如果某正常工作的应用程序突然在新内核上
+出现不稳定，这也是回归；这些问题可能是由于procfs、sysfs或Linux提供给用户空间
+软件的许多其他接口之一的变化。但请记住，前述例子中的5.14需要使用类似于5.13的
+配置构建。这可以用 ``make olddefconfig`` 实现，详细解释见下。
+
+注意本节第一句话中的“实例”：即使开发者需要遵循“拒绝回归”规则，但仍可自由地改
+变内核的任何方面，甚至是导出到用户空间的API或ABI，只要别破坏现有的应用程序或
+用例。
+
+还需注意，“拒绝回归”规则只限制内核提供给用户空间的接口。它不适用于内核内部接
+口，比如一些外部开发的驱动程序用来插入钩子到内核的模块API。
+
+如何报告回归？
+~~~~~~~~~~~~~~
+
+只需按照 Documentation/admin-guide/reporting-issues.rst 中所说的报告你的问题，
+该文档已经包含了要点。下面几点概述了一下只在回归中重要的方面：
+
+ * 在检查可加入讨论的现有报告时，别忘了搜索 `Linux回归邮件列表
+ <https://lore.kernel.org/regressions/>`_ 和 `regzbot网页界面
+ <https://linux-regtracking.leemhuis.info/regzbot/>`_ 。
+
+ * 在报告主题的开头加上“[REGRESSION]”。
+
+ * 在你的报告中明确最后一个正常工作的内核版本和首个出问题的版本。如若可能，
+ 用二分法尝试找出导致回归的变更，更多细节见下。
+
+ * 记得把报告发到Linux回归邮件列表（regressions@lists.linux.dev）。
+
+ * 如果通过邮件报告回归，请抄送回归列表。
+
+ * 如果你使用某些缺陷追踪器报告回归，请通过邮件转发已提交的报告到回归列表，
+ 并抄送维护者以及出问题的相关子系统的邮件列表。
+
+ 如果是稳定版或长期支持版系列（如v5.15.3…v5.15.5）的回归，请记得抄送
+ `Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ （stable@vger.kernel.org）。
+
+ 如果你成功地执行了二分，请抄送肇事提交的信息中所有签了“Signed-off-by:”的人。
+
+在抄送你的报告到列表时，也请记得通知前述的Linux内核回归追踪机器人。只需在邮件
+中包含如下片段::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+
+Regzbot会就将你的邮件视为在某个特定版本区间的回归报告。上例中即linux v5.13仍
+然正常，而Linux 5.14-rc1是首个您遇到问题的版本。如果你执行了二分以查找导致回
+归的提交，请使用指定肇事提交的id代替::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+添加这样的“regzbot命令”对你是有好处的，它会确保报告不会被忽略。如果你省略了
+它，Linux内核的回归跟踪者会把你的回归告诉regzbot，只要你发送了一个副本到回归
+邮件列表。但是回归跟踪者只有一个人，有时不得不休息或甚至偶尔享受可以远离电脑
+的时光（听起来很疯狂）。因此，依赖此人手动将回归添加到 `已追踪且尚未解决的
+Linux内核回归列表 <https://linux-regtracking.leemhuis.info/regzbot/>`_ 和
+regzbot发送的每周回归报告，可能会出现延迟。 这样的延误会导致Linus Torvalds
+在决定“继续开发还是发布新版本？”时忽略严重的回归。
+
+真的修复了所有的回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+几乎所有都是，只要引起问题的变更（肇事提交）被可靠定位。也有些回归可以不用这
+样，但通常是必须的。
+
+谁需要找出回归的根本原因？
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+受影响代码区域的开发者应该自行尝试定位问题所在。但仅靠他们的努力往往是不可
+能做到的，很多问题只发生在开发者的无法接触的其他特定外部环境中——例如特定的
+硬件平台、固件、Linux发行版、系统的配置或应用程序。这就是为什么最终往往是报
+告者定位肇事提交；有时用户甚至需要再运行额外测试以查明确切的根本原因。开发
+者应该提供建议和可能的帮助，以使普通用户更容易完成该流程。
+
+如何找到罪魁祸首？
+~~~~~~~~~~~~~~~~~~
+
+如 Documentation/admin-guide/reporting-issues.rst （简要）和
+Documentation/admin-guide/bug-bisect.rst （详细）中所述，执行二分。听起来工
+作量很大，但大部分情况下很快就能找到罪魁祸首。如果这很困难或可靠地重现问题很
+耗时，请考虑与其他受影响的用户合作，一起缩小搜索范围。
+
+当出现回归时我可以向谁寻求建议？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+发送邮件到回归邮件列表（regressions@lists.linux.dev）同时抄送Linux内核的回归
+跟踪者（regressions@leemhuis.info）;如果问题需要保密处理，可以省略列表。
+
+
+关于回归的更多细节
+------------------
+
+
+“无回归规则”的目标是什么？
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+用户应该放心升级内核版本，而不必担心有程序可能崩溃。这符合内核开发者的利益，
+可以使更新有吸引力：他们不希望用户停留在停止维护或超过一年半的稳定/长期Linux
+版本系列上。这也符合所有人的利益，因为 `那些系列可能含有已知的缺陷、安全问题
+或其他后续版本已经修复的问题
+<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_ 。
+此外，内核开发者希望使用户测试最新的预发行版或常规发行版变得简单而有吸引力。
+这同样符合所有人的利益，如果新版本出来后很快就有相关报告，会使追踪和修复问题
+更容易。
+
+实际中“无回归”规则真的可行吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+这不是句玩笑话，请见Linux创建者和主要开发人员Linus Torvalds在邮件列表中的许
+多发言，其中一些在 Documentation/process/handling-regressions.rst 中被引用。
+
+此规则的例外情况极为罕见；之前当开发者认为某个特定的情况有必要援引例外时，
+基本都被证明错了。
+
+谁来确保“无回归”被落实？
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+照看和支撑树的子系统维护者应该关心这一点——例如，Linus Torvalds之于主线，
+Greg Kroah-Hartman等人之于各种稳定/长期系列。
+
+他们都得到了别人的帮助，以确保回归报告不会被遗漏。其中之一是Thorsten
+Leemhuis，他目前担任Linux内核的“回归跟踪者”；为了做好这项工作，他使用了
+regzbot——Linux内核回归跟踪机器人。所以这就是为什么要抄送或转发你的报告到
+回归邮件列表来通知这些人，已经最好在你的邮件中包含“regzbot命令”来立即追踪它。
+
+回归通常多久能修复？
+~~~~~~~~~~~~~~~~~~~~
+
+开发者应该尽快修复任何被报告的回归，以提供及时为受影响的用户提供解决方案，并
+防止更多用户遇到问题；然而，开发人员需要花足够的时间和注意力确保回归修复不会
+造成额外的损害。
+
+因此，答案取决于各种因素，如回归的影响、存在时长或出现于哪个Linux版本系列。
+但最终，大多数的回归应该在两周内修复。
+
+当问题可以通过升级某些软件解决时，是回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+基本都是。如果开发人员告诉您其他情况，请咨询上述回归跟踪者。
+
+当新内核变慢或能耗增加，是回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+是的，但有一些差别。在微型基准测试中变慢5%不太可能被视为回归，除非它也会对
+广泛基准测试的结果产生超过1%的影响。如果有疑问，请寻求建议。
+
+当更新Linux时外部内核模块崩溃了，是回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+不，因为“无回归”规则仅限于Linux内核提供给用户空间的接口和服务。因此，它不包括
+构建或运行外部开发的内核模块，因为它们在内核空间中运行与挂进内核使用的内部接
+口偶尔会变化。
+
+如何处理安全修复引起的回归？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+在极为罕见的情况下，安全问题无法在不引起回归的情况下修复；这些修复都被放弃了，
+因为它们终究会引起问题。幸运的是这种两难境地基本都可以避免，受影响区域的主要
+开发者以及Linus Torvalds本人通常都会努力在不引入回归的情况下解决安全问题。
+
+如果你仍然面临此种情况，请查看邮件列表档案是否有人尽力避免过回归。如果没有，
+请报告它；如有疑问，请如上所述寻求建议。
+
+当修复回归时不可避免会引入另一个，如何处理？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+很遗憾这种事确实会出现，但幸运的是并不经常出现；如果发生了，受影响代码区的资
+深开发者应当调查该问题以找到避免回归的解决方法，至少避免它们的影响。如果你遇
+到这样的情况，如上所述：检查之前的讨论是否有人已经尽了最大努力，如有疑问请寻
+求建议。
+
+小提示：如果人们在每个开发周期中定期给出主线预发布（即v5.15-rc1或-rc3）以供
+测试，则可以避免这种情况。为了更好地解释，可以设想一个在Linux v5.14和v5.15-rc1
+之间集成的更改，该更改导致了回归，但同时是应用于5.15-rc1的其他改进的强依赖。
+如果有人在5.15发布之前就发现并报告了这个问题，那么所有更改都可以直接撤销，从
+而解决回归问题。而就在几天或几周后，此解决方案变成了不可能，因为一些软件可能
+已经开始依赖于后续更改之一：撤销所有更改将导致上述用户软件出现回归，这是不可
+接受的。
+
+若我所依赖的功能在数月前被移除了，是回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+是的，但如前节所述，通常很难修复此类回归。因此需要逐案处理。这也是定期测试主
+线预发布对所有人有好处的另一个原因。
+
+如果我似乎是唯一受影响的人，是否仍适用“无回归”规则？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+适用，但仅限于实际使用：Linux开发人员希望能够自由地取消那些只能在阁楼和博物
+馆中找到的硬件的支持。
+
+请注意，有时为了取得进展，不得不出现回归——后者也是防止Linux停滞不前所必需
+的。因此如果回归所影响的用户很少，那么为了他们和其他人更大的利益，还是让事情
+过去吧。尤其是存在某种规避回归的简单方法，例如更新一些软件或者使用专门为此目
+的创建的内核参数。
+
+回归规则是否也适用于staging树中的代码？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+不，参见 `适用于所有staging代码配置选项的帮助文本
+<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_ ，
+其早已声明::
+
+ 请注意：这些驱动正在积极开发中，可能无法正常工作，并可能包含会在不久的
+ 将来发生变化的用户接口。
+
+虽然staging开发人员通常坚持“无回归”的原则，但有时为了取得进展也会违背它。这就
+是为什么当staging树的WiFi驱动被基本推倒重来时，有些用户不得不处理回归（通常可
+以忽略）。
+
+为什么较新版本必须“使用相似配置编译”？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+因为Linux内核开发人员有时会集成已知的会导致回归的变更，但使它们成为可选的，并
+在内核的默认配置下禁用它们。这一技巧允许进步，否则“无回归”规则将导致停滞。
+
+例如，试想一个新的可以阻止恶意软件滥用某个内核的接口的安全特性，同时又需要满足
+另一个很罕见的应用程序。上述的方法可使两方都满意：使用这些应用程序的人可以关闭
+新的安全功能，而其他不会遇到麻烦的人可以启用它。
+
+如何创建与旧内核相似的配置？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+用一个已知良好的内核启动机器，并用 ``make olddefconfig`` 配置新版的Linux。这
+会让内核的构建脚本从正在运行的内核中摘录配置文件（“.config”文件），作为即将编
+译的新版本的基础配置；同时将所有新的配置选项设为默认值，以禁用可能导致回归的
+新功能。
+
+如何报告在预编译的普通内核中发现的回归？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+您需要确保新的内核是用与旧版相似的配置编译（见上文），因为那些构建它们的人可
+能启用了一些已知的与新内核不兼容的特性。如有疑问，请向内核的提供者报告问题并
+寻求建议。
+
+
+用“regzbot”追踪回归的更多信息
+-----------------------------
+
+什么是回归追踪？为啥我需要关心它？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+像“无回归”这样的规则需要有人来确保它们被遵守，否则会被有意/无意打破。历史证
+明了这一点对于Linux内核开发也适用。这就是为什么Linux内核的回归跟踪者Thorsten
+Leemhuis，，和另一些人尽力关注所有的回归直到他们解决。他们从未为此获得报酬，
+因此这项工作是在尽最大努力的基础上完成的。
+
+为什么/如何使用机器人追踪Linux内核回归？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+由于Linux内核开发过程的分布式和松散结构，完全手动跟踪回归已经被证明是相当困难
+的。因此Linux内核的回归跟踪者开发了regzbot来促进这项工作，其长期目标是尽可能为
+所有相关人员自动化回归跟踪。
+
+Regzbot通过监视跟踪的回归报告的回复来工作。此外，它还查找用“Link:”标签引用这
+些报告的补丁；对这些补丁的回复也会被跟踪。结合这些数据，可以很好地了解当前修
+复过程的状态。
+
+如何查看regzbot当前追踪的回归？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+参见 `regzbot在线 <https://linux-regtracking.leemhuis.info/regzbot/>`_ 。
+
+何种问题可以由regzbot追踪？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+该机器人只为了跟踪回归，因此请不要让regzbot涉及常规问题。但是对于Linux内核的
+回归跟踪者来说，让regzbot跟踪严重问题也可以，如有关挂起、损坏数据或内部错误
+（Panic、Oops、BUG（）、warning…）的报告。
+
+How to change aspects of a tracked regression?
+如何修改被追踪回归的相关信息？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+在直接或间接回复报告邮件时使用“regzbot命令”即可。最简单的方法是：在“已发送”文
+件夹或邮件列表存档中找到报告，然后使用邮件客户端的“全部回复”功能对其进行回复。
+在该邮件中的独立段落中可使用以下命令之一（即使用空行将这些命令中的一个或多个与
+其余邮件文本分隔开）。
+
+ * 更新回归引入起点，例如在执行二分之后::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+ * 设置或更新标题::
+
+ #regzbot title: foo
+
+ * 监视讨论或bugzilla.kernel.org上有关讨论或修复的工单::
+
+ #regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * 标记一个有更多相关细节的地方，例如有关但主题不同的邮件列表帖子或缺陷追踪器中的工单::
+
+ #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * 标记回归已失效::
+
+ #regzbot invalid: wasn't a regression, problem has always existed
+
+Regzbot还支持其他一些主要由开发人员或回归追踪人员使用的命令。命令的更多细节请
+参考 `入门指南 <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
+和 `参考手册 <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_ 。
+
+..
+ end-of-content
+..
+ This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
+ of the file. If you want to distribute this text under CC-BY-4.0 only,
+ please use "The Linux kernel developers" for author attribution and link
+ this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
base-commit: 0ebe4dd124d3a0e708ea24734c13d52657e36363
--
2.30.2
^ permalink raw reply related [relevance 7%]
* [PATCH v2] docs/zh_CN: Add a new translation of reporting-regressions.rst
2022-06-25 2:10 7% [PATCH] docs/zh_CN: Add a new translation of reporting-regressions.rst Wu XiangCheng
@ 2022-07-07 14:30 7% ` Wu XiangCheng
0 siblings, 0 replies; 200+ results
From: Wu XiangCheng @ 2022-07-07 14:30 UTC (permalink / raw)
To: Alex Shi, Yanteng Si
Cc: Jonathan Corbet, xu xin, Yang Yang, Junhua Huang, Tang Yizhou,
Binbin Zhou, linux-doc
Last English version used:
commit d2b40ba2cce2 ("docs: *-regressions.rst: explain how quickly
issues should be handled")
Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
---
v2:
* fix all existed file path
* modified some words under Yanteng's advice, thanks
v1:
see <https://lore.kernel.org/linux-doc/YrZufcSEnvBWj+7Z@bobwxc.mipc/>
.../translations/zh_CN/admin-guide/index.rst | 2 +-
.../admin-guide/reporting-regressions.rst | 370 ++++++++++++++++++
2 files changed, 371 insertions(+), 1 deletion(-)
create mode 100644 Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst
index be535ffaf4b0..2f6970d0a032 100644
--- a/Documentation/translations/zh_CN/admin-guide/index.rst
+++ b/Documentation/translations/zh_CN/admin-guide/index.rst
@@ -36,6 +36,7 @@ Todolist:
:maxdepth: 1
reporting-issues
+ reporting-regressions
security-bugs
bug-hunting
bug-bisect
@@ -44,7 +45,6 @@ Todolist:
Todolist:
-* reporting-bugs
* ramoops
* dynamic-debug-howto
* kdump/index
diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst b/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
new file mode 100644
index 000000000000..c0461ee855bc
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
@@ -0,0 +1,370 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+.. 【重分发信息参见本文件结尾】
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/admin-guide/reporting-regressions.rst
+
+:译者:
+
+ 吴想成 Wu XiangCheng <bobwxc@email.cn>
+
+
+============
+报告回归问题
+============
+
+“*我们拒绝出现回归*”是Linux内核开发的首要规则；Linux的发起者和领军开发者Linus
+Torvalds立下了此规则并确保它被落实。
+
+本文档描述了这条规则对用户的意义，以及Linux内核开发模型如何确保解决所有被报告
+的回归；关于内核开发者如何处理的方面参见 Documentation/process/handling-regressions.rst 。
+
+
+本文重点（亦即“太长不看”）
+==========================
+
+#. 如果某程序在原先的Linux内核上运行良好，但在较新版本上效果更差、或者根本不
+ 能用，那么你就碰见回归问题了。注意，新内核需要使用类似配置编译；更多相关细
+ 节参见下方。
+
+#. 按照 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst 中
+ 所说的报告你的问题，该文档已经包含了所有关于回归的重要方面，为了方便起见也
+ 复制到了下面。两个重点：在报告主题中使用“[REGRESSION]”开头并抄送或转发到
+ `回归邮件列表 <https://lore.kernel.org/regressions/>`_
+ （regressions@lists.linux.dev）。
+
+#. 可选但是建议：在发送或转发报告时，指明该回归发生的起点，以便Linux内核回归
+ 追踪机器人“regzbot”可以追踪此问题::
+
+ #regzbot introduced v5.13..v5.14-rc1
+
+
+与用户相关的所有Linux内核回归细节
+=================================
+
+
+基本重点
+--------
+
+
+什么是“回归”以及什么是“无回归规则”？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+如果某程序/实例在原先的Linux内核上运行良好，但在较新版本上效果更差、或者根本
+不能用，那么你就碰见回归问题了。“无回归规则”不允许出现这种情况。如果偶然发
+生了，导致问题的开发者应当迅速修复问题。
+
+也就是说，若Linux 5.13中的WiFi驱动程序运行良好，但是在5.14版本上却不能用、速
+度明显变慢或出现错误，那就出现了回归。如果某正常工作的应用程序突然在新内核上
+出现不稳定，这也是回归；这些问题可能是由于procfs、sysfs或Linux提供给用户空间
+软件的许多其他接口之一的变化。但请记住，前述例子中的5.14需要使用类似于5.13的
+配置构建。这可以用 ``make olddefconfig`` 实现，详细解释见下。
+
+注意本节第一句话中的“实例”：即使开发者需要遵循“无回归”规则，但仍可自由地改
+变内核的任何方面，甚至是导出到用户空间的API或ABI，只要别破坏现有的应用程序或
+用例。
+
+还需注意，“无回归”规则只限制内核提供给用户空间的接口。它不适用于内核内部接
+口，比如一些外部开发的驱动程序用来插入钩子到内核的模块API。
+
+如何报告回归？
+~~~~~~~~~~~~~~
+
+只需按照 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst 中
+所说的报告你的问题，该文档已经包含了要点。下面几点概述了一下只在回归中重要的
+方面：
+
+ * 在检查可加入讨论的现有报告时，别忘了搜索 `Linux回归邮件列表
+ <https://lore.kernel.org/regressions/>`_ 和 `regzbot网页界面
+ <https://linux-regtracking.leemhuis.info/regzbot/>`_ 。
+
+ * 在报告主题的开头加上“[REGRESSION]”。
+
+ * 在你的报告中明确最后一个正常工作的内核版本和首个出问题的版本。如若可能，
+ 用二分法尝试找出导致回归的变更，更多细节见下。
+
+ * 记得把报告发到Linux回归邮件列表（regressions@lists.linux.dev）。
+
+ * 如果通过邮件报告回归，请抄送回归列表。
+
+ * 如果你使用某些缺陷追踪器报告回归，请通过邮件转发已提交的报告到回归列表，
+ 并抄送维护者以及出问题的相关子系统的邮件列表。
+
+ 如果是稳定版或长期支持版系列（如v5.15.3…v5.15.5）的回归，请记得抄送
+ `Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ （stable@vger.kernel.org）。
+
+ 如果你成功地执行了二分，请抄送肇事提交的信息中所有签了“Signed-off-by:”的人。
+
+在抄送你的报告到列表时，也请记得通知前述的Linux内核回归追踪机器人。只需在邮件
+中包含如下片段::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+
+Regzbot会就将你的邮件视为在某个特定版本区间的回归报告。上例中即linux v5.13仍
+然正常，而Linux 5.14-rc1是首个您遇到问题的版本。如果你执行了二分以查找导致回
+归的提交，请使用指定肇事提交的id代替::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+添加这样的“regzbot命令”对你是有好处的，它会确保报告不会被忽略。如果你省略了
+它，Linux内核的回归跟踪者会把你的回归告诉regzbot，只要你发送了一个副本到回归
+邮件列表。但是回归跟踪者只有一个人，有时不得不休息或甚至偶尔享受可以远离电脑
+的时光（听起来很疯狂）。因此，依赖此人手动将回归添加到 `已追踪且尚未解决的
+Linux内核回归列表 <https://linux-regtracking.leemhuis.info/regzbot/>`_ 和
+regzbot发送的每周回归报告，可能会出现延迟。 这样的延误会导致Linus Torvalds
+在决定“继续开发还是发布新版本？”时忽略严重的回归。
+
+真的修复了所有的回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+几乎所有都是，只要引起问题的变更（肇事提交）被可靠定位。也有些回归可以不用这
+样，但通常是必须的。
+
+谁需要找出回归的根本原因？
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+受影响代码区域的开发者应该自行尝试定位问题所在。但仅靠他们的努力往往是不可
+能做到的，很多问题只发生在开发者的无法接触的其他特定外部环境中——例如特定的
+硬件平台、固件、Linux发行版、系统的配置或应用程序。这就是为什么最终往往是报
+告者定位肇事提交；有时用户甚至需要再运行额外测试以查明确切的根本原因。开发
+者应该提供建议和可能的帮助，以使普通用户更容易完成该流程。
+
+如何找到罪魁祸首？
+~~~~~~~~~~~~~~~~~~
+
+如 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst （简要）
+和 Documentation/translations/zh_CN/admin-guide/bug-bisect.rst （详细）中所
+述，执行二分。听起来工作量很大，但大部分情况下很快就能找到罪魁祸首。如果这很
+困难或可靠地重现问题很耗时，请考虑与其他受影响的用户合作，一起缩小搜索范围。
+
+当出现回归时我可以向谁寻求建议？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+发送邮件到回归邮件列表（regressions@lists.linux.dev）同时抄送Linux内核的回归
+跟踪者（regressions@leemhuis.info）;如果问题需要保密处理，可以省略列表。
+
+
+关于回归的更多细节
+------------------
+
+
+“无回归规则”的目标是什么？
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+用户应该放心升级内核版本，而不必担心有程序可能崩溃。这符合内核开发者的利益，
+可以使更新有吸引力：他们不希望用户停留在停止维护或超过一年半的稳定/长期Linux
+版本系列上。这也符合所有人的利益，因为 `那些系列可能含有已知的缺陷、安全问题
+或其他后续版本已经修复的问题
+<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_ 。
+此外，内核开发者希望使用户测试最新的预发行版或常规发行版变得简单而有吸引力。
+这同样符合所有人的利益，如果新版本出来后很快就有相关报告，会使追踪和修复问题
+更容易。
+
+实际中“无回归”规则真的可行吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+这不是句玩笑话，请见Linux创建者和主要开发人员Linus Torvalds在邮件列表中的许
+多发言，其中一些在 Documentation/process/handling-regressions.rst 中被引用。
+
+此规则的例外情况极为罕见；之前当开发者认为某个特定的情况有必要援引例外时，
+基本都被证明错了。
+
+谁来确保“无回归”被落实？
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+照看和支撑树的子系统维护者应该关心这一点——例如，Linus Torvalds之于主线，
+Greg Kroah-Hartman等人之于各种稳定/长期系列。
+
+他们都得到了别人的帮助，以确保回归报告不会被遗漏。其中之一是Thorsten
+Leemhuis，他目前担任Linux内核的“回归跟踪者”；为了做好这项工作，他使用了
+regzbot——Linux内核回归跟踪机器人。所以这就是为什么要抄送或转发你的报告到
+回归邮件列表来通知这些人，已经最好在你的邮件中包含“regzbot命令”来立即追踪它。
+
+回归通常多久能修复？
+~~~~~~~~~~~~~~~~~~~~
+
+开发者应该尽快修复任何被报告的回归，以提供及时为受影响的用户提供解决方案，并
+防止更多用户遇到问题；然而，开发人员需要花足够的时间和注意力确保回归修复不会
+造成额外的损害。
+
+因此，答案取决于各种因素，如回归的影响、存在时长或出现于哪个Linux版本系列。
+但最终，大多数的回归应该在两周内修复。
+
+当问题可以通过升级某些软件解决时，是回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+基本都是。如果开发人员告诉您其他情况，请咨询上述回归跟踪者。
+
+当新内核变慢或能耗增加，是回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+是的，但有一些差别。在微型基准测试中变慢5%不太可能被视为回归，除非它也会对
+广泛基准测试的结果产生超过1%的影响。如果有疑问，请寻求建议。
+
+当更新Linux时外部内核模块崩溃了，是回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+不，因为“无回归”规则仅限于Linux内核提供给用户空间的接口和服务。因此，它不包括
+构建或运行外部开发的内核模块，因为它们在内核空间中运行与挂进内核使用的内部接
+口偶尔会变化。
+
+如何处理安全修复引起的回归？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+在极为罕见的情况下，安全问题无法在不引起回归的情况下修复；这些修复都被放弃了，
+因为它们终究会引起问题。幸运的是这种两难境地基本都可以避免，受影响区域的主要
+开发者以及Linus Torvalds本人通常都会努力在不引入回归的情况下解决安全问题。
+
+如果你仍然面临此种情况，请查看邮件列表档案是否有人尽力避免过回归。如果没有，
+请报告它；如有疑问，请如上所述寻求建议。
+
+当修复回归时不可避免会引入另一个，如何处理？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+很遗憾这种事确实会出现，但幸运的是并不经常出现；如果发生了，受影响代码区的资
+深开发者应当调查该问题以找到避免回归的解决方法，至少避免它们的影响。如果你遇
+到这样的情况，如上所述：检查之前的讨论是否有人已经尽了最大努力，如有疑问请寻
+求建议。
+
+小提示：如果人们在每个开发周期中定期给出主线预发布（即v5.15-rc1或-rc3）以供
+测试，则可以避免这种情况。为了更好地解释，可以设想一个在Linux v5.14和v5.15-rc1
+之间集成的更改，该更改导致了回归，但同时是应用于5.15-rc1的其他改进的强依赖。
+如果有人在5.15发布之前就发现并报告了这个问题，那么所有更改都可以直接撤销，从
+而解决回归问题。而就在几天或几周后，此解决方案变成了不可能，因为一些软件可能
+已经开始依赖于后续更改之一：撤销所有更改将导致上述用户软件出现回归，这是不可
+接受的。
+
+若我所依赖的功能在数月前被移除了，是回归吗？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+是的，但如前节所述，通常很难修复此类回归。因此需要逐案处理。这也是定期测试主
+线预发布对所有人有好处的另一个原因。
+
+如果我似乎是唯一受影响的人，是否仍适用“无回归”规则？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+适用，但仅限于实际使用：Linux开发人员希望能够自由地取消那些只能在阁楼和博物
+馆中找到的硬件的支持。
+
+请注意，有时为了取得进展，不得不出现回归——后者也是防止Linux停滞不前所必需
+的。因此如果回归所影响的用户很少，那么为了他们和其他人更大的利益，还是让事情
+过去吧。尤其是存在某种规避回归的简单方法，例如更新一些软件或者使用专门为此目
+的创建的内核参数。
+
+回归规则是否也适用于staging树中的代码？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+不，参见 `适用于所有staging代码配置选项的帮助文本
+<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_ ，
+其早已声明::
+
+ 请注意：这些驱动正在积极开发中，可能无法正常工作，并可能包含会在不久的
+ 将来发生变化的用户接口。
+
+虽然staging开发人员通常坚持“无回归”的原则，但有时为了取得进展也会违背它。这就
+是为什么当staging树的WiFi驱动被基本推倒重来时，有些用户不得不处理回归（通常可
+以忽略）。
+
+为什么较新版本必须“使用相似配置编译”？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+因为Linux内核开发人员有时会集成已知的会导致回归的变更，但使它们成为可选的，并
+在内核的默认配置下禁用它们。这一技巧允许进步，否则“无回归”规则将导致停滞。
+
+例如，试想一个新的可以阻止恶意软件滥用某个内核的接口的安全特性，同时又需要满足
+另一个很罕见的应用程序。上述的方法可使两方都满意：使用这些应用程序的人可以关闭
+新的安全功能，而其他不会遇到麻烦的人可以启用它。
+
+如何创建与旧内核相似的配置？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+用一个已知良好的内核启动机器，并用 ``make olddefconfig`` 配置新版的Linux。这
+会让内核的构建脚本从正在运行的内核中摘录配置文件（“.config”文件），作为即将编
+译的新版本的基础配置；同时将所有新的配置选项设为默认值，以禁用可能导致回归的
+新功能。
+
+如何报告在预编译的普通内核中发现的回归？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+您需要确保新的内核是用与旧版相似的配置编译（见上文），因为那些构建它们的人可
+能启用了一些已知的与新内核不兼容的特性。如有疑问，请向内核的提供者报告问题并
+寻求建议。
+
+
+用“regzbot”追踪回归的更多信息
+-----------------------------
+
+什么是回归追踪？为啥我需要关心它？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+像“无回归”这样的规则需要有人来确保它们被遵守，否则会被有意/无意打破。历史证
+明了这一点对于Linux内核开发也适用。这就是为什么Linux内核的回归跟踪者Thorsten
+Leemhuis，，和另一些人尽力关注所有的回归直到他们解决。他们从未为此获得报酬，
+因此这项工作是在尽最大努力的基础上完成的。
+
+为什么/如何使用机器人追踪Linux内核回归？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+由于Linux内核开发过程的分布式和松散结构，完全手动跟踪回归已经被证明是相当困难
+的。因此Linux内核的回归跟踪者开发了regzbot来促进这项工作，其长期目标是尽可能为
+所有相关人员自动化回归跟踪。
+
+Regzbot通过监视跟踪的回归报告的回复来工作。此外，它还查找用“Link:”标签引用这
+些报告的补丁；对这些补丁的回复也会被跟踪。结合这些数据，可以很好地了解当前修
+复过程的状态。
+
+如何查看regzbot当前追踪的回归？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+参见 `regzbot在线 <https://linux-regtracking.leemhuis.info/regzbot/>`_ 。
+
+何种问题可以由regzbot追踪？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+该机器人只为了跟踪回归，因此请不要让regzbot涉及常规问题。但是对于Linux内核的
+回归跟踪者来说，让regzbot跟踪严重问题也可以，如有关挂起、损坏数据或内部错误
+（Panic、Oops、BUG（）、warning…）的报告。
+
+如何修改被追踪回归的相关信息？
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+在直接或间接回复报告邮件时使用“regzbot命令”即可。最简单的方法是：在“已发送”文
+件夹或邮件列表存档中找到报告，然后使用邮件客户端的“全部回复”功能对其进行回复。
+在该邮件中的独立段落中可使用以下命令之一（即使用空行将这些命令中的一个或多个与
+其余邮件文本分隔开）。
+
+ * 更新回归引入起点，例如在执行二分之后::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+ * 设置或更新标题::
+
+ #regzbot title: foo
+
+ * 监视讨论或bugzilla.kernel.org上有关讨论或修复的工单::
+
+ #regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * 标记一个有更多相关细节的地方，例如有关但主题不同的邮件列表帖子或缺陷追踪器中的工单::
+
+ #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * 标记回归已失效::
+
+ #regzbot invalid: wasn't a regression, problem has always existed
+
+Regzbot还支持其他一些主要由开发人员或回归追踪人员使用的命令。命令的更多细节请
+参考 `入门指南 <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
+和 `参考手册 <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_ 。
+
+..
+ 正文结束
+..
+ 如本文件开头所述，本文以GPL-2.0+或CC-BY-4.0许可发行。如您想仅在CC-BY-4.0许
+ 可下重分发本文，请用“Linux内核开发者”作为作者，并用如下链接作为来源：
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
+..
+ 注意：本RST文件内容只有在来自Linux内核源代码时是使用CC-BY-4.0许可的，因为经
+ 过处理的版本（如经内核的构建系统）可能包含来自使用更严格许可证的文件的内容。
base-commit: 4d627ef12b409fd149226617180f1cc6088bbf12
--
2.30.2
^ permalink raw reply related [relevance 7%]
* [RFC PATCH v1 1/2] docs: add a document about regression handling
@ 2022-01-03 9:50 7% ` Thorsten Leemhuis
0 siblings, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2022-01-03 9:50 UTC (permalink / raw)
To: linux-doc, Linus Torvalds, Greg Kroah-Hartman
Cc: workflows, Linux Kernel Mailing List, Randy Dunlap,
Jonathan Corbet
Create a document explaining various aspects around regression handling
and tracking both for users and developers. Among others describe the
first rule of Linux kernel development and what it means in practice.
Also explain what a regression actually is and how to report them
properly. The text additionally provides a brief introduction to the bot
the kernel's regression tracker users to facilitate the work. To sum
things up, provide a few quotes from Linus to show how serious the he
takes regressions.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
Documentation/admin-guide/index.rst | 1 +
Documentation/admin-guide/regressions.rst | 869 ++++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 871 insertions(+)
create mode 100644 Documentation/admin-guide/regressions.rst
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 1bedab498104..17157ee5a416 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -36,6 +36,7 @@ problems and bugs in particular.
reporting-issues
security-bugs
+ regressions
bug-hunting
bug-bisect
tainted-kernels
diff --git a/Documentation/admin-guide/regressions.rst b/Documentation/admin-guide/regressions.rst
new file mode 100644
index 000000000000..1ff6a0802fc9
--- /dev/null
+++ b/Documentation/admin-guide/regressions.rst
@@ -0,0 +1,869 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+..
+ If you want to distribute this text under CC-BY-4.0 only, please use 'The
+ Linux kernel developers' for author attribution and link this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/regressions.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
+
+
+Regressions
++++++++++++
+
+The first rule of Linux kernel development: '*We don't cause regressions*'.
+Linux founder and lead developer Linus Torvalds strictly enforces the rule
+himself. This document describes what this means in practice and how the Linux
+kernel's development model ensues all reported regressions get addressed; it
+covers aspects relevant for both users and developers.
+
+The important bits for people affected by regressions
+=====================================================
+
+It's a regression if something running fine with one Linux kernel works worse or
+not at all with a newer version. Note, the newer kernel has to be compiled using
+a similar configuration -- for this and other fine print, check out below
+section "What is a 'regression' and what is the 'no regressions rule'?".
+
+Report your regression as outlined in
+`Documentation/admin-guide/reporting-issues.rst`, it already covers all aspects
+important for regressions. Below section "How do I report a regression?"
+highlights them for convenience.
+
+The most important aspect: CC for forward the report to `the regression mailing
+list <https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev).
+When doing so, consider mentioning the version range where the regression
+started using a paragraph like this::
+
+ #regzbot introduced v5.13..v5.14-rc1
+
+The Linux kernel regression tracking bot 'regzbot' will then add the report to
+the list of tracked regressions. This is in your interest, as it gets the report
+on the radar of people ensuring all regressions are acted upon in timely manner.
+
+The important bits for people fixing regressions
+================================================
+
+When getting regression reports by mail, check if the reporter CCed `the
+regression mailing list <https://lore.kernel.org/regressions/>`_
+(regressions@lists.linux.dev). If not, forward or bounce the report to the Linux
+kernel's regression tracker (regressions@leemhuis.info), unless you plan sending
+a reply to the report anyway. In that case simply CC the list in a direct reply
+to the report. Also check, if the report included a 'regzbot command' like
+``#regzbot introduced v5.13..v5.14-rc1`` (see above); if not, please include a
+paragraph like the following, to get the regression tracked by the Linux kernel
+regression tracking bot 'regzbot'::
+
+ #regzbot ^introduced v5.13..v5.14-rc1
+
+If the report was filed in a public bug-tracker, forward it to the regression
+list; add the aforementioned paragraph, just omit the caret (the ^) before the
+``introduced``, which make regzbot treat your mail (and not the one you reply
+to) as the report.
+
+When submitting fixes for regressions, always include 'Link:' tags in the commit
+message that point to all places where the issue was reported, as explained in
+`Documentation/process/submitting-patches.rst` and
+:ref:`Documentation/process/5.Posting.rst <development_posting>`. Hence, link to
+any mails in the archive with reports about the issue as well as all bug-tracker
+entries::
+
+ Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=215375
+
+This is important for regression tracking, as this allows regzbot to
+automatically associate tracked regression reports with patch postings and
+commits fixing it.
+
+
+All the details on handling Linux kernel regressions
+====================================================
+
+The important basics
+--------------------
+
+What is a 'regression' and what is the 'no regressions rule'?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's a regression if some application or practical use case running fine on one
+Linux kernel works worse or not at all with a newer version compiled using a
+similar configuration. The 'no regressions rule' forbids this to happen. If a
+regression happens by accident, developers that caused it are expected to
+quickly fix the issue.
+
+It thus is a regression when a WiFi driver from Linux 5.13 works fine, but with
+5.14 doesn't work at all, works significantly slower, or misbehaves somehow.
+It's also a regression if a perfectly working application suddenly shows erratic
+behavior with a newer kernel version, which can be caused by changes in procfs,
+sysfs, or one of the many other interfaces Linux provides to userland software.
+But keep in mind, as mentioned earlier: 5.14 in this example needs to be build
+from a configuration similar to the one from 5.13. This can be achieved using
+``make olddefconfig``, as explained in more detail below.
+
+Note the 'practical use case' in the first sentence of this section: developers
+despite the 'no regressions' rule are free to change any aspect of the kernel
+and even APIs or ABIs to userland, as long as no existing application or
+use-case breaks.
+
+Also be aware the 'no regressions' rule covers only interfaces the kernel
+provides to the userland. It thus does not apply to kernel-internal interfaces
+like the module API, which some externally developed drivers use to hook into
+the kernel.
+
+What is the goal of the 'no regressions rule'?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Users should feel safe when updating kernel versions and not have to worry
+something might break. This is in the interest of the kernel developers to make
+updating attractive: they don't want users to stay on stable or longterm Linux
+series either abandoned or more than one and a half year old, as `those might
+have known problems, security issues, or other aspects already improved in later
+versions
+<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_.
+
+How hard is the rule enforced?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Extraordinarily strict, as can be seen by many mailing list posts from Linux
+creator and lead-developer Linus Torvalds, some of which are quoted at the end
+of this document.
+
+Exceptions to this rule are extremely rare; in the past developers almost always
+turned out to be wrong when they assumed a particular situation was warranting
+an exception.
+
+How is the rule enforced?
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's the duty of the subsystem maintainers, which are watched and supported by
+Linus Torvalds for mainline or stable/longterm tree maintainers like Greg
+Kroah-Hartman. All of them are supported by Thorsten Leemhuis: he's acting as
+'regressions tracker' for the Linux kernel and trying to ensure all regression
+reports are acted upon in timely manner.
+
+The distributed and slightly unstructured nature of the Linux kernel's
+development makes tracking regressions hard. That's why Thorsten relies on the
+help of his Linux kernel regression tracking robot 'regzbot'. It watches mailing
+lists and git trees to semi-automatically associate regression reports to patch
+submissions and commits fixing the issue, as this provides all necessary
+insights into the fixing progress.
+
+To ensure no regression falls through the cracks, the regression tracker or his
+bot need to get aware of every report. That's why you need to get them into the
+loop for regressions, as explained in the next section.
+
+How do I report a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Just report the issue as outlined in
+`Documentation/admin-guide/reporting-issues.rst`, it already describes the
+important points. The following aspects described there are especially relevant
+for regressions:
+
+ * When checking for existing reports to join, first check the `archives of the
+ Linux regressions mailing list <https://lore.kernel.org/regressions/>`_ and
+ `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_.
+
+ * In your report, mention the last kernel version that worked fine and the
+ first broken one. Even better: try to find the commit causing the regression
+ using a bisection.
+
+ * Remember to let the Linux regressions mailing list
+ (regressions@lists.linux.dev) known about your report:
+
+ * If you report the regression by mail, CC the regressions list.
+
+ * If you report your regression to some bug tracker, forward the filed report
+ by mail to the regressions list while CCing the maintainer and the mailing
+ list for the subsystem in question.
+
+Additionally, you in both cases should directly get the aforementioned Linux
+kernel regression tracking bot into the loop. To do that, include a paragraph
+like this in your report to tell the bot when the regression started to happen::
+
+ #regzbot introduced: v5.13..v5.14-rc1
+
+In this example, v5.13 was the last version that worked, while v5.14-rc1 was the
+first broken one. The smaller the range, the better, as that makes it easier to
+find out what's wrong and who's responsible. That's why you ideally should
+perform a bisection to find the commit causing the regression (the 'culprit').
+If you did, specify it instead::
+
+ #regzbot introduced: 1f2e3d4c5d
+
+Placing such a 'regzbot command' is in your interest, as it will ensure the
+report won't fall through the cracks unnoticed. If you omit this, the Linux
+kernel's regressions tracker will take care of telling regzbot about your
+regression, as long as you sent a copy to the regressions mailing lists. But the
+regression tracker is just one human which sometimes has to rest or occasionally
+might even enjoy some time away from computers (as crazy as that might sound).
+Relying on this person thus will result in an unnecessary delay before the
+regressions becomes mentioned `on the list of tracked and unresolved Linux
+kernel regressions <https://linux-regtracking.leemhuis.info/regzbot/>`_ and the
+weekly regression reports sent by regzbot. Such delays can result in Linus
+Torvalds being unaware of important regressions when deciding between 'continue
+development or call this finished by performing a release?'.
+
+How to add a regression to regzbot's tracking somebody else reported?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Use your mailers 'Reply-all' function to send a reply where you CC the
+regressions list (regressions@lists.linux.dev). In that reply create a new
+paragraph with a regzbot command like this::
+
+ #regzbot ^introduced: v5.13..v5.14-rc1
+
+The caret (^) before the 'introduced' makes regzbot treat the parent mail (the
+one you reply to) as the report for the regression you want to see tracked.
+Instead of a version range you can also specify the commit causing the
+regression, as outlined in the previous section.
+
+If the report came in private from a bug tracker, forward it to the list;
+include the aforementioned line, just omit the caret (the ^) before the
+'introduced'; consider adding a line with the line '#regzbot link: <url>' (see
+below) pointing to the place with the initial report.
+
+Alternatively to all the above you can just forward or bounce the report to the
+Linux kernel's regression tracker, but consider the downsides already outlined
+in the previous section.
+
+Do really all regressions get fixed?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Nearly all of them are, as long as the change causing the regression (the
+'culprit commit') gets reliably identified. Some regressions can be fixed
+without this, but often it's required.
+
+Who needs to find the commit causing a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's the reporter's duty to find the culprit, but developers of the affected
+subsystem should offer advice and reasonably help where they can.
+
+How can I find the change causing a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Perform a bisection, as roughly outlined in
+`Documentation/admin-guide/reporting-issues.rst` and described in more detail by
+`Documentation/admin-guide/bug-bisect.rst`. It might sound like a lot of work,
+but in many cases finds the culprit relative quickly. If it's hard or
+time-consuming to reliably reproduce the issue, consider teaming up with others
+affected by the problem to narrow down the search range together.
+
+Who can I ask for advice when it comes to regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
+CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the
+issue might better be dealt with in private, feel free to omit the list.
+
+
+More details about regressions relevant for reporters
+-----------------------------------------------------
+
+Does a regression need to be fixed, if it can be avoided by updating some other software?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Almost always: yes. If a developer tell you otherwise, ask the regression
+tracker for advice as outlined above.
+
+Does it qualify as a regression if a newer kernel works slower or makes the system consumes more energy?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but the difference has to be significant. A five percent slow-down in a
+micro-benchmark thus is unlikely to qualify as regression, unless it also
+influences the results of a broad benchmark by more than one percent. If in a
+doubt, ask for advice.
+
+Is it a regression, if an externally developed kernel module is incompatible with a newer kernel?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+No, as the 'no regression' rule is about interfaces and services the Linux
+kernel provides to the userland. It thus does not cover building or running
+externally developed kernel modules, as they run in kernel-space and use
+occasionally changed internal interfaces to hook into the kernel.
+
+How are regressions handled that are caused by a fix for security vulnerability?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In extremely rare situations security issues can't be fixed without causing
+regressions; those are given way, as they are the lesser evil in the end.
+Luckily this almost always can be avoided, as key developers for the affected
+area and often Linus Torvalds himself try very hard to fix security issues
+without causing regressions.
+
+If you nevertheless face such a case, check the mailing list archives if people
+tried their best to avoid the regression; if in a doubt, ask for advice as
+outlined above.
+
+What happens if fixing a regression is impossible without causing another regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sadly these things happen, but luckily not very often; if they occur, expert
+developers of the affected code area should look into the issue to find a fix
+that avoids regressions or at least their impact. If you run into such a
+situation you thus do what was outlined already for regressions caused by
+security fixes: check earlier discussions if people already tried their best and
+ask for advice if in a doubt.
+
+A quick note while at it: these situations could be avoided, if you would
+regularly give mainline pre-releases (say v5.15-rc1 or -rc3) from each cycle a
+test run. This is best explained by imagining a change integrated between Linux
+v5.14 and v5.15-rc1 which causes a regression, but at the same time is a hard
+requirement for some other improvement applied for 5.15-rc1. All these changes
+often can simply be reverted and the regression thus solved, if someone finds
+and reports it before 5.15 is released. A few days or weeks later after the
+release this solution might become impossible, if some software starts to rely
+on aspects introduced by one of the follow-up changes: reverting all changes
+would cause regressions for users of said software and thus out of the question.
+
+A feature I relied on was removed months ago, but I only noticed now. Does that qualify as regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but often it's hard to fix them due to the aspects outlined in the
+previous section. It hence needs to be dealt with on a case-by-case basis; this
+is another reason why it's in your interest to regular test mainline releases.
+
+Does the 'no regression' rule apply if I seem to be the only person in the world that is affected by a regression?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It does, but only for practical usage: the Linux developers want to be free to
+remove support for hardware only to be found in attics and museums anymore.
+
+Note, sometimes regressions can't be avoided to make progress -- and the latter
+is needed to prevent Linux from stagnation. Hence, if only very few users seem
+to be affected by a regression, it for the greater good might be in their and
+everyone else interest to not insist on the rule. Especially if there is a easy
+way to circumvent the regression somehow, for example by updating some software
+or using a kernel parameter created just for this purpose.
+
+Does the regression rule apply for code in the staging tree as well?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Not according to the `help text for the configuration option covering all
+staging code <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_,
+which since its early days states::
+
+ Please note that these drivers are under heavy development, may or
+ may not work, and may contain userspace interfaces that most likely
+ will be changed in the near future.
+
+The staging developers nevertheless often adhere the 'no regressions' rule, but
+sometimes bend it to make progress. That's for example why some users had to
+deal with (often negligible) regressions when a WiFi driver from the staging
+tree got replaced by a totally different one written from scratch.
+
+Why do later versions have to be 'compiled with a similar configuration'?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Because the Linux kernel developers sometimes integrate changes known to cause
+regressions, but make them optional and disable them in the kernel's default
+configuration. This trick allows progress, as the 'no regressions' rule
+otherwise would lead to stagnation. Consider for example a new security feature
+which blocks access to some kernel interfaces often abused by malware, but at
+the same time are required to run a few rarely used applications. The outlined
+trick makes both camps happy: people using these applications can leave the new
+security feature off, while everyone else can enable it without running into
+trouble.
+
+How to create a configuration similar to the one of an older kernel?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Start a known-good kernel and configure the newer Linux version with ``make
+olddefconfig``. This makes the kernel's build scripts pick up the configuration
+file (the `.config` file) from the running kernel as base for the new one you
+are about to compile; afterwards they set all new configuration options to their
+default value, which disables new features that might cause regressions.
+
+Can I report a regression with vanilla kernels provided by someone else to the upstream Linux kernel developers?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Only if the newer kernel was compiled with a similar configuration file as the
+older one (see above), as your provider might have enabled some known-to-be
+incompatible feature in the newer kernel. If in a doubt, report this problem to
+the provider and ask for advice.
+
+
+More details about regressions relevant for developers
+------------------------------------------------------
+
+What should I do, if I suspect a change I'm working on might cause regressions?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Evaluate how big the risk of regressions is, for example by performing a code
+search in Linux distributions and Git forges. Also consider asking other
+developers or projects likely to be affected to evaluate or even test the
+proposed change; if problems surface, maybe some middle ground acceptable for
+all can be found.
+
+If the risk of regressions in the end seems to be relative small, go ahead with
+the change, but let all involved parties know about the risk. Hence, make sure
+your patch description makes this aspect obvious. Once the change got merged,
+tell the Linux kernel's regression tracker and the regressions mailing list
+about the risk, so everyone has the change on the radar in case reports trickle
+in. Depending on the risk, you also might want to ask the subsystem maintainer
+to mention the issue in his pull request to mainline.
+
+
+Everything developers need to know about regression tracking
+------------------------------------------------------------
+
+Do I have to use regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's in the interest of everyone if you do, as kernel maintainers like Linus
+Torvalds partly rely on regzbot's tracking in their work -- for example when
+deciding to release a new version or extend the development phase. For this they
+need to be aware of all unfixed regression; to do that, Linus is known to look
+into the weekly reports sent by regzbot.
+
+Do I have to tell regzbot about every regression I stumble upon?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ideally yes: we are all humans and easily forget problems when something more
+important unexpectedly comes up -- for example a bigger problem in the Linux
+kernel or something in real life that's keeping us away from keyboards for a
+while. Hence, it's best to tell regzbot about every regression, except when you
+immediately write a fix and commit it to a tree regularly merged to the affected
+kernel series.
+
+Why does the Linux kernel need a regression tracker, and why does he utilize regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Rules like 'no regressions' need someone to enforce them, otherwise they are
+broken either accidentally or on purpose. History has shown that this is true
+for the Linux kernel as well. That's why Thorsten volunteered to keep an eye on
+things.
+
+Tracking regressions completely manually has proven to be exhausting and
+demotivating, which is why earlier attempts to establish it failed after a
+while. To prevent this from happening again, Thorsten developed Regzbot to
+facilitate the work, with the long term goal to automate regression tracking as
+much as possible for everyone involved.
+
+How does regression tracking work with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bot keeps track of all the reports and monitor their fixing progress. It
+tries to do that with as little overhead as possible for both reporters and
+developers.
+
+In fact, only reporters or someone helping them gets an extra duty: they need to
+tell regzbot about the regression report using one of the ``#regzbot
+introduced`` commands outlined above.
+
+For developers there normally is no extra work involved, they just need to do
+something that's expected from them already: add 'Link:' tags to the patch
+description pointing to all reports about the issue fixed.
+
+Thanks to these tags regzbot can associate regression reports with patches to
+fix the issue, whenever they get posted for review or applied to a git tree. The
+bot additionally watches out for replies to the report. All this data combined
+provides a good impression about the current status of the fixing process.
+
+How to see which regressions regzbot tracks currently?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_
+for the latest info; alternatively, `search for the latest regression report
+<https://lore.kernel.org/lkml/?q=%22Linux+regressions+report%22+f%3Aregzbot>`_,
+which regzbot normally sends out once a week on Sunday evening (UTC), which is a
+few hours before Linus usually publishes new (pre-)releases.
+
+What places is regzbot monitoring?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Regzbot is watching the most important Linux mailing lists as well as the Linux
+next, mainline and stable/longterm git repositories.
+
+How to interact with regzbot?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Everyone can interact with the bot using mails containing `regzbot commands`,
+which need to be in their own paragraph (IOW: they need to be separated from the
+rest of the mail using blank lines). One such command is ``#regzbot introduced
+<version or commit>``, which adds a report to the tracking, as already described
+above; ``#regzbot ^introduced <version or commit>`` is another such command,
+which makes regzbot consider the parent mail as a report for a regression which
+it starts to track.
+
+Once one of those two commands has been utilized, other regzbot commands can be
+used. You can write them below one of the `introduced` commands or in replies to
+the mail that used one of them or itself is a reply to that mail:
+
+ * Set or update the title::
+
+ #regzbot title: foo
+
+ * Link to a related discussion (for example the posting of a patch to fix the
+ issue) and monitor it::
+
+ #regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ Monitoring only works for lore.kernel.org; regzbot will consider all messages
+ in that thread as related to the fixing process.
+
+ * Point to a place with further details, like a bug-tracker or a related
+ mailing list post::
+
+ #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
+
+ * Mark a regression as fixed by a commit that is heading upstream or already
+ landed::
+
+ #regzbot fixed-by: 1f2e3d4c5d
+
+ * Mark a regression as a duplicate of another one already tracked by regzbot::
+
+ #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
+
+ * Mark a regression as invalid::
+
+ #regzbot invalid: wasn't a regression, problem has always existed
+
+Is there more to tell about regzbot and its commands?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+More detailed and up-to-date information about the Linux kernels regression
+tracking bot can be found on its `project page <https://gitlab.com/knurd42/regzbot>`_,
+which among others contains a
+`getting started guide <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
+and `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
+which both are more in-depth.
+
+
+Quotes from Linus about regression
+----------------------------------
+
+Find below a few real life examples of how Linus Torvalds expects regressions to
+be handled:
+
+ * From `2017-10-26 (1/2) <https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_::
+
+ If you break existing user space setups THAT IS A REGRESSION.
+
+ It's not ok to say "but we'll fix the user space setup".
+
+ Really. NOT OK.
+
+ [...]
+
+ The first rule is:
+
+ - we don't cause regressions
+
+ and the corollary is that when regressions *do* occur, we admit to
+ them and fix them, instead of blaming user space.
+
+ The fact that you have apparently been denying the regression now for
+ three weeks means that I will revert, and I will stop pulling apparmor
+ requests until the people involved understand how kernel development
+ is done.
+
+ * From `2017-10-26 (2/2) <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_::
+
+ People should basically always feel like they can update their kernel
+ and simply not have to worry about it.
+
+ I refuse to introduce "you can only update the kernel if you also
+ update that other program" kind of limitations. If the kernel used to
+ work for you, the rule is that it continues to work for you.
+
+ There have been exceptions, but they are few and far between, and they
+ generally have some major and fundamental reasons for having happened,
+ that were basically entirely unavoidable, and people _tried_hard_ to
+ avoid them. Maybe we can't practically support the hardware any more
+ after it is decades old and nobody uses it with modern kernels any
+ more. Maybe there's a serious security issue with how we did things,
+ and people actually depended on that fundamentally broken model. Maybe
+ there was some fundamental other breakage that just _had_ to have a
+ flag day for very core and fundamental reasons.
+
+ And notice that this is very much about *breaking* peoples environments.
+
+ Behavioral changes happen, and maybe we don't even support some
+ feature any more. There's a number of fields in /proc/<pid>/stat that
+ are printed out as zeroes, simply because they don't even *exist* in
+ the kernel any more, or because showing them was a mistake (typically
+ an information leak). But the numbers got replaced by zeroes, so that
+ the code that used to parse the fields still works. The user might not
+ see everything they used to see, and so behavior is clearly different,
+ but things still _work_, even if they might no longer show sensitive
+ (or no longer relevant) information.
+
+ But if something actually breaks, then the change must get fixed or
+ reverted. And it gets fixed in the *kernel*. Not by saying "well, fix
+ your user space then". It was a kernel change that exposed the
+ problem, it needs to be the kernel that corrects for it, because we
+ have a "upgrade in place" model. We don't have a "upgrade with new
+ user space".
+
+ And I seriously will refuse to take code from people who do not
+ understand and honor this very simple rule.
+
+ This rule is also not going to change.
+
+ And yes, I realize that the kernel is "special" in this respect. I'm
+ proud of it.
+
+ I have seen, and can point to, lots of projects that go "We need to
+ break that use case in order to make progress" or "you relied on
+ undocumented behavior, it sucks to be you" or "there's a better way to
+ do what you want to do, and you have to change to that new better
+ way", and I simply don't think that's acceptable outside of very early
+ alpha releases that have experimental users that know what they signed
+ up for. The kernel hasn't been in that situation for the last two
+ decades.
+
+ We do API breakage _inside_ the kernel all the time. We will fix
+ internal problems by saying "you now need to do XYZ", but then it's
+ about internal kernel API's, and the people who do that then also
+ obviously have to fix up all the in-kernel users of that API. Nobody
+ can say "I now broke the API you used, and now _you_ need to fix it
+ up". Whoever broke something gets to fix it too.
+
+ And we simply do not break user space.
+
+ * From `2020-05-21 <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_::
+
+ The rules about regressions have never been about any kind of
+ documented behavior, or where the code lives.
+
+ The rules about regressions are always about "breaks user workflow".
+
+ Users are literally the _only_ thing that matters.
+
+ No amount of "you shouldn't have used this" or "that behavior was
+ undefined, it's your own fault your app broke" or "that used to work
+ simply because of a kernel bug" is at all relevant.
+
+ Now, reality is never entirely black-and-white. So we've had things
+ like "serious security issue" etc that just forces us to make changes
+ that may break user space. But even then the rule is that we don't
+ really have other options that would allow things to continue.
+
+ And obviously, if users take years to even notice that something
+ broke, or if we have sane ways to work around the breakage that
+ doesn't make for too much trouble for users (ie "ok, there are a
+ handful of users, and they can use a kernel command line to work
+ around it" kind of things) we've also been a bit less strict.
+
+ But no, "that was documented to be broken" (whether it's because the
+ code was in staging or because the man-page said something else) is
+ irrelevant. If staging code is so useful that people end up using it,
+ that means that it's basically regular kernel code with a flag saying
+ "please clean this up".
+
+ The other side of the coin is that people who talk about "API
+ stability" are entirely wrong. API's don't matter either. You can make
+ any changes to an API you like - as long as nobody notices.
+
+ Again, the regression rule is not about documentation, not about
+ API's, and not about the phase of the moon.
+
+ It's entirely about "we caused problems for user space that used to work".
+
+ * From `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_::
+
+ > Now this got me wondering if Debian _unstable_ actually qualifies as a
+ > standard distro userspace.
+
+ Oh, if the kernel breaks some standard user space, that counts. Tons
+ of people run Debian unstable (and from my limited interactions with
+ it, for damn good reasons: -stable tends to run so old versions of
+ everything that you have to sometimes deal with cuneiform writing when
+ using it)
+
+ * From `2017-11-05 <https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_::
+
+ And our regression rule has never been "behavior doesn't change".
+ That would mean that we could never make any changes at all.
+
+ For example, we do things like add new error handling etc all the
+ time, which we then sometimes even add tests for in our kselftest
+ directory.
+
+ So clearly behavior changes all the time and we don't consider that a
+ regression per se.
+
+ The rule for a regression for the kernel is that some real user
+ workflow breaks. Not some test. Not a "look, I used to be able to do
+ X, now I can't".
+
+ * From `2018-08-03 <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_::
+
+ YOU ARE MISSING THE #1 KERNEL RULE.
+
+ We do not regress, and we do not regress exactly because your are 100% wrong.
+
+ And the reason you state for your opinion is in fact exactly *WHY* you
+ are wrong.
+
+ Your "good reasons" are pure and utter garbage.
+
+ The whole point of "we do not regress" is so that people can upgrade
+ the kernel and never have to worry about it.
+
+ > Kernel had a bug which has been fixed
+
+ That is *ENTIRELY* immaterial.
+
+ Guys, whether something was buggy or not DOES NOT MATTER.
+
+ Why?
+
+ Bugs happen. That's a fact of life. Arguing that "we had to break
+ something because we were fixing a bug" is completely insane. We fix
+ tens of bugs every single day, thinking that "fixing a bug" means that
+ we can break something is simply NOT TRUE.
+
+ So bugs simply aren't even relevant to the discussion. They happen,
+ they get found, they get fixed, and it has nothing to do with "we
+ break users".
+
+ Because the only thing that matters IS THE USER.
+
+ How hard is that to understand?
+
+ Anybody who uses "but it was buggy" as an argument is entirely missing
+ the point. As far as the USER was concerned, it wasn't buggy - it
+ worked for him/her.
+
+ Maybe it worked *because* the user had taken the bug into account,
+ maybe it worked because the user didn't notice - again, it doesn't
+ matter. It worked for the user.
+
+ Breaking a user workflow for a "bug" is absolutely the WORST reason
+ for breakage you can imagine.
+
+ It's basically saying "I took something that worked, and I broke it,
+ but now it's better". Do you not see how f*cking insane that statement
+ is?
+
+ And without users, your program is not a program, it's a pointless
+ piece of code that you might as well throw away.
+
+ Seriously. This is *why* the #1 rule for kernel development is "we
+ don't break users". Because "I fixed a bug" is absolutely NOT AN
+ ARGUMENT if that bug fix broke a user setup. You actually introduced a
+ MUCH BIGGER bug by "fixing" something that the user clearly didn't
+ even care about.
+
+ And dammit, we upgrade the kernel ALL THE TIME without upgrading any
+ other programs at all. It is absolutely required, because flag-days
+ and dependencies are horribly bad.
+
+ And it is also required simply because I as a kernel developer do not
+ upgrade random other tools that I don't even care about as I develop
+ the kernel, and I want any of my users to feel safe doing the same
+ time.
+
+ So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel
+ without upgrading some other random binary, then we have a problem.
+
+ * From `2021-06-05 <https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_::
+
+ THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS.
+
+ Honestly, security people need to understand that "not working" is not
+ a success case of security. It's a failure case.
+
+ Yes, "not working" may be secure. But security in that case is *pointless*.
+
+ * From `2021-07-30 <https://lore.kernel.org/lkml/CAHk-=witY33b-vqqp=ApqyoFDpx9p+n4PwG9N-TvF8bq7-tsHw@mail.gmail.com/>`_::
+
+ But we have the policy that regressions aren't about documentation or
+ even sane behavior.
+
+ Regressions are about whether a user application broke in a noticeable way.
+
+ * From `2011-05-06 (1/3) <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_::
+
+ Binary compatibility is more important.
+
+ And if binaries don't use the interface to parse the format (or just
+ parse it wrongly - see the fairly recent example of adding uuid's to
+ /proc/self/mountinfo), then it's a regression.
+
+ And regressions get reverted, unless there are security issues or
+ similar that makes us go "Oh Gods, we really have to break things".
+
+ I don't understand why this simple logic is so hard for some kernel
+ developers to understand. Reality matters. Your personal wishes matter
+ NOT AT ALL.
+
+ If you made an interface that can be used without parsing the
+ interface description, then we're stuck with the interface. Theory
+ simply doesn't matter.
+
+ You could help fix the tools, and try to avoid the compatibility
+ issues that way. There aren't that many of them.
+
+ * From `2011-05-06 (2/3) <https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_::
+
+ it's clearly NOT an internal tracepoint. By definition. It's being
+ used by powertop.
+
+ * From `2011-05-06 (3/3) <https://lore.kernel.org/all/BANLkTinazaXRdGovYL7rRVp+j6HbJ7pzhg@mail.gmail.com/>`_::
+
+ We have programs that use that ABI and thus it's a regression if they break.
+
+ * From `2006-02-21 <https://lore.kernel.org/lkml/Pine.LNX.4.64.0602211631310.30245@g5.osdl.org/>`_::
+
+ The fact is, if changing the kernel breaks user-space, it's a regression.
+ IT DOES NOT MATTER WHETHER IT'S IN /sbin/hotplug OR ANYTHING ELSE. If it
+ was installed by a distribution, it's user-space. If it got installed by
+ "vmlinux", it's the kernel.
+
+ The only piece of user-space code we ship with the kernel is the system
+ call trampoline etc that the kernel sets up. THOSE interfaces we can
+ really change, because it changes with the kernel.
+
+ * From `2019-09-15 <https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_::
+
+ One _particularly_ last-minute revert is the top-most commit (ignoring
+ the version change itself) done just before the release, and while
+ it's very annoying, it's perhaps also instructive.
+
+ What's instructive about it is that I reverted a commit that wasn't
+ actually buggy. In fact, it was doing exactly what it set out to do,
+ and did it very well. In fact it did it _so_ well that the much
+ improved IO patterns it caused then ended up revealing a user-visible
+ regression due to a real bug in a completely unrelated area.
+
+ The actual details of that regression are not the reason I point that
+ revert out as instructive, though. It's more that it's an instructive
+ example of what counts as a regression, and what the whole "no
+ regressions" kernel rule means. The reverted commit didn't change any
+ API's, and it didn't introduce any new bugs. But it ended up exposing
+ another problem, and as such caused a kernel upgrade to fail for a
+ user. So it got reverted.
+
+ The point here being that we revert based on user-reported _behavior_,
+ not based on some "it changes the ABI" or "it caused a bug" concept.
+ The problem was really pre-existing, and it just didn't happen to
+ trigger before. The better IO patterns introduced by the change just
+ happened to expose an old bug, and people had grown to depend on the
+ previously benign behavior of that old issue.
+
+ And never fear, we'll re-introduce the fix that improved on the IO
+ patterns once we've decided just how to handle the fact that we had a
+ bad interaction with an interface that people had then just happened
+ to rely on incidental behavior for before. It's just that we'll have
+ to hash through how to do that (there are no less than three different
+ patches by three different developers being discussed, and there might
+ be more coming...). In the meantime, I reverted the thing that exposed
+ the problem to users for this release, even if I hope it will be
+ re-introduced (perhaps even backported as a stable patch) once we have
+ consensus about the issue it exposed.
+
+ Take-away from the whole thing: it's not about whether you change the
+ kernel-userspace ABI, or fix a bug, or about whether the old code
+ "should never have worked in the first place". It's about whether
+ something breaks existing users' workflow.
+
+ Anyway, that was my little aside on the whole regression thing. Since
+ it's that "first rule of kernel programming", I felt it is perhaps
+ worth just bringing it up every once in a while.
diff --git a/MAINTAINERS b/MAINTAINERS
index 27a83bb940d4..1b740c922867 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10351,6 +10351,7 @@ KERNEL REGRESSIONS
M: Thorsten Leemhuis <linux@leemhuis.info>
L: regressions@lists.linux.dev
S: Supported
+F: Documentation/admin-guide/regressions.rst
KERNEL SELFTEST FRAMEWORK
M: Shuah Khan <shuah@kernel.org>
--
2.31.1
^ permalink raw reply related [relevance 7%]
* Re: Bouncing messages from linux-staging@lists.linux.dev
@ 2021-05-07 11:42 7% ` Greg KH
2021-05-07 14:32 7% ` Fabio Aiuto
0 siblings, 1 reply; 200+ results
From: Greg KH @ 2021-05-07 11:42 UTC (permalink / raw)
To: Fabio Aiuto; +Cc: linux-staging
On Fri, May 07, 2021 at 11:08:27AM +0200, Fabio Aiuto wrote:
> Hi all,
>
> On Fri, May 07, 2021 at 08:30:01AM +0000, linux-staging+owner@lists.linux.dev wrote:
> > Greetings!
> >
> > This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> > mailing list.
> >
> > Some messages to you could not be delivered. If you're seeing this
> > message it means things are back to normal, and it's merely for your
> > information.
> >
> > Here is the list of the bounced messages:
> > - 2608
> >
> >
>
> what I'm supposed to do now if I'd want to retrieve the bounced message?
What do you mean by "retrieve"?
^ permalink raw reply [relevance 7%]
* Re: Bouncing messages from linux-staging@lists.linux.dev
2021-05-07 11:42 7% ` Greg KH
@ 2021-05-07 14:32 7% ` Fabio Aiuto
2021-05-07 16:10 7% ` Dan Carpenter
0 siblings, 1 reply; 200+ results
From: Fabio Aiuto @ 2021-05-07 14:32 UTC (permalink / raw)
To: Greg KH; +Cc: linux-staging
On Fri, May 07, 2021 at 01:42:32PM +0200, Greg KH wrote:
> On Fri, May 07, 2021 at 11:08:27AM +0200, Fabio Aiuto wrote:
> > Hi all,
> >
> > On Fri, May 07, 2021 at 08:30:01AM +0000, linux-staging+owner@lists.linux.dev wrote:
> > > Greetings!
> > >
> > > This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> > > mailing list.
> > >
> > > Some messages to you could not be delivered. If you're seeing this
> > > message it means things are back to normal, and it's merely for your
> > > information.
> > >
> > > Here is the list of the bounced messages:
> > > - 2608
> > >
> > >
> >
> > what I'm supposed to do now if I'd want to retrieve the bounced message?
>
> What do you mean by "retrieve"?
bring back home the message 2608 which is a message to me that could
not be delivered. I mean, a message sent to me which was never delivered...
If I didn't misunderstand.
thank you,
fabio
^ permalink raw reply [relevance 7%]
* Re: Bouncing messages from linux-staging@lists.linux.dev
2021-05-07 14:32 7% ` Fabio Aiuto
@ 2021-05-07 16:10 7% ` Dan Carpenter
2021-05-07 16:31 7% ` Fabio Aiuto
0 siblings, 1 reply; 200+ results
From: Dan Carpenter @ 2021-05-07 16:10 UTC (permalink / raw)
To: Fabio Aiuto; +Cc: Greg KH, linux-staging
On Fri, May 07, 2021 at 04:32:02PM +0200, Fabio Aiuto wrote:
> On Fri, May 07, 2021 at 01:42:32PM +0200, Greg KH wrote:
> > On Fri, May 07, 2021 at 11:08:27AM +0200, Fabio Aiuto wrote:
> > > Hi all,
> > >
> > > On Fri, May 07, 2021 at 08:30:01AM +0000, linux-staging+owner@lists.linux.dev wrote:
> > > > Greetings!
> > > >
> > > > This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> > > > mailing list.
> > > >
> > > > Some messages to you could not be delivered. If you're seeing this
> > > > message it means things are back to normal, and it's merely for your
> > > > information.
> > > >
> > > > Here is the list of the bounced messages:
> > > > - 2608
> > > >
> > > >
> > >
> > > what I'm supposed to do now if I'd want to retrieve the bounced message?
> >
> > What do you mean by "retrieve"?
>
> bring back home the message 2608 which is a message to me that could
> not be delivered. I mean, a message sent to me which was never delivered...
>
> If I didn't misunderstand.
Just ignore it. We all got the same message. If it's really important
people will resend.
regards,
dan carpenter
^ permalink raw reply [relevance 7%]
* Re: Bouncing messages from linux-staging@lists.linux.dev
2021-05-07 16:10 7% ` Dan Carpenter
@ 2021-05-07 16:31 7% ` Fabio Aiuto
0 siblings, 0 replies; 200+ results
From: Fabio Aiuto @ 2021-05-07 16:31 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Greg KH, linux-staging
On Fri, May 07, 2021 at 07:10:34PM +0300, Dan Carpenter wrote:
> On Fri, May 07, 2021 at 04:32:02PM +0200, Fabio Aiuto wrote:
> > On Fri, May 07, 2021 at 01:42:32PM +0200, Greg KH wrote:
> > > On Fri, May 07, 2021 at 11:08:27AM +0200, Fabio Aiuto wrote:
> > > > Hi all,
> > > >
> > > > On Fri, May 07, 2021 at 08:30:01AM +0000, linux-staging+owner@lists.linux.dev wrote:
> > > > > Greetings!
> > > > >
> > > > > This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> > > > > mailing list.
> > > > >
> > > > > Some messages to you could not be delivered. If you're seeing this
> > > > > message it means things are back to normal, and it's merely for your
> > > > > information.
> > > > >
> > > > > Here is the list of the bounced messages:
> > > > > - 2608
> > > > >
> > > > >
> > > >
> > > > what I'm supposed to do now if I'd want to retrieve the bounced message?
> > >
> > > What do you mean by "retrieve"?
> >
> > bring back home the message 2608 which is a message to me that could
> > not be delivered. I mean, a message sent to me which was never delivered...
> >
> > If I didn't misunderstand.
>
> Just ignore it. We all got the same message. If it's really important
> people will resend.
>
> regards,
> dan carpenter
>
got it, thank you all,
fabio
^ permalink raw reply [relevance 7%]
* Re: Post to linux-staging@lists.linux.dev denied: [PATCH] staging: rtl8723bs: os_dep: remove unused variable
@ 2021-08-04 13:56 7% ` Greg KH
2021-08-04 17:20 7% ` SAURAV GIREPUNJE
0 siblings, 1 reply; 200+ results
From: Greg KH @ 2021-08-04 13:56 UTC (permalink / raw)
To: SAURAV GIREPUNJE
Cc: fabioaiuto83, marcocesati, ross.schm.dev, insafonov,
linux-staging, saurav.girepunje, moun.girepunje
On Wed, Aug 04, 2021 at 07:15:05PM +0530, SAURAV GIREPUNJE wrote:
> On Wed, Aug 04, 2021 at 12:57:04PM +0000, linux-staging+owner@lists.linux.dev wrote:
> > Greetings!
> >
> > This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> > mailing list.
> >
> > The message from <saurav.girepunje@gmail.com> with subject "[PATCH]
> > staging: rtl8723bs: os_dep: remove unused variable" was unable to be
> > delivered to the list because the list address was not found in either the
> > To: or CC: header.
> >
> > (The denied message is below.)
>
> > Date: Wed, 4 Aug 2021 18:26:57 +0530
> > From: Saurav Girepunje <saurav.girepunje@gmail.com>
> > To: gregkh@linuxfoundation.org;, fabioaiuto83@gmail.com;,
> > saurav.girepunje@gmail.com;, marcocesati@gmail.com;,
> > ross.schm.dev@gmail.com;, insafonov@gmail.com;,
> > linux-staging@lists.linux.dev;, linux-kernel@vger.kernel.org;
> > Cc: saurav.girepunje@hotmail.com
Why do you have ";" in your email addresses here?
Try removing them.
^ permalink raw reply [relevance 7%]
* Re: Post to linux-staging@lists.linux.dev denied: [PATCH] staging: rtl8723bs: os_dep: remove unused variable
2021-08-04 13:56 7% ` Greg KH
@ 2021-08-04 17:20 7% ` SAURAV GIREPUNJE
2021-08-05 11:04 7% ` Greg KH
0 siblings, 1 reply; 200+ results
From: SAURAV GIREPUNJE @ 2021-08-04 17:20 UTC (permalink / raw)
To: Greg KH
Cc: fabioaiuto83, marcocesati, ross.schm.dev, insafonov,
linux-staging, saurav.girepunje
On Wed, Aug 04, 2021 at 03:56:00PM +0200, Greg KH wrote:
> On Wed, Aug 04, 2021 at 07:15:05PM +0530, SAURAV GIREPUNJE wrote:
> > On Wed, Aug 04, 2021 at 12:57:04PM +0000, linux-staging+owner@lists.linux.dev wrote:
> > > Greetings!
> > >
> > > This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> > > mailing list.
> > >
> > > The message from <saurav.girepunje@gmail.com> with subject "[PATCH]
> > > staging: rtl8723bs: os_dep: remove unused variable" was unable to be
> > > delivered to the list because the list address was not found in either the
> > > To: or CC: header.
> > >
> > > (The denied message is below.)
> >
> > > Date: Wed, 4 Aug 2021 18:26:57 +0530
> > > From: Saurav Girepunje <saurav.girepunje@gmail.com>
> > > To: gregkh@linuxfoundation.org;, fabioaiuto83@gmail.com;,
> > > saurav.girepunje@gmail.com;, marcocesati@gmail.com;,
> > > ross.schm.dev@gmail.com;, insafonov@gmail.com;,
> > > linux-staging@lists.linux.dev;, linux-kernel@vger.kernel.org;
> > > Cc: saurav.girepunje@hotmail.com
>
> Why do you have ";" in your email addresses here?
>
> Try removing them.
Thanks Greg, That was the problem.
^ permalink raw reply [relevance 7%]
* Re: Post to linux-staging@lists.linux.dev denied: [PATCH] staging: rtl8723bs: os_dep: remove unused variable
2021-08-04 17:20 7% ` SAURAV GIREPUNJE
@ 2021-08-05 11:04 7% ` Greg KH
2021-08-07 4:14 7% ` SAURAV GIREPUNJE
0 siblings, 1 reply; 200+ results
From: Greg KH @ 2021-08-05 11:04 UTC (permalink / raw)
To: SAURAV GIREPUNJE
Cc: fabioaiuto83, marcocesati, ross.schm.dev, insafonov,
linux-staging, saurav.girepunje
On Wed, Aug 04, 2021 at 10:50:36PM +0530, SAURAV GIREPUNJE wrote:
> On Wed, Aug 04, 2021 at 03:56:00PM +0200, Greg KH wrote:
> > On Wed, Aug 04, 2021 at 07:15:05PM +0530, SAURAV GIREPUNJE wrote:
> > > On Wed, Aug 04, 2021 at 12:57:04PM +0000, linux-staging+owner@lists.linux.dev wrote:
> > > > Greetings!
> > > >
> > > > This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> > > > mailing list.
> > > >
> > > > The message from <saurav.girepunje@gmail.com> with subject "[PATCH]
> > > > staging: rtl8723bs: os_dep: remove unused variable" was unable to be
> > > > delivered to the list because the list address was not found in either the
> > > > To: or CC: header.
> > > >
> > > > (The denied message is below.)
> > >
> > > > Date: Wed, 4 Aug 2021 18:26:57 +0530
> > > > From: Saurav Girepunje <saurav.girepunje@gmail.com>
> > > > To: gregkh@linuxfoundation.org;, fabioaiuto83@gmail.com;,
> > > > saurav.girepunje@gmail.com;, marcocesati@gmail.com;,
> > > > ross.schm.dev@gmail.com;, insafonov@gmail.com;,
> > > > linux-staging@lists.linux.dev;, linux-kernel@vger.kernel.org;
> > > > Cc: saurav.girepunje@hotmail.com
> >
> > Why do you have ";" in your email addresses here?
> >
> > Try removing them.
>
>
> Thanks Greg, That was the problem.
>
Can you resend all of your pending patches in the proper way, in a patch
series, so I know what to apply and in what order they should be applied
in? Right now I have a bunch that never made it to a public list, and I
can not take them, so I will just drop all patches from you that are
pending in my queue to make it obvious what I need to review.
thanks,
greg k-h
^ permalink raw reply [relevance 7%]
* Re: Post to linux-staging@lists.linux.dev denied: [PATCH] staging: rtl8723bs: os_dep: remove unused variable
2021-08-05 11:04 7% ` Greg KH
@ 2021-08-07 4:14 7% ` SAURAV GIREPUNJE
0 siblings, 0 replies; 200+ results
From: SAURAV GIREPUNJE @ 2021-08-07 4:14 UTC (permalink / raw)
To: Greg KH
Cc: fabioaiuto83, marcocesati, ross.schm.dev, insafonov,
linux-staging, saurav.girepunje
On Thu, Aug 05, 2021 at 01:04:07PM +0200, Greg KH wrote:
> On Wed, Aug 04, 2021 at 10:50:36PM +0530, SAURAV GIREPUNJE wrote:
> > On Wed, Aug 04, 2021 at 03:56:00PM +0200, Greg KH wrote:
> > > On Wed, Aug 04, 2021 at 07:15:05PM +0530, SAURAV GIREPUNJE wrote:
> > > > On Wed, Aug 04, 2021 at 12:57:04PM +0000, linux-staging+owner@lists.linux.dev wrote:
> > > > > Greetings!
> > > > >
> > > > > This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> > > > > mailing list.
> > > > >
> > > > > The message from <saurav.girepunje@gmail.com> with subject "[PATCH]
> > > > > staging: rtl8723bs: os_dep: remove unused variable" was unable to be
> > > > > delivered to the list because the list address was not found in either the
> > > > > To: or CC: header.
> > > > >
> > > > > (The denied message is below.)
> > > >
> > > > > Date: Wed, 4 Aug 2021 18:26:57 +0530
> > > > > From: Saurav Girepunje <saurav.girepunje@gmail.com>
> > > > > To: gregkh@linuxfoundation.org;, fabioaiuto83@gmail.com;,
> > > > > saurav.girepunje@gmail.com;, marcocesati@gmail.com;,
> > > > > ross.schm.dev@gmail.com;, insafonov@gmail.com;,
> > > > > linux-staging@lists.linux.dev;, linux-kernel@vger.kernel.org;
> > > > > Cc: saurav.girepunje@hotmail.com
> > >
> > > Why do you have ";" in your email addresses here?
> > >
> > > Try removing them.
> >
> >
> > Thanks Greg, That was the problem.
> >
>
> Can you resend all of your pending patches in the proper way, in a patch
> series, so I know what to apply and in what order they should be applied
> in? Right now I have a bunch that never made it to a public list, and I
> can not take them, so I will just drop all patches from you that are
> pending in my queue to make it obvious what I need to review.
>
> thanks,
>
> greg k-h
Yes, I will resend all the patch.
^ permalink raw reply [relevance 7%]
* Re: Invitation: [PATCH] staging: rtl8723bs: remove possible deadlock when... @ Sat 2021-09-11 05:30 - 06:30 (CEST) (linux-staging@lists.linux.dev)
@ 2021-09-11 5:08 7% ` Fabio M. De Francesco
0 siblings, 0 replies; 200+ results
From: Fabio M. De Francesco @ 2021-09-11 5:08 UTC (permalink / raw)
To: linux-staging
On Saturday, September 11, 2021 5:09:43 AM CEST fmdefrancesco@gmail.com
wrote:
> You have been invited to the following event.
>
> Title: [PATCH] staging: rtl8723bs: remove possible deadlock when disconnect
Sorry, please disregard this invitation. I inadvertently messed up with my
Google Calendar.
Thanks,
Fabio
^ permalink raw reply [relevance 7%]
* Re: PSA: the linux-kernel-mentees list is migrating to lists.linux.dev
@ 2023-11-07 18:37 7% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-07 18:37 UTC (permalink / raw)
To: linux-kernel-mentees
On Wed, 1 Nov 2023 at 15:47, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> *On November 7*, The linux-kernel-mentees list will be migrated to live on
> lists.linux.dev, but the impact of this move should be minor:
This work is now complete. This message is partly a test to ensure
that delivery to the old address still works. There will also be
another test message to make sure the *new* address works as well.
To remind everyone, this is the impact of this change:
> 1. The new canonical list address will be linux-kernel-mentees@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The archive on https://lore.kernel.org/linux-kernel-mentees/ will be
> automatically updated to track the new list address.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <linux-kernel-mentees.lists.linuxfoundation.org>
> after: List-Id: <linux-kernel-mentees.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after November 7).
>
> 6. The mailman footer will no longer be added to message bodies.
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
The archives on lore.kernel.org/linux-kernel-mentees should be
tracking the new list location as well.
With any concerns or problems, please reach out to helpdesk@kernel.org.
Best regards,
-K
^ permalink raw reply [relevance 7%]
* The new list address is: linux-kernel-mentees@lists.linux.dev (old one still works)
@ 2023-11-07 18:40 7% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-07 18:40 UTC (permalink / raw)
To: linux-kernel-mentees
Hello:
This is a test of the new list address. Please update any of your address
books to reflect this change, but keep in mind that the old address should
continue to work for the foreseeable future.
-K
^ permalink raw reply [relevance 7%]
* [merged mm-hotfixes-stable] maintainers-change-vmwarecom-addresses-to-broadcomcom.patch removed from -mm tree
@ 2024-04-05 18:22 7% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-04-05 18:22 UTC (permalink / raw)
To: mm-commits, vishnu.dasa, vishal.bhakta, ronak.doshi, nick.shi,
gregkh, florian.fainelli, bryan-bt.tan, ajay.kaher,
alexey.makhalov, akpm
The quilt patch titled
Subject: MAINTAINERS: change vmware.com addresses to broadcom.com
has been removed from the -mm tree. Its filename was
maintainers-change-vmwarecom-addresses-to-broadcomcom.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Alexey Makhalov <alexey.makhalov@broadcom.com>
Subject: MAINTAINERS: change vmware.com addresses to broadcom.com
Date: Tue, 2 Apr 2024 16:23:34 -0700
Update all remaining vmware.com email addresses to actual broadcom.com.
Add corresponding .mailmap entries for maintainers who contributed in the
past as the vmware.com address will start bouncing soon.
Maintainership update. Jeff Sipek has left VMware, Nick Shi will be
maintaining VMware PTP.
Link: https://lkml.kernel.org/r/20240402232334.33167-1-alexey.makhalov@broadcom.com
Signed-off-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Ajay Kaher <ajay.kaher@broadcom.com>
Acked-by: Ronak Doshi <ronak.doshi@broadcom.com>
Acked-by: Nick Shi <nick.shi@broadcom.com>
Acked-by: Bryan Tan <bryan-bt.tan@broadcom.com>
Acked-by: Vishnu Dasa <vishnu.dasa@broadcom.com>
Acked-by: Vishal Bhakta <vishal.bhakta@broadcom.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
.mailmap | 5 +++++
MAINTAINERS | 46 +++++++++++++++++++++++-----------------------
2 files changed, 28 insertions(+), 23 deletions(-)
--- a/.mailmap~maintainers-change-vmwarecom-addresses-to-broadcomcom
+++ a/.mailmap
@@ -20,6 +20,7 @@ Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.com>
Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com>
Adrian Bunk <bunk@stusta.de>
+Ajay Kaher <ajay.kaher@broadcom.com> <akaher@vmware.com>
Akhil P Oommen <quic_akhilpo@quicinc.com> <akhilpo@codeaurora.org>
Alan Cox <alan@lxorguk.ukuu.org.uk>
Alan Cox <root@hraefn.swansea.linux.org.uk>
@@ -36,6 +37,7 @@ Alexei Avshalom Lazar <quic_ailizaro@qui
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
+Alexey Makhalov <alexey.amakhalov@broadcom.com> <amakhalov@vmware.com>
Alex Hung <alexhung@gmail.com> <alex.hung@canonical.com>
Alex Shi <alexs@kernel.org> <alex.shi@intel.com>
Alex Shi <alexs@kernel.org> <alex.shi@linaro.org>
@@ -110,6 +112,7 @@ Brendan Higgins <brendan.higgins@linux.d
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com>
+Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com>
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org>
Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org>
@@ -529,6 +532,7 @@ Rocky Liao <quic_rjliao@quicinc.com> <rj
Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com>
Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com>
Roman Gushchin <roman.gushchin@linux.dev> <klamm@yandex-team.ru>
+Ronak Doshi <ronak.doshi@broadcom.com> <doshir@vmware.com>
Muchun Song <muchun.song@linux.dev> <songmuchun@bytedance.com>
Muchun Song <muchun.song@linux.dev> <smuchun@gmail.com>
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
@@ -651,6 +655,7 @@ Viresh Kumar <vireshk@kernel.org> <vires
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.org>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.com>
+Vishnu Dasa <vishnu.dasa@broadcom.com> <vdasa@vmware.com>
Vivek Aknurwar <quic_viveka@quicinc.com> <viveka@codeaurora.org>
Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
--- a/MAINTAINERS~maintainers-change-vmwarecom-addresses-to-broadcomcom
+++ a/MAINTAINERS
@@ -16731,9 +16731,9 @@ F: include/uapi/linux/ppdev.h
PARAVIRT_OPS INTERFACE
M: Juergen Gross <jgross@suse.com>
-R: Ajay Kaher <akaher@vmware.com>
-R: Alexey Makhalov <amakhalov@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+R: Ajay Kaher <ajay.kaher@broadcom.com>
+R: Alexey Makhalov <alexey.amakhalov@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: virtualization@lists.linux.dev
L: x86@kernel.org
S: Supported
@@ -23652,9 +23652,9 @@ S: Supported
F: drivers/misc/vmw_balloon.c
VMWARE HYPERVISOR INTERFACE
-M: Ajay Kaher <akaher@vmware.com>
-M: Alexey Makhalov <amakhalov@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Ajay Kaher <ajay.kaher@broadcom.com>
+M: Alexey Makhalov <alexey.amakhalov@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: virtualization@lists.linux.dev
L: x86@kernel.org
S: Supported
@@ -23663,34 +23663,34 @@ F: arch/x86/include/asm/vmware.h
F: arch/x86/kernel/cpu/vmware.c
VMWARE PVRDMA DRIVER
-M: Bryan Tan <bryantan@vmware.com>
-M: Vishnu Dasa <vdasa@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Bryan Tan <bryan-bt.tan@broadcom.com>
+M: Vishnu Dasa <vishnu.dasa@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-rdma@vger.kernel.org
S: Supported
F: drivers/infiniband/hw/vmw_pvrdma/
VMWARE PVSCSI DRIVER
-M: Vishal Bhakta <vbhakta@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Vishal Bhakta <vishal.bhakta@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-scsi@vger.kernel.org
S: Supported
F: drivers/scsi/vmw_pvscsi.c
F: drivers/scsi/vmw_pvscsi.h
VMWARE VIRTUAL PTP CLOCK DRIVER
-M: Jeff Sipek <jsipek@vmware.com>
-R: Ajay Kaher <akaher@vmware.com>
-R: Alexey Makhalov <amakhalov@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Nick Shi <nick.shi@broadcom.com>
+R: Ajay Kaher <ajay.kaher@broadcom.com>
+R: Alexey Makhalov <alexey.amakhalov@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/ptp/ptp_vmw.c
VMWARE VMCI DRIVER
-M: Bryan Tan <bryantan@vmware.com>
-M: Vishnu Dasa <vdasa@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Bryan Tan <bryan-bt.tan@broadcom.com>
+M: Vishnu Dasa <vishnu.dasa@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-kernel@vger.kernel.org
S: Supported
F: drivers/misc/vmw_vmci/
@@ -23705,16 +23705,16 @@ F: drivers/input/mouse/vmmouse.c
F: drivers/input/mouse/vmmouse.h
VMWARE VMXNET3 ETHERNET DRIVER
-M: Ronak Doshi <doshir@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Ronak Doshi <ronak.doshi@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/vmxnet3/
VMWARE VSOCK VMCI TRANSPORT DRIVER
-M: Bryan Tan <bryantan@vmware.com>
-M: Vishnu Dasa <vdasa@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Bryan Tan <bryan-bt.tan@broadcom.com>
+M: Vishnu Dasa <vishnu.dasa@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-kernel@vger.kernel.org
S: Supported
F: net/vmw_vsock/vmci_transport*
_
Patches currently in -mm which might be from alexey.makhalov@broadcom.com are
^ permalink raw reply [relevance 7%]
* [PATCH] MAINTAINERS: refresh LLVM support
@ 2023-11-17 19:24 7% ndesaulniers
0 siblings, 0 replies; 200+ results
From: ndesaulniers @ 2023-11-17 19:24 UTC (permalink / raw)
To: Kees Cook
Cc: Nathan Chancellor, Bill Wendling, Justin Stitt, Tom Rix,
Sami Tolvanen, Miguel Ojeda, Masahiro Yamada, Nicolas Schier,
llvm, linux-kbuild, linux-kernel, Nick Desaulniers
As discussed at the ClangBuiltLinux '23 meetup (co-located with Linux Plumbers
Conf '23), I'll be taking a step back from kernel work to focus on my growing
family and helping Google figure out its libc story. So I think it's time to
formally hand over the reigns to my co-maintainer Nathan.
As such, remove myself from reviewer for:
- CLANG CONTROL FLOW INTEGRITY SUPPORT
- COMPILER ATTRIBUTES
- KERNEL BUILD
For CLANG/LLVM BUILD SUPPORT I'm bumping myself down from maintainer to
reviewer, adding Bill and Justin, and removing Tom (Tom and I confirmed this
via private email; thanks for the work done Tom, ++beers_owed).
It has been my pleasure to work with everyone to improve the toolchain
portability of the Linux kernel, and to help bring LLVM to the table as a
competitor. The work here is not done. I have a few last LLVM patches in the
works to improve stack usage of clang which has been our longest standing open
issue (getting "rm" inline asm constraints to DTRT is part of that). But
looking back I'm incredibly proud of where we are to today relative to where we
were when we started the ClangBuiltLinux journey, and am confident that the
team and processes we have put in place will continue to be successful. I
continue to believe that a rising tide will lift all boats.
I identify first and foremost as a Linux kernel developer, and an LLVM dev
second. May it be a cold day in hell when that changes.
Wake me when you need me.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
MAINTAINERS | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 482d428472e7..1e6692697167 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5076,7 +5076,6 @@ CLANG CONTROL FLOW INTEGRITY SUPPORT
M: Sami Tolvanen <samitolvanen@google.com>
M: Kees Cook <keescook@chromium.org>
R: Nathan Chancellor <nathan@kernel.org>
-R: Nick Desaulniers <ndesaulniers@google.com>
L: llvm@lists.linux.dev
S: Supported
B: https://github.com/ClangBuiltLinux/linux/issues
@@ -5091,8 +5090,9 @@ F: .clang-format
CLANG/LLVM BUILD SUPPORT
M: Nathan Chancellor <nathan@kernel.org>
-M: Nick Desaulniers <ndesaulniers@google.com>
-R: Tom Rix <trix@redhat.com>
+R: Nick Desaulniers <ndesaulniers@google.com>
+R: Bill Wendling <morbo@google.com>
+R: Justin Stitt <justinstitt@google.com>
L: llvm@lists.linux.dev
S: Supported
W: https://clangbuiltlinux.github.io/
@@ -5242,7 +5242,6 @@ F: drivers/platform/x86/compal-laptop.c
COMPILER ATTRIBUTES
M: Miguel Ojeda <ojeda@kernel.org>
-R: Nick Desaulniers <ndesaulniers@google.com>
S: Maintained
F: include/linux/compiler_attributes.h
@@ -11516,7 +11515,6 @@ F: fs/autofs/
KERNEL BUILD + files below scripts/ (unless maintained elsewhere)
M: Masahiro Yamada <masahiroy@kernel.org>
R: Nathan Chancellor <nathan@kernel.org>
-R: Nick Desaulniers <ndesaulniers@google.com>
R: Nicolas Schier <nicolas@fjasle.eu>
L: linux-kbuild@vger.kernel.org
S: Maintained
---
base-commit: 6bc40e44f1ddef16a787f3501b97f1fff909177c
change-id: 20231117-maintainers-88eac4c024a1
Best regards,
--
Nick Desaulniers <ndesaulniers@google.com>
^ permalink raw reply related [relevance 7%]
* [PATCH v2 1/3] Docs/admin-guide/mm/damon/usage: add DAMON debugfs interface deprecation notice
@ 2023-02-10 4:48 7% ` SeongJae Park
0 siblings, 0 replies; 200+ results
From: SeongJae Park @ 2023-02-10 4:48 UTC (permalink / raw)
To: SeongJae Park, Andrew Morton
Cc: Jonathan Corbet, damon, linux-mm, linux-doc, linux-kernel
DAMON debugfs interface has announced to be deprecated after >v5.15 LTS
kernel is released. And, v6.1.y has announced to be an LTS[1].
Though the announcement was there for a while, some people might not
noticed that so far. Also, some users could depend on it and have
problems at movng to the alternative (DAMON sysfs interface).
For such cases, note DAMON debugfs interface as deprecated, and contacts
to ask helps on the document.
[1] https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=332e9121320bc7461b2d3a79665caf153e51732c
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 9237d6a25897..9b823fec974d 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -25,10 +25,12 @@ DAMON provides below interfaces for different users.
interface provides only simple :ref:`statistics <damos_stats>` for the
monitoring results. For detailed monitoring results, DAMON provides a
:ref:`tracepoint <tracepoint>`.
-- *debugfs interface.*
+- *debugfs interface. (DEPRECATED!)*
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
- <sysfs_interface>`. This will be removed after next LTS kernel is released,
- so users should move to the :ref:`sysfs interface <sysfs_interface>`.
+ <sysfs_interface>`. This is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
@@ -487,13 +489,17 @@ the files as above. Above is only for an example.
.. _debugfs_interface:
-debugfs Interface
-=================
+debugfs Interface (DEPRECATED!)
+===============================
.. note::
- DAMON debugfs interface will be removed after next LTS kernel is released, so
- users should move to the :ref:`sysfs interface <sysfs_interface>`.
+ THIS IS DEPRECATED!
+
+ DAMON debugfs interface is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
--
2.25.1
^ permalink raw reply related [relevance 7%]
* [PATCH 1/3] Docs/admin-guide/mm/damon/usage: add DAMON debugfs interface deprecation notice
@ 2023-02-09 19:20 7% ` SeongJae Park
0 siblings, 0 replies; 200+ results
From: SeongJae Park @ 2023-02-09 19:20 UTC (permalink / raw)
To: Andrew Morton
Cc: SeongJae Park, Jonathan Corbet, damon, linux-mm, linux-doc,
linux-kernel
DAMON debugfs interface has announced to be deprecated after >v5.15 LTS
kernel is released. And, v6.1.y has announced to be an LTS[1].
Though the announcement was there for a while, some people might not
noticed that so far. Also, some users could depend on it and have
problems at movng to the alternative (DAMON sysfs interface).
For such cases, note DAMON debugfs interface as deprecated, and contacts
to ask helps on the document.
[1] https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=332e9121320bc7461b2d3a79665caf153e51732c
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 9237d6a25897..9b823fec974d 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -25,10 +25,12 @@ DAMON provides below interfaces for different users.
interface provides only simple :ref:`statistics <damos_stats>` for the
monitoring results. For detailed monitoring results, DAMON provides a
:ref:`tracepoint <tracepoint>`.
-- *debugfs interface.*
+- *debugfs interface. (DEPRECATED!)*
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
- <sysfs_interface>`. This will be removed after next LTS kernel is released,
- so users should move to the :ref:`sysfs interface <sysfs_interface>`.
+ <sysfs_interface>`. This is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
@@ -487,13 +489,17 @@ the files as above. Above is only for an example.
.. _debugfs_interface:
-debugfs Interface
-=================
+debugfs Interface (DEPRECATED!)
+===============================
.. note::
- DAMON debugfs interface will be removed after next LTS kernel is released, so
- users should move to the :ref:`sysfs interface <sysfs_interface>`.
+ THIS IS DEPRECATED!
+
+ DAMON debugfs interface is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
--
2.25.1
^ permalink raw reply related [relevance 7%]
* [I-PIPE] ipipe-core-5.4.198-x86-9 released
@ 2022-06-20 6:11 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-06-20 6:11 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v5.x/x86/ipipe-core-5.4.198-x86-9.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-5.4.198-x86-9
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-4.4.302-cip69-arm-18 released
@ 2022-06-20 6:30 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-06-20 6:30 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v4.x/arm/ipipe-core-4.4.302-cip69-arm-18.patch
Repository: https://git.xenomai.org/ipipe-arm
Release tag: ipipe-core-4.4.302-cip69-arm-18
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-4.4.302-cip69-x86-33 released
@ 2022-06-20 6:30 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-06-20 6:30 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.4.302-cip69-x86-33.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.4.302-cip69-x86-33
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-4.19.246-cip75-x86-22 released
@ 2022-06-20 6:30 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-06-20 6:30 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.19.246-cip75-x86-22.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.19.246-cip75-x86-22
^ permalink raw reply [relevance 7%]
* [DOVETAIL] 5.10.127-dovetail1 released
@ 2022-06-30 16:55 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-06-30 16:55 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/dovetail/patch-5.10.127-dovetail1.patch.bz2
Repository: https://git.xenomai.org/linux-dovetail
Release tag: v5.10.127-dovetail1-rebase
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-4.19.252-cip78-x86-23 released
@ 2022-08-03 4:51 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-08-03 4:51 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.19.252-cip78-x86-23.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.19.252-cip78-x86-23
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-4.4.302-cip70-arm-19 released
@ 2022-08-04 16:25 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-08-04 16:25 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v4.x/arm/ipipe-core-4.4.302-cip70-arm-19.patch
Repository: https://git.xenomai.org/ipipe-arm
Release tag: ipipe-core-4.4.302-cip70-arm-19
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-4.4.302-cip70-x86-34 released
@ 2022-08-04 16:25 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-08-04 16:25 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.4.302-cip70-x86-34.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.4.302-cip70-x86-34
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-5.4.223-x86-11 released
@ 2022-11-16 5:50 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-11-16 5:50 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v5.x/x86/ipipe-core-5.4.223-x86-11.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-5.4.223-x86-11
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-4.19.266-cip86-x86-25 released
@ 2022-12-09 15:58 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2022-12-09 15:58 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.19.266-cip86-x86-25.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.19.266-cip86-x86-25
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-5.4.239-x86-13 released
@ 2023-04-06 19:03 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2023-04-06 19:03 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v5.x/x86/ipipe-core-5.4.239-x86-13.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-5.4.239-x86-13
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-4.19.279-cip95-x86-26 released
@ 2023-04-06 19:03 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2023-04-06 19:03 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.19.279-cip95-x86-26.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.19.279-cip95-x86-26
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-5.4.231-arm-6 released
@ 2023-04-06 19:13 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2023-04-06 19:13 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v5.x/arm/ipipe-core-5.4.231-arm-6.patch
Repository: https://git.xenomai.org/ipipe-arm
Release tag: ipipe-core-5.4.231-arm-6
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-5.4.253-x86-14 released
@ 2023-08-14 19:34 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2023-08-14 19:34 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v5.x/x86/ipipe-core-5.4.253-x86-14.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-5.4.253-x86-14
^ permalink raw reply [relevance 7%]
* [I-PIPE] ipipe-core-4.19.288-cip101-x86-27 released
@ 2023-08-14 19:34 7% xenomai
0 siblings, 0 replies; 200+ results
From: xenomai @ 2023-08-14 19:34 UTC (permalink / raw)
To: xenomai
Download URL: https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.19.288-cip101-x86-27.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.19.288-cip101-x86-27
^ permalink raw reply [relevance 7%]
* Re: Is the data rate estimation for 5GHz channels overly pessimistic?
@ 2023-10-14 17:45 7% ` Simonas Kazlauskas
0 siblings, 1 reply; 200+ results
From: Simonas Kazlauskas @ 2023-10-14 17:45 UTC (permalink / raw)
To: Denis Kenzior; +Cc: James Prestwood, iwd
Denis Kenzior wrote:
>Hi James,
>
>>>
>>> RSSI -78 dBm
>>> AverageRSSI -79 dBm
>>> RxMode 802.11ax
>>> RxMCS 8
>>> TxMode 802.11ax
>>> TxMCS 4
>>> TxBitrate 206400 Kbit/s
>>> RxBitrate 206500 Kbit/s
>>
>>This is probably because IWD doesn't take into account any of the
>>newer 802.11ax IEs when estimating the data rate. So its estimation
>>is based on VHT and not the newest EHT rates.
>
>We should support HE rates just fine. Just look at the unit tests in
>test-band.c. Probably need an iwmon log of the AP IEs and local
>capabilities to see why the estimate is lower than what happens in
>practice.
>
>What hardware is being used here?
Intel’s AX201 on the client side and Ubiquiti’s U6-Pro are the AP(s).
Thank you for pointing me at iwmon, I’ll fiddle with it :)
>
>Regards,
>-Denis
^ permalink raw reply [relevance 7%]
* Re: Is the data rate estimation for 5GHz channels overly pessimistic?
@ 2023-10-16 20:20 7% ` Simonas Kazlauskas
0 siblings, 1 reply; 200+ results
From: Simonas Kazlauskas @ 2023-10-16 20:20 UTC (permalink / raw)
To: James Prestwood; +Cc: iwd, Denis Kenzior
James,
Thank you for implementing the display of HE capabilities in `iwmon` – these do
indeed show up in my scans now, false alert there.
> HE Capabilities: len 34
> HE supported channel width set: bit 1: 40MHz/80MHz supported (5GHz/6GHz)
> Rx HE-MCS Map <= 80MHz 1 Streams: MCS 0-11 supported
> Rx HE-MCS Map <= 80MHz 2 Streams: MCS 0-11 supported
> Rx HE-MCS Map <= 80MHz 3 Streams: MCS 0-11 supported
> Rx HE-MCS Map <= 80MHz 4 Streams: MCS 0-11 supported
> Tx HE-MCS Map <= 80MHz 1 Streams: MCS 0-11 supported
> Tx HE-MCS Map <= 80MHz 2 Streams: MCS 0-11 supported
> Tx HE-MCS Map <= 80MHz 3 Streams: MCS 0-11 supported
> Tx HE-MCS Map <= 80MHz 4 Streams: MCS 0-11 supported
> 0d 01 08 9a 40 10 04 60 48 88 1f 43 81 1c 11 08 ....@..`H..C....
> 00 aa ff aa ff 7b 1c c7 71 1c c7 71 1c c7 71 1c .....{..q..q..q.
> c7 71 .q
I’ve sent you and Denis both the pcap of the scan. I, unforunately, don’t think
I’ll be able to hack on the test and/or data rate investigation much further
before the weekend, but I’m happy to test out patches and such at any time.
Thanks,
S.
^ permalink raw reply [relevance 7%]
* [PATCH v3 2/4] docs/system: Add vhost-user-input documentation
@ 2023-11-20 4:37 7% ` Leo Yan
0 siblings, 0 replies; 200+ results
From: Leo Yan @ 2023-11-20 4:37 UTC (permalink / raw)
To: qemu-devel
Cc: Alex Bennée, Gerd Hoffmann, Michael S . Tsirkin,
Manos Pitsidianakis, Marc-André Lureau, Leo Yan
This adds basic documentation for vhost-user-input.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
MAINTAINERS | 1 +
docs/system/device-emulation.rst | 1 +
docs/system/devices/vhost-user-input.rst | 45 ++++++++++++++++++++++++
docs/system/devices/vhost-user.rst | 4 ++-
4 files changed, 50 insertions(+), 1 deletion(-)
create mode 100644 docs/system/devices/vhost-user-input.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index 0624d67932..8a26fe9493 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2262,6 +2262,7 @@ L: virtio-fs@lists.linux.dev
virtio-input
M: Gerd Hoffmann <kraxel@redhat.com>
S: Odd Fixes
+F: docs/system/devices/vhost-user-input.rst
F: hw/input/vhost-user-input.c
F: hw/input/virtio-input*.c
F: include/hw/virtio/virtio-input.h
diff --git a/docs/system/device-emulation.rst b/docs/system/device-emulation.rst
index d1f3277cb0..f19777411c 100644
--- a/docs/system/device-emulation.rst
+++ b/docs/system/device-emulation.rst
@@ -94,6 +94,7 @@ Emulated Devices
devices/virtio-gpu.rst
devices/virtio-pmem.rst
devices/virtio-snd.rst
+ devices/vhost-user-input.rst
devices/vhost-user-rng.rst
devices/canokey.rst
devices/usb-u2f.rst
diff --git a/docs/system/devices/vhost-user-input.rst b/docs/system/devices/vhost-user-input.rst
new file mode 100644
index 0000000000..118eb78101
--- /dev/null
+++ b/docs/system/devices/vhost-user-input.rst
@@ -0,0 +1,45 @@
+.. _vhost_user_input:
+
+QEMU vhost-user-input - Input emulation
+=======================================
+
+This document describes the setup and usage of the Virtio input device.
+The Virtio input device is a paravirtualized device for input events.
+
+Description
+-----------
+
+The vhost-user-input device implementation was designed to work with a daemon
+polling on input devices and passes input events to the guest.
+
+QEMU provides a backend implementation in contrib/vhost-user-input.
+
+Linux kernel support
+--------------------
+
+Virtio input requires a guest Linux kernel built with the
+``CONFIG_VIRTIO_INPUT`` option.
+
+Examples
+--------
+
+The backend daemon should be started first:
+
+::
+
+ host# vhost-user-input --socket-path=input.sock \
+ --evdev-path=/dev/input/event17
+
+The QEMU invocation needs to create a chardev socket to communicate with the
+backend daemon and access the VirtIO queues with the guest over the
+:ref:`shared memory <shared_memory_object>`.
+
+::
+
+ host# qemu-system \
+ -chardev socket,path=/tmp/input.sock,id=mouse0 \
+ -device vhost-user-input-pci,chardev=mouse0 \
+ -m 4096 \
+ -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
+ -numa node,memdev=mem \
+ ...
diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
index c6afc4836f..9b2da106ce 100644
--- a/docs/system/devices/vhost-user.rst
+++ b/docs/system/devices/vhost-user.rst
@@ -42,7 +42,7 @@ platform details for what sort of virtio bus to use.
- See https://github.com/rust-vmm/vhost-device
* - vhost-user-input
- Generic input driver
- - See contrib/vhost-user-input
+ - :ref:`vhost_user_input`
* - vhost-user-rng
- Entropy driver
- :ref:`vhost_user_rng`
@@ -91,6 +91,8 @@ following the :ref:`vhost_user_proto`. There are a number of daemons
that can be built when enabled by the project although any daemon that
meets the specification for a given device can be used.
+.. _shared_memory_object:
+
Shared memory object
====================
--
2.39.2
^ permalink raw reply related [relevance 7%]
* [PATCH] MAINTAINERS: change vmware.com addresses to broadcom.com
@ 2024-04-02 23:23 7% Alexey Makhalov
0 siblings, 0 replies; 200+ results
From: Alexey Makhalov @ 2024-04-02 23:23 UTC (permalink / raw)
To: linux-kernel, Andrew Morton, Greg Kroah-Hartman
Cc: Alexey Makhalov, Florian Fainelli, Ajay Kaher, Ronak Doshi,
Nick Shi, Bryan Tan, Vishnu Dasa, Vishal Bhakta,
Broadcom internal kernel review list
Update all remaining vmware.com email addresses to actual broadcom.com.
Add corresponding .mailmap entries for maintainers who contributed in the
past as the vmware.com address will start bouncing soon.
Maintainership update. Jeff Sipek has left VMware, Nick Shi will be
maintaining VMware PTP.
Signed-off-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Ajay Kaher <ajay.kaher@broadcom.com>
Acked-by: Ronak Doshi <ronak.doshi@broadcom.com>
Acked-by: Nick Shi <nick.shi@broadcom.com>
Acked-by: Bryan Tan <bryan-bt.tan@broadcom.com>
Acked-by: Vishnu Dasa <vishnu.dasa@broadcom.com>
Acked-by: Vishal Bhakta <vishal.bhakta@broadcom.com>
Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
---
.mailmap | 5 +++++
MAINTAINERS | 46 +++++++++++++++++++++++-----------------------
2 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/.mailmap b/.mailmap
index 59c9a841bf71..8284692f9610 100644
--- a/.mailmap
+++ b/.mailmap
@@ -20,6 +20,7 @@ Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.com>
Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com>
Adrian Bunk <bunk@stusta.de>
+Ajay Kaher <ajay.kaher@broadcom.com> <akaher@vmware.com>
Akhil P Oommen <quic_akhilpo@quicinc.com> <akhilpo@codeaurora.org>
Alan Cox <alan@lxorguk.ukuu.org.uk>
Alan Cox <root@hraefn.swansea.linux.org.uk>
@@ -36,6 +37,7 @@ Alexei Avshalom Lazar <quic_ailizaro@quicinc.com> <ailizaro@codeaurora.org>
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
+Alexey Makhalov <alexey.amakhalov@broadcom.com> <amakhalov@vmware.com>
Alex Hung <alexhung@gmail.com> <alex.hung@canonical.com>
Alex Shi <alexs@kernel.org> <alex.shi@intel.com>
Alex Shi <alexs@kernel.org> <alex.shi@linaro.org>
@@ -110,6 +112,7 @@ Brendan Higgins <brendan.higgins@linux.dev> <brendanhiggins@google.com>
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com>
+Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com>
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org>
Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org>
@@ -529,6 +532,7 @@ Rocky Liao <quic_rjliao@quicinc.com> <rjliao@codeaurora.org>
Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com>
Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com>
Roman Gushchin <roman.gushchin@linux.dev> <klamm@yandex-team.ru>
+Ronak Doshi <ronak.doshi@broadcom.com> <doshir@vmware.com>
Muchun Song <muchun.song@linux.dev> <songmuchun@bytedance.com>
Muchun Song <muchun.song@linux.dev> <smuchun@gmail.com>
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
@@ -651,6 +655,7 @@ Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.org>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.com>
+Vishnu Dasa <vishnu.dasa@broadcom.com> <vdasa@vmware.com>
Vivek Aknurwar <quic_viveka@quicinc.com> <viveka@codeaurora.org>
Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index ae447c08a11d..2658c4cc22b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16731,9 +16731,9 @@ F: include/uapi/linux/ppdev.h
PARAVIRT_OPS INTERFACE
M: Juergen Gross <jgross@suse.com>
-R: Ajay Kaher <akaher@vmware.com>
-R: Alexey Makhalov <amakhalov@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+R: Ajay Kaher <ajay.kaher@broadcom.com>
+R: Alexey Makhalov <alexey.amakhalov@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: virtualization@lists.linux.dev
L: x86@kernel.org
S: Supported
@@ -23666,9 +23666,9 @@ S: Supported
F: drivers/misc/vmw_balloon.c
VMWARE HYPERVISOR INTERFACE
-M: Ajay Kaher <akaher@vmware.com>
-M: Alexey Makhalov <amakhalov@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Ajay Kaher <ajay.kaher@broadcom.com>
+M: Alexey Makhalov <alexey.amakhalov@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: virtualization@lists.linux.dev
L: x86@kernel.org
S: Supported
@@ -23677,34 +23677,34 @@ F: arch/x86/include/asm/vmware.h
F: arch/x86/kernel/cpu/vmware.c
VMWARE PVRDMA DRIVER
-M: Bryan Tan <bryantan@vmware.com>
-M: Vishnu Dasa <vdasa@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Bryan Tan <bryan-bt.tan@broadcom.com>
+M: Vishnu Dasa <vishnu.dasa@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-rdma@vger.kernel.org
S: Supported
F: drivers/infiniband/hw/vmw_pvrdma/
VMWARE PVSCSI DRIVER
-M: Vishal Bhakta <vbhakta@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Vishal Bhakta <vishal.bhakta@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-scsi@vger.kernel.org
S: Supported
F: drivers/scsi/vmw_pvscsi.c
F: drivers/scsi/vmw_pvscsi.h
VMWARE VIRTUAL PTP CLOCK DRIVER
-M: Jeff Sipek <jsipek@vmware.com>
-R: Ajay Kaher <akaher@vmware.com>
-R: Alexey Makhalov <amakhalov@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Nick Shi <nick.shi@broadcom.com>
+R: Ajay Kaher <ajay.kaher@broadcom.com>
+R: Alexey Makhalov <alexey.amakhalov@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/ptp/ptp_vmw.c
VMWARE VMCI DRIVER
-M: Bryan Tan <bryantan@vmware.com>
-M: Vishnu Dasa <vdasa@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Bryan Tan <bryan-bt.tan@broadcom.com>
+M: Vishnu Dasa <vishnu.dasa@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-kernel@vger.kernel.org
S: Supported
F: drivers/misc/vmw_vmci/
@@ -23719,16 +23719,16 @@ F: drivers/input/mouse/vmmouse.c
F: drivers/input/mouse/vmmouse.h
VMWARE VMXNET3 ETHERNET DRIVER
-M: Ronak Doshi <doshir@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Ronak Doshi <ronak.doshi@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/vmxnet3/
VMWARE VSOCK VMCI TRANSPORT DRIVER
-M: Bryan Tan <bryantan@vmware.com>
-M: Vishnu Dasa <vdasa@vmware.com>
-R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
+M: Bryan Tan <bryan-bt.tan@broadcom.com>
+M: Vishnu Dasa <vishnu.dasa@broadcom.com>
+R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-kernel@vger.kernel.org
S: Supported
F: net/vmw_vsock/vmci_transport*
--
2.39.0
^ permalink raw reply related [relevance 7%]
* [PATCH 5.15 1/2] MAINTAINERS: update maintainer list of DMA MAPPING BENCHMARK
@ 2023-08-23 17:57 7% ` Easwar Hariharan
0 siblings, 0 replies; 200+ results
From: Easwar Hariharan @ 2023-08-23 17:57 UTC (permalink / raw)
To: stable; +Cc: Xiang Chen, Barry Song, Christoph Hellwig, open list
From: Xiang Chen <chenxiang66@hisilicon.com>
commit e62c17f0455a74b182ce6373e2777817256afaa1 upstream
Barry Song will not focus on this area, and Xiang Chen will continue his
work to maintain this module.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Acked-by: Barry Song <song.bao.hua@hisilicon.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e6b53e76651b..6c3f7ce19a79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5609,7 +5609,7 @@ F: include/linux/dma-map-ops.h
F: kernel/dma/
DMA MAPPING BENCHMARK
-M: Barry Song <song.bao.hua@hisilicon.com>
+M: Xiang Chen <chenxiang66@hisilicon.com>
L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
--
2.25.1
^ permalink raw reply related [relevance 7%]
* [PATCH] docs: ABI: sysfs-bus-mhi: Update contact info
@ 2023-06-28 18:23 7% Jeffrey Hugo
0 siblings, 0 replies; 200+ results
From: Jeffrey Hugo @ 2023-06-28 18:23 UTC (permalink / raw)
To: mani, andersson; +Cc: mhi, linux-kernel, Jeffrey Hugo
@codeaurora.org email addresses are no longer valid and will bounce to
sender. Also, Bhaumik has previously indicated he is no longer interested
in participating in MHI bus discussions.
Update contact info from Bhaumik to the mhi mail list so that mails will
be routed to the MHI maintainers and interested parties.
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
---
Documentation/ABI/stable/sysfs-bus-mhi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/stable/sysfs-bus-mhi b/Documentation/ABI/stable/sysfs-bus-mhi
index 96ccc3385a2b..1a47f9e0cc84 100644
--- a/Documentation/ABI/stable/sysfs-bus-mhi
+++ b/Documentation/ABI/stable/sysfs-bus-mhi
@@ -1,7 +1,7 @@
What: /sys/bus/mhi/devices/.../serialnumber
Date: Sept 2020
KernelVersion: 5.10
-Contact: Bhaumik Bhatt <bbhatt@codeaurora.org>
+Contact: mhi@lists.linux.dev
Description: The file holds the serial number of the client device obtained
using a BHI (Boot Host Interface) register read after at least
one attempt to power up the device has been done. If read
@@ -12,7 +12,7 @@ Users: Any userspace application or clients interested in device info.
What: /sys/bus/mhi/devices/.../oem_pk_hash
Date: Sept 2020
KernelVersion: 5.10
-Contact: Bhaumik Bhatt <bbhatt@codeaurora.org>
+Contact: mhi@lists.linux.dev
Description: The file holds the OEM PK Hash value of the endpoint device
obtained using a BHI (Boot Host Interface) register read after
at least one attempt to power up the device has been done. If
--
2.40.1
^ permalink raw reply related [relevance 7%]
* [PATCH v2] REAMDE: Announce new mailing list
@ 2021-06-02 6:37 7% Daniel Wagner
0 siblings, 0 replies; 200+ results
From: Daniel Wagner @ 2021-06-02 6:37 UTC (permalink / raw)
To: connman; +Cc: Daniel Wagner
The project moved to a new mailing list hosted by the LF.
The 01.org domain does not longer host any ConnMan related
services. Drop these references also from the README.
---
README | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/README b/README
index e911bc2d6bbd..e36d796c30a7 100644
--- a/README
+++ b/README
@@ -444,10 +444,12 @@ Information
===========
Mailing list:
- connman@connman.net
+ connman@lists.linux.dev
-For additional information about the project visit ConnMan web site:
- https://01.org/connman
- http://www.connman.net
+If you would like to subscribe to receive mail in your inbox, just
+send a (empty) message from your email account to
-You can report bugs at https://01.org/jira/browse/CM
+ connman+subscribe@lists.linux.dev
+
+Maling list archive:
+ https://lore.kernel.org/connman
--
2.31.1
^ permalink raw reply related [relevance 7%]
* [PATCH] dm vdo: add MAINTAINERS file entry
@ 2023-10-26 21:47 7% Matthew Sakai
0 siblings, 0 replies; 200+ results
From: Matthew Sakai @ 2023-10-26 21:47 UTC (permalink / raw)
To: dm-devel, linux-block; +Cc: Matthew Sakai
Signed-off-by: Matthew Sakai <msakai@redhat.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8b17e29a75c8..5357fbe1cc90 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6001,6 +6001,15 @@ F: include/linux/device-mapper.h
F: include/linux/dm-*.h
F: include/uapi/linux/dm-*.h
+DEVICE-MAPPER VDO TARGET
+M: Matthew Sakai <msakai@redhat.com>
+M: dm-devel@lists.linux.dev
+L: dm-devel@lists.linux.dev
+S: Maintained
+F: Documentation/admin-guide/device-mapper/vdo*.rst
+F: drivers/md/dm-vdo-target.c
+F: drivers/md/dm-vdo/
+
DEVLINK
M: Jiri Pirko <jiri@resnulli.us>
L: netdev@vger.kernel.org
--
2.40.0
^ permalink raw reply related [relevance 7%]
* [PATCH v5 40/40] dm vdo: add MAINTAINERS file entry
@ 2023-11-17 20:59 7% ` Matthew Sakai
0 siblings, 0 replies; 200+ results
From: Matthew Sakai @ 2023-11-17 20:59 UTC (permalink / raw)
To: dm-devel; +Cc: Matthew Sakai
Signed-off-by: Matthew Sakai <msakai@redhat.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ce3f9099bf23..7402652ac5a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6002,6 +6002,15 @@ F: include/linux/device-mapper.h
F: include/linux/dm-*.h
F: include/uapi/linux/dm-*.h
+DEVICE-MAPPER VDO TARGET
+M: Matthew Sakai <msakai@redhat.com>
+M: dm-devel@lists.linux.dev
+L: dm-devel@lists.linux.dev
+S: Maintained
+F: Documentation/admin-guide/device-mapper/vdo*.rst
+F: drivers/md/dm-vdo-target.c
+F: drivers/md/dm-vdo/
+
DEVLINK
M: Jiri Pirko <jiri@resnulli.us>
L: netdev@vger.kernel.org
--
2.40.0
^ permalink raw reply related [relevance 7%]
* Updated invitation: Justin Stitt's Intern Presentation @ Wed Aug 17, 2022 10am - 11am (PDT) (llvm@lists.linux.dev)
@ 2022-08-10 19:44 7% Nick Desaulniers
0 siblings, 0 replies; 200+ results
From: Nick Desaulniers @ 2022-08-10 19:44 UTC (permalink / raw)
To: llvm, gosst-kernel, android-llvm-dev, android-kernel-team,
kernel-dynamic-tools, natechancellor, Clang Built Linux,
Sedat Dilek (DHL Supply Chain)
[-- Attachment #1.1: Type: text/plain, Size: 2834 bytes --]
This event has been updated
Changed: location
Justin Stitt's Intern Presentation
Wednesday Aug 17, 2022 ⋅ 10am – 11am
Pacific Time - Los Angeles
Location
UK-LON-6PS-9-C-Camden Town (No Externals Except For Interviews) (8) [GVC],
US-NYC-9TH-11-A-232-It's Too Cold (7) [GVC], US-MTV-PLYM1625-4-A-Aesthetics
(7) [GVC, Phone], US-SAN-6420-4-3-Mt. Soledad (5) [GVC],
US-SVL-CRSM1240-2-Q-Feijoada (4) [GVC], US-MTV-1667-1-N-Hey Jude (8) [GVC,
Phone], DE-MUC-ARN60-G-2-Ochsenbraterei (7) [GVC], CH-ZRH-EURD-6-A-Pruntrut
(5) [GVC]
https://www.google.com/maps/search/UK-LON-6PS-9-C-Camden+Town+(No+Externals+Except+For+Interviews)+(8)+%5BGVC%5D,+US-NYC-9TH-11-A-232-It's+Too+Cold+(7)+%5BGVC%5D,+US-MTV-PLYM1625-4-A-Aesthetics+(7)+%5BGVC,+Phone%5D,+US-SAN-6420-4-3-Mt.+Soledad+(5)+%5BGVC%5D,+US-SVL-CRSM1240-2-Q-Feijoada+(4)+%5BGVC%5D,+US-MTV-1667-1-N-Hey+Jude+(8)+%5BGVC,+Phone%5D,+DE-MUC-ARN60-G-2-Ochsenbraterei+(7)+%5BGVC%5D,+CH-ZRH-EURD-6-A-Pruntrut+(5)+%5BGVC%5D?hl=en
Join with Google Meet
https://meet.google.com/wts-viup-bbu?hs=224
Join by phone
(US) +1 253-289-6982
PIN: 52630526169
More phone numbers
https://tel.meet/wts-viup-bbu?pin=4782004268358&hs=0
Join us for Justin's Intern presentation about work he did over the summer
regarding getting -Wformat enabled in the Linux kernel for Clang, and
profiling/performance work on building the Linux kernel faster with Clang.
Organizer
Nick Desaulniers
ndesaulniers@google.com
Guests
Nick Desaulniers - organizer
gosst-kernel
android-llvm-dev
android-kernel-team
kernel-dynamic-tools
natechancellor@gmail.com
Clang Built Linux
llvm@lists.linux.dev
Sedat Dilek (DHL Supply Chain)
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NGVoYWEyOWkxanEwYjU1cnQzNnJsNm5sOGggbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb204ZjQwMzA4ZDgzMWNkMjM4MzBjMzRjNDg0YmIxOWQ0YzRkMmRlMmMx&ctz=America%2FLos_Angeles&hl=en&es=0
Reply for llvm@lists.linux.dev and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NGVoYWEyOWkxanEwYjU1cnQzNnJsNm5sOGggbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb204ZjQwMzA4ZDgzMWNkMjM4MzBjMzRjNDg0YmIxOWQ0YzRkMmRlMmMx&ctz=America%2FLos_Angeles&hl=en&es=0
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
[-- Attachment #1.2: Type: text/html, Size: 35746 bytes --]
[-- Attachment #1.3: Type: text/calendar, Size: 5199 bytes --]
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220817T170000Z
DTEND:20220817T180000Z
DTSTAMP:20220810T194449Z
ORGANIZER;CN=Nick Desaulniers:mailto:ndesaulniers@google.com
UID:4ehaa29i1jq0b55rt36rl6nl8h@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=gosst-kernel;X-NUM-GUESTS=0:mailto:gosst-kernel@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Nick Desaulniers;X-NUM-GUESTS=0:mailto:ndesaulniers@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=android-llvm-dev;X-NUM-GUESTS=0:mailto:android-llvm-dev@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=android-kernel-team;X-NUM-GUESTS=0:mailto:android-kernel-team@googl
e.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=kernel-dynamic-tools;X-NUM-GUESTS=0:mailto:kernel-dynamic-tools@goo
gle.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=natechancellor@gmail.com;X-NUM-GUESTS=0:mailto:natechancellor@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Clang Built Linux;X-NUM-GUESTS=0:mailto:clang-built-linux@googlegro
ups.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=llvm@lists.linux.dev;X-NUM-GUESTS=0:mailto:llvm@lists.linux.dev
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Sedat Dilek (DHL Supply Chain);X-NUM-GUESTS=0:mailto:sedat.dilek@dhl.co
m
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
UE;CN=UK-LON-6PS-9-C-Camden Town (No Externals Except For Interviews) (8) [
GVC];X-NUM-GUESTS=0:mailto:google.com_726f6f6d5f756b5f6c6f6e5f3670735f395f3
96330@resource.calendar.google.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
UE;CN=US-NYC-9TH-11-A-232-It's Too Cold (7) [GVC];X-NUM-GUESTS=0:mailto:goo
gle.com_726f6f6d5f75735f6e79635f3974685f31315f313161323332@resource.calenda
r.google.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
UE;CN="US-MTV-PLYM1625-4-A-Aesthetics (7) [GVC, Phone]";X-NUM-GUESTS=0:mail
to:google.com_726f6f6d5f75735f6d74765f706c796d313632355f345f346132@resource
.calendar.google.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
UE;CN=US-SAN-6420-4-3-Mt. Soledad (5) [GVC];X-NUM-GUESTS=0:mailto:google.co
m_726f6f6d5f75735f73616e5f363432305f345f343334@resource.calendar.google.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
UE;CN=US-SVL-CRSM1240-2-Q-Feijoada (4) [GVC];X-NUM-GUESTS=0:mailto:google.c
om_726f6f6d5f75735f73766c5f6372736d313234305f325f327133@resource.calendar.g
oogle.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
UE;CN="US-MTV-1667-1-N-Hey Jude (8) [GVC, Phone]";X-NUM-GUESTS=0:mailto:goo
gle.com_726f6f6d5f75735f6d74765f313636375f315f316e34@resource.calendar.goog
le.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
UE;CN=DE-MUC-ARN60-G-2-Ochsenbraterei (7) [GVC];X-NUM-GUESTS=0:mailto:c_188
a6bnqb18uiinrgvr6v18gtg2ua4gactnmuprcckn66rrd@resource.calendar.google.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
UE;CN=CH-ZRH-EURD-6-A-Pruntrut (5) [GVC];X-NUM-GUESTS=0:mailto:c_1887deim3r
5k0i5tgpf94aorhl3k2@resource.calendar.google.com
X-GOOGLE-CONFERENCE:https://meet.google.com/wts-viup-bbu
X-MICROSOFT-CDO-OWNERAPPTID:-796859524
CREATED:20220801T185710Z
DESCRIPTION:Join us for Justin's Intern presentation about work he did over
the summer regarding getting -Wformat enabled in the Linux kernel for Clan
g\, and profiling/performance work on building the Linux kernel faster with
Clang.\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of the description.\n\nTh
is event has a video call.\nJoin: https://meet.google.com/wts-viup-bbu\n(US
) +1 253-289-6982 PIN: 52630526169#\nView more phone numbers: https://tel.m
eet/wts-viup-bbu?pin=4782004268358&hs=7\n\nView your event at https://calen
dar.google.com/calendar/event?action=VIEW&eid=NGVoYWEyOWkxanEwYjU1cnQzNnJsN
m5sOGggbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb204
ZjQwMzA4ZDgzMWNkMjM4MzBjMzRjNDg0YmIxOWQ0YzRkMmRlMmMx&ctz=America%2FLos_Ange
les&hl=en&es=0.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220810T194447Z
LOCATION:UK-LON-6PS-9-C-Camden Town (No Externals Except For Interviews) (8
) [GVC]\, US-NYC-9TH-11-A-232-It's Too Cold (7) [GVC]\, US-MTV-PLYM1625-4-A
-Aesthetics (7) [GVC\, Phone]\, US-SAN-6420-4-3-Mt. Soledad (5) [GVC]\, US-
SVL-CRSM1240-2-Q-Feijoada (4) [GVC]\, US-MTV-1667-1-N-Hey Jude (8) [GVC\, P
hone]\, DE-MUC-ARN60-G-2-Ochsenbraterei (7) [GVC]\, CH-ZRH-EURD-6-A-Pruntru
t (5) [GVC]
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Justin Stitt's Intern Presentation
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
[-- Attachment #2: invite.ics --]
[-- Type: application/ics, Size: 5290 bytes --]
^ permalink raw reply [relevance 7%]
* Undelivered Mail Returned to Sender
@ 2022-05-28 3:49 7% Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2022-05-28 3:49 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 649 bytes --]
This is the mail system at host server.green17creative.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<info@passdoorsystems.com>: host eu-smtp-inbound-2.mimecast.com[91.220.42.241]
said: 554 Email rejected due to security policies -
https://community.mimecast.com/docs/DOC-1369#554
[j-IKiw5QOeqlgtzv74a_Zg.uk241] (in reply to end of DATA command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 9514 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 4325 bytes --]
<html>
<body leftmargin="0" marginwidth="0" topmargin="0" marginheight="0" offset="0" bgcolor='#FFFFFF' >
<STYLE>
body {background:#f9f9f9;}
.headerTop { background-color:white; border-top:0px solid #000000; border-bottom:1px solid #FFFFFF; text-align:center; }
.adminText { font-size:10px; color:#996600; line-height:200%; font-family:verdana; text-decoration:none; }
.headerBar { background-color:#FFFFFF; border-top:0px solid #333333; border-bottom:10px solid #FFFFFF; }
.title { font-size:20px; font-weight:bold; color:#CC6600; font-family:arial; line-height:110%; }
.subTitle { font-size:11px; font-weight:normal; color:#666666; font-style:italic; font-family:arial; }
td { font-size:12px; color:#000000; line-height:150%; font-family:trebuchet ms; }
.sideColumn { background-color:#FFFFFF; border-left:1px dashed #CCCCCC; text-align:left; }
.sideColumnText { font-size:11px; font-weight:normal; color:#999999; font-family:arial; line-height:150%; }
.sideColumnTitle { font-size:15px; font-weight:bold; color:#333333; font-family:arial; line-height:150%; }
.footerRow { background-color:#FFFFCC; border-top:10px solid #FFFFFF; }
.footerText { font-size:10px; color:#996600; line-height:100%; font-family:verdana; }
a { color:#901832;}
a.twitter-ie { -webkit-transition:0.3s; padding:0!important; margin-top: 15px; margin-left: 0; }
a.linkedin-ie { -webkit-transition:0.3s; padding:0!important; margin-top: 15px; margin-left:15px; }
a.facebook-ie { -webkit-transition:0.3s; padding:0!important; margin-top: 15px; margin-left:15px; }
a.twitter:hover {opacity:0.6; -webkit-transition:0.3s;}
a.facebook:hover {opacity:0.6; -webkit-transition:0.3s;}
a.linkedin:hover {opacity:0.6; -webkit-transition:0.3s;}
</STYLE>
<table width="100%" cellpadding="10" cellspacing="0" bgcolor='#FFFFFF'>
<td valign="top" align="center">
<table width="600" cellpadding="0" cellspacing="0">
<tr>
<td align="left" valign="middle" style="background-color:#FFFFFF;border-top:0px solid #333333;border-bottom:10px solid #FFFFFF;">
<center>
<a href="">
<img src="https://passdoorsystems.com/assets/img/pass-door-systems-logo@2x.png" height="120" alt="Pass Door Systems" name="editableImg1" border="0" align="center" id='editableImg1' title="Pass Door Systems">
</a>
</center>
</td>
</tr>
</table>
<!--sub table-->
<table width="600" cellpadding="20" cellspacing="0" bgcolor="#FFFFFF">
<tr>
<td bgcolor="#FFFFFF" valign="top" width="400" style="font-size:12px;color:#000000;line-height:150%;font-family:trebuchet ms;">
<p>
<span style="font-size:20px; font-weight:bold; color:#666666; font-family:arial; line-height:110%;">💛 Helen just viewed your profile! Click here: https://sweetgirl22.page.link/c2Sd?wcza8 💛 contacted you from the website</span>
<br/>
</p>
<p>Details submitted:</p>
<p>
<b>Name:</b> 💛 Helen just viewed your profile! Click here: https://sweetgirl22.page.link/c2Sd?wcza8 💛<br />
<b>Email:</b> mptcp@lists.linux.dev<br />
<b>Phone:</b> 245751741878<br />
<b>Address:</b> dl715w<br />
<b>Sector:</b> 9jm0rc<br />
<br />
<b>Message:</b> gss9jj
</p>
</td>
<td width="200" valign="top" style="background-color:#FFFFFF;border-left:1px solid #CCCCCC;text-align:left; font-size:12px;color:#000000;line-height:150%;font-family:trebuchet ms;">
<p>
<span style="font-weight:bold; color:#666666; font-family:arial; line-height:22px;">Pass Door Systems Limited</span><br>
Unit 5 & 6,<br/>
Woodside Road Industrial Estate,<br/>
Broughshane,<br/>
BT42 4QJ
</p>
<p>
<b>t.</b> +44 (0) 28 25 44 69 30<br/>
<b>e.</b> <a href="mailto:info@passdoorsystems.com">info@passdoorsystems.com</a><br />
</p>
</td>
</tr>
</table>
<!--sub table end-->
<!--sub2 table-->
<table width="600" cellpadding="20" cellspacing="0" bgcolor="#FFFFFF">
<td width="600">
</td>
</table>
<!--sub2 table end-->
</td>
</tr>
</table>
</body>
</html>
[-- Attachment #3.1.2: Type: text/html, Size: 4326 bytes --]
^ permalink raw reply [relevance 7%]
* [PATCH v7 3/7] configfs-tsm: Introduce a shared ABI for attestation reports
@ 2023-10-20 1:16 7% ` Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2023-10-20 1:16 UTC (permalink / raw)
To: linux-coco
Cc: Kuppuswamy Sathyanarayanan, Dionna Amalie Glaze, James Bottomley,
Peter Gonda, Greg Kroah-Hartman, Samuel Ortiz, Greg Kroah-Hartman,
Thomas Gleixner, Kuppuswamy Sathyanarayanan,
Kuppuswamy Sathyanarayanan, Tom Lendacky, peterz, dave.hansen,
x86
One of the common operations of a TSM (Trusted Security Module) is to
provide a way for a TVM (confidential computing guest execution
environment) to take a measurement of its launch state, sign it and
submit it to a verifying party. Upon successful attestation that
verifies the integrity of the TVM additional secrets may be deployed.
The concept is common across TSMs, but the implementations are
unfortunately vendor specific. While the industry grapples with a common
definition of this attestation format [1], Linux need not make this
problem worse by defining a new ABI per TSM that wants to perform a
similar operation. The current momentum has been to invent new ioctl-ABI
per TSM per function which at best is an abdication of the kernel's
responsibility to make common infrastructure concepts share common ABI.
The proposal, targeted to conceptually work with TDX, SEV-SNP, COVE if
not more, is to define a configfs interface to retrieve the TSM-specific
blob.
report=/sys/kernel/config/tsm/report/report0
mkdir $report
dd if=binary_userdata_plus_nonce > $report/inblob
hexdump $report/outblob
This approach later allows for the standardization of the attestation
blob format without needing to invent a new ABI. Once standardization
happens the standard format can be emitted by $report/outblob and
indicated by $report/provider, or a new attribute like
"$report/tcg_coco_report" can emit the standard format alongside the
vendor format.
Review of previous iterations of this interface identified that there is
a need to scale report generation for multiple container environments
[2]. Configfs enables a model where each container can bind mount one or
more report generation item instances. Still, within a container only a
single thread can be manipulating a given configuration instance at a
time. A 'generation' count is provided to detect conflicts between
multiple threads racing to configure a report instance.
The SEV-SNP concepts of "extended reports" and "privilege levels" are
optionally enabled by selecting 'tsm_report_ext_type' at register_tsm()
time. The expectation is that those concepts are generic enough that
they may be adopted by other TSM implementations. In other words,
configfs-tsm aims to address a superset of TSM specific functionality
with a common ABI where attributes may appear, or not appear, based on
the set of concepts the implementation supports.
Link: http://lore.kernel.org/r/64961c3baf8ce_142af829436@dwillia2-xfh.jf.intel.com.notmuch [1]
Link: http://lore.kernel.org/r/57f3a05e-8fcd-4656-beea-56bb8365ae64@linux.microsoft.com [2]
Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Peter Gonda <pgonda@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Samuel Ortiz <sameo@rivosinc.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Documentation/ABI/testing/configfs-tsm | 82 ++++++
MAINTAINERS | 8 +
drivers/virt/coco/Kconfig | 5
drivers/virt/coco/Makefile | 1
drivers/virt/coco/tsm.c | 425 ++++++++++++++++++++++++++++++++
include/linux/tsm.h | 69 +++++
6 files changed, 590 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-tsm
create mode 100644 drivers/virt/coco/tsm.c
create mode 100644 include/linux/tsm.h
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
new file mode 100644
index 000000000000..dd24202b5ba5
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -0,0 +1,82 @@
+What: /sys/kernel/config/tsm/report/$name/inblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Up to 64 bytes of user specified binary data. For replay
+ protection this should include a nonce, but the kernel does not
+ place any restrictions on the content.
+
+What: /sys/kernel/config/tsm/report/$name/outblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Binary attestation report generated from @inblob and other
+ options The format of the report is implementation specific
+ where the implementation is conveyed via the @provider
+ attribute.
+
+What: /sys/kernel/config/tsm/report/$name/auxblob
+Date: October, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Optional supplemental data that a TSM may emit, visibility
+ of this attribute depends on TSM, and may be empty if no
+ auxiliary data is available.
+
+ When @provider is "sev_guest" this file contains the
+ "cert_table" from SEV-ES Guest-Hypervisor Communication Block
+ Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
+
+What: /sys/kernel/config/tsm/report/$name/provider
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) A name for the format-specification of @outblob like
+ "sev_guest" [1] or "tdx_guest" [2] in the near term, or a
+ common standard format in the future.
+
+ [1]: SEV Secure Nested Paging Firmware ABI Specification
+ Revision 1.55 Table 22
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf
+
+ [2]: Intel® Trust Domain Extensions Data Center Attestation
+ Primitives : Quote Generation Library and Quote Verification
+ Library Revision 0.8 Appendix 4,5
+ https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf
+
+What: /sys/kernel/config/tsm/report/$name/generation
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) The value in this attribute increments each time @inblob or
+ any option is written. Userspace can detect conflicts by
+ checking generation before writing to any attribute and making
+ sure the number of writes matches expectations after reading
+ @outblob, or it can prevent conflicts by creating a report
+ instance per requesting context.
+
+What: /sys/kernel/config/tsm/report/$name/privlevel
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running at
+ different privilege levels, like SEV-SNP "VMPL", specify the
+ privilege level via this attribute. The minimum acceptable
+ value is conveyed via @privlevel_floor and the maximum
+ acceptable value is TSM_PRIVLEVEL_MAX (3).
+
+What: /sys/kernel/config/tsm/report/$name/privlevel_floor
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Indicates the minimum permissible value that can be written
+ to @privlevel.
diff --git a/MAINTAINERS b/MAINTAINERS
index b19995690904..8acbeb029ba1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21889,6 +21889,14 @@ W: https://github.com/srcres258/linux-doc
T: git git://github.com/srcres258/linux-doc.git doc-zh-tw
F: Documentation/translations/zh_TW/
+TRUSTED SECURITY MODULE (TSM) ATTESTATION REPORTS
+M: Dan Williams <dan.j.williams@intel.com>
+L: linux-coco@lists.linux.dev
+S: Maintained
+F: Documentation/ABI/testing/configfs-tsm
+F: drivers/virt/coco/tsm.c
+F: include/linux/tsm.h
+
TTY LAYER AND SERIAL DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Jiri Slaby <jirislaby@kernel.org>
diff --git a/drivers/virt/coco/Kconfig b/drivers/virt/coco/Kconfig
index fc5c64f04c4a..87d142c1f932 100644
--- a/drivers/virt/coco/Kconfig
+++ b/drivers/virt/coco/Kconfig
@@ -2,6 +2,11 @@
#
# Confidential computing related collateral
#
+
+config TSM_REPORTS
+ select CONFIGFS_FS
+ tristate
+
source "drivers/virt/coco/efi_secret/Kconfig"
source "drivers/virt/coco/sev-guest/Kconfig"
diff --git a/drivers/virt/coco/Makefile b/drivers/virt/coco/Makefile
index 55302ef719ad..18c1aba5edb7 100644
--- a/drivers/virt/coco/Makefile
+++ b/drivers/virt/coco/Makefile
@@ -2,6 +2,7 @@
#
# Confidential computing related collateral
#
+obj-$(CONFIG_TSM_REPORTS) += tsm.o
obj-$(CONFIG_EFI_SECRET) += efi_secret/
obj-$(CONFIG_SEV_GUEST) += sev-guest/
obj-$(CONFIG_INTEL_TDX_GUEST) += tdx-guest/
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
new file mode 100644
index 000000000000..d1c2db83a8ca
--- /dev/null
+++ b/drivers/virt/coco/tsm.c
@@ -0,0 +1,425 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright(c) 2023 Intel Corporation. All rights reserved. */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/tsm.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/rwsem.h>
+#include <linux/string.h>
+#include <linux/module.h>
+#include <linux/cleanup.h>
+#include <linux/configfs.h>
+
+static struct tsm_provider {
+ const struct tsm_ops *ops;
+ const struct config_item_type *type;
+ void *data;
+} provider;
+static DECLARE_RWSEM(tsm_rwsem);
+
+/**
+ * DOC: Trusted Security Module (TSM) Attestation Report Interface
+ *
+ * The TSM report interface is a common provider of blobs that facilitate
+ * attestation of a TVM (confidential computing guest) by an attestation
+ * service. A TSM report combines a user-defined blob (likely a public-key with
+ * a nonce for a key-exchange protocol) with a signed attestation report. That
+ * combined blob is then used to obtain secrets provided by an agent that can
+ * validate the attestation report. The expectation is that this interface is
+ * invoked infrequently, however configfs allows for multiple agents to
+ * own their own report generation instances to generate reports as
+ * often as needed.
+ *
+ * The attestation report format is TSM provider specific, when / if a standard
+ * materializes that can be published instead of the vendor layout. Until then
+ * the 'provider' attribute indicates the format of 'outblob', and optionally
+ * 'auxblob'.
+ */
+
+struct tsm_report_state {
+ struct tsm_report report;
+ unsigned long write_generation;
+ unsigned long read_generation;
+ struct config_item cfg;
+};
+
+enum tsm_data_select {
+ TSM_REPORT,
+ TSM_CERTS,
+};
+
+static struct tsm_report *to_tsm_report(struct config_item *cfg)
+{
+ struct tsm_report_state *state =
+ container_of(cfg, struct tsm_report_state, cfg);
+
+ return &state->report;
+}
+
+static struct tsm_report_state *to_state(struct tsm_report *report)
+{
+ return container_of(report, struct tsm_report_state, report);
+}
+
+static int try_advance_write_generation(struct tsm_report *report)
+{
+ struct tsm_report_state *state = to_state(report);
+
+ lockdep_assert_held_write(&tsm_rwsem);
+
+ /*
+ * Malicious or broken userspace has written enough times for
+ * read_generation == write_generation by modular arithmetic without an
+ * interim read. Stop accepting updates until the current report
+ * configuration is read.
+ */
+ if (state->write_generation == state->read_generation - 1)
+ return -EBUSY;
+ state->write_generation++;
+ return 0;
+}
+
+static ssize_t tsm_report_privlevel_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ /*
+ * The valid privilege levels that a TSM might accept, if it accepts a
+ * privilege level setting at all, are a max of TSM_PRIVLEVEL_MAX (see
+ * SEV-SNP GHCB) and a minimum of a TSM selected floor value no less
+ * than 0.
+ */
+ if (provider.ops->privlevel_floor > val || val > TSM_PRIVLEVEL_MAX)
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.privlevel = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, privlevel);
+
+static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
+ char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%u\n", provider.ops->privlevel_floor);
+}
+CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+
+static ssize_t tsm_report_inblob_write(struct config_item *cfg,
+ const void *buf, size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ report->desc.inblob_len = count;
+ memcpy(report->desc.inblob, buf, count);
+ return count;
+}
+CONFIGFS_BIN_ATTR_WO(tsm_report_, inblob, NULL, TSM_INBLOB_MAX);
+
+static ssize_t tsm_report_generation_show(struct config_item *cfg, char *buf)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ struct tsm_report_state *state = to_state(report);
+
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%lu\n", state->write_generation);
+}
+CONFIGFS_ATTR_RO(tsm_report_, generation);
+
+static ssize_t tsm_report_provider_show(struct config_item *cfg, char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%s\n", provider.ops->name);
+}
+CONFIGFS_ATTR_RO(tsm_report_, provider);
+
+static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
+ enum tsm_data_select select)
+{
+ loff_t offset = 0;
+ ssize_t len;
+ u8 *out;
+
+ if (select == TSM_REPORT) {
+ out = report->outblob;
+ len = report->outblob_len;
+ } else {
+ out = report->auxblob;
+ len = report->auxblob_len;
+ }
+
+ /*
+ * Recall that a NULL @buf is configfs requesting the size of
+ * the buffer.
+ */
+ if (!buf)
+ return len;
+ return memory_read_from_buffer(buf, count, &offset, out, len);
+}
+
+static ssize_t read_cached_report(struct tsm_report *report, void *buf,
+ size_t count, enum tsm_data_select select)
+{
+ struct tsm_report_state *state = to_state(report);
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ /*
+ * A given TSM backend always fills in ->outblob regardless of
+ * whether the report includes an auxblob or not.
+ */
+ if (!report->outblob ||
+ state->read_generation != state->write_generation)
+ return -EWOULDBLOCK;
+
+ return __read_report(report, buf, count, select);
+}
+
+static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
+ size_t count, enum tsm_data_select select)
+{
+ struct tsm_report_state *state = to_state(report);
+ const struct tsm_ops *ops;
+ ssize_t rc;
+
+ /* try to read from the existing report if present and valid... */
+ rc = read_cached_report(report, buf, count, select);
+ if (rc >= 0 || rc != -EWOULDBLOCK)
+ return rc;
+
+ /* slow path, report may need to be regenerated... */
+ guard(rwsem_write)(&tsm_rwsem);
+ ops = provider.ops;
+ if (!ops)
+ return -ENOTTY;
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ /* did another thread already generate this report? */
+ if (report->outblob &&
+ state->read_generation == state->write_generation)
+ goto out;
+
+ kvfree(report->outblob);
+ kvfree(report->auxblob);
+ report->outblob = NULL;
+ report->auxblob = NULL;
+ rc = ops->report_new(report, provider.data);
+ if (rc < 0)
+ return rc;
+ state->read_generation = state->write_generation;
+out:
+ return __read_report(report, buf, count, select);
+}
+
+static ssize_t tsm_report_outblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_REPORT);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, outblob, NULL, TSM_OUTBLOB_MAX);
+
+static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_CERTS);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
+
+#define TSM_DEFAULT_ATTRS() \
+ &tsm_report_attr_generation, \
+ &tsm_report_attr_provider
+
+static struct configfs_attribute *tsm_report_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ NULL,
+};
+
+static struct configfs_attribute *tsm_report_extra_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ &tsm_report_attr_privlevel,
+ &tsm_report_attr_privlevel_floor,
+ NULL,
+};
+
+#define TSM_DEFAULT_BIN_ATTRS() \
+ &tsm_report_attr_inblob, \
+ &tsm_report_attr_outblob
+
+static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
+ TSM_DEFAULT_BIN_ATTRS(),
+ NULL,
+};
+
+static struct configfs_bin_attribute *tsm_report_bin_extra_attrs[] = {
+ TSM_DEFAULT_BIN_ATTRS(),
+ &tsm_report_attr_auxblob,
+ NULL,
+};
+
+static void tsm_report_item_release(struct config_item *cfg)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ struct tsm_report_state *state = to_state(report);
+
+ kvfree(report->auxblob);
+ kvfree(report->outblob);
+ kfree(state);
+}
+
+static struct configfs_item_operations tsm_report_item_ops = {
+ .release = tsm_report_item_release,
+};
+
+const struct config_item_type tsm_report_default_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_attrs,
+ .ct_attrs = tsm_report_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_default_type);
+
+const struct config_item_type tsm_report_extra_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_extra_attrs,
+ .ct_attrs = tsm_report_extra_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_extra_type);
+
+static struct config_item *tsm_report_make_item(struct config_group *group,
+ const char *name)
+{
+ struct tsm_report_state *state;
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!provider.ops)
+ return ERR_PTR(-ENXIO);
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ config_item_init_type_name(&state->cfg, name, provider.type);
+ return &state->cfg;
+}
+
+static struct configfs_group_operations tsm_report_group_ops = {
+ .make_item = tsm_report_make_item,
+};
+
+static const struct config_item_type tsm_reports_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_group_ops = &tsm_report_group_ops,
+};
+
+static const struct config_item_type tsm_root_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static struct configfs_subsystem tsm_configfs = {
+ .su_group = {
+ .cg_item = {
+ .ci_namebuf = "tsm",
+ .ci_type = &tsm_root_group_type,
+ },
+ },
+ .su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
+};
+
+int tsm_register(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type)
+{
+ const struct tsm_ops *conflict;
+
+ if (!type)
+ type = &tsm_report_default_type;
+ if (!(type == &tsm_report_default_type || type == &tsm_report_extra_type))
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ conflict = provider.ops;
+ if (conflict) {
+ pr_err("\"%s\" ops already registered\n", conflict->name);
+ return -EBUSY;
+ }
+
+ provider.ops = ops;
+ provider.data = priv;
+ provider.type = type;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(tsm_register);
+
+int tsm_unregister(const struct tsm_ops *ops)
+{
+ guard(rwsem_write)(&tsm_rwsem);
+ if (ops != provider.ops)
+ return -EBUSY;
+ provider.ops = NULL;
+ provider.data = NULL;
+ provider.type = NULL;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(tsm_unregister);
+
+static struct config_group *tsm_report_group;
+
+static int __init tsm_init(void)
+{
+ struct config_group *root = &tsm_configfs.su_group;
+ struct config_group *tsm;
+ int rc;
+
+ config_group_init(root);
+ rc = configfs_register_subsystem(&tsm_configfs);
+ if (rc)
+ return rc;
+
+ tsm = configfs_register_default_group(root, "report",
+ &tsm_reports_type);
+ if (IS_ERR(tsm)) {
+ configfs_unregister_subsystem(&tsm_configfs);
+ return PTR_ERR(tsm);
+ }
+ tsm_report_group = tsm;
+
+ return 0;
+}
+module_init(tsm_init);
+
+static void __exit tsm_exit(void)
+{
+ configfs_unregister_default_group(tsm_report_group);
+ configfs_unregister_subsystem(&tsm_configfs);
+}
+module_exit(tsm_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Provide Trusted Security Module attestation reports via configfs");
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
new file mode 100644
index 000000000000..de8324a2223c
--- /dev/null
+++ b/include/linux/tsm.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __TSM_H
+#define __TSM_H
+
+#include <linux/sizes.h>
+#include <linux/types.h>
+
+#define TSM_INBLOB_MAX 64
+#define TSM_OUTBLOB_MAX SZ_32K
+
+/*
+ * Privilege level is a nested permission concept to allow confidential
+ * guests to partition address space, 4-levels are supported.
+ */
+#define TSM_PRIVLEVEL_MAX 3
+
+/**
+ * struct tsm_desc - option descriptor for generating tsm report blobs
+ * @privlevel: optional privilege level to associate with @outblob
+ * @inblob_len: sizeof @inblob
+ * @inblob: arbitrary input data
+ */
+struct tsm_desc {
+ unsigned int privlevel;
+ size_t inblob_len;
+ u8 inblob[TSM_INBLOB_MAX];
+};
+
+/**
+ * struct tsm_report - track state of report generation relative to options
+ * @desc: input parameters to @report_new()
+ * @outblob_len: sizeof(@outblob)
+ * @outblob: generated evidence to provider to the attestation agent
+ * @auxblob_len: sizeof(@auxblob)
+ * @auxblob: (optional) auxiliary data to the report (e.g. certificate data)
+ */
+struct tsm_report {
+ struct tsm_desc desc;
+ size_t outblob_len;
+ u8 *outblob;
+ size_t auxblob_len;
+ u8 *auxblob;
+};
+
+/**
+ * struct tsm_ops - attributes and operations for tsm instances
+ * @name: tsm id reflected in /sys/kernel/config/tsm/report/$report/provider
+ * @privlevel_floor: convey base privlevel for nested scenarios
+ * @report_new: Populate @report with the report blob and auxblob
+ * (optional), return 0 on successful population, or -errno otherwise
+ *
+ * Implementation specific ops, only one is expected to be registered at
+ * a time i.e. only one of "sev-guest", "tdx-guest", etc.
+ */
+struct tsm_ops {
+ const char *name;
+ const unsigned int privlevel_floor;
+ int (*report_new)(struct tsm_report *report, void *data);
+};
+
+extern const struct config_item_type tsm_report_default_type;
+
+/* publish @privlevel, @privlevel_floor, and @auxblob attributes */
+extern const struct config_item_type tsm_report_extra_type;
+
+int tsm_register(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type);
+int tsm_unregister(const struct tsm_ops *ops);
+#endif /* __TSM_H */
^ permalink raw reply related [relevance 7%]
* [PATCH v6 3/7] configfs-tsm: Introduce a shared ABI for attestation reports
@ 2023-10-13 2:14 7% ` Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2023-10-13 2:14 UTC (permalink / raw)
To: linux-coco
Cc: Kuppuswamy Sathyanarayanan, Dionna Amalie Glaze, James Bottomley,
Peter Gonda, Greg Kroah-Hartman, Samuel Ortiz, Greg Kroah-Hartman,
Thomas Gleixner, Kuppuswamy Sathyanarayanan,
Kuppuswamy Sathyanarayanan, peterz, sathyanarayanan.kuppuswamy,
dave.hansen, bp
One of the common operations of a TSM (Trusted Security Module) is to
provide a way for a TVM (confidential computing guest execution
environment) to take a measurement of its launch state, sign it and
submit it to a verifying party. Upon successful attestation that
verifies the integrity of the TVM additional secrets may be deployed.
The concept is common across TSMs, but the implementations are
unfortunately vendor specific. While the industry grapples with a common
definition of this attestation format [1], Linux need not make this
problem worse by defining a new ABI per TSM that wants to perform a
similar operation. The current momentum has been to invent new ioctl-ABI
per TSM per function which at best is an abdication of the kernel's
responsibility to make common infrastructure concepts share common ABI.
The proposal, targeted to conceptually work with TDX, SEV-SNP, COVE if
not more, is to define a configfs interface to retrieve the TSM-specific
blob.
report=/sys/kernel/config/tsm/report/report0
mkdir $report
dd if=binary_userdata_plus_nonce > $report/inblob
hexdump $report/outblob
This approach later allows for the standardization of the attestation
blob format without needing to invent a new ABI. Once standardization
happens the standard format can be emitted by $report/outblob and
indicated by $report/provider, or a new attribute like
"$report/tcg_coco_report" can emit the standard format alongside the
vendor format.
Review of previous iterations of this interface identified that there is
a need to scale report generation for multiple container environments
[2]. Configfs enables a model where each container can bind mount one or
more report generation item instances. Still, within a container only a
single thread can be manipulating a given configuration instance at a
time. A 'generation' count is provided to detect conflicts between
multiple threads racing to configure a report instance.
The SEV-SNP concepts of "extended reports" and "privilege levels" are
optionally enabled by selecting 'tsm_report_ext_type' at register_tsm()
time. The expectation is that those concepts are generic enough that
they may be adopted by other TSM implementations. In other words,
configfs-tsm aims to address a superset of TSM specific functionality
with a common ABI where attributes may appear, or not appear, based on
the set of concepts the implementation supports.
Link: http://lore.kernel.org/r/64961c3baf8ce_142af829436@dwillia2-xfh.jf.intel.com.notmuch [1]
Link: http://lore.kernel.org/r/57f3a05e-8fcd-4656-beea-56bb8365ae64@linux.microsoft.com [2]
Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Peter Gonda <pgonda@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Samuel Ortiz <sameo@rivosinc.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Documentation/ABI/testing/configfs-tsm | 82 ++++++
MAINTAINERS | 8 +
drivers/virt/coco/Kconfig | 5
drivers/virt/coco/Makefile | 1
drivers/virt/coco/tsm.c | 423 ++++++++++++++++++++++++++++++++
include/linux/tsm.h | 68 +++++
6 files changed, 587 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-tsm
create mode 100644 drivers/virt/coco/tsm.c
create mode 100644 include/linux/tsm.h
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
new file mode 100644
index 000000000000..64eb4d937e48
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -0,0 +1,82 @@
+What: /sys/kernel/config/tsm/report/$name/inblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Up to 64 bytes of user specified binary data. For replay
+ protection this should include a nonce, but the kernel does not
+ place any restrictions on the content.
+
+What: /sys/kernel/config/tsm/report/$name/outblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Binary attestation report generated from @inblob and other
+ options The format of the report is implementation specific
+ where the implementation is conveyed via the @provider
+ attribute.
+
+What: /sys/kernel/config/tsm/report/$name/auxblob
+Date: October, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Optional supplemental data that a TSM may emit, visibility
+ of this attribute depends on TSM, and may be empty if no
+ auxiliary data is available.
+
+ When @provider is "sev-guest" this file contains the
+ "cert_table" from SEV-ES Guest-Hypervisor Communication Block
+ Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
+
+What: /sys/kernel/config/tsm/report/$name/provider
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) A name for the format-specification of @outblob like
+ "sev-guest" [1] or "tdx-guest" [2] in the near term, or a
+ common standard format in the future.
+
+ [1]: SEV Secure Nested Paging Firmware ABI Specification
+ Revision 1.55 Table 22
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf
+
+ [2]: Intel® Trust Domain Extensions Data Center Attestation
+ Primitives : Quote Generation Library and Quote Verification
+ Library Revision 0.8 Appendix 4,5
+ https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf
+
+What: /sys/kernel/config/tsm/report/$name/generation
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) The value in this attribute increments each time @inblob or
+ any option is written. Userspace can detect conflicts by
+ checking generation before writing to any attribute and making
+ sure the number of writes matches expectations after reading
+ @outblob, or it can prevent conflicts by creating a report
+ instance per requesting context.
+
+What: /sys/kernel/config/tsm/report/$name/privlevel
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running at
+ different privilege levels, like SEV-SNP "VMPL", specify the
+ privilege level via this attribute. The minimum acceptable
+ value is conveyed via @privlevel_floor and the maximum
+ acceptable value is TSM_PRIVLEVEL_MAX (3).
+
+What: /sys/kernel/config/tsm/report/$name/privlevel_floor
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Indicates the minimum permissible value that can be written
+ to @privlevel.
diff --git a/MAINTAINERS b/MAINTAINERS
index b19995690904..8acbeb029ba1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21889,6 +21889,14 @@ W: https://github.com/srcres258/linux-doc
T: git git://github.com/srcres258/linux-doc.git doc-zh-tw
F: Documentation/translations/zh_TW/
+TRUSTED SECURITY MODULE (TSM) ATTESTATION REPORTS
+M: Dan Williams <dan.j.williams@intel.com>
+L: linux-coco@lists.linux.dev
+S: Maintained
+F: Documentation/ABI/testing/configfs-tsm
+F: drivers/virt/coco/tsm.c
+F: include/linux/tsm.h
+
TTY LAYER AND SERIAL DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Jiri Slaby <jirislaby@kernel.org>
diff --git a/drivers/virt/coco/Kconfig b/drivers/virt/coco/Kconfig
index fc5c64f04c4a..87d142c1f932 100644
--- a/drivers/virt/coco/Kconfig
+++ b/drivers/virt/coco/Kconfig
@@ -2,6 +2,11 @@
#
# Confidential computing related collateral
#
+
+config TSM_REPORTS
+ select CONFIGFS_FS
+ tristate
+
source "drivers/virt/coco/efi_secret/Kconfig"
source "drivers/virt/coco/sev-guest/Kconfig"
diff --git a/drivers/virt/coco/Makefile b/drivers/virt/coco/Makefile
index 55302ef719ad..18c1aba5edb7 100644
--- a/drivers/virt/coco/Makefile
+++ b/drivers/virt/coco/Makefile
@@ -2,6 +2,7 @@
#
# Confidential computing related collateral
#
+obj-$(CONFIG_TSM_REPORTS) += tsm.o
obj-$(CONFIG_EFI_SECRET) += efi_secret/
obj-$(CONFIG_SEV_GUEST) += sev-guest/
obj-$(CONFIG_INTEL_TDX_GUEST) += tdx-guest/
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
new file mode 100644
index 000000000000..0200a86f1efe
--- /dev/null
+++ b/drivers/virt/coco/tsm.c
@@ -0,0 +1,423 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright(c) 2023 Intel Corporation. All rights reserved. */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/tsm.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/rwsem.h>
+#include <linux/string.h>
+#include <linux/module.h>
+#include <linux/cleanup.h>
+#include <linux/configfs.h>
+
+static struct tsm_provider {
+ const struct tsm_ops *ops;
+ const struct config_item_type *type;
+ void *data;
+} provider;
+static DECLARE_RWSEM(tsm_rwsem);
+
+/**
+ * DOC: Trusted Security Module (TSM) Attestation Report Interface
+ *
+ * The TSM report interface is a common provider of blobs that facilitate
+ * attestation of a TVM (confidential computing guest) by an attestation
+ * service. A TSM report combines a user-defined blob (likely a public-key with
+ * a nonce for a key-exchange protocol) with a signed attestation report. That
+ * combined blob is then used to obtain secrets provided by an agent that can
+ * validate the attestation report. The expectation is that this interface is
+ * invoked infrequently, however configfs allows for multiple agents to
+ * own their own report generation instances to generate reports as
+ * often as needed.
+ *
+ * The attestation report format is TSM provider specific, when / if a standard
+ * materializes that can be published instead of the vendor layout. Until then
+ * the 'provider' attribute indicates the format of 'outblob', and optionally
+ * 'auxblob'.
+ */
+
+struct tsm_report_state {
+ struct tsm_report report;
+ unsigned long write_generation;
+ unsigned long read_generation;
+ struct config_item cfg;
+};
+
+enum tsm_data_select {
+ TSM_REPORT,
+ TSM_CERTS,
+};
+
+static struct tsm_report *to_tsm_report(struct config_item *cfg)
+{
+ struct tsm_report_state *state =
+ container_of(cfg, struct tsm_report_state, cfg);
+
+ return &state->report;
+}
+
+static struct tsm_report_state *to_state(struct tsm_report *report)
+{
+ return container_of(report, struct tsm_report_state, report);
+}
+
+static int try_advance_write_generation(struct tsm_report *report)
+{
+ struct tsm_report_state *state = to_state(report);
+
+ lockdep_assert_held_write(&tsm_rwsem);
+
+ /*
+ * Malicious or broken userspace has written enough times for
+ * read_generation == write_generation by modular arithmetic without an
+ * interim read. Stop accepting updates until the current report
+ * configuration is read.
+ */
+ if (state->write_generation == state->read_generation - 1)
+ return -EBUSY;
+ state->write_generation++;
+ return 0;
+}
+
+static ssize_t tsm_report_privlevel_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ /*
+ * The valid privilege levels that a TSM might accept, if it accepts a
+ * privilege level setting at all, are a max of TSM_PRIVLEVEL_MAX (see
+ * SEV-SNP GHCB) and a minimum of a TSM selected floor value no less
+ * than 0.
+ */
+ if (provider.ops->privlevel_floor > val || val > TSM_PRIVLEVEL_MAX)
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.privlevel = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, privlevel);
+
+static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
+ char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%u\n", provider.ops->privlevel_floor);
+}
+CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+
+static ssize_t tsm_report_inblob_write(struct config_item *cfg,
+ const void *buf, size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ report->desc.inblob_len = count;
+ memcpy(report->desc.inblob, buf, count);
+ return count;
+}
+CONFIGFS_BIN_ATTR_WO(tsm_report_, inblob, NULL, TSM_INBLOB_MAX);
+
+static ssize_t tsm_report_generation_show(struct config_item *cfg, char *buf)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ struct tsm_report_state *state = to_state(report);
+
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%lu\n", state->write_generation);
+}
+CONFIGFS_ATTR_RO(tsm_report_, generation);
+
+static ssize_t tsm_report_provider_show(struct config_item *cfg, char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%s\n", provider.ops->name);
+}
+CONFIGFS_ATTR_RO(tsm_report_, provider);
+
+static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
+ enum tsm_data_select select)
+{
+ loff_t offset = 0;
+ ssize_t len;
+ u8 *out;
+
+ if (select == TSM_REPORT) {
+ out = report->outblob;
+ len = report->outblob_len;
+ } else {
+ out = report->auxblob;
+ len = report->auxblob_len;
+ }
+
+ /*
+ * Recall that a NULL @buf is configfs requesting the size of
+ * the buffer.
+ */
+ if (!buf)
+ return len;
+ return memory_read_from_buffer(buf, count, &offset, out, len);
+}
+
+static ssize_t read_cached_report(struct tsm_report *report, void *buf,
+ size_t count, enum tsm_data_select select)
+{
+ struct tsm_report_state *state = to_state(report);
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ /*
+ * A given TSM backend always fills in ->outblob regardless of
+ * whether the report includes an auxblob or not.
+ */
+ if (!report->outblob ||
+ state->read_generation != state->write_generation)
+ return -EWOULDBLOCK;
+
+ return __read_report(report, buf, count, select);
+}
+
+static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
+ size_t count, enum tsm_data_select select)
+{
+ struct tsm_report_state *state = to_state(report);
+ const struct tsm_ops *ops;
+ ssize_t rc;
+
+ /* try to read from the existing report if present and valid... */
+ rc = read_cached_report(report, buf, count, select);
+ if (rc >= 0 || rc != -EWOULDBLOCK)
+ return rc;
+
+ /* slow path, report may need to be regenerated... */
+ guard(rwsem_write)(&tsm_rwsem);
+ ops = provider.ops;
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ /* did another thread already generate this report? */
+ if (report->outblob &&
+ state->read_generation == state->write_generation)
+ goto out;
+
+ kvfree(report->outblob);
+ kvfree(report->auxblob);
+ report->outblob = NULL;
+ report->auxblob = NULL;
+ rc = ops->report_new(report, provider.data);
+ if (rc < 0)
+ return rc;
+ state->read_generation = state->write_generation;
+out:
+ return __read_report(report, buf, count, select);
+}
+
+static ssize_t tsm_report_outblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_REPORT);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, outblob, NULL, TSM_OUTBLOB_MAX);
+
+static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_CERTS);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
+
+#define TSM_DEFAULT_ATTRS() \
+ &tsm_report_attr_generation, \
+ &tsm_report_attr_provider
+
+static struct configfs_attribute *tsm_report_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ NULL,
+};
+
+#define TSM_DEFAULT_BIN_ATTRS() \
+ &tsm_report_attr_inblob, \
+ &tsm_report_attr_outblob
+
+static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
+ TSM_DEFAULT_BIN_ATTRS(),
+ NULL,
+};
+
+static struct configfs_bin_attribute *tsm_report_bin_extra_attrs[] = {
+ TSM_DEFAULT_BIN_ATTRS(),
+ &tsm_report_attr_auxblob,
+ NULL,
+};
+
+static struct configfs_attribute *tsm_report_extra_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ &tsm_report_attr_privlevel,
+ &tsm_report_attr_privlevel_floor,
+ NULL,
+};
+
+static void tsm_report_item_release(struct config_item *cfg)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ struct tsm_report_state *state = to_state(report);
+
+ kvfree(report->auxblob);
+ kvfree(report->outblob);
+ kfree(state);
+}
+
+static struct configfs_item_operations tsm_report_item_ops = {
+ .release = tsm_report_item_release,
+};
+
+const struct config_item_type tsm_report_default_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_attrs,
+ .ct_attrs = tsm_report_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_default_type);
+
+const struct config_item_type tsm_report_ext_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_extra_attrs,
+ .ct_attrs = tsm_report_extra_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_ext_type);
+
+static struct config_item *tsm_report_make_item(struct config_group *group,
+ const char *name)
+{
+ struct tsm_report_state *state;
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!provider.ops)
+ return ERR_PTR(-ENXIO);
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ config_item_init_type_name(&state->cfg, name, provider.type);
+ return &state->cfg;
+}
+
+static struct configfs_group_operations tsm_report_group_ops = {
+ .make_item = tsm_report_make_item,
+};
+
+static const struct config_item_type tsm_reports_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_group_ops = &tsm_report_group_ops,
+};
+
+static const struct config_item_type tsm_root_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static struct configfs_subsystem tsm_configfs = {
+ .su_group = {
+ .cg_item = {
+ .ci_namebuf = "tsm",
+ .ci_type = &tsm_root_group_type,
+ },
+ },
+ .su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
+};
+
+static struct config_group *tsm_report_group;
+
+int tsm_register(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type)
+{
+ const struct tsm_ops *conflict;
+
+ if (!type)
+ type = &tsm_report_default_type;
+ if (!(type == &tsm_report_default_type || type == &tsm_report_ext_type))
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ conflict = provider.ops;
+ if (conflict) {
+ pr_err("\"%s\" ops already registered\n", conflict->name);
+ return -EBUSY;
+ }
+
+ provider.ops = ops;
+ provider.data = priv;
+ provider.type = type;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(tsm_register);
+
+int tsm_unregister(const struct tsm_ops *ops)
+{
+ guard(rwsem_write)(&tsm_rwsem);
+ if (ops != provider.ops)
+ return -EBUSY;
+ provider.ops = NULL;
+ provider.data = NULL;
+ provider.type = NULL;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(tsm_unregister);
+
+static int __init tsm_init(void)
+{
+ struct config_group *root = &tsm_configfs.su_group;
+ struct config_group *tsm;
+ int rc;
+
+ config_group_init(root);
+ rc = configfs_register_subsystem(&tsm_configfs);
+ if (rc)
+ return rc;
+
+ tsm = configfs_register_default_group(root, "report",
+ &tsm_reports_type);
+ if (IS_ERR(tsm)) {
+ configfs_unregister_subsystem(&tsm_configfs);
+ return PTR_ERR(tsm);
+ }
+ tsm_report_group = tsm;
+
+ return 0;
+}
+module_init(tsm_init);
+
+static void __exit tsm_exit(void)
+{
+ configfs_unregister_default_group(tsm_report_group);
+ configfs_unregister_subsystem(&tsm_configfs);
+}
+module_exit(tsm_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Provide Trusted Security Module attestation reports via configfs");
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
new file mode 100644
index 000000000000..5fadc382064d
--- /dev/null
+++ b/include/linux/tsm.h
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __TSM_H
+#define __TSM_H
+
+#include <linux/sizes.h>
+#include <linux/types.h>
+#include <linux/device.h>
+
+#define TSM_INBLOB_MAX 64
+#define TSM_OUTBLOB_MAX SZ_32K
+
+/*
+ * Privilege level is a nested permission concept to allow confidential
+ * guests to partition address space, 4-levels are supported.
+ */
+#define TSM_PRIVLEVEL_MAX 3
+
+/**
+ * struct tsm_desc - option descriptor for generating tsm report blobs
+ * @privlevel: optional privilege level to associate with @outblob
+ * @inblob_len: sizeof @inblob
+ * @inblob: arbitrary input data
+ */
+struct tsm_desc {
+ unsigned int privlevel;
+ size_t inblob_len;
+ u8 inblob[TSM_INBLOB_MAX];
+};
+
+/**
+ * struct tsm_report - track state of report generation relative to options
+ * @desc: input parameters to @report_new()
+ * @outblob_len: sizeof(@outblob)
+ * @outblob: generated evidence to provider to the attestation agent
+ * @auxblob_len: sizeof(@auxblob)
+ * @auxblob: (optional) auxiliary data to the report (e.g. certificate data)
+ */
+struct tsm_report {
+ struct tsm_desc desc;
+ size_t outblob_len;
+ u8 *outblob;
+ size_t auxblob_len;
+ u8 *auxblob;
+};
+
+/**
+ * struct tsm_ops - attributes and operations for tsm instances
+ * @name: tsm id reflected in /sys/kernel/config/tsm/report/$report/provider
+ * @privlevel_floor: convey base privlevel for nested scenarios
+ * @report_new: Populate @report with the report blob and auxblob
+ * (optional), return 0 on successful population, or -errno otherwise
+ *
+ * Implementation specific ops, only one is expected to be registered at
+ * a time i.e. only one of "sev-guest", "tdx-guest", etc.
+ */
+struct tsm_ops {
+ const char *name;
+ const int privlevel_floor;
+ int (*report_new)(struct tsm_report *report, void *data);
+};
+
+extern const struct config_item_type tsm_report_ext_type;
+extern const struct config_item_type tsm_report_default_type;
+
+int tsm_register(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type);
+int tsm_unregister(const struct tsm_ops *ops);
+#endif /* __TSM_H */
^ permalink raw reply related [relevance 7%]
* [RFC PATCH v1 2/2] docs: reporting-issues: make everyone CC the regressions list
2021-04-07 9:21 8% ` [RFC PATCH v1 1/2] MAINTAINERS: add regressions mailing list Thorsten Leemhuis
@ 2021-04-07 9:21 7% ` Thorsten Leemhuis
1 sibling, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2021-04-07 9:21 UTC (permalink / raw)
To: Jonathan Corbet, Greg KH, Linus Torvalds
Cc: Randy Dunlap, linux-doc, linux-kernel
Make people CC the recently created mailing list dedicated to Linux
kernel regressions when reporting one. Some paragraphs had to be
reshuffled and slightly rewritten during the process, as the text
otherwise would have gotten unnecessarily hard to follow.
The new text also makes reporters include a line useful for automatic
regression tracking solution which does not exist yet, but is planned.
The term "#regzb" (short for regression bot) is inspired by the "#syz"
which can be used to communicate with syszbot (see
https://github.com/google/syzkaller/blob/master/docs/syzbot.md).
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
Lo! Now that we have a mailing list for regressions I was inclined to
remove the "Make the report's subject start with '[REGRESSION]'" part
from the text. But in the end I left it, to make it obvious on other
lists that the mail is about a regression. Nevertheless, I'm still
wondering if it should be toned down a bit, as it might be enough if the
subject starts with "regression:" or contains the word somewhere.
That automatic tracking solution hinted at in the commit message is
something I plan to work on in the next months. It won't be another
bugzilla-like tracker, more a simple database that works in the
background like syzbot. I'm not attached to the "#regzb" term, so please
speak up if you can think of something better that also works when
searching the internet.
Ciao, Thorsten
---
.../admin-guide/reporting-issues.rst | 64 +++++++++++++------
1 file changed, 44 insertions(+), 20 deletions(-)
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index fd407c6951ea..45065c501beb 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -23,7 +23,8 @@ longterm series? One still supported? Then search the `LKML
<https://lore.kernel.org/stable/>`_ archives for matching reports to join. If
you don't find any, install `the latest release from that series
<https://kernel.org/>`_. If it still shows the issue, report it to the stable
-mailing list (stable@vger.kernel.org).
+mailing list (stable@vger.kernel.org) and CC the regressions list
+(regressions@lists.linux.dev).
In all other cases try your best guess which kernel part might be causing the
issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
@@ -44,10 +45,11 @@ ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
sure it's built and running in a healthy environment and not already tainted
before the issue occurs.
-While writing your report, include all information relevant to the issue, like
-the kernel and the distro used. In case of a regression try to include the
-commit-id of the change causing it, which a bisection can find. If you're facing
-multiple issues with the Linux kernel at once, report each separately.
+If you are facing multiple issues with the Linux kernel at once, report each
+separately. While writing your report, include all information relevant to the
+issue, like the kernel and the distro used. In case of a regression, CC the
+regressions mailing list (regressions@lists.linux.dev) to your report; also try
+to include the commit-id of the change causing it, which a bisection can find.
Once the report is out, answer any questions that come up and help where you
can. That includes keeping the ball rolling by occasionally retesting with newer
@@ -192,12 +194,14 @@ report them:
kernel. Ensure this kernel is not tainted and still shows the problem, as
the issue might have already been fixed there. If you first noticed the
problem with a vendor kernel, check a vanilla build of the last version
- known to work performs fine as well.*
+ known to work performs fine as well.
* Send a short problem report to the Linux stable mailing list
- (stable@vger.kernel.org). Roughly describe the issue and ideally explain
- how to reproduce it. Mention the first version that shows the problem and
- the last version that's working fine. Then wait for further instructions.*
+ (stable@vger.kernel.org) and CC the Linux regressions mailing list
+ (regressions@lists.linux.dev). Roughly describe the issue and ideally
+ explain how to reproduce it. Mention the commit or version that introduced
+ the regression as outlined in 'Special handling for high priority issues'.
+ Then wait for further instructions.
The reference section below explains each of these steps in more detail.
@@ -1236,14 +1240,32 @@ Reports for high priority issues need special handling.
**Severe issues**: make sure the subject or ticket title as well as the first
paragraph makes the severeness obvious.
-**Regressions**: If the issue is a regression add [REGRESSION] to the mail's
-subject or the title in the bug-tracker. If you did not perform a bisection
-mention at least the latest mainline version you tested that worked fine (say
-5.7) and the oldest where the issue occurs (say 5.8). If you did a successful
-bisection mention the commit id and subject of the change that causes the
-regression. Also make sure to add the author of that change to your report; if
-you need to file your bug in a bug-tracker forward the report to him in a
-private mail and mention where your filed it.
+**Regressions**: Make the report's subject start with '[REGRESSION]'.
+
+In case you performed a successful bisection, use the title of the change that
+introduced the regression as the second part of your subject. Make the report
+also mention the commit id of the culprit. For tracking purposes, add a line
+like the following that contains both pieces of information, but with the
+commit id shortened to 12 characters::
+
+ #regzb introduced: 94a632d91ad1 ("usc: xhbi-foo: check bar_params earlier")
+
+In case of an unsuccessful bisection, make your report mention the latest tested
+version that's working fine (say 5.7) and the oldest where the issue occurs (say
+5.8-rc1). For tracking purposes add a line expressing it like this::
+
+ #regzb introduced: v5.7..v5.8-rc1
+
+When sending the report by mail, CC the Linux regressions mailing list
+(regressions@lists.linux.dev). In case the report needs to be filed to some web
+tracker, proceed to do so; once filed, forward the report by mail to the
+regressions list. Make sure to inline the forwarded report, hence do not attach
+it. Also add a short note at the top where you mention the URL to the ticket and
+repeat the line starting with '#regzb'.
+
+When mailing or forwarding the report, in case of a successful bisection add the
+author of the culprit to the recipients; also CC everyone in the signed-off-by
+chain, which you find at the end of its commit message.
**Security issues**: for these issues your will have to evaluate if a
short-term risk to other users would arise if details were publicly disclosed.
@@ -1523,9 +1545,11 @@ Report the regression
~~~~~~~~~~~~~~~~~~~~~
*Send a short problem report to the Linux stable mailing list
- (stable@vger.kernel.org). Roughly describe the issue and ideally explain
- how to reproduce it. Mention the first version that shows the problem and
- the last version that's working fine. Then wait for further instructions.*
+ (stable@vger.kernel.org) and CC the Linux regressions mailing list
+ (regressions@lists.linux.dev). Roughly describe the issue and ideally
+ explain how to reproduce it. Mention the commit or version that introduced
+ the regression as outlined in 'Special handling for high priority issues'.
+ Then wait for further instructions.*
When reporting a regression that happens within a stable or longterm kernel
line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
--
2.30.2
^ permalink raw reply related [relevance 7%]
* [PATCH v5 3/7] configfs-tsm: Introduce a shared ABI for attestation reports
@ 2023-10-11 5:27 7% ` Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2023-10-11 5:27 UTC (permalink / raw)
To: linux-coco
Cc: Kuppuswamy Sathyanarayanan, Dionna Amalie Glaze, James Bottomley,
Peter Gonda, Greg Kroah-Hartman, Samuel Ortiz, Greg Kroah-Hartman,
Thomas Gleixner, peterz, sathyanarayanan.kuppuswamy, dave.hansen,
bp
One of the common operations of a TSM (Trusted Security Module) is to
provide a way for a TVM (confidential computing guest execution
environment) to take a measurement of its launch state, sign it and
submit it to a verifying party. Upon successful attestation that
verifies the integrity of the TVM additional secrets may be deployed.
The concept is common across TSMs, but the implementations are
unfortunately vendor specific. While the industry grapples with a common
definition of this attestation format [1], Linux need not make this
problem worse by defining a new ABI per TSM that wants to perform a
similar operation. The current momentum has been to invent new ioctl-ABI
per TSM per function which at best is an abdication of the kernel's
responsibility to make common infrastructure concepts share common ABI.
The proposal, targeted to conceptually work with TDX, SEV-SNP, COVE if
not more, is to define a configfs interface to retrieve the TSM-specific
blob.
report=/sys/kernel/config/tsm/report/report0
mkdir $report
dd if=binary_userdata_plus_nonce > $report/inblob
hexdump $report/outblob
This approach later allows for the standardization of the attestation
blob format without needing to invent a new ABI. Once standardization
happens the standard format can be emitted by $report/outblob and
indicated by $report/provider, or a new attribute like
"$report/tcg_coco_report" can emit the standard format alongside the
vendor format.
Review of previous iterations of this interface identified that there is
a need to scale report generation for multiple container environments
[2]. Configfs enables a model where each container can bind mount one or
more report generation item instances. Still, within a container only a
single thread can be manipulating a given configuration instance at a
time. A 'generation' count is provided to detect conflicts between
multiple threads racing to configure a report instance.
The SEV-SNP concepts of "extended reports" and "privilege levels" are
optionally enabled by selecting 'tsm_report_ext_type' at register_tsm()
time. The expectation is that those concepts are generic enough that
they may be adopted by other TSM implementations. In other words,
configfs-tsm aims to address a superset of TSM specific functionality
with a common ABI where attributes may appear, or not appear, based on
the set of concepts the implementation supports.
Link: http://lore.kernel.org/r/64961c3baf8ce_142af829436@dwillia2-xfh.jf.intel.com.notmuch [1]
Link: http://lore.kernel.org/r/57f3a05e-8fcd-4656-beea-56bb8365ae64@linux.microsoft.com [2]
Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Peter Gonda <pgonda@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Samuel Ortiz <sameo@rivosinc.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Documentation/ABI/testing/configfs-tsm | 76 ++++++
MAINTAINERS | 8 +
drivers/virt/coco/Kconfig | 5
drivers/virt/coco/Makefile | 1
drivers/virt/coco/tsm.c | 416 ++++++++++++++++++++++++++++++++
include/linux/tsm.h | 68 +++++
6 files changed, 574 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-tsm
create mode 100644 drivers/virt/coco/tsm.c
create mode 100644 include/linux/tsm.h
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
new file mode 100644
index 000000000000..8c6987ece462
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -0,0 +1,76 @@
+What: /sys/kernel/config/tsm/report/$name/inblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Up to 64 bytes of user specified binary data. For replay
+ protection this should include a nonce, but the kernel does not
+ place any restrictions on the content.
+
+What: /sys/kernel/config/tsm/report/$name/outblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Binary attestation report generated from @inblob and other
+ options The format of the report is implementation specific
+ where the implementation is conveyed via the @provider
+ attribute.
+
+What: /sys/kernel/config/tsm/report/$name/certs
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Zero or more certificates in concatenated PEM format. Refer
+ to implementation specific documentation on which certificates
+ might be returned.
+
+What: /sys/kernel/config/tsm/report/$name/provider
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) A name for the format-specification of @outblob like
+ "sev-guest" [1] or "tdx-guest" [2] in the near term, or a
+ common standard format in the future.
+
+ [1]: SEV Secure Nested Paging Firmware ABI Specification
+ Revision 1.55 Table 22
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf
+
+ [2]: Intel® Trust Domain Extensions Data Center Attestation
+ Primitives : Quote Generation Library and Quote Verification
+ Library Revision 0.8 Appendix 4,5
+ https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf
+
+What: /sys/kernel/config/tsm/report/$name/generation
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) The value in this attribute increments each time @inblob or
+ any option is written. Userspace can detect conflicts by
+ checking generation before writing to any attribute and making
+ sure the number of writes matches expectations after reading
+ @outblob, or it can prevent conflicts by creating a report
+ instance per requesting context.
+
+What: /sys/kernel/config/tsm/report/$name/privlevel
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) If a TSM implementation supports the concept of attestation
+ reports for TVMs running at different privilege levels, like
+ SEV-SNP "VMPL", specify the privilege level via this attribute.
+ The minimum acceptable value is conveyed via @privlevel_floor
+ and the maximum acceptable value is TSM_PRIVLEVEL_MAX (3).
+
+What: /sys/kernel/config/tsm/report/$name/privlevel_floor
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Indicates the minimum permissible value that can be written
+ to @privlevel.
diff --git a/MAINTAINERS b/MAINTAINERS
index b19995690904..8acbeb029ba1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21889,6 +21889,14 @@ W: https://github.com/srcres258/linux-doc
T: git git://github.com/srcres258/linux-doc.git doc-zh-tw
F: Documentation/translations/zh_TW/
+TRUSTED SECURITY MODULE (TSM) ATTESTATION REPORTS
+M: Dan Williams <dan.j.williams@intel.com>
+L: linux-coco@lists.linux.dev
+S: Maintained
+F: Documentation/ABI/testing/configfs-tsm
+F: drivers/virt/coco/tsm.c
+F: include/linux/tsm.h
+
TTY LAYER AND SERIAL DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Jiri Slaby <jirislaby@kernel.org>
diff --git a/drivers/virt/coco/Kconfig b/drivers/virt/coco/Kconfig
index fc5c64f04c4a..87d142c1f932 100644
--- a/drivers/virt/coco/Kconfig
+++ b/drivers/virt/coco/Kconfig
@@ -2,6 +2,11 @@
#
# Confidential computing related collateral
#
+
+config TSM_REPORTS
+ select CONFIGFS_FS
+ tristate
+
source "drivers/virt/coco/efi_secret/Kconfig"
source "drivers/virt/coco/sev-guest/Kconfig"
diff --git a/drivers/virt/coco/Makefile b/drivers/virt/coco/Makefile
index 55302ef719ad..18c1aba5edb7 100644
--- a/drivers/virt/coco/Makefile
+++ b/drivers/virt/coco/Makefile
@@ -2,6 +2,7 @@
#
# Confidential computing related collateral
#
+obj-$(CONFIG_TSM_REPORTS) += tsm.o
obj-$(CONFIG_EFI_SECRET) += efi_secret/
obj-$(CONFIG_SEV_GUEST) += sev-guest/
obj-$(CONFIG_INTEL_TDX_GUEST) += tdx-guest/
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
new file mode 100644
index 000000000000..054fec924bea
--- /dev/null
+++ b/drivers/virt/coco/tsm.c
@@ -0,0 +1,416 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright(c) 2023 Intel Corporation. All rights reserved. */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/tsm.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/rwsem.h>
+#include <linux/string.h>
+#include <linux/module.h>
+#include <linux/cleanup.h>
+#include <linux/configfs.h>
+
+static struct tsm_provider {
+ const struct tsm_ops *ops;
+ const struct config_item_type *type;
+ void *data;
+} provider;
+static DECLARE_RWSEM(tsm_rwsem);
+
+/**
+ * DOC: Trusted Security Module (TSM) Attestation Report Interface
+ *
+ * The TSM report interface is a common provider of blobs that facilitate
+ * attestation of a TVM (confidential computing guest) by an attestation
+ * service. A TSM report combines a user-defined blob (likely a public-key with
+ * a nonce for a key-exchange protocol) with a signed attestation report. That
+ * combined blob is then used to obtain secrets provided by an agent that can
+ * validate the attestation report. The expectation is that this interface is
+ * invoked infrequently, however configfs allows for multiple agents to
+ * own their own report generation instances to generate reports as
+ * often as needed.
+ *
+ * The attestation report format is TSM provider specific, when / if a standard
+ * materializes that can be published instead of the vendor layout. Until then
+ * the 'provider' attribute indicates the format of 'outblob'. However,
+ * the common "return a list of certs" capability across multiple TSM
+ * implementations is returned in a unified @certs attribute.
+ */
+
+struct tsm_report_state {
+ struct tsm_report report;
+ unsigned long write_generation;
+ unsigned long read_generation;
+ struct config_item cfg;
+};
+
+enum tsm_data_select {
+ TSM_REPORT,
+ TSM_CERTS,
+};
+
+static struct tsm_report *to_tsm_report(struct config_item *cfg)
+{
+ struct tsm_report_state *state =
+ container_of(cfg, struct tsm_report_state, cfg);
+
+ return &state->report;
+}
+
+static struct tsm_report_state *to_state(struct tsm_report *report)
+{
+ return container_of(report, struct tsm_report_state, report);
+}
+
+static int try_advance_write_generation(struct tsm_report *report)
+{
+ struct tsm_report_state *state = to_state(report);
+
+ lockdep_assert_held_write(&tsm_rwsem);
+
+ /*
+ * Malicious or broken userspace has written enough times for
+ * read_generation == write_generation by modular arithmetic without an
+ * interim read. Stop accepting updates until the current report
+ * configuration is read.
+ */
+ if (state->write_generation == state->read_generation - 1)
+ return -EBUSY;
+ state->write_generation++;
+ return 0;
+}
+
+static ssize_t tsm_report_privlevel_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ /*
+ * The valid privilege levels that a TSM might accept, if it accepts a
+ * privilege level setting at all, are a max of TSM_PRIVLEVEL_MAX (see
+ * SEV-SNP GHCB) and a minimum of a TSM selected floor value no less
+ * than 0.
+ */
+ if (provider.ops->privlevel_floor > val || val > TSM_PRIVLEVEL_MAX)
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.privlevel = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, privlevel);
+
+static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
+ char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%u\n", provider.ops->privlevel_floor);
+}
+CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+
+static ssize_t tsm_report_inblob_write(struct config_item *cfg,
+ const void *buf, size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ report->desc.inblob_len = count;
+ memcpy(report->desc.inblob, buf, count);
+ return count;
+}
+CONFIGFS_BIN_ATTR_WO(tsm_report_, inblob, NULL, TSM_INBLOB_MAX);
+
+static ssize_t tsm_report_generation_show(struct config_item *cfg, char *buf)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ struct tsm_report_state *state = to_state(report);
+
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%lu\n", state->write_generation);
+}
+CONFIGFS_ATTR_RO(tsm_report_, generation);
+
+static ssize_t tsm_report_provider_show(struct config_item *cfg, char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%s\n", provider.ops->name);
+}
+CONFIGFS_ATTR_RO(tsm_report_, provider);
+
+static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
+ enum tsm_data_select select)
+{
+ loff_t offset = 0;
+ ssize_t len;
+ u8 *out;
+
+ if (select == TSM_REPORT) {
+ out = report->outblob;
+ len = report->outblob_len;
+ } else {
+ out = report->certs;
+ len = report->certs_len;
+ }
+
+ /*
+ * Recall that a NULL @buf is configfs requesting the size of
+ * the buffer.
+ */
+ if (!buf)
+ return len;
+ return memory_read_from_buffer(buf, count, &offset, out, len);
+}
+
+static ssize_t read_cached_report(struct tsm_report *report, void *buf,
+ size_t count, enum tsm_data_select select)
+{
+ struct tsm_report_state *state = to_state(report);
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ /*
+ * A given TSM backend always fills in ->outblob regardless of
+ * whether the report includes certs or not.
+ */
+ if (!report->outblob ||
+ state->read_generation != state->write_generation)
+ return -EWOULDBLOCK;
+
+ return __read_report(report, buf, count, select);
+}
+
+static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
+ size_t count, enum tsm_data_select select)
+{
+ struct tsm_report_state *state = to_state(report);
+ const struct tsm_ops *ops;
+ ssize_t rc;
+
+ /* try to read from the existing report if present and valid... */
+ rc = read_cached_report(report, buf, count, select);
+ if (rc >= 0 || rc != -EWOULDBLOCK)
+ return rc;
+
+ /* slow path, report may need to be regenerated... */
+ guard(rwsem_write)(&tsm_rwsem);
+ ops = provider.ops;
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ /* did another thread already generate this report? */
+ if (report->outblob &&
+ state->read_generation == state->write_generation)
+ goto out;
+
+ kvfree(report->outblob);
+ kvfree(report->certs);
+ report->outblob = NULL;
+ report->certs = NULL;
+ rc = ops->report_new(report, provider.data);
+ if (rc < 0)
+ return rc;
+ state->read_generation = state->write_generation;
+out:
+ return __read_report(report, buf, count, select);
+}
+
+static ssize_t tsm_report_outblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_REPORT);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, outblob, NULL, TSM_OUTBLOB_MAX);
+
+static ssize_t tsm_report_certs_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_CERTS);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, certs, NULL, TSM_OUTBLOB_MAX);
+
+#define TSM_DEFAULT_ATTRS() \
+ &tsm_report_attr_generation, \
+ &tsm_report_attr_provider
+
+static struct configfs_attribute *tsm_report_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ NULL,
+};
+
+static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
+ &tsm_report_attr_inblob,
+ &tsm_report_attr_outblob,
+ &tsm_report_attr_certs,
+ NULL,
+};
+
+static struct configfs_attribute *tsm_report_extra_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ &tsm_report_attr_privlevel,
+ &tsm_report_attr_privlevel_floor,
+ NULL,
+};
+
+static void tsm_report_item_release(struct config_item *cfg)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ struct tsm_report_state *state = to_state(report);
+
+ kvfree(report->certs);
+ kvfree(report->outblob);
+ kfree(state);
+}
+
+static struct configfs_item_operations tsm_report_item_ops = {
+ .release = tsm_report_item_release,
+};
+
+const struct config_item_type tsm_report_default_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_attrs,
+ .ct_attrs = tsm_report_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_default_type);
+
+const struct config_item_type tsm_report_ext_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_attrs,
+ .ct_attrs = tsm_report_extra_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_ext_type);
+
+static struct config_item *tsm_report_make_item(struct config_group *group,
+ const char *name)
+{
+ struct tsm_report_state *state;
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!provider.ops)
+ return ERR_PTR(-ENXIO);
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ config_item_init_type_name(&state->cfg, name, provider.type);
+ return &state->cfg;
+}
+
+static struct configfs_group_operations tsm_report_group_ops = {
+ .make_item = tsm_report_make_item,
+};
+
+static const struct config_item_type tsm_reports_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_group_ops = &tsm_report_group_ops,
+};
+
+static const struct config_item_type tsm_root_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static struct configfs_subsystem tsm_configfs = {
+ .su_group = {
+ .cg_item = {
+ .ci_namebuf = "tsm",
+ .ci_type = &tsm_root_group_type,
+ },
+ },
+ .su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
+};
+
+static struct config_group *tsm_report_group;
+
+int tsm_register(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type)
+{
+ const struct tsm_ops *conflict;
+
+ if (!type)
+ type = &tsm_report_default_type;
+ if (!(type == &tsm_report_default_type || type == &tsm_report_ext_type))
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ conflict = provider.ops;
+ if (conflict) {
+ pr_err("\"%s\" ops already registered\n", conflict->name);
+ return -EBUSY;
+ }
+
+ provider.ops = ops;
+ provider.data = priv;
+ provider.type = type;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(tsm_register);
+
+int tsm_unregister(const struct tsm_ops *ops)
+{
+ guard(rwsem_write)(&tsm_rwsem);
+ if (ops != provider.ops)
+ return -EBUSY;
+ provider.ops = NULL;
+ provider.data = NULL;
+ provider.type = NULL;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(tsm_unregister);
+
+static int __init tsm_init(void)
+{
+ struct config_group *root = &tsm_configfs.su_group;
+ struct config_group *tsm;
+ int rc;
+
+ config_group_init(root);
+ rc = configfs_register_subsystem(&tsm_configfs);
+ if (rc)
+ return rc;
+
+ tsm = configfs_register_default_group(root, "report",
+ &tsm_reports_type);
+ if (IS_ERR(tsm)) {
+ configfs_unregister_subsystem(&tsm_configfs);
+ return PTR_ERR(tsm);
+ }
+ tsm_report_group = tsm;
+
+ return 0;
+}
+module_init(tsm_init);
+
+static void __exit tsm_exit(void)
+{
+ configfs_unregister_default_group(tsm_report_group);
+ configfs_unregister_subsystem(&tsm_configfs);
+}
+module_exit(tsm_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Provide Trusted Security Module attestation reports via configfs");
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
new file mode 100644
index 000000000000..d6c0752502e0
--- /dev/null
+++ b/include/linux/tsm.h
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __TSM_H
+#define __TSM_H
+
+#include <linux/sizes.h>
+#include <linux/types.h>
+#include <linux/device.h>
+
+#define TSM_INBLOB_MAX 64
+#define TSM_OUTBLOB_MAX SZ_32K
+
+/*
+ * Privilege level is a nested permission concept to allow confidential
+ * guests to partition address space, 4-levels are supported.
+ */
+#define TSM_PRIVLEVEL_MAX 3
+
+/**
+ * struct tsm_desc - option descriptor for generating tsm report blobs
+ * @privlevel: optional privilege level to associate with @outblob
+ * @inblob_len: sizeof @inblob
+ * @inblob: arbitrary input data
+ */
+struct tsm_desc {
+ unsigned int privlevel;
+ size_t inblob_len;
+ u8 inblob[TSM_INBLOB_MAX];
+};
+
+/**
+ * struct tsm_report - track state of report generation relative to options
+ * @desc: input parameters to @report_new()
+ * @outblob_len: sizeof(@outblob)
+ * @outblob: generated evidence to provider to the attestation agent
+ * @certs_len: sizeof(@certs)
+ * @certs: concatenated list of PEM formatted certificates
+ */
+struct tsm_report {
+ struct tsm_desc desc;
+ size_t outblob_len;
+ u8 *outblob;
+ size_t certs_len;
+ u8 *certs;
+};
+
+/**
+ * struct tsm_ops - attributes and operations for tsm instances
+ * @name: tsm id reflected in /sys/kernel/config/tsm/report/$report/provider
+ * @privlevel_floor: convey base privlevel for nested scenarios
+ * @report_new: Populate @report with the report blob and certs
+ * (optional), return 0 on successful population, or -errno otherwise
+ *
+ * Implementation specific ops, only one is expected to be registered at
+ * a time i.e. only one of "sev-guest", "tdx-guest", etc.
+ */
+struct tsm_ops {
+ const char *name;
+ const int privlevel_floor;
+ int (*report_new)(struct tsm_report *report, void *data);
+};
+
+extern const struct config_item_type tsm_report_ext_type;
+extern const struct config_item_type tsm_report_default_type;
+
+int tsm_register(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type);
+int tsm_unregister(const struct tsm_ops *ops);
+#endif /* __TSM_H */
^ permalink raw reply related [relevance 7%]
* [PATCH] MAINTAINERS: remove section LIBNVDIMM BLK: MMIO-APERTURE DRIVER
@ 2022-03-16 5:21 7% Lukas Bulwahn
0 siblings, 0 replies; 200+ results
From: Lukas Bulwahn @ 2022-03-16 5:21 UTC (permalink / raw)
To: Dan Williams, nvdimm
Cc: Vishal Verma, Dave Jiang, Ira Weiny, kernel-janitors,
linux-kernel, Lukas Bulwahn
Commit f8669f1d6a86 ("nvdimm/blk: Delete the block-aperture window driver")
removes the file drivers/nvdimm/blk.c, but misses to adjust MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a
broken reference.
The section LIBNVDIMM BLK: MMIO-APERTURE DRIVER refers to the driver in
blk.c, and some more generic nvdimm code in region_devs.c.
As the driver is deleted, delete the section LIBNVDIMM BLK: MMIO-APERTURE
DRIVER in MAINTAINERS as well.
The remaining file region_devs.c is still covered by the section LIBNVDIMM:
NON-VOLATILE MEMORY DEVICE SUBSYSTEM, and all patches to region_devs.c will
still reach the same developers as before.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
---
Dan, please pick this minor clean-up patch in your -next tree on top of
the commit above.
MAINTAINERS | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index faa5e53db1dd..5eacf125e052 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11128,17 +11128,6 @@ F: drivers/ata/
F: include/linux/ata.h
F: include/linux/libata.h
-LIBNVDIMM BLK: MMIO-APERTURE DRIVER
-M: Dan Williams <dan.j.williams@intel.com>
-M: Vishal Verma <vishal.l.verma@intel.com>
-M: Dave Jiang <dave.jiang@intel.com>
-L: nvdimm@lists.linux.dev
-S: Supported
-Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
-P: Documentation/nvdimm/maintainer-entry-profile.rst
-F: drivers/nvdimm/blk.c
-F: drivers/nvdimm/region_devs.c
-
LIBNVDIMM BTT: BLOCK TRANSLATION TABLE
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dan Williams <dan.j.williams@intel.com>
--
2.17.1
^ permalink raw reply related [relevance 7%]
* [PATCH 01/12] iommu/vt-d: Remove include/linux/intel-svm.h
@ 2023-01-31 7:37 7% ` Lu Baolu
0 siblings, 0 replies; 200+ results
From: Lu Baolu @ 2023-01-31 7:37 UTC (permalink / raw)
To: Joerg Roedel; +Cc: kan.liang, iommu, linux-kernel
There's no need to have a public header for Intel SVA implementation.
The device driver should interact with Intel SVA implementation via
the IOMMU generic APIs.
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20230109014955.147068-2-baolu.lu@linux.intel.com
---
include/linux/intel-svm.h | 16 ----------------
drivers/iommu/intel/iommu.h | 5 +++++
drivers/iommu/intel/iommu.c | 1 -
drivers/iommu/intel/svm.c | 1 -
MAINTAINERS | 1 -
5 files changed, 5 insertions(+), 19 deletions(-)
delete mode 100644 include/linux/intel-svm.h
diff --git a/include/linux/intel-svm.h b/include/linux/intel-svm.h
deleted file mode 100644
index f9a0d44f6fdb..000000000000
--- a/include/linux/intel-svm.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright © 2015 Intel Corporation.
- *
- * Authors: David Woodhouse <David.Woodhouse@intel.com>
- */
-
-#ifndef __INTEL_SVM_H__
-#define __INTEL_SVM_H__
-
-/* Page Request Queue depth */
-#define PRQ_ORDER 4
-#define PRQ_RING_MASK ((0x1000 << PRQ_ORDER) - 0x20)
-#define PRQ_DEPTH ((0x1000 << PRQ_ORDER) >> 5)
-
-#endif /* __INTEL_SVM_H__ */
diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h
index 06e61e474856..f89f63d7a72a 100644
--- a/drivers/iommu/intel/iommu.h
+++ b/drivers/iommu/intel/iommu.h
@@ -438,6 +438,11 @@ struct q_inval {
int free_cnt;
};
+/* Page Request Queue depth */
+#define PRQ_ORDER 4
+#define PRQ_RING_MASK ((0x1000 << PRQ_ORDER) - 0x20)
+#define PRQ_DEPTH ((0x1000 << PRQ_ORDER) >> 5)
+
struct dmar_pci_notify_info;
#ifdef CONFIG_IRQ_REMAP
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 59df7e42fd53..317af67b6098 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -16,7 +16,6 @@
#include <linux/crash_dump.h>
#include <linux/dma-direct.h>
#include <linux/dmi.h>
-#include <linux/intel-svm.h>
#include <linux/memory.h>
#include <linux/pci.h>
#include <linux/pci-ats.h>
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index c76b66263467..d38a54396c23 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -9,7 +9,6 @@
#include <linux/sched.h>
#include <linux/sched/mm.h>
#include <linux/slab.h>
-#include <linux/intel-svm.h>
#include <linux/rculist.h>
#include <linux/pci.h>
#include <linux/pci-ats.h>
diff --git a/MAINTAINERS b/MAINTAINERS
index f781f936ae35..dbc36fa870d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10458,7 +10458,6 @@ L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/intel/
-F: include/linux/intel-svm.h
INTEL IPU3 CSI-2 CIO2 DRIVER
M: Yong Zhi <yong.zhi@intel.com>
--
2.34.1
^ permalink raw reply related [relevance 7%]
* [PATCH 1/4] iommu/vt-d: Remove include/linux/intel-svm.h
@ 2023-01-09 1:49 7% ` Lu Baolu
0 siblings, 0 replies; 200+ results
From: Lu Baolu @ 2023-01-09 1:49 UTC (permalink / raw)
To: iommu
Cc: Joerg Roedel, Will Deacon, Robin Murphy, Kevin Tian, linux-kernel,
Lu Baolu
There's no need to have a public header for Intel SVA implementation.
The device driver should interact with Intel SVA implementation via
the IOMMU generic APIs.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
include/linux/intel-svm.h | 16 ----------------
drivers/iommu/intel/iommu.h | 5 +++++
drivers/iommu/intel/iommu.c | 1 -
drivers/iommu/intel/svm.c | 1 -
MAINTAINERS | 1 -
5 files changed, 5 insertions(+), 19 deletions(-)
delete mode 100644 include/linux/intel-svm.h
diff --git a/include/linux/intel-svm.h b/include/linux/intel-svm.h
deleted file mode 100644
index f9a0d44f6fdb..000000000000
--- a/include/linux/intel-svm.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright © 2015 Intel Corporation.
- *
- * Authors: David Woodhouse <David.Woodhouse@intel.com>
- */
-
-#ifndef __INTEL_SVM_H__
-#define __INTEL_SVM_H__
-
-/* Page Request Queue depth */
-#define PRQ_ORDER 4
-#define PRQ_RING_MASK ((0x1000 << PRQ_ORDER) - 0x20)
-#define PRQ_DEPTH ((0x1000 << PRQ_ORDER) >> 5)
-
-#endif /* __INTEL_SVM_H__ */
diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h
index 06e61e474856..f89f63d7a72a 100644
--- a/drivers/iommu/intel/iommu.h
+++ b/drivers/iommu/intel/iommu.h
@@ -438,6 +438,11 @@ struct q_inval {
int free_cnt;
};
+/* Page Request Queue depth */
+#define PRQ_ORDER 4
+#define PRQ_RING_MASK ((0x1000 << PRQ_ORDER) - 0x20)
+#define PRQ_DEPTH ((0x1000 << PRQ_ORDER) >> 5)
+
struct dmar_pci_notify_info;
#ifdef CONFIG_IRQ_REMAP
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 59df7e42fd53..317af67b6098 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -16,7 +16,6 @@
#include <linux/crash_dump.h>
#include <linux/dma-direct.h>
#include <linux/dmi.h>
-#include <linux/intel-svm.h>
#include <linux/memory.h>
#include <linux/pci.h>
#include <linux/pci-ats.h>
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index c76b66263467..d38a54396c23 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -9,7 +9,6 @@
#include <linux/sched.h>
#include <linux/sched/mm.h>
#include <linux/slab.h>
-#include <linux/intel-svm.h>
#include <linux/rculist.h>
#include <linux/pci.h>
#include <linux/pci-ats.h>
diff --git a/MAINTAINERS b/MAINTAINERS
index a36df9ed283d..43fd97f0e1df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10459,7 +10459,6 @@ L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/intel/
-F: include/linux/intel-svm.h
INTEL IPU3 CSI-2 CIO2 DRIVER
M: Yong Zhi <yong.zhi@intel.com>
--
2.34.1
^ permalink raw reply related [relevance 7%]
* + maintainers-add-maillist-information-for-loongarch.patch added to mm-hotfixes-unstable branch
@ 2022-06-16 18:36 7% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2022-06-16 18:36 UTC (permalink / raw)
To: mm-commits, lixuefeng, kernel, jiaxun.yang, guoren, git, arnd,
chenhuacai, akpm
The patch titled
Subject: MAINTAINERS: add maillist information for LoongArch
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
maintainers-add-maillist-information-for-loongarch.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/maintainers-add-maillist-information-for-loongarch.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Huacai Chen <chenhuacai@loongson.cn>
Subject: MAINTAINERS: add maillist information for LoongArch
Date: Thu, 16 Jun 2022 20:14:56 +0800
Now there is a dedicated maillist (loongarch@lists.linux.dev) for
LoongArch, add it for better collaboration.
Link: https://lkml.kernel.org/r/20220616121456.3613470-1-chenhuacai@loongson.cn
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Cc: Huacai Chen <chenhuacai@loongson.cn>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Cc: Guo Ren <guoren@kernel.org>
Cc: Xuerui Wang <kernel@xen0n.name>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
--- a/MAINTAINERS~maintainers-add-maillist-information-for-loongarch
+++ a/MAINTAINERS
@@ -11591,6 +11591,7 @@ F: drivers/gpu/drm/bridge/lontium-lt8912
LOONGARCH
M: Huacai Chen <chenhuacai@kernel.org>
R: WANG Xuerui <kernel@xen0n.name>
+L: loongarch@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git
F: arch/loongarch/
_
Patches currently in -mm which might be from chenhuacai@loongson.cn are
maintainers-add-maillist-information-for-loongarch.patch
^ permalink raw reply [relevance 7%]
* [PATCH v4 2/6] configfs-tsm: Introduce a shared ABI for attestation reports
@ 2023-09-26 4:17 7% ` Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2023-09-26 4:17 UTC (permalink / raw)
To: linux-coco
Cc: Kuppuswamy Sathyanarayanan, Dionna Amalie Glaze, James Bottomley,
Peter Gonda, Greg Kroah-Hartman, Samuel Ortiz, Greg Kroah-Hartman,
Thomas Gleixner, peterz, linux-kernel, x86, dave.hansen
One of the common operations of a TSM (Trusted Security Module) is to
provide a way for a TVM (confidential computing guest execution
environment) to take a measurement of its launch state, sign it and
submit it to a verifying party. Upon successful attestation that
verifies the integrity of the TVM additional secrets may be deployed.
The concept is common across TSMs, but the implementations are
unfortunately vendor specific. While the industry grapples with a common
definition of this attestation format [1], Linux need not make this
problem worse by defining a new ABI per TSM that wants to perform a
similar operation. The current momentum has been to invent new ioctl-ABI
per TSM per function which at best is an abdication of the kernel's
responsibility to make common infrastructure concepts share common ABI.
The proposal, targeted to conceptually work with TDX, SEV-SNP, COVE if
not more, is to define a configfs interface to retrieve the TSM-specific
blob.
report=/sys/kernel/config/tsm/report/report0
mkdir $report
dd if=binary_userdata_plus_nonce > $report/inblob
hexdump $report/outblob
This approach later allows for the standardization of the attestation
blob format without needing to invent a new ABI. Once standardization
happens the standard format can be emitted by $report/outblob and
indicated by $report/provider, or a new attribute like
"$report/tcg_coco_report" can emit the standard format alongside the
vendor format.
Review of previous iterations of this interface identified that there is
a need to scale report generation for multiple container environments
[2]. Configfs enables a model where each container can bind mount one or
more report generation item instances. Still, within a container only a
single thread can be manipulating a given configuration instance at a
time. A 'generation' count is provided to detect conflicts between
multiple threads racing to configure a report instance.
The SEV-SNP concepts of "extended reports" and "privilege levels" are
optionally enabled by selecting 'tsm_report_ext_type' at register_tsm()
time. The expectation is that those concepts are generic enough that
they may be adopted by other TSM implementations. In other words,
configfs-tsm aims to address a superset of TSM specific functionality
with a common ABI where attributes may appear, or not appear, based on the set
of concepts the implementation supports.
Link: http://lore.kernel.org/r/64961c3baf8ce_142af829436@dwillia2-xfh.jf.intel.com.notmuch [1]
Link: http://lore.kernel.org/r/57f3a05e-8fcd-4656-beea-56bb8365ae64@linux.microsoft.com [2]
Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Peter Gonda <pgonda@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Samuel Ortiz <sameo@rivosinc.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Documentation/ABI/testing/configfs-tsm | 67 +++++
MAINTAINERS | 8 +
drivers/virt/coco/Kconfig | 5
drivers/virt/coco/Makefile | 1
drivers/virt/coco/tsm.c | 411 ++++++++++++++++++++++++++++++++
include/linux/tsm.h | 63 +++++
6 files changed, 555 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-tsm
create mode 100644 drivers/virt/coco/tsm.c
create mode 100644 include/linux/tsm.h
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
new file mode 100644
index 000000000000..ba81083046d3
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -0,0 +1,67 @@
+What: /sys/kernel/config/tsm/report/$name/inblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Up to 64 bytes of user specified binary data. For replay
+ protection this should include a nonce, but the kernel does not
+ place any restrictions on the content.
+
+What: /sys/kernel/config/tsm/report/$name/outblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Binary attestation report generated from @inblob and other
+ options The format of the report is implementation specific
+ where the implementation is conveyed via the @provider
+ attribute.
+
+What: /sys/kernel/config/tsm/report/$name/certs
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Zero or more certificates in concatenated PEM format. Refer
+ to implementation specific documentation on which certificates
+ might be returned.
+
+What: /sys/kernel/config/tsm/report/$name/provider
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) A name for the format-specification of @outblob like
+ "sev-snp" or "tdx" in the near term, or a common standard format
+ in the future.
+
+What: /sys/kernel/config/tsm/report/$name/generation
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) The value in this attribute increments each time @inblob or
+ any option is written. Userspace can detect conflicts by
+ checking generation before writing to any attribute and making
+ sure the number of writes matches expectations after reading
+ @outblob, or it can prevent conflicts by creating a report
+ instance per requesting context.
+
+What: /sys/kernel/config/tsm/report/$name/privlevel
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) If a TSM implementation supports the concept of attestation
+ reports for TVMs running at different privilege levels, like
+ SEV-SNP "VMPL", specify the privilege level via this attribute.
+ The minimum acceptable value is conveyed via @privlevel_floor
+ and the maximum acceptable value is TSM_PRIVLEVEL_MAX (3).
+
+What: /sys/kernel/config/tsm/report/$name/privlevel_floor
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Indicates the minimum permissible value that can be written
+ to @privlevel.
diff --git a/MAINTAINERS b/MAINTAINERS
index b19995690904..8acbeb029ba1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21889,6 +21889,14 @@ W: https://github.com/srcres258/linux-doc
T: git git://github.com/srcres258/linux-doc.git doc-zh-tw
F: Documentation/translations/zh_TW/
+TRUSTED SECURITY MODULE (TSM) ATTESTATION REPORTS
+M: Dan Williams <dan.j.williams@intel.com>
+L: linux-coco@lists.linux.dev
+S: Maintained
+F: Documentation/ABI/testing/configfs-tsm
+F: drivers/virt/coco/tsm.c
+F: include/linux/tsm.h
+
TTY LAYER AND SERIAL DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Jiri Slaby <jirislaby@kernel.org>
diff --git a/drivers/virt/coco/Kconfig b/drivers/virt/coco/Kconfig
index fc5c64f04c4a..87d142c1f932 100644
--- a/drivers/virt/coco/Kconfig
+++ b/drivers/virt/coco/Kconfig
@@ -2,6 +2,11 @@
#
# Confidential computing related collateral
#
+
+config TSM_REPORTS
+ select CONFIGFS_FS
+ tristate
+
source "drivers/virt/coco/efi_secret/Kconfig"
source "drivers/virt/coco/sev-guest/Kconfig"
diff --git a/drivers/virt/coco/Makefile b/drivers/virt/coco/Makefile
index 55302ef719ad..18c1aba5edb7 100644
--- a/drivers/virt/coco/Makefile
+++ b/drivers/virt/coco/Makefile
@@ -2,6 +2,7 @@
#
# Confidential computing related collateral
#
+obj-$(CONFIG_TSM_REPORTS) += tsm.o
obj-$(CONFIG_EFI_SECRET) += efi_secret/
obj-$(CONFIG_SEV_GUEST) += sev-guest/
obj-$(CONFIG_INTEL_TDX_GUEST) += tdx-guest/
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
new file mode 100644
index 000000000000..343fc77d0509
--- /dev/null
+++ b/drivers/virt/coco/tsm.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright(c) 2023 Intel Corporation. All rights reserved. */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/tsm.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/rwsem.h>
+#include <linux/string.h>
+#include <linux/module.h>
+#include <linux/cleanup.h>
+#include <linux/configfs.h>
+
+static struct tsm_provider {
+ const struct tsm_ops *ops;
+ const struct config_item_type *type;
+ void *data;
+} provider;
+static DECLARE_RWSEM(tsm_rwsem);
+
+/**
+ * DOC: Trusted Security Module (TSM) Attestation Report Interface
+ *
+ * The TSM report interface is a common provider of blobs that facilitate
+ * attestation of a TVM (confidential computing guest) by an attestation
+ * service. A TSM report combines a user-defined blob (likely a public-key with
+ * a nonce for a key-exchange protocol) with a signed attestation report. That
+ * combined blob is then used to obtain secrets provided by an agent that can
+ * validate the attestation report. The expectation is that this interface is
+ * invoked infrequently, however configfs allows for multiple agents to
+ * own their own report generation instances to generate reports as
+ * often as needed.
+ *
+ * The attestation report format is TSM provider specific, when / if a standard
+ * materializes that can be published instead of the vendor layout. Until then
+ * the 'provider' attribute indicates the format of 'outblob'. However,
+ * the common "return a list of certs" capability across multiple TSM
+ * implementations is returned in a unified @certs attribute.
+ */
+
+struct tsm_report_state {
+ struct tsm_report report;
+ unsigned long write_generation;
+ unsigned long read_generation;
+ struct config_item cfg;
+};
+
+enum tsm_data_select {
+ TSM_REPORT,
+ TSM_CERTS,
+};
+
+static struct tsm_report *to_tsm_report(struct config_item *cfg)
+{
+ struct tsm_report_state *state =
+ container_of(cfg, struct tsm_report_state, cfg);
+
+ return &state->report;
+}
+
+static struct tsm_report_state *to_state(struct tsm_report *report)
+{
+ return container_of(report, struct tsm_report_state, report);
+}
+
+static int try_advance_write_generation(struct tsm_report *report)
+{
+ struct tsm_report_state *state = to_state(report);
+
+ lockdep_assert_held_write(&tsm_rwsem);
+
+ /*
+ * Malicious or broken userspace has written enough times for
+ * read_generation == write_generation by modular arithmetic without an
+ * interim read. Stop accepting updates until the current report
+ * configuration is read.
+ */
+ if (state->write_generation == state->read_generation - 1)
+ return -EBUSY;
+ state->write_generation++;
+ return 0;
+}
+
+static ssize_t tsm_report_privlevel_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ /*
+ * The valid privilege levels that a TSM might accept, if it accepts a
+ * privilege level setting at all, are a max of TSM_PRIVLEVEL_MAX (see
+ * SEV-SNP GHCB) and a minimum of a TSM selected floor value no less
+ * than 0.
+ */
+ if (provider.ops->privlevel_floor > val || val > TSM_PRIVLEVEL_MAX)
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.privlevel = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, privlevel);
+
+static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
+ char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%u\n", provider.ops->privlevel_floor);
+}
+CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+
+static ssize_t tsm_report_inblob_write(struct config_item *cfg,
+ const void *buf, size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ report->desc.inblob_len = count;
+ memcpy(report->desc.inblob, buf, count);
+ return count;
+}
+CONFIGFS_BIN_ATTR_WO(tsm_report_, inblob, NULL, TSM_INBLOB_MAX);
+
+static ssize_t tsm_report_generation_show(struct config_item *cfg, char *buf)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ struct tsm_report_state *state = to_state(report);
+
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%lu\n", state->write_generation);
+}
+CONFIGFS_ATTR_RO(tsm_report_, generation);
+
+static ssize_t tsm_report_provider_show(struct config_item *cfg, char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%s\n", provider.ops->name);
+}
+CONFIGFS_ATTR_RO(tsm_report_, provider);
+
+static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
+ enum tsm_data_select select)
+{
+ loff_t offset = 0;
+ u8 *out, len;
+
+ if (select == TSM_REPORT) {
+ out = report->outblob;
+ len = report->outblob_len;
+ } else {
+ out = report->certs;
+ len = report->certs_len;
+ }
+
+ if (!buf)
+ return len;
+ return memory_read_from_buffer(buf, count, &offset, out, len);
+}
+
+static ssize_t read_cached_report(struct tsm_report *report, void *buf,
+ size_t count, enum tsm_data_select select)
+{
+ struct tsm_report_state *state = to_state(report);
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ /*
+ * A given TSM backend always fills in ->outblob regardless of
+ * whether the report includes certs or not.
+ */
+ if (!report->outblob ||
+ state->read_generation != state->write_generation)
+ return -EWOULDBLOCK;
+
+ return __read_report(report, buf, count, select);
+}
+
+static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
+ size_t count, enum tsm_data_select select)
+{
+ struct tsm_report_state *state = to_state(report);
+ const struct tsm_ops *ops;
+ ssize_t rc;
+
+ /* try to read from the existing report if present and valid... */
+ rc = read_cached_report(report, buf, count, select);
+ if (rc >= 0 || rc != -EWOULDBLOCK)
+ return rc;
+
+ /* slow path, report may need to be regenerated... */
+ guard(rwsem_write)(&tsm_rwsem);
+ ops = provider.ops;
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ /* did another thread already generate this report? */
+ if (report->outblob &&
+ state->read_generation == state->write_generation)
+ goto out;
+
+ kvfree(report->outblob);
+ kvfree(report->certs);
+ report->outblob = NULL;
+ report->certs = NULL;
+ rc = ops->report_new(report, provider.data);
+ if (rc < 0)
+ return rc;
+ state->read_generation = state->write_generation;
+out:
+ return __read_report(report, buf, count, select);
+}
+
+static ssize_t tsm_report_outblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_REPORT);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, outblob, NULL, TSM_OUTBLOB_MAX);
+
+static ssize_t tsm_report_certs_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_CERTS);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, certs, NULL, TSM_OUTBLOB_MAX);
+
+#define TSM_DEFAULT_ATTRS() \
+ &tsm_report_attr_generation, \
+ &tsm_report_attr_provider
+
+static struct configfs_attribute *tsm_report_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ NULL,
+};
+
+static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
+ &tsm_report_attr_inblob,
+ &tsm_report_attr_outblob,
+ &tsm_report_attr_certs,
+ NULL,
+};
+
+static struct configfs_attribute *tsm_report_extra_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ &tsm_report_attr_privlevel,
+ &tsm_report_attr_privlevel_floor,
+ NULL,
+};
+
+static void tsm_report_item_release(struct config_item *cfg)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ struct tsm_report_state *state = to_state(report);
+
+ kvfree(report->certs);
+ kvfree(report->outblob);
+ kfree(state);
+}
+
+static struct configfs_item_operations tsm_report_item_ops = {
+ .release = tsm_report_item_release,
+};
+
+const struct config_item_type tsm_report_default_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_attrs,
+ .ct_attrs = tsm_report_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_default_type);
+
+const struct config_item_type tsm_report_ext_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_attrs,
+ .ct_attrs = tsm_report_extra_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_ext_type);
+
+static struct config_item *tsm_report_make_item(struct config_group *group,
+ const char *name)
+{
+ struct tsm_report_state *state;
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!provider.ops)
+ return ERR_PTR(-ENXIO);
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ config_item_init_type_name(&state->cfg, name, provider.type);
+ return &state->cfg;
+}
+
+static struct configfs_group_operations tsm_report_group_ops = {
+ .make_item = tsm_report_make_item,
+};
+
+static const struct config_item_type tsm_reports_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_group_ops = &tsm_report_group_ops,
+};
+
+static const struct config_item_type tsm_root_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static struct configfs_subsystem tsm_configfs = {
+ .su_group = {
+ .cg_item = {
+ .ci_namebuf = "tsm",
+ .ci_type = &tsm_root_group_type,
+ },
+ },
+ .su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
+};
+
+static struct config_group *tsm_report_group;
+
+int tsm_register(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type)
+{
+ const struct tsm_ops *conflict;
+
+ if (!type)
+ type = &tsm_report_default_type;
+ if (!(type == &tsm_report_default_type || type == &tsm_report_ext_type))
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ conflict = provider.ops;
+ if (conflict) {
+ pr_err("\"%s\" ops already registered\n", conflict->name);
+ return -EBUSY;
+ }
+
+ provider.ops = ops;
+ provider.data = priv;
+ provider.type = type;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(tsm_register);
+
+int tsm_unregister(const struct tsm_ops *ops)
+{
+ guard(rwsem_write)(&tsm_rwsem);
+ if (ops != provider.ops)
+ return -EBUSY;
+ provider.ops = NULL;
+ provider.data = NULL;
+ provider.type = NULL;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(tsm_unregister);
+
+static int __init tsm_init(void)
+{
+ struct config_group *root = &tsm_configfs.su_group;
+ struct config_group *tsm;
+ int rc;
+
+ config_group_init(root);
+ rc = configfs_register_subsystem(&tsm_configfs);
+ if (rc)
+ return rc;
+
+ tsm = configfs_register_default_group(root, "report",
+ &tsm_reports_type);
+ if (IS_ERR(tsm)) {
+ configfs_unregister_subsystem(&tsm_configfs);
+ return PTR_ERR(tsm);
+ }
+ tsm_report_group = tsm;
+
+ return 0;
+}
+module_init(tsm_init);
+
+static void __exit tsm_exit(void)
+{
+ configfs_unregister_default_group(tsm_report_group);
+ configfs_unregister_subsystem(&tsm_configfs);
+}
+module_exit(tsm_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Provide Trusted Security Module attestation reports via configfs");
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
new file mode 100644
index 000000000000..1fe1dba3a912
--- /dev/null
+++ b/include/linux/tsm.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __TSM_H
+#define __TSM_H
+
+#include <linux/sizes.h>
+#include <linux/types.h>
+#include <linux/device.h>
+
+#define TSM_INBLOB_MAX 64
+#define TSM_OUTBLOB_MAX SZ_32K
+
+/*
+ * Privilege level is a nested permission concept to allow confidential
+ * guests to partition address space, 4-levels are supported.
+ */
+#define TSM_PRIVLEVEL_MAX 3
+
+/**
+ * struct tsm_desc - option descriptor for generating tsm report blobs
+ * @privlevel: optional privilege level to associate with @outblob
+ * @inblob_len: sizeof @inblob
+ * @inblob: arbitrary input data
+ */
+struct tsm_desc {
+ unsigned int privlevel;
+ size_t inblob_len;
+ u8 inblob[TSM_INBLOB_MAX];
+};
+
+/**
+ * struct tsm_report - track state of report generation relative to options
+ * @desc: report generation options / cached report state
+ * @outblob: generated evidence to provider to the attestation agent
+ * @outblob_len: sizeof(outblob)
+ * @write_generation: conflict detection, and report regeneration tracking
+ * @read_generation: cached report invalidation tracking
+ * @cfg: configfs interface
+ */
+struct tsm_report {
+ struct tsm_desc desc;
+ size_t outblob_len;
+ u8 *outblob;
+ size_t certs_len;
+ u8 *certs;
+};
+
+/*
+ * arch specific ops, only one is expected to be registered at a time
+ * i.e. only one of SEV, TDX, COVE, etc.
+ */
+struct tsm_ops {
+ const char *name;
+ const int privlevel_floor;
+ int (*report_new)(struct tsm_report *desc, void *data);
+};
+
+extern const struct config_item_type tsm_report_ext_type;
+extern const struct config_item_type tsm_report_default_type;
+
+int tsm_register(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type);
+int tsm_unregister(const struct tsm_ops *ops);
+#endif /* __TSM_H */
^ permalink raw reply related [relevance 7%]
* [PATCH v3 2/5] configfs-tsm: Introduce a shared ABI for attestation reports
@ 2023-08-30 19:33 7% ` Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2023-08-30 19:33 UTC (permalink / raw)
To: linux-coco
Cc: Kuppuswamy Sathyanarayanan, Dionna Amalie Glaze, James Bottomley,
Peter Gonda, Greg Kroah-Hartman, Samuel Ortiz, peterz,
linux-kernel, tglx
One of the common operations of a TSM (Trusted Security Module) is to
provide a way for a TVM (confidential computing guest execution
environment) to take a measurement of its launch state, sign it and
submit it to a verifying party. Upon successful attestation that
verifies the integrity of the TVM additional secrets may be deployed.
The concept is common across TSMs, but the implementations are
unfortunately vendor specific. While the industry grapples with a common
definition of this attestation format [1], Linux need not make this
problem worse by defining a new ABI per TSM that wants to perform a
similar operation. The current momentum has been to invent new ioctl-ABI
per TSM per function which at best is an abdication of the kernel's
responsibility to make common infrastructure concepts share common ABI.
The proposal, targeted to conceptually work with TDX, SEV-SNP, COVE if
not more, is to define a configfs interface to retrieve the TSM-specific
blob.
report=/sys/kernel/config/tsm/report/report0
mkdir $report
dd if=binary_userdata_plus_nonce > $report/inblob
hexdump $report/outblob
This approach later allows for the standardization of the attestation
blob format without needing to invent a new ABI. Once standardization
happens the standard format can be emitted by $report/outblob and
indicated by $report/provider, or a new attribute like
"$report/tcg_coco_report" can emit the standard format alongside the
vendor format.
Review of previous iterations of this interface identified that there is
a need to scale report generation for multiple container environments
[2]. Configfs enables a model where each container can bind mount one or
more report generation item instances. Still, within a container only a
single thread can be manipulating a given configuration instance at a
time. A 'generation' count is provided to detect conflicts between
multiple threads racing to configure a report instance.
The SEV-SNP concepts of "extended reports" and "privilege levels" are
optionally enabled by selecting 'tsm_report_ext_type' at register_tsm()
time. The expectation is that those concepts are generic enough that
they may be adopted by other TSM implementations. In other words,
configfs-tsm aims to address a superset of TSM specific functionality
with a common ABI where attributes may appear, or not appear, based on the set
of concepts the implementation supports.
Link: http://lore.kernel.org/r/64961c3baf8ce_142af829436@dwillia2-xfh.jf.intel.com.notmuch [1]
Link: http://lore.kernel.org/r/57f3a05e-8fcd-4656-beea-56bb8365ae64@linux.microsoft.com [2]
Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Peter Gonda <pgonda@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Samuel Ortiz <sameo@rivosinc.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Documentation/ABI/testing/configfs-tsm | 68 ++++++
MAINTAINERS | 8 +
drivers/virt/coco/Kconfig | 5
drivers/virt/coco/Makefile | 1
drivers/virt/coco/tdx-guest/Kconfig | 1
drivers/virt/coco/tsm.c | 391 ++++++++++++++++++++++++++++++++
include/linux/tsm.h | 54 ++++
7 files changed, 528 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-tsm
create mode 100644 drivers/virt/coco/tsm.c
create mode 100644 include/linux/tsm.h
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
new file mode 100644
index 000000000000..0f137039643b
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -0,0 +1,68 @@
+What: /sys/kernel/config/tsm/report/$name/inblob
+Date: August, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Up to 64 bytes of user specified binary data. For replay
+ protection this should include a nonce, but the kernel does not
+ place any restrictions on the content.
+
+What: /sys/kernel/config/tsm/report/$name/outblob
+Date: August, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Binary attestation report generated from @inblob and other
+ options The format of the report is implementation specific
+ (modulo options like @format and @privlevel) where the
+ implementation is conveyed via the @provider attribute.
+
+What: /sys/kernel/config/tsm/report/$name/provider
+Date: August, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) A name for the format-specification of @outblob like
+ "sev-snp" or "tdx" in the near term, or a common standard format
+ in the future.
+
+What: /sys/kernel/config/tsm/report/$name/generation
+Date: August, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) The value in this attribute increments each time @inblob or
+ any option is written. Userspace can detect conflicts by
+ checking generation before writing to any attribute and making
+ sure the number of writes matches expectations after reading
+ @outblob, or it can prevent conflicts by creating a report
+ instance per requesting context.
+
+What: /sys/kernel/config/tsm/report/$name/privlevel
+Date: August, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) If a TSM implementation supports the concept of attestation
+ reports for TVMs running at different privilege levels, like
+ SEV-SNP "VMPL", specify the privilege level via this attribute.
+ The minimum acceptable value is conveyed via @privlevel_floor
+ and the maximum acceptable value is TSM_PRIVLEVEL_MAX (3).
+
+What: /sys/kernel/config/tsm/report/$name/privlevel_floor
+Date: August, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Indicates the minimum permissible value that can be written
+ to @privlevel.
+
+What: /sys/kernel/config/tsm/report/$name/format
+Date: August, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) If a TSM implementation supports the concept of attestation
+ reports with "extended" contents, like SEV-SNP extended reports
+ with certificate chains, specify "extended" vs "default" via
+ this attribute.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4cc6bf79fdd8..996122ab62ab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21671,6 +21671,14 @@ W: https://github.com/srcres258/linux-doc
T: git git://github.com/srcres258/linux-doc.git doc-zh-tw
F: Documentation/translations/zh_TW/
+TRUSTED SECURITY MODULE (TSM) ATTESTATION REPORTS
+M: Dan Williams <dan.j.williams@intel.com>
+L: linux-coco@lists.linux.dev
+S: Maintained
+F: Documentation/ABI/testing/configfs-tsm
+F: drivers/virt/coco/tsm.c
+F: include/linux/tsm.h
+
TTY LAYER AND SERIAL DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Jiri Slaby <jirislaby@kernel.org>
diff --git a/drivers/virt/coco/Kconfig b/drivers/virt/coco/Kconfig
index fc5c64f04c4a..87d142c1f932 100644
--- a/drivers/virt/coco/Kconfig
+++ b/drivers/virt/coco/Kconfig
@@ -2,6 +2,11 @@
#
# Confidential computing related collateral
#
+
+config TSM_REPORTS
+ select CONFIGFS_FS
+ tristate
+
source "drivers/virt/coco/efi_secret/Kconfig"
source "drivers/virt/coco/sev-guest/Kconfig"
diff --git a/drivers/virt/coco/Makefile b/drivers/virt/coco/Makefile
index 55302ef719ad..18c1aba5edb7 100644
--- a/drivers/virt/coco/Makefile
+++ b/drivers/virt/coco/Makefile
@@ -2,6 +2,7 @@
#
# Confidential computing related collateral
#
+obj-$(CONFIG_TSM_REPORTS) += tsm.o
obj-$(CONFIG_EFI_SECRET) += efi_secret/
obj-$(CONFIG_SEV_GUEST) += sev-guest/
obj-$(CONFIG_INTEL_TDX_GUEST) += tdx-guest/
diff --git a/drivers/virt/coco/tdx-guest/Kconfig b/drivers/virt/coco/tdx-guest/Kconfig
index 14246fc2fb02..22dd59e19431 100644
--- a/drivers/virt/coco/tdx-guest/Kconfig
+++ b/drivers/virt/coco/tdx-guest/Kconfig
@@ -1,6 +1,7 @@
config TDX_GUEST_DRIVER
tristate "TDX Guest driver"
depends on INTEL_TDX_GUEST
+ select TSM_REPORTS
help
The driver provides userspace interface to communicate with
the TDX module to request the TDX guest details like attestation
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
new file mode 100644
index 000000000000..da19257797d7
--- /dev/null
+++ b/drivers/virt/coco/tsm.c
@@ -0,0 +1,391 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright(c) 2023 Intel Corporation. All rights reserved. */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/tsm.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/rwsem.h>
+#include <linux/string.h>
+#include <linux/module.h>
+#include <linux/cleanup.h>
+#include <linux/configfs.h>
+
+static struct tsm_provider {
+ const struct tsm_ops *ops;
+ const struct config_item_type *type;
+ void *data;
+} provider;
+static DECLARE_RWSEM(tsm_rwsem);
+
+/**
+ * DOC: Trusted Security Module (TSM) Attestation Report Interface
+ *
+ * The TSM report interface is a common provider of blobs that facilitate
+ * attestation of a TVM (confidential computing guest) by an attestation
+ * service. A TSM report combines a user-defined blob (likely a public-key with
+ * a nonce for a key-exchange protocol) with a signed attestation report. That
+ * combined blob is then used to obtain secrets provided by an agent that can
+ * validate the attestation report. The expectation is that this interface is
+ * invoked infrequently, likely only once at TVM boot time.
+ *
+ * The attestation report format is TSM provider specific, when / if a standard
+ * materializes that can be published instead of the vendor layout. Until then
+ * the 'provider' attribute indicates the format of 'outblob'.
+ */
+
+/**
+ * struct tsm_report - track state of report generation relative to options
+ * @desc: report generation options / cached report state
+ * @outblob: generated evidence to provider to the attestation agent
+ * @outblob_len: sizeof(outblob)
+ * @write_generation: conflict detection, and report regeneration tracking
+ * @read_generation: cached report invalidation tracking
+ * @cfg: configfs interface
+ */
+struct tsm_report {
+ struct tsm_desc desc;
+ size_t outblob_len;
+ u8 *outblob;
+ unsigned long write_generation;
+ unsigned long read_generation;
+ struct config_item cfg;
+};
+
+static struct tsm_report *to_tsm_report(struct config_item *cfg)
+{
+ return container_of(cfg, struct tsm_report, cfg);
+}
+
+static int try_advance_write_generation(struct tsm_report *report)
+{
+ lockdep_assert_held_write(&tsm_rwsem);
+
+ /*
+ * malicious or broken userspace is attempting to wrap read_generation,
+ * stop accepting updates until current report configuration is read.
+ */
+ if (report->write_generation == report->read_generation - 1)
+ return -EBUSY;
+ report->write_generation++;
+ return 0;
+}
+
+static ssize_t tsm_report_privlevel_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ /*
+ * The valid privilege levels that a TSM might accept, if it accepts a
+ * privilege level setting at all, are a max of TSM_PRIVLEVEL_MAX (see
+ * SEV-SNP GHCB) and a minimum of a TSM selected floor value no less
+ * than 0.
+ */
+ if (provider.ops->privlevel_floor > val || val > TSM_PRIVLEVEL_MAX)
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.privlevel = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, privlevel);
+
+static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
+ char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%u\n", provider.ops->privlevel_floor);
+}
+CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+
+static ssize_t tsm_report_format_store(struct config_item *cfg, const char *buf,
+ size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ enum tsm_format format;
+ int rc;
+
+ if (sysfs_streq(buf, "default"))
+ format = TSM_FORMAT_DEFAULT;
+ else if (sysfs_streq(buf, "extended"))
+ format = TSM_FORMAT_EXTENDED;
+ else
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.outblob_format = format;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, format);
+
+static ssize_t tsm_report_inblob_write(struct config_item *cfg,
+ const void *buf, size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ report->desc.inblob_len = count;
+ memcpy(report->desc.inblob, buf, count);
+ return count;
+}
+CONFIGFS_BIN_ATTR_WO(tsm_report_, inblob, NULL, TSM_INBLOB_MAX);
+
+static ssize_t tsm_report_generation_show(struct config_item *cfg, char *buf)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%lu\n", report->write_generation);
+}
+CONFIGFS_ATTR_RO(tsm_report_, generation);
+
+static ssize_t tsm_report_provider_show(struct config_item *cfg, char *buf)
+{
+ guard(rwsem_read)(&tsm_rwsem);
+ return sysfs_emit(buf, "%s\n", provider.ops->name);
+}
+CONFIGFS_ATTR_RO(tsm_report_, provider);
+
+static ssize_t read_cached_report(struct tsm_report *report, void *buf, size_t count)
+{
+ loff_t offset = 0;
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ if (!report->outblob ||
+ report->read_generation != report->write_generation)
+ return -EWOULDBLOCK;
+
+ if (!buf)
+ return report->outblob_len;
+ return memory_read_from_buffer(buf, count, &offset, report->outblob,
+ report->outblob_len);
+}
+
+static ssize_t tsm_report_outblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ const struct tsm_ops *ops;
+ size_t outblob_len;
+ loff_t offset = 0;
+ u8 *outblob;
+ ssize_t rc;
+
+ /* try to read from the existing report if present and valid... */
+ rc = read_cached_report(report, buf, count);
+ if (rc >= 0 || rc != -EWOULDBLOCK)
+ return rc;
+
+ /* slow path, report may need to be regenerated... */
+ guard(rwsem_write)(&tsm_rwsem);
+ ops = provider.ops;
+ if (!report->desc.inblob_len)
+ return -EINVAL;
+
+ /* did another thread already generate this report? */
+ if (report->outblob &&
+ report->read_generation == report->write_generation)
+ goto out;
+
+ kvfree(report->outblob);
+ report->outblob = NULL;
+ outblob = ops->report_new(&report->desc, provider.data, &outblob_len);
+ if (IS_ERR(outblob))
+ return PTR_ERR(outblob);
+ report->outblob_len = outblob_len;
+ report->outblob = outblob;
+ report->read_generation = report->write_generation;
+
+out:
+ if (!buf)
+ return report->outblob_len;
+ return memory_read_from_buffer(buf, count, &offset, report->outblob,
+ report->outblob_len);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, outblob, NULL, TSM_OUTBLOB_MAX);
+
+#define TSM_DEFAULT_ATTRS() \
+ &tsm_report_attr_generation, \
+ &tsm_report_attr_provider
+
+static struct configfs_attribute *tsm_report_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ NULL,
+};
+
+static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
+ &tsm_report_attr_inblob,
+ &tsm_report_attr_outblob,
+ NULL,
+};
+
+static struct configfs_attribute *tsm_report_extra_attrs[] = {
+ TSM_DEFAULT_ATTRS(),
+ &tsm_report_attr_format,
+ &tsm_report_attr_privlevel,
+ &tsm_report_attr_privlevel_floor,
+ NULL,
+};
+
+static void tsm_report_item_release(struct config_item *cfg)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ kvfree(report->outblob);
+ kfree(report);
+}
+
+static struct configfs_item_operations tsm_report_item_ops = {
+ .release = tsm_report_item_release,
+};
+
+const struct config_item_type tsm_report_default_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_attrs,
+ .ct_attrs = tsm_report_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_default_type);
+
+const struct config_item_type tsm_report_ext_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_bin_attrs = tsm_report_bin_attrs,
+ .ct_attrs = tsm_report_extra_attrs,
+ .ct_item_ops = &tsm_report_item_ops,
+};
+EXPORT_SYMBOL_GPL(tsm_report_ext_type);
+
+static struct config_item *tsm_report_make_item(struct config_group *group,
+ const char *name)
+{
+ struct tsm_report *report;
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!provider.ops)
+ return ERR_PTR(-ENXIO);
+
+ report = kzalloc(sizeof(*report), GFP_KERNEL);
+ if (!report)
+ return ERR_PTR(-ENOMEM);
+
+ config_item_init_type_name(&report->cfg, name, provider.type);
+ return &report->cfg;
+}
+
+static struct configfs_group_operations tsm_report_group_ops = {
+ .make_item = tsm_report_make_item,
+};
+
+static const struct config_item_type tsm_reports_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_group_ops = &tsm_report_group_ops,
+};
+
+static const struct config_item_type tsm_root_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static struct configfs_subsystem tsm_configfs = {
+ .su_group = {
+ .cg_item = {
+ .ci_namebuf = "tsm",
+ .ci_type = &tsm_root_group_type,
+ },
+ },
+ .su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
+};
+
+static struct config_group *tsm_report_group;
+
+int register_tsm(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type)
+{
+ const struct tsm_ops *conflict;
+
+ if (!type)
+ type = &tsm_report_default_type;
+ if (!(type == &tsm_report_default_type || type == &tsm_report_ext_type))
+ return -EINVAL;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ conflict = provider.ops;
+ if (conflict) {
+ pr_err("\"%s\" ops already registered\n", conflict->name);
+ return -EBUSY;
+ }
+
+ provider.ops = ops;
+ provider.data = priv;
+ provider.type = type;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(register_tsm);
+
+int unregister_tsm(const struct tsm_ops *ops)
+{
+ guard(rwsem_write)(&tsm_rwsem);
+ if (ops != provider.ops)
+ return -EBUSY;
+ provider.ops = NULL;
+ provider.data = NULL;
+ provider.type = NULL;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(unregister_tsm);
+
+static int __init tsm_init(void)
+{
+ struct config_group *root = &tsm_configfs.su_group;
+ struct config_group *tsm;
+ int rc;
+
+ config_group_init(root);
+ rc = configfs_register_subsystem(&tsm_configfs);
+ if (rc)
+ return rc;
+
+ tsm = configfs_register_default_group(root, "report",
+ &tsm_reports_type);
+ if (IS_ERR(tsm)) {
+ configfs_unregister_subsystem(&tsm_configfs);
+ return PTR_ERR(tsm);
+ }
+ tsm_report_group = tsm;
+
+ return 0;
+}
+module_init(tsm_init);
+
+static void __exit tsm_exit(void)
+{
+ configfs_unregister_default_group(tsm_report_group);
+ configfs_unregister_subsystem(&tsm_configfs);
+}
+module_exit(tsm_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Provide Trusted Security Module attestation reports via configfs");
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
new file mode 100644
index 000000000000..4b110b69a330
--- /dev/null
+++ b/include/linux/tsm.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __TSM_H
+#define __TSM_H
+
+#include <linux/sizes.h>
+#include <linux/types.h>
+#include <linux/device.h>
+
+#define TSM_INBLOB_MAX 64
+#define TSM_OUTBLOB_MAX SZ_32K
+
+/*
+ * Privilege level is a nested permission concept to allow confidential
+ * guests to partition address space, 4-levels are supported.
+ */
+#define TSM_PRIVLEVEL_MAX 3
+
+enum tsm_format {
+ TSM_FORMAT_DEFAULT,
+ TSM_FORMAT_EXTENDED,
+};
+
+/**
+ * struct tsm_desc - option descriptor for generating tsm report blobs
+ * @privlevel: optional privilege level to associate with @outblob
+ * @inblob_len: sizeof @inblob
+ * @inblob: arbitrary input data
+ * @outblob_format: for TSMs with an "extended" format
+ */
+struct tsm_desc {
+ unsigned int privlevel;
+ size_t inblob_len;
+ u8 inblob[TSM_INBLOB_MAX];
+ enum tsm_format outblob_format;
+};
+
+/*
+ * arch specific ops, only one is expected to be registered at a time
+ * i.e. only one of SEV, TDX, COVE, etc.
+ */
+struct tsm_ops {
+ const char *name;
+ const int privlevel_floor;
+ u8 *(*report_new)(const struct tsm_desc *desc, void *data,
+ size_t *outblob_len);
+};
+
+extern const struct config_item_type tsm_report_ext_type;
+extern const struct config_item_type tsm_report_default_type;
+
+int register_tsm(const struct tsm_ops *ops, void *priv,
+ const struct config_item_type *type);
+int unregister_tsm(const struct tsm_ops *ops);
+#endif /* __TSM_H */
^ permalink raw reply related [relevance 7%]
* Re: Subscriber actions for migrating lists to lists.linux.dev
@ 2021-04-16 21:22 7% ` James Bottomley
0 siblings, 0 replies; 200+ results
From: James Bottomley @ 2021-04-16 21:22 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: users, tools
On Fri, 2021-04-16 at 17:16 -0400, Konstantin Ryabitsev wrote:
> On Fri, Apr 16, 2021 at 01:58:22PM -0700, James Bottomley wrote:
> > I'm fairly certain all I need to do is a bit of duplicate message
> > elimination and to update my procmail rules, but on the latter,
> > what is the header I should be sorting on? For current kernel.org
> > lists, it's either X-Mailing-list: or List-ID: Will it be the same
> > for lists.linux.dev (so I just add to the domain in the rule)?
>
> We still add both List-Id and X-Mailing-List headers, but as "List-
> Id" is an actual RFC standard, I suggest filtering based on that.
> E.g. for linux-staging@lists.linux.dev we add the following headers:
>
> X-Mailing-List: linux-staging@lists.linux.dev
> List-Id: <linux-staging.lists.linux.dev>
> List-Subscribe: <mailto:linux-staging+subscribe@lists.linux.dev>
> List-Unsubscribe: <mailto:
> linux-staging+unsubscribe@lists.linux.dev>
>
> > Ordinarily I'd just wait and see, but given the volumes involved I
> > wasn't keen on waking up to hundreds of emails suddenly in my INBOX
> > instead of the list folders.
>
> Note, that once we get around to vger lists, we'll be preserving the
> address and list-id without changes.
Thanks, I like hearing "you don't have to do anything at all".
> The lists we're currently migrating are moving from other places --
> either from domains we don't control (lists.01.org), or from domains
> like lists.linuxfoundation.org where there are MLs that will likely
> not enjoy mlmmj-style list management and will move to groups.io
> instead after we cherry-pick the devel lists.
OK, so for ksummit-discuss and it's ilk I need
* ^List-Id: .*ksummit-discuss.lists.(linuxfoundation.org|linux.dev)
And I'll be good to go.
Thanks!
James
^ permalink raw reply [relevance 7%]
* [PATCH v3 05/11] MAINTAINERS: pci: imx: update imx6* to imx* since rename driver file
@ 2024-04-02 14:33 7% ` Frank Li
0 siblings, 0 replies; 200+ results
From: Frank Li @ 2024-04-02 14:33 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Philipp Zabel, Liam Girdwood, Mark Brown,
Manivannan Sadhasivam, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, imx, linux-arm-kernel, linux-kernel, bpf, devicetree,
Frank Li
Add me to imx pcie driver maintainer.
Add mail list imx@lists.linux.dev.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a692..59a409dd604d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16736,14 +16736,16 @@ F: drivers/pci/controller/pci-host-generic.c
PCI DRIVER FOR IMX6
M: Richard Zhu <hongxing.zhu@nxp.com>
+M: Frank Li <Frank.Li@nxp.com>
M: Lucas Stach <l.stach@pengutronix.de>
L: linux-pci@vger.kernel.org
+L: imx@lists.linux.dev
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
-F: drivers/pci/controller/dwc/*imx6*
+F: drivers/pci/controller/dwc/*imx*
PCI DRIVER FOR INTEL IXP4XX
M: Linus Walleij <linus.walleij@linaro.org>
--
2.34.1
^ permalink raw reply related [relevance 7%]
* [PATCH v2 2/2] docs: reporting-issues: make people CC the regressions list
@ 2021-04-09 11:47 7% ` Thorsten Leemhuis
0 siblings, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2021-04-09 11:47 UTC (permalink / raw)
To: Jonathan Corbet, Greg KH, Linus Torvalds
Cc: Randy Dunlap, linux-doc, linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=yes, Size: 6871 bytes --]
Make people CC the recently created mailing list dedicated to Linux
kernel regressions when reporting one. Some paragraphs had to be
reshuffled and slightly rewritten during the process, as the text
otherwise would have gotten unnecessarily hard to follow.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
v1->v2
* drop the bits that a would help a automatic tracking solution
FWIW, a quick reminder about something I wrote in v1, but nobody said
anything about it: now that we have a mailing list for regressions I was
inclined to remove the "Make the report's subject start with
'[REGRESSION]'" part from the text. But in the end I left it, to make it
obvious on other lists that the mail is about a regression.
Nevertheless, I'm still wondering if it should be toned down a bit, as
it might be enough if the subject starts with "regression:" or contains
the word somewhere.
Ciao, Thorsten
---
.../admin-guide/reporting-issues.rst | 55 ++++++++++++-------
1 file changed, 35 insertions(+), 20 deletions(-)
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index 5791eaa34ade..48b4d0ef2b09 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -23,7 +23,8 @@ longterm series? One still supported? Then search the `LKML
<https://lore.kernel.org/stable/>`_ archives for matching reports to join. If
you don't find any, install `the latest release from that series
<https://kernel.org/>`_. If it still shows the issue, report it to the stable
-mailing list (stable@vger.kernel.org).
+mailing list (stable@vger.kernel.org) and CC the regressions list
+(regressions@lists.linux.dev).
In all other cases try your best guess which kernel part might be causing the
issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
@@ -44,10 +45,11 @@ ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
sure it's built and running in a healthy environment and not already tainted
before the issue occurs.
-While writing your report, include all information relevant to the issue, like
-the kernel and the distro used. In case of a regression try to include the
-commit-id of the change causing it, which a bisection can find. If you're facing
-multiple issues with the Linux kernel at once, report each separately.
+If you are facing multiple issues with the Linux kernel at once, report each
+separately. While writing your report, include all information relevant to the
+issue, like the kernel and the distro used. In case of a regression, CC the
+regressions mailing list (regressions@lists.linux.dev) to your report; also try
+to include the commit-id of the change causing it, which a bisection can find.
Once the report is out, answer any questions that come up and help where you
can. That includes keeping the ball rolling by occasionally retesting with newer
@@ -192,12 +194,14 @@ report them:
kernel. Ensure this kernel is not tainted and still shows the problem, as
the issue might have already been fixed there. If you first noticed the
problem with a vendor kernel, check a vanilla build of the last version
- known to work performs fine as well.*
+ known to work performs fine as well.
* Send a short problem report to the Linux stable mailing list
- (stable@vger.kernel.org). Roughly describe the issue and ideally explain
- how to reproduce it. Mention the first version that shows the problem and
- the last version that's working fine. Then wait for further instructions.*
+ (stable@vger.kernel.org) and CC the Linux regressions mailing list
+ (regressions@lists.linux.dev). Roughly describe the issue and ideally
+ explain how to reproduce it. Mention the first version that shows the
+ problem and the last version that's working fine. Then wait for further
+ instructions.
The reference section below explains each of these steps in more detail.
@@ -1235,14 +1239,23 @@ Reports for high priority issues need special handling.
**Severe issues**: make sure the subject or ticket title as well as the first
paragraph makes the severeness obvious.
-**Regressions**: If the issue is a regression add [REGRESSION] to the mail's
-subject or the title in the bug-tracker. If you did not perform a bisection
-mention at least the latest mainline version you tested that worked fine (say
-5.7) and the oldest where the issue occurs (say 5.8). If you did a successful
-bisection mention the commit id and subject of the change that causes the
-regression. Also make sure to add the author of that change to your report; if
-you need to file your bug in a bug-tracker forward the report to him in a
-private mail and mention where your filed it.
+**Regressions**: make the report's subject start with '[REGRESSION]'.
+
+In case you performed a successful bisection, use the title of the change that
+introduced the regression as the second part of your subject. Make the report
+also mention the commit id of the culprit. In case of an unsuccessful bisection,
+make your report mention the latest tested version that's working fine (say 5.7)
+and the oldest where the issue occurs (say 5.8-rc1).
+
+When sending the report by mail, CC the Linux regressions mailing list
+(regressions@lists.linux.dev). In case the report needs to be filed to some web
+tracker, proceed to do so; once filed, forward the report by mail to the
+regressions list. Make sure to inline the forwarded report, hence do not attach
+it. Also add a short note at the top where you mention the URL to the ticket.
+
+When mailing or forwarding the report, in case of a successful bisection add the
+author of the culprit to the recipients; also CC everyone in the signed-off-by
+chain, which you find at the end of its commit message.
**Security issues**: for these issues your will have to evaluate if a
short-term risk to other users would arise if details were publicly disclosed.
@@ -1522,9 +1535,11 @@ Report the regression
~~~~~~~~~~~~~~~~~~~~~
*Send a short problem report to the Linux stable mailing list
- (stable@vger.kernel.org). Roughly describe the issue and ideally explain
- how to reproduce it. Mention the first version that shows the problem and
- the last version that's working fine. Then wait for further instructions.*
+ (stable@vger.kernel.org) and CC the Linux regressions mailing list
+ (regressions@lists.linux.dev). Roughly describe the issue and ideally
+ explain how to reproduce it. Mention the first version that shows the
+ problem and the last version that's working fine. Then wait for further
+ instructions.*
When reporting a regression that happens within a stable or longterm kernel
line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
--
2.30.2
^ permalink raw reply related [relevance 7%]
* [PATCH] MAINTAINERS: Move from git://github.com to https://github.com
@ 2022-10-13 15:32 7% Palmer Dabbelt
0 siblings, 0 replies; 200+ results
From: Palmer Dabbelt @ 2022-10-13 15:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Palmer Dabbelt, Conor Dooley
Github deprecated the git:// links about a year ago, but it looks like
there's still a handful of them in the MAINTAINERS file. Conor pointed
this out about the RISC-V KVM tree, but I figured it'd be better to just
fix them all -- I've got a bunch of insteadOf so I didn't even notice
the deprecation, but new contributors probably don't and might get a bit
confused.
Reported-by: Conor Dooley <conor@kernel.org>
Link: https://github.blog/2021-09-01-improving-git-protocol-security-github/
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
MAINTAINERS | 76 ++++++++++++++++++++++++++---------------------------
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8a5012ba6ff9..748f9aaffdf2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -233,7 +233,7 @@ S: Maintained
W: http://swik.net/v9fs
Q: http://patchwork.kernel.org/project/v9fs-devel/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git
-T: git git://github.com/martinetd/linux.git
+T: git https://github.com/martinetd/linux.git
F: Documentation/filesystems/9p.rst
F: fs/9p/
F: include/net/9p/
@@ -2045,7 +2045,7 @@ M: Hans Ulli Kroll <ulli.kroll@googlemail.com>
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: git git://github.com/ulli-kroll/linux.git
+T: git https://github.com/ulli-kroll/linux.git
F: Documentation/devicetree/bindings/arm/gemini.yaml
F: Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml
F: Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt
@@ -2158,7 +2158,7 @@ M: Wei Xu <xuwei5@hisilicon.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
W: http://www.hisilicon.com
-T: git git://github.com/hisilicon/linux-hisi.git
+T: git https://github.com/hisilicon/linux-hisi.git
F: arch/arm/boot/dts/hi3*
F: arch/arm/boot/dts/hip*
F: arch/arm/boot/dts/hisi*
@@ -2281,7 +2281,7 @@ ARM/LPC32XX SOC SUPPORT
M: Vladimir Zapolskiy <vz@mleia.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: git git://github.com/vzapolskiy/linux-lpc32xx.git
+T: git https://github.com/vzapolskiy/linux-lpc32xx.git
F: Documentation/devicetree/bindings/i2c/i2c-pnx.txt
F: arch/arm/boot/dts/lpc32*
F: arch/arm/mach-lpc32xx/
@@ -2397,7 +2397,7 @@ M: Steen Hegelund <Steen.Hegelund@microchip.com>
M: UNGLinuxDriver@microchip.com
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
-T: git git://github.com/microchip-ung/linux-upstream.git
+T: git https://github.com/microchip-ung/linux-upstream.git
F: arch/arm64/boot/dts/microchip/
F: drivers/pinctrl/pinctrl-microchip-sgpio.c
N: sparx5
@@ -2430,7 +2430,7 @@ M: Romain Perier <romain.perier@gmail.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
W: http://linux-chenxing.org/
-T: git git://github.com/linux-chenxing/linux.git
+T: git https://github.com/linux-chenxing/linux.git
F: Documentation/devicetree/bindings/arm/mstar/*
F: Documentation/devicetree/bindings/clock/mstar,msc313-mpll.yaml
F: Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
@@ -3301,7 +3301,7 @@ ATHEROS 71XX/9XXX GPIO DRIVER
M: Alban Bedel <albeu@free.fr>
S: Maintained
W: https://github.com/AlbanBedel/linux
-T: git git://github.com/AlbanBedel/linux
+T: git https://github.com/AlbanBedel/linux
F: Documentation/devicetree/bindings/gpio/gpio-ath79.txt
F: drivers/gpio/gpio-ath79.c
@@ -3309,7 +3309,7 @@ ATHEROS 71XX/9XXX USB PHY DRIVER
M: Alban Bedel <albeu@free.fr>
S: Maintained
W: https://github.com/AlbanBedel/linux
-T: git git://github.com/AlbanBedel/linux
+T: git https://github.com/AlbanBedel/linux
F: Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
F: drivers/phy/qualcomm/phy-ath79-usb.c
@@ -3372,7 +3372,7 @@ F: drivers/net/ethernet/cadence/
ATMEL MAXTOUCH DRIVER
M: Nick Dyer <nick@shmanahar.org>
S: Maintained
-T: git git://github.com/ndyer/linux.git
+T: git https://github.com/ndyer/linux.git
F: Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
F: drivers/input/touchscreen/atmel_mxt_ts.c
@@ -3951,7 +3951,7 @@ M: Florian Fainelli <f.fainelli@gmail.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: git git://github.com/broadcom/stblinux.git
+T: git https://github.com/broadcom/stblinux.git
F: Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml
F: arch/arm64/boot/dts/broadcom/bcmbca/*
N: bcmbca
@@ -3976,7 +3976,7 @@ R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-rpi-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: git git://github.com/broadcom/stblinux.git
+T: git https://github.com/broadcom/stblinux.git
F: Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
F: drivers/pci/controller/pcie-brcmstb.c
F: drivers/staging/vc04_services
@@ -3990,7 +3990,7 @@ M: Ray Jui <rjui@broadcom.com>
M: Scott Branden <sbranden@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
S: Maintained
-T: git git://github.com/broadcom/mach-bcm
+T: git https://github.com/broadcom/mach-bcm
F: arch/arm/mach-bcm/
N: bcm281*
N: bcm113*
@@ -4055,7 +4055,7 @@ M: Florian Fainelli <f.fainelli@gmail.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: git git://github.com/broadcom/stblinux.git
+T: git https://github.com/broadcom/stblinux.git
F: Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
F: arch/arm/boot/dts/bcm7*.dts*
F: arch/arm/include/asm/hardware/cache-b15-rac.h
@@ -4087,7 +4087,7 @@ M: Florian Fainelli <f.fainelli@gmail.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-mips@vger.kernel.org
S: Maintained
-T: git git://github.com/broadcom/stblinux.git
+T: git https://github.com/broadcom/stblinux.git
F: arch/mips/bmips/*
F: arch/mips/boot/dts/brcm/bcm*.dts*
F: arch/mips/include/asm/mach-bmips/*
@@ -4226,7 +4226,7 @@ M: Scott Branden <sbranden@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: git git://github.com/broadcom/stblinux.git
+T: git https://github.com/broadcom/stblinux.git
F: arch/arm64/boot/dts/broadcom/northstar2/*
F: arch/arm64/boot/dts/broadcom/stingray/*
F: drivers/clk/bcm/clk-ns*
@@ -4296,7 +4296,7 @@ M: Florian Fainelli <f.fainelli@gmail.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-pm@vger.kernel.org
S: Maintained
-T: git git://github.com/broadcom/stblinux.git
+T: git https://github.com/broadcom/stblinux.git
F: drivers/soc/bcm/bcm63xx/bcm-pmb.c
F: include/dt-bindings/soc/bcm-pmb.h
@@ -4771,7 +4771,7 @@ R: Jeff Layton <jlayton@kernel.org>
L: ceph-devel@vger.kernel.org
S: Supported
W: http://ceph.com/
-T: git git://github.com/ceph/ceph-client.git
+T: git https://github.com/ceph/ceph-client.git
F: include/linux/ceph/
F: include/linux/crush/
F: net/ceph/
@@ -4783,7 +4783,7 @@ R: Jeff Layton <jlayton@kernel.org>
L: ceph-devel@vger.kernel.org
S: Supported
W: http://ceph.com/
-T: git git://github.com/ceph/ceph-client.git
+T: git https://github.com/ceph/ceph-client.git
F: Documentation/filesystems/ceph.rst
F: fs/ceph/
@@ -6865,7 +6865,7 @@ DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
M: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://github.com/patjak/drm-gma500
+T: git https://github.com/patjak/drm-gma500
F: drivers/gpu/drm/gma500/
DRM DRIVERS FOR HISILICON
@@ -7003,7 +7003,7 @@ DRM DRIVERS FOR VC4
M: Emma Anholt <emma@anholt.net>
M: Maxime Ripard <mripard@kernel.org>
S: Supported
-T: git git://github.com/anholt/linux
+T: git https://github.com/anholt/linux
T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/brcm,bcm2835-*.yaml
F: drivers/gpu/drm/vc4/
@@ -10867,7 +10867,7 @@ M: Dave Kleikamp <shaggy@kernel.org>
L: jfs-discussion@lists.sourceforge.net
S: Maintained
W: http://jfs.sourceforge.net/
-T: git git://github.com/kleikamp/linux-shaggy.git
+T: git https://github.com/kleikamp/linux-shaggy.git
F: Documentation/admin-guide/jfs.rst
F: fs/jfs/
@@ -11156,7 +11156,7 @@ L: kvm@vger.kernel.org
L: kvm-riscv@lists.infradead.org
L: linux-riscv@lists.infradead.org
S: Maintained
-T: git git://github.com/kvm-riscv/linux.git
+T: git https://github.com/kvm-riscv/linux.git
F: arch/riscv/include/asm/kvm*
F: arch/riscv/include/uapi/asm/kvm*
F: arch/riscv/kvm/
@@ -11972,7 +11972,7 @@ M: Alexey Kodanev <alexey.kodanev@oracle.com>
L: ltp@lists.linux.it (subscribers-only)
S: Maintained
W: http://linux-test-project.github.io/
-T: git git://github.com/linux-test-project/ltp.git
+T: git https://github.com/linux-test-project/ltp.git
LYNX 28G SERDES PHY DRIVER
M: Ioana Ciornei <ioana.ciornei@nxp.com>
@@ -14363,7 +14363,7 @@ L: linux-nilfs@vger.kernel.org
S: Supported
W: https://nilfs.sourceforge.io/
W: https://nilfs.osdn.jp/
-T: git git://github.com/konis/nilfs2.git
+T: git https://github.com/konis/nilfs2.git
F: Documentation/filesystems/nilfs2.rst
F: fs/nilfs2/
F: include/trace/events/nilfs2.h
@@ -14465,7 +14465,7 @@ M: Allen Hubbe <allenbh@gmail.com>
L: ntb@lists.linux.dev
S: Supported
W: https://github.com/jonmason/ntb/wiki
-T: git git://github.com/jonmason/ntb.git
+T: git https://github.com/jonmason/ntb.git
F: drivers/net/ntb_netdev.c
F: drivers/ntb/
F: drivers/pci/endpoint/functions/pci-epf-*ntb.c
@@ -15234,7 +15234,7 @@ M: Stafford Horne <shorne@gmail.com>
L: openrisc@lists.librecores.org
S: Maintained
W: http://openrisc.io
-T: git git://github.com/openrisc/linux.git
+T: git https://github.com/openrisc/linux.git
F: Documentation/devicetree/bindings/openrisc/
F: Documentation/openrisc/
F: arch/openrisc/
@@ -16211,7 +16211,7 @@ L: linux-pm@vger.kernel.org
S: Supported
W: https://01.org/pm-graph
B: https://bugzilla.kernel.org/buglist.cgi?component=pm-graph&product=Tools
-T: git git://github.com/intel/pm-graph
+T: git https://github.com/intel/pm-graph
F: tools/power/pm-graph
PMBUS HARDWARE MONITORING DRIVERS
@@ -16585,8 +16585,8 @@ M: Haojian Zhuang <haojian.zhuang@gmail.com>
M: Robert Jarzmik <robert.jarzmik@free.fr>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: git git://github.com/hzhuang1/linux.git
-T: git git://github.com/rjarzmik/linux.git
+T: git https://github.com/hzhuang1/linux.git
+T: git https://github.com/rjarzmik/linux.git
F: arch/arm/boot/dts/pxa*
F: arch/arm/mach-pxa/
F: drivers/dma/pxa*
@@ -17028,7 +17028,7 @@ R: Dongsheng Yang <dongsheng.yang@easystack.cn>
L: ceph-devel@vger.kernel.org
S: Supported
W: http://ceph.com/
-T: git git://github.com/ceph/ceph-client.git
+T: git https://github.com/ceph/ceph-client.git
F: Documentation/ABI/testing/sysfs-bus-rbd
F: drivers/block/rbd.c
F: drivers/block/rbd_types.h
@@ -18548,7 +18548,7 @@ M: Palmer Dabbelt <palmer@dabbelt.com>
M: Paul Walmsley <paul.walmsley@sifive.com>
L: linux-riscv@lists.infradead.org
S: Supported
-T: git git://github.com/sifive/riscv-linux.git
+T: git https://github.com/sifive/riscv-linux.git
N: sifive
K: [^@]sifive
@@ -18723,7 +18723,7 @@ M: Casey Schaufler <casey@schaufler-ca.com>
L: linux-security-module@vger.kernel.org
S: Maintained
W: http://schaufler-ca.com
-T: git git://github.com/cschaufler/smack-next
+T: git https://github.com/cschaufler/smack-next
F: Documentation/admin-guide/LSM/Smack.rst
F: security/smack/
@@ -20069,7 +20069,7 @@ M: Chris Zankel <chris@zankel.net>
M: Max Filippov <jcmvbkbc@gmail.com>
L: linux-xtensa@linux-xtensa.org
S: Maintained
-T: git git://github.com/czankel/xtensa-linux.git
+T: git https://github.com/czankel/xtensa-linux.git
F: arch/xtensa/
F: drivers/irqchip/irq-xtensa-*
@@ -20639,7 +20639,7 @@ M: Hu Haowen <src.res@email.cn>
L: linux-doc-tw-discuss@lists.sourceforge.net (moderated for non-subscribers)
S: Maintained
W: https://github.com/srcres258/linux-doc
-T: git git://github.com/srcres258/linux-doc.git doc-zh-tw
+T: git https://github.com/srcres258/linux-doc.git doc-zh-tw
F: Documentation/translations/zh_TW/
TTY LAYER
@@ -21047,7 +21047,7 @@ L: linux-usb@vger.kernel.org
L: netdev@vger.kernel.org
S: Maintained
W: https://github.com/petkan/pegasus
-T: git git://github.com/petkan/pegasus.git
+T: git https://github.com/petkan/pegasus.git
F: drivers/net/usb/pegasus.*
USB PHY LAYER
@@ -21084,7 +21084,7 @@ L: linux-usb@vger.kernel.org
L: netdev@vger.kernel.org
S: Maintained
W: https://github.com/petkan/rtl8150
-T: git git://github.com/petkan/rtl8150.git
+T: git https://github.com/petkan/rtl8150.git
F: drivers/net/usb/rtl8150.c
USB SERIAL SUBSYSTEM
@@ -21305,7 +21305,7 @@ M: Alex Williamson <alex.williamson@redhat.com>
R: Cornelia Huck <cohuck@redhat.com>
L: kvm@vger.kernel.org
S: Maintained
-T: git git://github.com/awilliam/linux-vfio.git
+T: git https://github.com/awilliam/linux-vfio.git
F: Documentation/driver-api/vfio.rst
F: drivers/vfio/
F: include/linux/vfio.h
@@ -22528,7 +22528,7 @@ ZSTD
M: Nick Terrell <terrelln@fb.com>
S: Maintained
B: https://github.com/facebook/zstd/issues
-T: git git://github.com/terrelln/linux.git
+T: git https://github.com/terrelln/linux.git
F: include/linux/zstd*
F: lib/zstd/
F: lib/decompress_unzstd.c
--
2.38.0
^ permalink raw reply related [relevance 7%]
* [kvm-unit-tests PATCH] MAINTAINERS: Add a catch-all entry for the kvm mailing list
@ 2023-04-04 12:51 7% Thomas Huth
0 siblings, 0 replies; 200+ results
From: Thomas Huth @ 2023-04-04 12:51 UTC (permalink / raw)
To: kvm, Paolo Bonzini, Andrew Jones
Cc: Claudio Imbrenda, Janosch Frank, Nico Boehr,
Nina Schoetterl-Glausch
The scripts/get_maintainer.pl currently fails to suggest sending
patches to kvm@vger.kernel.org if a patch only touches files that
are not part of any target specific code (e.g. files in the script
folder). All patches should be CC:-ed to the kvm list, so we should
have an entry here that covers all files.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
MAINTAINERS | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 649de509..cb198ed7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -51,14 +51,25 @@ Descriptions of section entries:
One regex pattern per line. Multiple K: lines acceptable.
-Maintainers
------------
+General Project Administration
+------------------------------
+
+Project administration
M: Paolo Bonzini <pbonzini@redhat.com>
M: Thomas Huth <thuth@redhat.com>
M: Andrew Jones <andrew.jones@linux.dev>
S: Supported
L: kvm@vger.kernel.org
T: https://gitlab.com/kvm-unit-tests/kvm-unit-tests.git
+F: COPYRIGHT
+F: LICENSE
+F: MAINTAINERS
+F: README.md
+
+Default mailing list
+L: kvm@vger.kernel.org
+F: *
+F: */
Architecture Specific Code:
---------------------------
@@ -66,7 +77,6 @@ Architecture Specific Code:
ARM
M: Andrew Jones <andrew.jones@linux.dev>
S: Supported
-L: kvm@vger.kernel.org
L: kvmarm@lists.linux.dev
L: kvmarm@lists.cs.columbia.edu (deprecated)
F: arm/
@@ -78,7 +88,6 @@ POWERPC
M: Laurent Vivier <lvivier@redhat.com>
M: Thomas Huth <thuth@redhat.com>
S: Maintained
-L: kvm@vger.kernel.org
L: kvm-ppc@vger.kernel.org
F: powerpc/
F: lib/powerpc/
@@ -90,7 +99,6 @@ M: Janosch Frank <frankja@linux.ibm.com>
M: Claudio Imbrenda <imbrenda@linux.ibm.com>
S: Supported
R: David Hildenbrand <david@redhat.com>
-L: kvm@vger.kernel.org
L: linux-s390@vger.kernel.org
F: s390x/
F: lib/s390x/
@@ -98,7 +106,6 @@ F: lib/s390x/
X86
M: Paolo Bonzini <pbonzini@redhat.com>
S: Supported
-L: kvm@vger.kernel.org
F: x86/
F: lib/x86/
T: https://gitlab.com/bonzini/kvm-unit-tests.git
--
2.31.1
^ permalink raw reply related [relevance 7%]
* [PATCH v2 3/6] MAINTAINERS: pci: imx: update imx6* to imx* since rename driver file
@ 2024-03-04 20:25 7% ` Frank Li
0 siblings, 0 replies; 200+ results
From: Frank Li @ 2024-03-04 20:25 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Philipp Zabel, Liam Girdwood, Mark Brown
Cc: linux-pci, imx, linux-arm-kernel, linux-kernel, bpf, Frank Li
Add me to imx pcie driver maintainer.
Add mail list imx@lists.linux.dev.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a692..59a409dd604d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16736,14 +16736,16 @@ F: drivers/pci/controller/pci-host-generic.c
PCI DRIVER FOR IMX6
M: Richard Zhu <hongxing.zhu@nxp.com>
+M: Frank Li <Frank.Li@nxp.com>
M: Lucas Stach <l.stach@pengutronix.de>
L: linux-pci@vger.kernel.org
+L: imx@lists.linux.dev
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
-F: drivers/pci/controller/dwc/*imx6*
+F: drivers/pci/controller/dwc/*imx*
PCI DRIVER FOR INTEL IXP4XX
M: Linus Walleij <linus.walleij@linaro.org>
--
2.34.1
^ permalink raw reply related [relevance 7%]
* [PATCH 3/6] MAINTAINERS: pci: imx: update imx6* to imx* since rename driver file
@ 2024-02-27 21:47 7% ` Frank Li
0 siblings, 0 replies; 200+ results
From: Frank Li @ 2024-02-27 21:47 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Philipp Zabel, Liam Girdwood, Mark Brown
Cc: linux-pci, imx, linux-arm-kernel, linux-kernel, bpf, Frank Li
Add me to imx pcie driver maintainer.
Add mail list imx@lists.linux.dev.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a692..59a409dd604d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16736,14 +16736,16 @@ F: drivers/pci/controller/pci-host-generic.c
PCI DRIVER FOR IMX6
M: Richard Zhu <hongxing.zhu@nxp.com>
+M: Frank Li <Frank.Li@nxp.com>
M: Lucas Stach <l.stach@pengutronix.de>
L: linux-pci@vger.kernel.org
+L: imx@lists.linux.dev
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
-F: drivers/pci/controller/dwc/*imx6*
+F: drivers/pci/controller/dwc/*imx*
PCI DRIVER FOR INTEL IXP4XX
M: Linus Walleij <linus.walleij@linaro.org>
--
2.34.1
^ permalink raw reply related [relevance 7%]
* [PATCH v2] docs/zh_CN: Update translation of reporting-issues.rst to 5.18
2022-05-17 17:08 8% ` [PATCH 1/2] docs/zh_CN: sync reporting-issues.rst Wu XiangCheng
@ 2022-05-18 3:16 7% ` Wu XiangCheng
1 sibling, 0 replies; 200+ results
From: Wu XiangCheng @ 2022-05-18 3:16 UTC (permalink / raw)
To: Alex Shi, Yanteng Si; +Cc: Jonathan Corbet, linux-doc
Update zh_CN/admin-guide/reporting-issues.rst to newest English version
commit 247097e2bbff4 ("docs: reporting-issues.rst: link new document
about regressions")
Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
---
v2:
* merge former two patches together
* give the commit a better name
v1:
<https://lore.kernel.org/linux-doc/cover.1652792205.git.bobwxc@email.cn/T/#t>
.../zh_CN/admin-guide/reporting-issues.rst | 125 +++++++++++-------
1 file changed, 79 insertions(+), 46 deletions(-)
diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
index 6b4988da2c5a..59e51e3539b4 100644
--- a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
+++ b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
@@ -1,13 +1,6 @@
.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
-..
- If you want to distribute this text under CC-BY-4.0 only, please use 'The
- Linux kernel developers' for author attribution and link this as source:
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
-..
- Note: Only the content of this RST file as found in the Linux kernel sources
- is available under CC-BY-4.0, as versions of this text that were processed
- (for example by the kernel's build system) might contain content taken from
- files which use a more restrictive license.
+.. See the bottom of this file for additional redistribution information.
+
.. include:: ../disclaimer-zh_CN.rst
@@ -29,7 +22,9 @@
请搜索 `LKML内核邮件列表 <https://lore.kernel.org/lkml/>`_ 和
`Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ 存档中匹配的报告并
加入讨论。如果找不到匹配的报告，请安装该系列的最新版本。如果它仍然出现问题，
-报告给稳定版邮件列表（stable@vger.kernel.org）。
+请报告给稳定版邮件列表（stable@vger.kernel.org）并抄送回归邮件列表
+（regressions@lists.linux.dev）；理想情况下，还可以抄送维护者和相关子系统的
+邮件列表。
在所有其他情况下，请尽可能猜测是哪个内核部分导致了问题。查看MAINTAINERS文件，
了解开发人员希望如何得知问题，大多数情况下，报告问题都是通过电子邮件和抄送
@@ -46,9 +41,10 @@
有使用附加模块）。还要确保它是在一个正常的环境中构建和运行，并且在问题发生
之前没有被污染（tainted）。
-在编写报告时，要涵盖与问题相关的所有信息，如使用的内核和发行版。在碰见回归时，
-尝试给出引入它的更改的提交ID，二分可以找到它。如果您同时面临Linux内核的多个
-问题，请分别报告每个问题。
+当你同时面临Linux内核的多个问题时，请分别报告。在编写报告时，要涵盖与问题
+相关的所有信息，如使用的内核和发行版。如果碰见回归，请把报告抄送回归邮件列表
+（regressions@lists.linux.dev）。也请试试用二分法找出源头；如果成功找到，请
+在报告中写上它的提交ID并抄送sign-off-by链中的所有人。
一旦报告发出，请回答任何出现的问题，并尽可能地提供帮助。这包括通过不时重新
测试新版本并发送状态更新来推动进展。
@@ -156,9 +152,10 @@
存在问题，因为问题可能已经在那里被修复了。如果您第一次发现供应商内核的问题，
请检查已知最新版本的普通构建是否可以正常运行。
- * 向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)。大致
- 描述问题，并解释如何复现。讲清楚首个出现问题的版本和最后一个工作正常的版本。
- 然后等待进一步的指示。
+ * 向Linux稳定版邮件列表发送一个简短的问题报告（stable@vger.kernel.org）并抄送
+ Linux回归邮件列表（regressions@lists.linux.dev）；如果你怀疑是由某子系统
+ 引起的，请抄送其维护人员和子系统邮件列表。大致描述问题，并解释如何复现。
+ 讲清楚首个出现问题的版本和最后一个工作正常的版本。然后等待进一步的指示。
下面的参考章节部分详细解释了这些步骤中的每一步。
@@ -296,17 +293,14 @@ Linus Torvalds和主要的Linux内核开发人员希望看到一些问题尽快
报告过程中有一些“高优先级问题”的处理略有不同。有三种情况符合条件:回归、安全
问题和非常严重的问题。
-如果在旧版本的Linux内核中工作的东西不能在新版本的Linux内核中工作，或者某种
-程度上在新版本的Linux内核中工作得更差，那么你就需要处理“回归”。因此，当一个
-在Linux 5.7中表现良好的WiFi驱动程序在5.8中表现不佳或根本不能工作时，这是一
-种回归。如果应用程序在新的内核中出现不稳定的现象，这也是一种回归，这可能是
-由于内核和用户空间之间的接口（如procfs和sysfs）发生不兼容的更改造成的。显著
-的性能降低或功耗增加也可以称为回归。但是请记住:新内核需要使用与旧内核相似的
-配置来构建（参见下面如何实现这一点）。这是因为内核开发人员在实现新特性时有
-时无法避免不兼容性；但是为了避免回归，这些特性必须在构建配置期间显式地启用。
+如果某个应用程序或实际用例在原先的Linux内核上运行良好，但在使用类似配置编译的
+较新版本上效果更差、或者根本不能用，那么你就需要处理回归问题。
+Documentation/admin-guide/reporting-regressions.rst 对此进行了更详细的解释。
+它还提供了很多你可能想知道的关于回归的其他信息；例如，它解释了如何将您的问题
+添加到回归跟踪列表中，以确保它不会被忽略。
什么是安全问题留给您自己判断。在继续之前，请考虑阅读
-“Documentation/translations/zh_CN/admin-guide/security-bugs.rst”，
+Documentation/translations/zh_CN/admin-guide/security-bugs.rst ，
因为它提供了如何最恰当地处理安全问题的额外细节。
当发生了完全无法接受的糟糕事情时，此问题就是一个“非常严重的问题”。例如，
@@ -390,7 +384,7 @@ Linux内核破坏了它处理的数据或损坏了它运行的硬件。当内核
核未被污染，那么它应该以“Not infected”结束；如果你看到“Tainted:”且后跟一些
空格和字母，那就被污染了。
-如果你的内核被污染了，请阅读“Documentation/translations/zh_CN/admin-guide/tainted-kernels.rst”
+如果你的内核被污染了，请阅读 Documentation/translations/zh_CN/admin-guide/tainted-kernels.rst
以找出原因。设法消除污染因素。通常是由以下三种因素之一引起的：
1. 发生了一个可恢复的错误（“kernel Oops”），内核污染了自己，因为内核知道在
@@ -591,7 +585,8 @@ ath10k@lists.infradead.org”，将引导您到ath10k邮件列表的信息页，
搜索引擎，并添加类似“site:lists.infadead.org/pipermail/ath10k/”这
样的搜索条件，这会把结果限制在该链接中的档案。
-也请进一步搜索网络、LKML和bugzilla.kernel.org网站。
+也请进一步搜索网络、LKML和bugzilla.kernel.org网站。如果你的报告需要发送到缺陷
+跟踪器中，那么您可能还需要检查子系统的邮件列表存档，因为可能有人只在那里报告了它。
有关如何搜索以及在找到匹配报告时如何操作的详细信息，请参阅上面的“搜索现有报告
（第一部分）”。
@@ -802,10 +797,10 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
重现它。
有一个叫做“二分”的过程可以来寻找变化，这在
-“Documentation/translations/zh_CN/admin-guide/bug-bisect.rst”文档中进行了详细
+Documentation/translations/zh_CN/admin-guide/bug-bisect.rst 文档中进行了详细
的描述，这个过程通常需要你构建十到二十个内核镜像，每次都尝试在构建下一个镜像
之前重现问题。是的，这需要花费一些时间，但不用担心，它比大多数人想象的要快得多。
-多亏了“binary search二进制搜索”，这将引导你在源代码管理系统中找到导致回归的提交。
+多亏了“binary search二分搜索”，这将引导你在源代码管理系统中找到导致回归的提交。
一旦你找到它，就在网上搜索其主题、提交ID和缩短的提交ID（提交ID的前12个字符）。
如果有的话，这将引导您找到关于它的现有报告。
@@ -823,10 +818,10 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
当处理回归问题时，请确保你所面临的问题真的是由内核引起的，而不是由其他东西
引起的，如上文所述。
-在整个过程中，请记住：只有当旧内核和新内核的配置相似时，问题才算回归。最好
-的方法是：把配置文件（``.config``）从旧的工作内核直接复制到你尝试的每个新内
-核版本。之后运行 ``make oldnoconfig`` 来调整它以适应新版本的需要，而不启用
-任何新的功能，因为那些功能也可能导致回归。
+在整个过程中，请记住：只有当旧内核和新内核的配置相似时，问题才算回归。这可以
+通过 ``make olddefconfig`` 来实现，详细解释参见
+Documentation/admin-guide/reporting-regressions.rst ；它还提供了大量其他您
+可能希望了解的有关回归的信息。
撰写并发送报告
@@ -959,11 +954,19 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
**非常严重的缺陷** ：确保在主题或工单标题以及第一段中明显标出 severeness
（非常严重的）。
-**回归** ：如果问题是一个回归，请在邮件的主题或缺陷跟踪器的标题中添加
-[REGRESSION]。如果您没有进行二分，请至少注明您测试的最新主线版本（比如 5.7）
-和出现问题的最新版本（比如 5.8）。如果您成功地进行了二分，请注明导致回归
-的提交ID和主题。也请添加该变更的作者到你的报告中；如果您需要将您的缺陷提交
-到缺陷跟踪器中，请将报告以私人邮件的形式转发给他，并注明报告提交地点。
+**回归** ：报告的主题应以“[REGRESSION]”开头。
+
+如果您成功用二分法定位了问题，请使用引入回归之更改的标题作为主题的第二部分。
+请在报告中写明“罪魁祸首”的提交ID。如果未能成功二分，请在报告中讲明最后一个
+正常工作的版本（例如5.7）和最先发生问题的版本（例如5.8-rc1）。
+
+通过邮件发送报告时，请抄送Linux回归邮件列表（regressions@lists.linux.dev）。
+如果报告需要提交到某个web追踪器，请继续提交；并在提交后，通过邮件将报告转发
+至回归列表；抄送相关子系统的维护人员和邮件列表。请确保报告是内联转发的，不要
+把它作为附件。另外请在顶部添加一个简短的说明，在那里写上工单的网址。
+
+在邮寄或转发报告时，如果成功二分，需要将“罪魁祸首”的作者添加到收件人中；同时
+抄送signed-off-by链中的每个人，您可以在提交消息的末尾找到。
**安全问题** ：对于这种问题，你将必须评估：如果细节被公开披露，是否会对其他
用户产生短期风险。如果不会，只需按照所述继续报告问题。如果有此风险，你需要
@@ -980,7 +983,7 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
报告，请将报告的文本转发到这些地址；但请在报告的顶部加上注释，表明您提交了
报告，并附上工单链接。
-更多信息请参见“Documentation/translations/zh_CN/admin-guide/security-bugs.rst”。
+更多信息请参见 Documentation/translations/zh_CN/admin-guide/security-bugs.rst 。
发布报告后的责任
@@ -1173,14 +1176,18 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
报告回归
~~~~~~~~~~
- *向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)。
- 大致描述问题，并解释如何复现。讲清楚首个出现问题的版本和最后一个工作正常
- 的版本。然后等待进一步的指示。*
+ *向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)并
+ 抄送Linux回归邮件列表（regressions@lists.linux.dev）；如果你怀疑是由某
+ 子系统引起的，请抄送其维护人员和子系统邮件列表。大致描述问题，并解释如
+ 何复现。讲清楚首个出现问题的版本和最后一个工作正常的版本。然后等待进一
+ 步的指示。*
当报告在稳定版或长期支持内核线内发生的回归（例如在从5.10.4更新到5.10.5时），
-一份简短的报告足以快速报告问题。因此只需要粗略的描述。
+一份简短的报告足以快速报告问题。因此只需向稳定版和回归邮件列表发送粗略的描述；
+不过如果你怀疑某子系统导致此问题的话，请一并抄送其维护人员和子系统邮件列表，
+这会加快进程。
-但是请注意，如果您能够指明引入问题的确切版本，这将对开发人员有很大帮助。因此
+请注意，如果您能够指明引入问题的确切版本，这将对开发人员有很大帮助。因此
如果有时间的话，请尝试使用普通内核找到该版本。让我们假设发行版发布Linux内核
5.10.5到5.10.8的更新时发生了故障。那么按照上面的指示，去检查该版本线中的最新
内核，比如5.10.9。如果问题出现，请尝试普通5.10.5，以确保供应商应用的补丁不会
@@ -1190,7 +1197,9 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
前一段基本粗略地概述了“二分”方法。一旦报告出来，您可能会被要求做一个正确的
报告，因为它允许精确地定位导致问题的确切更改（然后很容易被恢复以快速修复问题）。
因此如果时间允许，考虑立即进行适当的二分。有关如何详细信息，请参阅“对回归的
-特别关照”部分和文档“Documentation/translations/zh_CN/admin-guide/bug-bisect.rst”。
+特别关照”部分和文档 Documentation/translations/zh_CN/admin-guide/bug-bisect.rst 。
+如果成功二分的话，请将“罪魁祸首”的作者添加到收件人中；同时抄送所有在
+signed-off-by链中的人，您可以在提交消息的末尾找到。
“报告仅在旧内核版本线中发生的问题”的参考
@@ -1207,7 +1216,7 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
即使是微小的、看似明显的代码变化，有时也会带来新的、完全意想不到的问题。稳
定版和长期支持内核的维护者非常清楚这一点，因此他们只对这些内核进行符合
-“Documentation/translations/zh_CN/process/stable-kernel-rules.rst”中所列出的
+Documentation/translations/zh_CN/process/stable-kernel-rules.rst 中所列出的
规则的修改。
复杂或有风险的修改不符合条件，因此只能应用于主线。其他的修复很容易被回溯到
@@ -1333,3 +1342,27 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
向 Linux 内核开发者报告问题是很难的：这个文档的长度和复杂性以及字里行间的内
涵都说明了这一点。但目前就是这样了。这篇文字的主要作者希望通过记录现状来为
以后改善这种状况打下一些基础。
+
+
+..
+ end-of-content
+..
+ This English version of this document is maintained by Thorsten Leemhuis
+ <linux@leemhuis.info>. If you spot a typo or small mistake, feel free to
+ let him know directly and he'll fix it. For translation problems, please
+ contact with translators. You are free to do the same in a mostly informal
+ way if you want to contribute changes to the text, but for copyright
+ reasons please CC linux-doc@vger.kernel.org and "sign-off" your
+ contribution as Documentation/process/submitting-patches.rst outlines in
+ the section "Sign your work - the Developer's Certificate of Origin".
+..
+ This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
+ of the file. If you want to distribute this text under CC-BY-4.0 only,
+ please use "The Linux kernel developers" for author attribution and link
+ this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
base-commit: b86f46d5ce3e7497930be931a9a9e57480f0baff
--
2.30.2
^ permalink raw reply related [relevance 7%]
* [PATCH v2] Update email address and mailing list for v9fs
@ 2023-04-02 23:53 7% Eric Van Hensbergen
0 siblings, 0 replies; 200+ results
From: Eric Van Hensbergen @ 2023-04-02 23:53 UTC (permalink / raw)
To: linux-kernel
Cc: v9fs-developer, v9fs, Eric Van Hensbergen, Dominique Martinet,
Christian Schoenebeck
We've recently moved the mailing list to lists.linux.dev to move away
from the sourceforge infrastructure. This also updates the website
from the (no longer v9fs relevant?) swik.net address to the github
group which contains pointers to test cases, the protocol, servers,
etc. This also changes my email from my gmail to my kernel.org
address.
Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
Acked-by: Dominique Martinet <asmadeus@codewreck.org>
Acked-by: Christian Schoenebeck <linux_oss@crudebyte.com>
---
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..8799a222048b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -224,13 +224,13 @@ S: Orphan / Obsolete
F: drivers/net/ethernet/8390/
9P FILE SYSTEM
-M: Eric Van Hensbergen <ericvh@gmail.com>
+M: Eric Van Hensbergen <ericvh@kernel.org>
M: Latchesar Ionkov <lucho@ionkov.net>
M: Dominique Martinet <asmadeus@codewreck.org>
R: Christian Schoenebeck <linux_oss@crudebyte.com>
-L: v9fs-developer@lists.sourceforge.net
+L: v9fs@lists.linux.dev
S: Maintained
-W: http://swik.net/v9fs
+W: http://github.com/v9fs
Q: http://patchwork.kernel.org/project/v9fs-devel/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git
T: git git://github.com/martinetd/linux.git
---
base-commit: 707823e7f22f3864ddc7d85e8e9b614afe4f1b16
change-id: 20230401-ericvh-fix-maintainers-865452e6c43a
Best regards,
--
Eric Van Hensbergen <ericvh@kernel.org>
^ permalink raw reply related [relevance 7%]
* [PATCH v2 1/2] MAINTAINERS: Update drm-misc.git URL
@ 2024-03-06 15:38 7% ` Maxime Ripard
0 siblings, 0 replies; 200+ results
From: Maxime Ripard @ 2024-03-06 15:38 UTC (permalink / raw)
To: dri-devel
Cc: Daniel Vetter, David Airlie, Maarten Lankhorst, Thomas Zimmermann,
Maxime Ripard, Daniel Stone
Now that the drm-misc tree has moved to Gitlab, adjust the MAINTAINERS
git trees to reflect the location change.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
MAINTAINERS | 172 ++++++++++++++++++++++++++--------------------------
1 file changed, 86 insertions(+), 86 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2a95919fbc3d..d4e33b3a3bc0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1649,11 +1649,11 @@ F: drivers/power/reset/arm-versatile-reboot.c
F: drivers/soc/versatile/
ARM KOMEDA DRM-KMS DRIVER
M: Liviu Dudau <liviu.dudau@arm.com>
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/arm,komeda.yaml
F: Documentation/gpu/komeda-kms.rst
F: drivers/gpu/drm/arm/display/include/
F: drivers/gpu/drm/arm/display/komeda/
@@ -1661,30 +1661,30 @@ ARM MALI PANFROST DRM DRIVER
M: Boris Brezillon <boris.brezillon@collabora.com>
M: Rob Herring <robh@kernel.org>
R: Steven Price <steven.price@arm.com>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/gpu/panfrost.rst
F: drivers/gpu/drm/panfrost/
F: include/uapi/drm/panfrost_drm.h
ARM MALI PANTHOR DRM DRIVER
M: Boris Brezillon <boris.brezillon@collabora.com>
M: Steven Price <steven.price@arm.com>
M: Liviu Dudau <liviu.dudau@arm.com>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
F: drivers/gpu/drm/panthor/
F: include/uapi/drm/panthor_drm.h
ARM MALI-DP DRM DRIVER
M: Liviu Dudau <liviu.dudau@arm.com>
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/arm,malidp.yaml
F: Documentation/gpu/afbc.rst
F: drivers/gpu/drm/arm/
ARM MFM AND FLOPPY DRIVERS
@@ -6268,11 +6268,11 @@ M: Sumit Semwal <sumit.semwal@linaro.org>
M: Christian König <christian.koenig@amd.com>
L: linux-media@vger.kernel.org
L: dri-devel@lists.freedesktop.org
L: linaro-mm-sig@lists.linaro.org (moderated for non-subscribers)
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/driver-api/dma-buf.rst
F: Documentation/userspace-api/dma-buf-alloc-exchange.rst
F: drivers/dma-buf/
F: include/linux/*fence.h
F: include/linux/dma-buf.h
@@ -6322,11 +6322,11 @@ R: John Stultz <jstultz@google.com>
R: T.J. Mercier <tjmercier@google.com>
L: linux-media@vger.kernel.org
L: dri-devel@lists.freedesktop.org
L: linaro-mm-sig@lists.linaro.org (moderated for non-subscribers)
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/dma-buf/dma-heap.c
F: drivers/dma-buf/heaps/*
F: include/linux/dma-heap.h
F: include/uapi/linux/dma-heap.h
@@ -6530,11 +6530,11 @@ F: include/linux/power/smartreflex.h
DRM ACCEL DRIVERS FOR INTEL VPU
M: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
M: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/accel/ivpu/
F: include/uapi/drm/ivpu_accel.h
DRM COMPUTE ACCELERATORS DRIVERS AND FRAMEWORK
M: Oded Gabbay <ogabbay@kernel.org>
@@ -6550,47 +6550,47 @@ DRM DRIVER FOR ALLWINNER DE2 AND DE3 ENGINE
M: Maxime Ripard <mripard@kernel.org>
M: Chen-Yu Tsai <wens@csie.org>
R: Jernej Skrabec <jernej.skrabec@gmail.com>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/sun4i/sun8i*
DRM DRIVER FOR ARM PL111 CLCD
S: Orphan
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/pl111/
DRM DRIVER FOR ARM VERSATILE TFT PANELS
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
F: drivers/gpu/drm/panel/panel-arm-versatile.c
DRM DRIVER FOR ASPEED BMC GFX
M: Joel Stanley <joel@jms.id.au>
L: linux-aspeed@lists.ozlabs.org (moderated for non-subscribers)
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
F: drivers/gpu/drm/aspeed/
DRM DRIVER FOR AST SERVER GRAPHICS CHIPS
M: Dave Airlie <airlied@redhat.com>
R: Thomas Zimmermann <tzimmermann@suse.de>
R: Jocelyn Falempe <jfalempe@redhat.com>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/ast/
DRM DRIVER FOR BOCHS VIRTUAL GPU
M: Gerd Hoffmann <kraxel@redhat.com>
L: virtualization@lists.linux.dev
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/tiny/bochs.c
DRM DRIVER FOR BOE HIMAX8279D PANELS
M: Jerry Han <hanxu5@huaqin.corp-partner.google.com>
S: Maintained
@@ -6604,18 +6604,18 @@ F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
F: drivers/gpu/drm/bridge/chipone-icn6211.c
DRM DRIVER FOR EBBG FT8719 PANEL
M: Joel Selvaraj <jo@jsfamily.in>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml
F: drivers/gpu/drm/panel/panel-ebbg-ft8719.c
DRM DRIVER FOR FARADAY TVE200 TV ENCODER
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/tve200/
DRM DRIVER FOR FEIXIN K101 IM2BA02 MIPI-DSI LCD PANELS
M: Icenowy Zheng <icenowy@aosc.io>
S: Maintained
@@ -6631,11 +6631,11 @@ F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
DRM DRIVER FOR FIRMWARE FRAMEBUFFERS
M: Thomas Zimmermann <tzimmermann@suse.de>
M: Javier Martinez Canillas <javierm@redhat.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/drm_aperture.c
F: drivers/gpu/drm/tiny/ofdrm.c
F: drivers/gpu/drm/tiny/simpledrm.c
F: drivers/video/aperture.c
F: drivers/video/nomodeset.c
@@ -6650,53 +6650,53 @@ F: drivers/gpu/drm/panel/panel-edp.c
DRM DRIVER FOR GENERIC USB DISPLAY
M: Noralf Trønnes <noralf@tronnes.org>
S: Maintained
W: https://github.com/notro/gud/wiki
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/gud/
F: include/drm/gud.h
DRM DRIVER FOR GRAIN MEDIA GM12U320 PROJECTORS
M: Hans de Goede <hdegoede@redhat.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/tiny/gm12u320.c
DRM DRIVER FOR HIMAX HX8394 MIPI-DSI LCD panels
M: Ondrej Jirman <megi@xff.cz>
M: Javier Martinez Canillas <javierm@redhat.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
F: drivers/gpu/drm/panel/panel-himax-hx8394.c
DRM DRIVER FOR HX8357D PANELS
S: Orphan
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/himax,hx8357d.txt
F: drivers/gpu/drm/tiny/hx8357d.c
DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
M: Deepak Rawat <drawat.floss@gmail.com>
L: linux-hyperv@vger.kernel.org
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/hyperv
DRM DRIVER FOR ILITEK ILI9225 PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
F: drivers/gpu/drm/tiny/ili9225.c
DRM DRIVER FOR ILITEK ILI9486 PANELS
M: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/ilitek,ili9486.yaml
F: drivers/gpu/drm/tiny/ili9486.c
DRM DRIVER FOR ILITEK ILI9805 PANELS
M: Michael Trimarchi <michael@amarulasolutions.com>
@@ -6711,18 +6711,18 @@ F: Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
F: drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER
M: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/logicvc/
DRM DRIVER FOR LVDS PANELS
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/lvds.yaml
F: Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
F: drivers/gpu/drm/panel/panel-lvds.c
DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
@@ -6736,25 +6736,25 @@ DRM DRIVER FOR MGA G200 GRAPHICS CHIPS
M: Dave Airlie <airlied@redhat.com>
R: Thomas Zimmermann <tzimmermann@suse.de>
R: Jocelyn Falempe <jfalempe@redhat.com>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/mgag200/
DRM DRIVER FOR MI0283QT
M: Noralf Trønnes <noralf@tronnes.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
F: drivers/gpu/drm/tiny/mi0283qt.c
DRM DRIVER FOR MIPI DBI compatible panels
M: Noralf Trønnes <noralf@tronnes.org>
S: Maintained
W: https://github.com/notro/panel-mipi-dbi/wiki
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
F: drivers/gpu/drm/tiny/panel-mipi-dbi.c
DRM DRIVER FOR MSM ADRENO GPU
M: Rob Clark <robdclark@gmail.com>
@@ -6774,32 +6774,32 @@ F: drivers/gpu/drm/msm/
F: include/uapi/drm/msm_drm.h
DRM DRIVER FOR NOVATEK NT35510 PANELS
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
F: drivers/gpu/drm/panel/panel-novatek-nt35510.c
DRM DRIVER FOR NOVATEK NT35560 PANELS
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
F: drivers/gpu/drm/panel/panel-novatek-nt35560.c
DRM DRIVER FOR NOVATEK NT36523 PANELS
M: Jianhua Lu <lujianhua000@gmail.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
F: drivers/gpu/drm/panel/panel-novatek-nt36523.c
DRM DRIVER FOR NOVATEK NT36672A PANELS
M: Sumit Semwal <sumit.semwal@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
F: drivers/gpu/drm/panel/panel-novatek-nt36672a.c
DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS
M: Karol Herbst <kherbst@redhat.com>
@@ -6829,30 +6829,30 @@ F: Documentation/devicetree/bindings/display/bridge/ps8640.yaml
F: drivers/gpu/drm/bridge/parade-ps8640.c
DRM DRIVER FOR PERVASIVE DISPLAYS REPAPER PANELS
M: Noralf Trønnes <noralf@tronnes.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/repaper.txt
F: drivers/gpu/drm/tiny/repaper.c
DRM DRIVER FOR QEMU'S CIRRUS DEVICE
M: Dave Airlie <airlied@redhat.com>
M: Gerd Hoffmann <kraxel@redhat.com>
L: virtualization@lists.linux.dev
S: Obsolete
W: https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/tiny/cirrus.c
DRM DRIVER FOR QXL VIRTUAL GPU
M: Dave Airlie <airlied@redhat.com>
M: Gerd Hoffmann <kraxel@redhat.com>
L: virtualization@lists.linux.dev
L: spice-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/qxl/
F: include/uapi/drm/qxl_drm.h
DRM DRIVER FOR RAYDIUM RM67191 PANELS
M: Robert Chiras <robert.chiras@nxp.com>
@@ -6861,20 +6861,20 @@ F: Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml
F: drivers/gpu/drm/panel/panel-raydium-rm67191.c
DRM DRIVER FOR SAMSUNG DB7430 PANELS
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml
F: drivers/gpu/drm/panel/panel-samsung-db7430.c
DRM DRIVER FOR SAMSUNG MIPI DSIM BRIDGE
M: Inki Dae <inki.dae@samsung.com>
M: Jagan Teki <jagan@amarulasolutions.com>
M: Marek Szyprowski <m.szyprowski@samsung.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
F: drivers/gpu/drm/bridge/samsung-dsim.c
F: include/drm/bridge/samsung-dsim.h
DRM DRIVER FOR SAMSUNG S6D27A1 PANELS
@@ -6890,11 +6890,11 @@ F: Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
F: drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
DRM DRIVER FOR SITRONIX ST7586 PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/sitronix,st7586.txt
F: drivers/gpu/drm/tiny/st7586.c
DRM DRIVER FOR SITRONIX ST7701 PANELS
M: Jagan Teki <jagan@amarulasolutions.com>
@@ -6911,26 +6911,26 @@ F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
DRM DRIVER FOR SITRONIX ST7735R PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
F: drivers/gpu/drm/tiny/st7735r.c
DRM DRIVER FOR SOLOMON SSD130X OLED DISPLAYS
M: Javier Martinez Canillas <javierm@redhat.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
F: Documentation/devicetree/bindings/display/solomon,ssd13*.yaml
F: drivers/gpu/drm/solomon/ssd130x*
DRM DRIVER FOR ST-ERICSSON MCDE
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/ste,mcde.yaml
F: drivers/gpu/drm/mcde/
DRM DRIVER FOR SYNAPTICS R63353 PANELS
M: Michael Trimarchi <michael@amarulasolutions.com>
@@ -6950,55 +6950,55 @@ F: Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
F: drivers/gpu/drm/bridge/ti-sn65dsi86.c
DRM DRIVER FOR TPO TPG110 PANELS
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
F: drivers/gpu/drm/panel/panel-tpo-tpg110.c
DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
M: Dave Airlie <airlied@redhat.com>
R: Sean Paul <sean@poorly.run>
R: Thomas Zimmermann <tzimmermann@suse.de>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/udl/
DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS)
M: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
M: Melissa Wen <melissa.srw@gmail.com>
M: Maíra Canal <mairacanal@riseup.net>
R: Haneen Mohammed <hamohammed.sa@gmail.com>
R: Daniel Vetter <daniel@ffwll.ch>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/gpu/vkms.rst
F: drivers/gpu/drm/vkms/
DRM DRIVER FOR VIRTUALBOX VIRTUAL GPU
M: Hans de Goede <hdegoede@redhat.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/vboxvideo/
DRM DRIVER FOR VMWARE VIRTUAL GPU
M: Zack Rusin <zack.rusin@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/vmwgfx/
F: include/uapi/drm/vmwgfx_drm.h
DRM DRIVER FOR WIDECHIPS WS2401 PANELS
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml
F: drivers/gpu/drm/panel/panel-widechips-ws2401.c
DRM DRIVERS
M: David Airlie <airlied@gmail.com>
@@ -7020,11 +7020,11 @@ DRM DRIVERS AND MISC GPU PATCHES
M: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
M: Maxime Ripard <mripard@kernel.org>
M: Thomas Zimmermann <tzimmermann@suse.de>
S: Maintained
W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/
F: Documentation/devicetree/bindings/gpu/
F: Documentation/gpu/
F: drivers/gpu/drm/
F: drivers/gpu/vga/
@@ -7047,21 +7047,21 @@ X: drivers/gpu/drm/tegra/
DRM DRIVERS FOR ALLWINNER A10
M: Maxime Ripard <mripard@kernel.org>
M: Chen-Yu Tsai <wens@csie.org>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/allwinner*
F: drivers/gpu/drm/sun4i/
DRM DRIVERS FOR AMLOGIC SOCS
M: Neil Armstrong <neil.armstrong@linaro.org>
L: dri-devel@lists.freedesktop.org
L: linux-amlogic@lists.infradead.org
S: Supported
W: http://linux-meson.com/
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
F: Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
F: Documentation/gpu/meson.rst
F: drivers/gpu/drm/ci/xfails/meson*
F: drivers/gpu/drm/meson/
@@ -7069,11 +7069,11 @@ F: drivers/gpu/drm/meson/
DRM DRIVERS FOR ATMEL HLCDC
M: Sam Ravnborg <sam@ravnborg.org>
M: Boris Brezillon <bbrezillon@kernel.org>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/atmel/
F: drivers/gpu/drm/atmel-hlcdc/
DRM DRIVERS FOR BRIDGE CHIPS
M: Andrzej Hajda <andrzej.hajda@intel.com>
@@ -7081,11 +7081,11 @@ M: Neil Armstrong <neil.armstrong@linaro.org>
M: Robert Foss <rfoss@kernel.org>
R: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
R: Jonas Karlman <jonas@kwiboo.se>
R: Jernej Skrabec <jernej.skrabec@gmail.com>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/bridge/
F: drivers/gpu/drm/bridge/
F: drivers/gpu/drm/drm_bridge.c
F: drivers/gpu/drm/drm_bridge_connector.c
F: include/drm/drm_bridge.h
@@ -7106,20 +7106,20 @@ F: include/uapi/drm/exynos_drm.h
DRM DRIVERS FOR FREESCALE DCU
M: Stefan Agner <stefan@agner.ch>
M: Alison Wang <alison.wang@nxp.com>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/fsl,dcu.txt
F: Documentation/devicetree/bindings/display/fsl,tcon.txt
F: drivers/gpu/drm/fsl-dcu/
DRM DRIVERS FOR FREESCALE IMX 5/6
M: Philipp Zabel <p.zabel@pengutronix.de>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
T: git git://git.pengutronix.de/git/pza/linux
F: Documentation/devicetree/bindings/display/imx/
F: drivers/gpu/drm/imx/ipuv3/
F: drivers/gpu/ipu-v3/
@@ -7135,11 +7135,11 @@ F: drivers/gpu/drm/bridge/imx/
DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
M: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/gma500/
DRM DRIVERS FOR HISILICON
M: Xinliang Liu <xinliang.liu@linaro.org>
M: Tian Tao <tiantao6@hisilicon.com>
@@ -7147,28 +7147,28 @@ R: Xinwei Kong <kong.kongxinwei@hisilicon.com>
R: Sumit Semwal <sumit.semwal@linaro.org>
R: Yongqin Liu <yongqin.liu@linaro.org>
R: John Stultz <jstultz@google.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/hisilicon/
F: drivers/gpu/drm/hisilicon/
DRM DRIVERS FOR LIMA
M: Qiang Yu <yuq825@gmail.com>
L: dri-devel@lists.freedesktop.org
L: lima@lists.freedesktop.org (moderated for non-subscribers)
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/lima/
F: include/uapi/drm/lima_drm.h
DRM DRIVERS FOR LOONGSON
M: Sui Jingfeng <suijingfeng@loongson.cn>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/loongson/
DRM DRIVERS FOR MEDIATEK
M: Chun-Kuang Hu <chunkuang.hu@kernel.org>
M: Philipp Zabel <p.zabel@pengutronix.de>
@@ -7212,96 +7212,96 @@ F: drivers/gpu/drm/renesas/rcar-du/
DRM DRIVERS FOR RENESAS RZ
M: Biju Das <biju.das.jz@bp.renesas.com>
L: dri-devel@lists.freedesktop.org
L: linux-renesas-soc@vger.kernel.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
F: drivers/gpu/drm/renesas/rz-du/
DRM DRIVERS FOR RENESAS SHMOBILE
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
M: Geert Uytterhoeven <geert+renesas@glider.be>
L: dri-devel@lists.freedesktop.org
L: linux-renesas-soc@vger.kernel.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/renesas,shmobile-lcdc.yaml
F: drivers/gpu/drm/renesas/shmobile/
F: include/linux/platform_data/shmob_drm.h
DRM DRIVERS FOR ROCKCHIP
M: Sandy Huang <hjc@rock-chips.com>
M: Heiko Stübner <heiko@sntech.de>
M: Andy Yan <andy.yan@rock-chips.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/rockchip/
F: drivers/gpu/drm/ci/xfails/rockchip*
F: drivers/gpu/drm/rockchip/
DRM DRIVERS FOR STI
M: Alain Volmat <alain.volmat@foss.st.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/st,stih4xx.txt
F: drivers/gpu/drm/sti
DRM DRIVERS FOR STM
M: Yannick Fertre <yannick.fertre@foss.st.com>
M: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
M: Philippe Cornu <philippe.cornu@foss.st.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
F: drivers/gpu/drm/stm
DRM DRIVERS FOR TI KEYSTONE
M: Jyri Sarha <jyri.sarha@iki.fi>
M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
F: Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
F: Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
F: drivers/gpu/drm/tidss/
DRM DRIVERS FOR TI LCDC
M: Jyri Sarha <jyri.sarha@iki.fi>
M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/tilcdc/
F: drivers/gpu/drm/tilcdc/
DRM DRIVERS FOR TI OMAP
M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/ti/
F: drivers/gpu/drm/omapdrm/
DRM DRIVERS FOR V3D
M: Melissa Wen <mwen@igalia.com>
M: Maíra Canal <mcanal@igalia.com>
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
F: drivers/gpu/drm/v3d/
F: include/uapi/drm/v3d_drm.h
DRM DRIVERS FOR VC4
M: Maxime Ripard <mripard@kernel.org>
S: Supported
T: git git://github.com/anholt/linux
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/brcm,bcm2835-*.yaml
F: drivers/gpu/drm/vc4/
F: include/uapi/drm/vc4_drm.h
DRM DRIVERS FOR VIVANTE GPU IP
@@ -7318,65 +7318,65 @@ F: include/uapi/drm/etnaviv_drm.h
DRM DRIVERS FOR XEN
M: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
L: dri-devel@lists.freedesktop.org
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/gpu/xen-front.rst
F: drivers/gpu/drm/xen/
DRM DRIVERS FOR XILINX
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/xlnx/
F: drivers/gpu/drm/xlnx/
DRM GPU SCHEDULER
M: Luben Tuikov <ltuikov89@gmail.com>
M: Matthew Brost <matthew.brost@intel.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/scheduler/
F: include/drm/gpu_scheduler.h
DRM PANEL DRIVERS
M: Neil Armstrong <neil.armstrong@linaro.org>
R: Jessica Zhang <quic_jesszhan@quicinc.com>
R: Sam Ravnborg <sam@ravnborg.org>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/
F: drivers/gpu/drm/drm_panel.c
F: drivers/gpu/drm/panel/
F: include/drm/drm_panel.h
DRM PRIVACY-SCREEN CLASS
M: Hans de Goede <hdegoede@redhat.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/drm_privacy_screen*
F: include/drm/drm_privacy_screen*
DRM TTM SUBSYSTEM
M: Christian Koenig <christian.koenig@amd.com>
M: Huang Rui <ray.huang@amd.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/ttm/
F: include/drm/ttm/
DRM AUTOMATED TESTING
M: Helen Koike <helen.koike@collabora.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/gpu/automated_testing.rst
F: drivers/gpu/drm/ci/
DSBR100 USB FM RADIO DRIVER
M: Alexey Klimov <klimov.linux@gmail.com>
@@ -8422,11 +8422,11 @@ W: https://floatingpoint.billm.au/
F: arch/x86/math-emu/
FRAMEBUFFER CORE
M: Daniel Vetter <daniel@ffwll.ch>
S: Odd Fixes
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/video/fbdev/core/
FRAMEBUFFER LAYER
M: Helge Deller <deller@gmx.de>
L: linux-fbdev@vger.kernel.org
@@ -10494,11 +10494,11 @@ F: drivers/media/rc/img-ir/
IMGTEC POWERVR DRM DRIVER
M: Frank Binns <frank.binns@imgtec.com>
M: Matt Coster <matt.coster@imgtec.com>
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/gpu/img,powervr.yaml
F: Documentation/gpu/imagination/
F: drivers/gpu/drm/imagination/
F: include/uapi/drm/pvr_drm.h
@@ -11281,11 +11281,11 @@ F: tools/testing/selftests/iommu/
IOSYS-MAP HELPERS
M: Thomas Zimmermann <tzimmermann@suse.de>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: include/linux/iosys-map.h
IO_URING
M: Jens Axboe <axboe@kernel.dk>
R: Pavel Begunkov <asml.silence@gmail.com>
@@ -11474,11 +11474,11 @@ F: drivers/media/tuners/it913x*
ITE IT66121 HDMI BRIDGE DRIVER
M: Phong LE <ple@baylibre.com>
M: Neil Armstrong <neil.armstrong@linaro.org>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
F: drivers/gpu/drm/bridge/ite-it66121.c
IVTV VIDEO4LINUX DRIVER
M: Andy Walls <awalls@md.metrocast.net>
@@ -15025,11 +15025,11 @@ F: drivers/media/tuners/mxl5007t.*
MXSFB DRM DRIVER
M: Marek Vasut <marex@denx.de>
M: Stefan Agner <stefan@agner.ch>
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/fsl,lcdif.yaml
F: drivers/gpu/drm/mxsfb/
MYLEX DAC960 PCI RAID Controller
M: Hannes Reinecke <hare@kernel.org>
@@ -15765,11 +15765,11 @@ F: include/uapi/linux/dw100.h
NXP i.MX 8MQ DCSS DRIVER
M: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
R: Lucas Stach <l.stach@pengutronix.de>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
F: drivers/gpu/drm/imx/dcss/
NXP i.MX 8QXP ADC DRIVER
M: Cai Huoqing <cai.huoqing@linux.dev>
@@ -18074,11 +18074,11 @@ M: Jeffrey Hugo <quic_jhugo@quicinc.com>
R: Carl Vanderlip <quic_carlv@quicinc.com>
R: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com>
L: linux-arm-msm@vger.kernel.org
L: dri-devel@lists.freedesktop.org
S: Supported
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/accel/qaic/
F: drivers/accel/qaic/
F: include/uapi/drm/qaic_accel.h
QUALCOMM CORE POWER REDUCTION (CPR) AVS DRIVER
@@ -21194,11 +21194,11 @@ SYNC FILE FRAMEWORK
M: Sumit Semwal <sumit.semwal@linaro.org>
R: Gustavo Padovan <gustavo@padovan.org>
L: linux-media@vger.kernel.org
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/driver-api/sync_file.rst
F: drivers/dma-buf/dma-fence*
F: drivers/dma-buf/sw_sync.c
F: drivers/dma-buf/sync_*
F: include/linux/sync_file.h
@@ -22966,11 +22966,11 @@ F: lib/iov_iter.c
USERSPACE DMA BUFFER DRIVER
M: Gerd Hoffmann <kraxel@redhat.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/dma-buf/udmabuf.c
F: include/uapi/linux/udmabuf.h
USERSPACE I/O (UIO)
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@@ -23142,11 +23142,11 @@ S: Maintained
F: drivers/vfio/platform/
VGA_SWITCHEROO
R: Lukas Wunner <lukas@wunner.de>
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/gpu/vga-switcheroo.rst
F: drivers/gpu/vga/vga_switcheroo.c
F: include/linux/vga_switcheroo.h
VIA RHINE NETWORK DRIVER
@@ -23335,11 +23335,11 @@ M: Gerd Hoffmann <kraxel@redhat.com>
R: Gurchetan Singh <gurchetansingh@chromium.org>
R: Chia-I Wu <olvaffe@gmail.com>
L: dri-devel@lists.freedesktop.org
L: virtualization@lists.linux.dev
S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
+T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: drivers/gpu/drm/ci/xfails/virtio*
F: drivers/gpu/drm/virtio/
F: include/uapi/linux/virtio_gpu.h
VIRTIO HOST (VHOST)
--
2.43.2
^ permalink raw reply related [relevance 7%]
* [merged mm-hotfixes-stable] maintainers-add-maillist-information-for-loongarch.patch removed from -mm tree
@ 2022-06-17 2:12 8% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2022-06-17 2:12 UTC (permalink / raw)
To: mm-commits, lixuefeng, kernel, jiaxun.yang, guoren, git, arnd,
chenhuacai, akpm
The quilt patch titled
Subject: MAINTAINERS: add maillist information for LoongArch
has been removed from the -mm tree. Its filename was
maintainers-add-maillist-information-for-loongarch.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Huacai Chen <chenhuacai@loongson.cn>
Subject: MAINTAINERS: add maillist information for LoongArch
Date: Thu, 16 Jun 2022 20:14:56 +0800
Now there is a dedicated maillist (loongarch@lists.linux.dev) for
LoongArch, add it for better collaboration.
Link: https://lkml.kernel.org/r/20220616121456.3613470-1-chenhuacai@loongson.cn
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Cc: Huacai Chen <chenhuacai@loongson.cn>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Cc: Guo Ren <guoren@kernel.org>
Cc: Xuerui Wang <kernel@xen0n.name>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
--- a/MAINTAINERS~maintainers-add-maillist-information-for-loongarch
+++ a/MAINTAINERS
@@ -11591,6 +11591,7 @@ F: drivers/gpu/drm/bridge/lontium-lt8912
LOONGARCH
M: Huacai Chen <chenhuacai@kernel.org>
R: WANG Xuerui <kernel@xen0n.name>
+L: loongarch@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git
F: arch/loongarch/
_
Patches currently in -mm which might be from chenhuacai@loongson.cn are
^ permalink raw reply [relevance 8%]
* + documentation-llvm-update-mailing-list.patch added to -mm tree
@ 2021-08-31 22:48 8% akpm
0 siblings, 0 replies; 200+ results
From: akpm @ 2021-08-31 22:48 UTC (permalink / raw)
To: keescook, masahiroy, mm-commits, nathan, ndesaulniers,
samitolvanen
The patch titled
Subject: Documentation/llvm: update mailing list
has been added to the -mm tree. Its filename is
documentation-llvm-update-mailing-list.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/documentation-llvm-update-mailing-list.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/documentation-llvm-update-mailing-list.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Nathan Chancellor <nathan@kernel.org>
Subject: Documentation/llvm: update mailing list
We are now at llvm@lists.linux.dev.
Link: https://lkml.kernel.org/r/20210825211823.6406-2-nathan@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/kbuild/llvm.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/Documentation/kbuild/llvm.rst~documentation-llvm-update-mailing-list
+++ a/Documentation/kbuild/llvm.rst
@@ -111,7 +111,8 @@ Getting Help
------------
- `Website <https://clangbuiltlinux.github.io/>`_
-- `Mailing List <https://groups.google.com/forum/#!forum/clang-built-linux>`_: <clang-built-linux@googlegroups.com>
+- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev>
+- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_
- `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_
- IRC: #clangbuiltlinux on chat.freenode.net
- `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux
_
Patches currently in -mm which might be from nathan@kernel.org are
mm-hugetlb-add-support-for-mempolicy-mpol_preferred_many-fix-fix.patch
maintainers-update-clangbuiltlinux-mailing-list.patch
documentation-llvm-update-mailing-list.patch
documentation-llvm-update-irc-location.patch
^ permalink raw reply [relevance 8%]
* [PATCH] MAINTAINERS: Add Zenghui Yu as a KVM/arm64 reviewer
@ 2023-01-03 12:39 8% ` Marc Zyngier
0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2023-01-03 12:39 UTC (permalink / raw)
To: kvmarm, kvmarm
Cc: James Morse, Suzuki K Poulose, Alexandru Elisei, Oliver Upton,
Will Deacon, Catalin Marinas, linux-arm-kernel, Zenghui Yu
Zenghui has been around for quite some time, and has been instrumental
in reviewing the GICv4/4.1 KVM support. I'm delighted that he's agreed
to help with the patch review in a more official capacity!
Cc: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f61eb221415b..551544d877a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11359,6 +11359,7 @@ R: James Morse <james.morse@arm.com>
R: Alexandru Elisei <alexandru.elisei@arm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Oliver Upton <oliver.upton@linux.dev>
+R: Zenghui Yu <yuzenghui@huawei.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: kvmarm@lists.linux.dev
L: kvmarm@lists.cs.columbia.edu (deprecated, moderated for non-subscribers)
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 8%]
* [PATCH] MAINTAINERS: Add Zenghui Yu as a KVM/arm64 reviewer
@ 2023-01-03 12:39 8% ` Marc Zyngier
0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2023-01-03 12:39 UTC (permalink / raw)
To: kvmarm, kvmarm
Cc: James Morse, Suzuki K Poulose, Alexandru Elisei, Oliver Upton,
Will Deacon, Catalin Marinas, linux-arm-kernel, Zenghui Yu
Zenghui has been around for quite some time, and has been instrumental
in reviewing the GICv4/4.1 KVM support. I'm delighted that he's agreed
to help with the patch review in a more official capacity!
Cc: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f61eb221415b..551544d877a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11359,6 +11359,7 @@ R: James Morse <james.morse@arm.com>
R: Alexandru Elisei <alexandru.elisei@arm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Oliver Upton <oliver.upton@linux.dev>
+R: Zenghui Yu <yuzenghui@huawei.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: kvmarm@lists.linux.dev
L: kvmarm@lists.cs.columbia.edu (deprecated, moderated for non-subscribers)
--
2.34.1
^ permalink raw reply related [relevance 8%]
* [PATCH] MAINTAINERS: Add Zenghui Yu as a KVM/arm64 reviewer
@ 2023-01-03 12:39 8% ` Marc Zyngier
0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2023-01-03 12:39 UTC (permalink / raw)
To: kvmarm, kvmarm; +Cc: Will Deacon, Catalin Marinas, linux-arm-kernel
Zenghui has been around for quite some time, and has been instrumental
in reviewing the GICv4/4.1 KVM support. I'm delighted that he's agreed
to help with the patch review in a more official capacity!
Cc: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f61eb221415b..551544d877a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11359,6 +11359,7 @@ R: James Morse <james.morse@arm.com>
R: Alexandru Elisei <alexandru.elisei@arm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Oliver Upton <oliver.upton@linux.dev>
+R: Zenghui Yu <yuzenghui@huawei.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: kvmarm@lists.linux.dev
L: kvmarm@lists.cs.columbia.edu (deprecated, moderated for non-subscribers)
--
2.34.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [relevance 8%]
* [PATCH v3 05/11] MAINTAINERS: pci: imx: update imx6* to imx* since rename driver file
@ 2024-04-02 14:33 7% ` Frank Li
0 siblings, 0 replies; 200+ results
From: Frank Li @ 2024-04-02 14:33 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Philipp Zabel, Liam Girdwood, Mark Brown,
Manivannan Sadhasivam, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, imx, linux-arm-kernel, linux-kernel, bpf, devicetree,
Frank Li
Add me to imx pcie driver maintainer.
Add mail list imx@lists.linux.dev.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a692..59a409dd604d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16736,14 +16736,16 @@ F: drivers/pci/controller/pci-host-generic.c
PCI DRIVER FOR IMX6
M: Richard Zhu <hongxing.zhu@nxp.com>
+M: Frank Li <Frank.Li@nxp.com>
M: Lucas Stach <l.stach@pengutronix.de>
L: linux-pci@vger.kernel.org
+L: imx@lists.linux.dev
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
-F: drivers/pci/controller/dwc/*imx6*
+F: drivers/pci/controller/dwc/*imx*
PCI DRIVER FOR INTEL IXP4XX
M: Linus Walleij <linus.walleij@linaro.org>
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 8%]
* [PATCH] HACKING: update to use new mailing list
@ 2022-06-15 23:53 8% James Prestwood
0 siblings, 0 replies; 200+ results
From: James Prestwood @ 2022-06-15 23:53 UTC (permalink / raw)
To: iwd
[-- Attachment #1: Type: text/plain, Size: 716 bytes --]
IWD will be switching to a new mailing list iwd(a)lists.linux.dev.
This list is active already, and any new patches should be sent
there.
---
HACKING | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/HACKING b/HACKING
index 5925490e..8a84a449 100644
--- a/HACKING
+++ b/HACKING
@@ -5,7 +5,7 @@ If you fixed a bug or you want to add support for something, patches are
welcome! The preferred method of submitting the patches to the project is by
email to the iwd mailing list:
- iwd(a)lists.01.org
+ iwd(a)lists.linux.dev
In order to ease the inclusion of your patch, it's important to follow
some rules, otherwise it will likely be rejected by maintainers.
--
2.34.1
^ permalink raw reply related [relevance 8%]
* [PATCH] MAINTAINERS: Add maillist information for LoongArch
@ 2022-06-16 12:14 8% Huacai Chen
0 siblings, 0 replies; 200+ results
From: Huacai Chen @ 2022-06-16 12:14 UTC (permalink / raw)
To: Arnd Bergmann, Andrew Morton
Cc: loongarch, linux-arch, Xuefeng Li, Huacai Chen, Guo Ren,
Xuerui Wang, Jiaxun Yang, Huacai Chen
Now there is a dedicated maillist (loongarch@lists.linux.dev) for
LoongArch, add it for better development.
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1fc9ead83d2a..dba5e89527a2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11590,6 +11590,7 @@ F: drivers/gpu/drm/bridge/lontium-lt8912b.c
LOONGARCH
M: Huacai Chen <chenhuacai@kernel.org>
R: WANG Xuerui <kernel@xen0n.name>
+L: loongarch@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git
F: arch/loongarch/
--
2.27.0
^ permalink raw reply related [relevance 8%]
* [PATCH v2] docs/zh_CN: sync reporting-issues.rst
2021-05-09 15:07 8% [PATCH] docs/zh_CN: sync reporting-issues.rst translation Wu XiangCheng
@ 2021-05-11 11:51 8% ` Wu XiangCheng
0 siblings, 0 replies; 200+ results
From: Wu XiangCheng @ 2021-05-11 11:51 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Alex Shi, linux-doc, Yanteng Si
Sync zh_CN/admin-guide/reporting-issues.rst to newest version
commit 0043f0b27a040 ("docs: reporting-issues.rst: CC subsystem and
maintainers on regressions")
Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
Reviewed-by: Alex Shi <alexs@kernel.org>
---
v2:
* Modify some words under YanTeng Si's advices
* Pick Alex Shi's reviewed-by tag
Thanks for their review!
v1:
<https://lore.kernel.org/linux-doc/20210509150735.GA30084@bobwxc.top/>
.../zh_CN/admin-guide/reporting-issues.rst | 58 ++++++++++++-------
1 file changed, 38 insertions(+), 20 deletions(-)
diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
index 6b4988da2c5a..6cb098feed94 100644
--- a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
+++ b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
@@ -29,7 +29,9 @@
请搜索 `LKML内核邮件列表 <https://lore.kernel.org/lkml/>`_ 和
`Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ 存档中匹配的报告并
加入讨论。如果找不到匹配的报告，请安装该系列的最新版本。如果它仍然出现问题，
-报告给稳定版邮件列表（stable@vger.kernel.org）。
+请报告给稳定版邮件列表（stable@vger.kernel.org）并抄送回归邮件列表
+（regressions@lists.linux.dev）；理想情况下，还可以抄送维护者和相关子系统的
+邮件列表。
在所有其他情况下，请尽可能猜测是哪个内核部分导致了问题。查看MAINTAINERS文件，
了解开发人员希望如何得知问题，大多数情况下，报告问题都是通过电子邮件和抄送
@@ -46,9 +48,10 @@
有使用附加模块）。还要确保它是在一个正常的环境中构建和运行，并且在问题发生
之前没有被污染（tainted）。
-在编写报告时，要涵盖与问题相关的所有信息，如使用的内核和发行版。在碰见回归时，
-尝试给出引入它的更改的提交ID，二分可以找到它。如果您同时面临Linux内核的多个
-问题，请分别报告每个问题。
+当你同时面临Linux内核的多个问题时，请分别报告。在编写报告时，要涵盖与问题
+相关的所有信息，如使用的内核和发行版。如果碰见回归，请把报告抄送回归邮件列表
+（regressions@lists.linux.dev）。也请试试用二分法找出源头；如果成功找到，请
+在报告中写上它的提交ID并抄送sign-off-by链中的所有人。
一旦报告发出，请回答任何出现的问题，并尽可能地提供帮助。这包括通过不时重新
测试新版本并发送状态更新来推动进展。
@@ -156,9 +159,10 @@
存在问题，因为问题可能已经在那里被修复了。如果您第一次发现供应商内核的问题，
请检查已知最新版本的普通构建是否可以正常运行。
- * 向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)。大致
- 描述问题，并解释如何复现。讲清楚首个出现问题的版本和最后一个工作正常的版本。
- 然后等待进一步的指示。
+ * 向Linux稳定版邮件列表发送一个简短的问题报告（stable@vger.kernel.org）并抄送
+ Linux回归邮件列表（regressions@lists.linux.dev）；如果你怀疑是由某子系统
+ 引起的，请抄送其维护人员和子系统邮件列表。大致描述问题，并解释如何复现。
+ 讲清楚首个出现问题的版本和最后一个工作正常的版本。然后等待进一步的指示。
下面的参考章节部分详细解释了这些步骤中的每一步。
@@ -591,7 +595,8 @@ ath10k@lists.infradead.org”，将引导您到ath10k邮件列表的信息页，
搜索引擎，并添加类似“site:lists.infadead.org/pipermail/ath10k/”这
样的搜索条件，这会把结果限制在该链接中的档案。
-也请进一步搜索网络、LKML和bugzilla.kernel.org网站。
+也请进一步搜索网络、LKML和bugzilla.kernel.org网站。如果你的报告需要发送到缺陷
+跟踪器中，那么您可能还需要检查子系统的邮件列表存档，因为可能有人只在那里报告了它。
有关如何搜索以及在找到匹配报告时如何操作的详细信息，请参阅上面的“搜索现有报告
（第一部分）”。
@@ -825,8 +830,7 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
在整个过程中，请记住：只有当旧内核和新内核的配置相似时，问题才算回归。最好
的方法是：把配置文件（``.config``）从旧的工作内核直接复制到你尝试的每个新内
-核版本。之后运行 ``make oldnoconfig`` 来调整它以适应新版本的需要，而不启用
-任何新的功能，因为那些功能也可能导致回归。
+核版本。之后运行 ``make olddefconfig`` 来调整它以适应新版本的需要。
撰写并发送报告
@@ -959,11 +963,19 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
**非常严重的缺陷** ：确保在主题或工单标题以及第一段中明显标出 severeness
（非常严重的）。
-**回归** ：如果问题是一个回归，请在邮件的主题或缺陷跟踪器的标题中添加
-[REGRESSION]。如果您没有进行二分，请至少注明您测试的最新主线版本（比如 5.7）
-和出现问题的最新版本（比如 5.8）。如果您成功地进行了二分，请注明导致回归
-的提交ID和主题。也请添加该变更的作者到你的报告中；如果您需要将您的缺陷提交
-到缺陷跟踪器中，请将报告以私人邮件的形式转发给他，并注明报告提交地点。
+**回归** ：报告的主题应以“[REGRESSION]”开头。
+
+如果您成功用二分法定位了问题，请使用引入回归之更改的标题作为主题的第二部分。
+请在报告中写明“罪魁祸首”的提交ID。如果未能成功二分，请在报告中讲明最后一个
+正常工作的版本（例如5.7）和最先发生问题的版本（例如5.8-rc1）。
+
+通过邮件发送报告时，请抄送Linux回归邮件列表（regressions@lists.linux.dev）。
+如果报告需要提交到某个web追踪器，请继续提交；并在提交后，通过邮件将报告转发
+至回归列表；抄送相关子系统的维护人员和邮件列表。请确保报告是内联转发的，不要
+把它作为附件。另外请在顶部添加一个简短的说明，在那里写上工单的网址。
+
+在邮寄或转发报告时，如果成功二分，需要将“罪魁祸首”的作者添加到收件人中；同时
+抄送signed-off-by链中的每个人，您可以在提交消息的末尾找到。
**安全问题** ：对于这种问题，你将必须评估：如果细节被公开披露，是否会对其他
用户产生短期风险。如果不会，只需按照所述继续报告问题。如果有此风险，你需要
@@ -1173,14 +1185,18 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
报告回归
~~~~~~~~~~
- *向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)。
- 大致描述问题，并解释如何复现。讲清楚首个出现问题的版本和最后一个工作正常
- 的版本。然后等待进一步的指示。*
+ *向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)并
+ 抄送Linux回归邮件列表（regressions@lists.linux.dev）；如果你怀疑是由某
+ 子系统引起的，请抄送其维护人员和子系统邮件列表。大致描述问题，并解释如
+ 何复现。讲清楚首个出现问题的版本和最后一个工作正常的版本。然后等待进一
+ 步的指示。*
当报告在稳定版或长期支持内核线内发生的回归（例如在从5.10.4更新到5.10.5时），
-一份简短的报告足以快速报告问题。因此只需要粗略的描述。
+一份简短的报告足以快速报告问题。因此只需向稳定版和回归邮件列表发送粗略的描述；
+不过如果你怀疑某子系统导致此问题的话，请一并抄送其维护人员和子系统邮件列表，
+这会加快进程。
-但是请注意，如果您能够指明引入问题的确切版本，这将对开发人员有很大帮助。因此
+请注意，如果您能够指明引入问题的确切版本，这将对开发人员有很大帮助。因此
如果有时间的话，请尝试使用普通内核找到该版本。让我们假设发行版发布Linux内核
5.10.5到5.10.8的更新时发生了故障。那么按照上面的指示，去检查该版本线中的最新
内核，比如5.10.9。如果问题出现，请尝试普通5.10.5，以确保供应商应用的补丁不会
@@ -1191,6 +1207,8 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
报告，因为它允许精确地定位导致问题的确切更改（然后很容易被恢复以快速修复问题）。
因此如果时间允许，考虑立即进行适当的二分。有关如何详细信息，请参阅“对回归的
特别关照”部分和文档“Documentation/translations/zh_CN/admin-guide/bug-bisect.rst”。
+如果成功二分的话，请将“罪魁祸首”的作者添加到收件人中；同时抄送所有在
+signed-off-by链中的人，您可以在提交消息的末尾找到。
“报告仅在旧内核版本线中发生的问题”的参考
--
2.20.1
^ permalink raw reply related [relevance 8%]
* [PATCH v2 3/6] MAINTAINERS: pci: imx: update imx6* to imx* since rename driver file
@ 2024-03-04 20:25 7% ` Frank Li
0 siblings, 0 replies; 200+ results
From: Frank Li @ 2024-03-04 20:25 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Philipp Zabel, Liam Girdwood, Mark Brown
Cc: linux-pci, imx, linux-arm-kernel, linux-kernel, bpf, Frank Li
Add me to imx pcie driver maintainer.
Add mail list imx@lists.linux.dev.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a692..59a409dd604d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16736,14 +16736,16 @@ F: drivers/pci/controller/pci-host-generic.c
PCI DRIVER FOR IMX6
M: Richard Zhu <hongxing.zhu@nxp.com>
+M: Frank Li <Frank.Li@nxp.com>
M: Lucas Stach <l.stach@pengutronix.de>
L: linux-pci@vger.kernel.org
+L: imx@lists.linux.dev
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
-F: drivers/pci/controller/dwc/*imx6*
+F: drivers/pci/controller/dwc/*imx*
PCI DRIVER FOR INTEL IXP4XX
M: Linus Walleij <linus.walleij@linaro.org>
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 8%]
* [PATCH 3/6] MAINTAINERS: pci: imx: update imx6* to imx* since rename driver file
@ 2024-02-27 21:47 7% ` Frank Li
0 siblings, 0 replies; 200+ results
From: Frank Li @ 2024-02-27 21:47 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Philipp Zabel, Liam Girdwood, Mark Brown
Cc: linux-pci, imx, linux-arm-kernel, linux-kernel, bpf, Frank Li
Add me to imx pcie driver maintainer.
Add mail list imx@lists.linux.dev.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a692..59a409dd604d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16736,14 +16736,16 @@ F: drivers/pci/controller/pci-host-generic.c
PCI DRIVER FOR IMX6
M: Richard Zhu <hongxing.zhu@nxp.com>
+M: Frank Li <Frank.Li@nxp.com>
M: Lucas Stach <l.stach@pengutronix.de>
L: linux-pci@vger.kernel.org
+L: imx@lists.linux.dev
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
-F: drivers/pci/controller/dwc/*imx6*
+F: drivers/pci/controller/dwc/*imx*
PCI DRIVER FOR INTEL IXP4XX
M: Linus Walleij <linus.walleij@linaro.org>
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 8%]
* [PATCH 1/2] docs/zh_CN: sync reporting-issues.rst
@ 2022-05-17 17:08 8% ` Wu XiangCheng
2022-05-18 3:16 7% ` [PATCH v2] docs/zh_CN: Update translation of reporting-issues.rst to 5.18 Wu XiangCheng
1 sibling, 0 replies; 200+ results
From: Wu XiangCheng @ 2022-05-17 17:08 UTC (permalink / raw)
To: Alex Shi, Yanteng Si; +Cc: Jonathan Corbet, linux-doc
sync zh_CN/admin-guide/reporting-issues.rst to newest version
commit 0043f0b27a040 ("docs: reporting-issues.rst: CC subsystem and
maintainers on regressions")
Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
Reviewed-by: Alex Shi <alexs@kernel.org>
Reviewed-by: Yanteng Si <siyanteng@loongson.cn>
---
.../zh_CN/admin-guide/reporting-issues.rst | 58 ++++++++++++-------
1 file changed, 38 insertions(+), 20 deletions(-)
diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
index 6b4988da2c5a..6cb098feed94 100644
--- a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
+++ b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
@@ -29,7 +29,9 @@
请搜索 `LKML内核邮件列表 <https://lore.kernel.org/lkml/>`_ 和
`Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ 存档中匹配的报告并
加入讨论。如果找不到匹配的报告，请安装该系列的最新版本。如果它仍然出现问题，
-报告给稳定版邮件列表（stable@vger.kernel.org）。
+请报告给稳定版邮件列表（stable@vger.kernel.org）并抄送回归邮件列表
+（regressions@lists.linux.dev）；理想情况下，还可以抄送维护者和相关子系统的
+邮件列表。
在所有其他情况下，请尽可能猜测是哪个内核部分导致了问题。查看MAINTAINERS文件，
了解开发人员希望如何得知问题，大多数情况下，报告问题都是通过电子邮件和抄送
@@ -46,9 +48,10 @@
有使用附加模块）。还要确保它是在一个正常的环境中构建和运行，并且在问题发生
之前没有被污染（tainted）。
-在编写报告时，要涵盖与问题相关的所有信息，如使用的内核和发行版。在碰见回归时，
-尝试给出引入它的更改的提交ID，二分可以找到它。如果您同时面临Linux内核的多个
-问题，请分别报告每个问题。
+当你同时面临Linux内核的多个问题时，请分别报告。在编写报告时，要涵盖与问题
+相关的所有信息，如使用的内核和发行版。如果碰见回归，请把报告抄送回归邮件列表
+（regressions@lists.linux.dev）。也请试试用二分法找出源头；如果成功找到，请
+在报告中写上它的提交ID并抄送sign-off-by链中的所有人。
一旦报告发出，请回答任何出现的问题，并尽可能地提供帮助。这包括通过不时重新
测试新版本并发送状态更新来推动进展。
@@ -156,9 +159,10 @@
存在问题，因为问题可能已经在那里被修复了。如果您第一次发现供应商内核的问题，
请检查已知最新版本的普通构建是否可以正常运行。
- * 向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)。大致
- 描述问题，并解释如何复现。讲清楚首个出现问题的版本和最后一个工作正常的版本。
- 然后等待进一步的指示。
+ * 向Linux稳定版邮件列表发送一个简短的问题报告（stable@vger.kernel.org）并抄送
+ Linux回归邮件列表（regressions@lists.linux.dev）；如果你怀疑是由某子系统
+ 引起的，请抄送其维护人员和子系统邮件列表。大致描述问题，并解释如何复现。
+ 讲清楚首个出现问题的版本和最后一个工作正常的版本。然后等待进一步的指示。
下面的参考章节部分详细解释了这些步骤中的每一步。
@@ -591,7 +595,8 @@ ath10k@lists.infradead.org”，将引导您到ath10k邮件列表的信息页，
搜索引擎，并添加类似“site:lists.infadead.org/pipermail/ath10k/”这
样的搜索条件，这会把结果限制在该链接中的档案。
-也请进一步搜索网络、LKML和bugzilla.kernel.org网站。
+也请进一步搜索网络、LKML和bugzilla.kernel.org网站。如果你的报告需要发送到缺陷
+跟踪器中，那么您可能还需要检查子系统的邮件列表存档，因为可能有人只在那里报告了它。
有关如何搜索以及在找到匹配报告时如何操作的详细信息，请参阅上面的“搜索现有报告
（第一部分）”。
@@ -825,8 +830,7 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
在整个过程中，请记住：只有当旧内核和新内核的配置相似时，问题才算回归。最好
的方法是：把配置文件（``.config``）从旧的工作内核直接复制到你尝试的每个新内
-核版本。之后运行 ``make oldnoconfig`` 来调整它以适应新版本的需要，而不启用
-任何新的功能，因为那些功能也可能导致回归。
+核版本。之后运行 ``make olddefconfig`` 来调整它以适应新版本的需要。
撰写并发送报告
@@ -959,11 +963,19 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
**非常严重的缺陷** ：确保在主题或工单标题以及第一段中明显标出 severeness
（非常严重的）。
-**回归** ：如果问题是一个回归，请在邮件的主题或缺陷跟踪器的标题中添加
-[REGRESSION]。如果您没有进行二分，请至少注明您测试的最新主线版本（比如 5.7）
-和出现问题的最新版本（比如 5.8）。如果您成功地进行了二分，请注明导致回归
-的提交ID和主题。也请添加该变更的作者到你的报告中；如果您需要将您的缺陷提交
-到缺陷跟踪器中，请将报告以私人邮件的形式转发给他，并注明报告提交地点。
+**回归** ：报告的主题应以“[REGRESSION]”开头。
+
+如果您成功用二分法定位了问题，请使用引入回归之更改的标题作为主题的第二部分。
+请在报告中写明“罪魁祸首”的提交ID。如果未能成功二分，请在报告中讲明最后一个
+正常工作的版本（例如5.7）和最先发生问题的版本（例如5.8-rc1）。
+
+通过邮件发送报告时，请抄送Linux回归邮件列表（regressions@lists.linux.dev）。
+如果报告需要提交到某个web追踪器，请继续提交；并在提交后，通过邮件将报告转发
+至回归列表；抄送相关子系统的维护人员和邮件列表。请确保报告是内联转发的，不要
+把它作为附件。另外请在顶部添加一个简短的说明，在那里写上工单的网址。
+
+在邮寄或转发报告时，如果成功二分，需要将“罪魁祸首”的作者添加到收件人中；同时
+抄送signed-off-by链中的每个人，您可以在提交消息的末尾找到。
**安全问题** ：对于这种问题，你将必须评估：如果细节被公开披露，是否会对其他
用户产生短期风险。如果不会，只需按照所述继续报告问题。如果有此风险，你需要
@@ -1173,14 +1185,18 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
报告回归
~~~~~~~~~~
- *向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)。
- 大致描述问题，并解释如何复现。讲清楚首个出现问题的版本和最后一个工作正常
- 的版本。然后等待进一步的指示。*
+ *向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)并
+ 抄送Linux回归邮件列表（regressions@lists.linux.dev）；如果你怀疑是由某
+ 子系统引起的，请抄送其维护人员和子系统邮件列表。大致描述问题，并解释如
+ 何复现。讲清楚首个出现问题的版本和最后一个工作正常的版本。然后等待进一
+ 步的指示。*
当报告在稳定版或长期支持内核线内发生的回归（例如在从5.10.4更新到5.10.5时），
-一份简短的报告足以快速报告问题。因此只需要粗略的描述。
+一份简短的报告足以快速报告问题。因此只需向稳定版和回归邮件列表发送粗略的描述；
+不过如果你怀疑某子系统导致此问题的话，请一并抄送其维护人员和子系统邮件列表，
+这会加快进程。
-但是请注意，如果您能够指明引入问题的确切版本，这将对开发人员有很大帮助。因此
+请注意，如果您能够指明引入问题的确切版本，这将对开发人员有很大帮助。因此
如果有时间的话，请尝试使用普通内核找到该版本。让我们假设发行版发布Linux内核
5.10.5到5.10.8的更新时发生了故障。那么按照上面的指示，去检查该版本线中的最新
内核，比如5.10.9。如果问题出现，请尝试普通5.10.5，以确保供应商应用的补丁不会
@@ -1191,6 +1207,8 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
报告，因为它允许精确地定位导致问题的确切更改（然后很容易被恢复以快速修复问题）。
因此如果时间允许，考虑立即进行适当的二分。有关如何详细信息，请参阅“对回归的
特别关照”部分和文档“Documentation/translations/zh_CN/admin-guide/bug-bisect.rst”。
+如果成功二分的话，请将“罪魁祸首”的作者添加到收件人中；同时抄送所有在
+signed-off-by链中的人，您可以在提交消息的末尾找到。
“报告仅在旧内核版本线中发生的问题”的参考
--
2.30.2
^ permalink raw reply related [relevance 8%]
* [PATCH] docs/zh_CN: sync reporting-issues.rst translation
@ 2021-05-09 15:07 8% Wu XiangCheng
2021-05-11 11:51 8% ` [PATCH v2] docs/zh_CN: sync reporting-issues.rst Wu XiangCheng
0 siblings, 1 reply; 200+ results
From: Wu XiangCheng @ 2021-05-09 15:07 UTC (permalink / raw)
To: Alex Shi; +Cc: Jonathan Corbet, Yanteng Si, linux-doc
Sync zh_CN/admin-guide/reporting-issues.rst to newest version
commit 0043f0b27a04 ("docs: reporting-issues.rst: CC subsystem and
maintainers on regressions")
Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
---
To make review easier, diff of original file
<http://fars.ee/v7Pk/diff>
Thanks!
.../zh_CN/admin-guide/reporting-issues.rst | 58 ++++++++++++-------
1 file changed, 38 insertions(+), 20 deletions(-)
diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
index 6b4988da2c5a..aa00b9835aee 100644
--- a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
+++ b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
@@ -29,7 +29,9 @@
请搜索 `LKML内核邮件列表 <https://lore.kernel.org/lkml/>`_ 和
`Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ 存档中匹配的报告并
加入讨论。如果找不到匹配的报告，请安装该系列的最新版本。如果它仍然出现问题，
-报告给稳定版邮件列表（stable@vger.kernel.org）。
+请报告给稳定版邮件列表（stable@vger.kernel.org）并抄送回归邮件列表
+（regressions@lists.linux.dev）；理想情况下，还可以抄送维护者和相关子系统的
+邮件列表。
在所有其他情况下，请尽可能猜测是哪个内核部分导致了问题。查看MAINTAINERS文件，
了解开发人员希望如何得知问题，大多数情况下，报告问题都是通过电子邮件和抄送
@@ -46,9 +48,10 @@
有使用附加模块）。还要确保它是在一个正常的环境中构建和运行，并且在问题发生
之前没有被污染（tainted）。
-在编写报告时，要涵盖与问题相关的所有信息，如使用的内核和发行版。在碰见回归时，
-尝试给出引入它的更改的提交ID，二分可以找到它。如果您同时面临Linux内核的多个
-问题，请分别报告每个问题。
+当你同时面临Linux内核的多个问题时，请分别报告。在编写报告时，要涵盖与问题
+相关的所有信息，如使用的内核和发行版。如果碰见回归，请把报告抄送回归邮件列表
+（regressions@lists.linux.dev）。也请试试用二分法找出源头；如果成功找到，请
+在报告中写上它的提交ID并抄送sign-off-by链中的所有人。
一旦报告发出，请回答任何出现的问题，并尽可能地提供帮助。这包括通过不时重新
测试新版本并发送状态更新来推动进展。
@@ -156,9 +159,10 @@
存在问题，因为问题可能已经在那里被修复了。如果您第一次发现供应商内核的问题，
请检查已知最新版本的普通构建是否可以正常运行。
- * 向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)。大致
- 描述问题，并解释如何复现。讲清楚首个出现问题的版本和最后一个工作正常的版本。
- 然后等待进一步的指示。
+ * 向Linux稳定版邮件列表发送一个简短的问题报告（stable@vger.kernel.org）并抄送
+ Linux回归邮件列表（regressions@lists.linux.dev）；如果你怀疑是由某子系统
+ 引起的，请抄送其维护人员和子系统邮件列表。大致描述问题，并解释如何复现。
+ 讲清楚首个出现问题的版本和最后一个工作正常的版本。然后等待进一步的指示。
下面的参考章节部分详细解释了这些步骤中的每一步。
@@ -591,7 +595,8 @@ ath10k@lists.infradead.org”，将引导您到ath10k邮件列表的信息页，
搜索引擎，并添加类似“site:lists.infadead.org/pipermail/ath10k/”这
样的搜索条件，这会把结果限制在该链接中的档案。
-也请进一步搜索网络、LKML和bugzilla.kernel.org网站。
+也请进一步搜索网络、LKML和bugzilla.kernel.org网站。如果你的报告需要发送到缺陷
+跟踪器中，那么您可能还需要检查子系统的邮件列表存档，因为可能有人只在那里报告了它。
有关如何搜索以及在找到匹配报告时如何操作的详细信息，请参阅上面的“搜索现有报告
（第一部分）”。
@@ -825,8 +830,7 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
在整个过程中，请记住：只有当旧内核和新内核的配置相似时，问题才算回归。最好
的方法是：把配置文件（``.config``）从旧的工作内核直接复制到你尝试的每个新内
-核版本。之后运行 ``make oldnoconfig`` 来调整它以适应新版本的需要，而不启用
-任何新的功能，因为那些功能也可能导致回归。
+核版本。之后运行 ``make olddefconfig`` 来调整它以适应新版本的需要。
撰写并发送报告
@@ -959,11 +963,19 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这
**非常严重的缺陷** ：确保在主题或工单标题以及第一段中明显标出 severeness
（非常严重的）。
-**回归** ：如果问题是一个回归，请在邮件的主题或缺陷跟踪器的标题中添加
-[REGRESSION]。如果您没有进行二分，请至少注明您测试的最新主线版本（比如 5.7）
-和出现问题的最新版本（比如 5.8）。如果您成功地进行了二分，请注明导致回归
-的提交ID和主题。也请添加该变更的作者到你的报告中；如果您需要将您的缺陷提交
-到缺陷跟踪器中，请将报告以私人邮件的形式转发给他，并注明报告提交地点。
+**回归** ：报告的主题应以“[REGRESSION]”开头。
+
+如果您成功地进行了二分，请使用引入回归之更改的标题作为主题的第二部分。请在
+报告中写明罪魁祸首的提交ID。如果未能成功二分，请在报告中讲明最后一个正常工作
+的版本（例如5.7）和最先发生问题的版本（例如5.8-rc1）。
+
+通过邮件发送报告时，请抄送Linux回归邮件列表（regressions@lists.linux.dev）。
+如果报告需要提交到某个web追踪器，请继续提交；并在提交后，通过邮件将报告转发
+至回归列表；抄送相关子系统的维护人员和邮件列表。请确保报告是内联转发的，不要
+把它作为附件。另外请在顶部添加一个简短的说明，在那里写上工单的网址。
+
+在邮寄或转发报告时，如果成功二分，需要将问题源头的作者添加到收件人中；同时
+抄送signed-off-by链中的每个人，您可以在提交消息的末尾找到。
**安全问题** ：对于这种问题，你将必须评估：如果细节被公开披露，是否会对其他
用户产生短期风险。如果不会，只需按照所述继续报告问题。如果有此风险，你需要
@@ -1173,14 +1185,18 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
报告回归
~~~~~~~~~~
- *向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)。
- 大致描述问题，并解释如何复现。讲清楚首个出现问题的版本和最后一个工作正常
- 的版本。然后等待进一步的指示。*
+ *向Linux稳定版邮件列表发送一个简短的问题报告(stable@vger.kernel.org)并
+ 抄送Linux回归邮件列表（regressions@lists.linux.dev）；如果你怀疑是由某
+ 子系统引起的，请抄送其维护人员和子系统邮件列表。大致描述问题，并解释如
+ 何复现。讲清楚首个出现问题的版本和最后一个工作正常的版本。然后等待进一
+ 步的指示。*
当报告在稳定版或长期支持内核线内发生的回归（例如在从5.10.4更新到5.10.5时），
-一份简短的报告足以快速报告问题。因此只需要粗略的描述。
+一份简短的报告足以快速报告问题。因此只需向稳定版和回归邮件列表发送粗略的描述；
+不过如果你怀疑某子系统导致此问题的话，请一并抄送其维护人员和子系统邮件列表，
+这会加快进程。
-但是请注意，如果您能够指明引入问题的确切版本，这将对开发人员有很大帮助。因此
+请注意，如果您能够指明引入问题的确切版本，这将对开发人员有很大帮助。因此
如果有时间的话，请尝试使用普通内核找到该版本。让我们假设发行版发布Linux内核
5.10.5到5.10.8的更新时发生了故障。那么按照上面的指示，去检查该版本线中的最新
内核，比如5.10.9。如果问题出现，请尝试普通5.10.5，以确保供应商应用的补丁不会
@@ -1191,6 +1207,8 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于
报告，因为它允许精确地定位导致问题的确切更改（然后很容易被恢复以快速修复问题）。
因此如果时间允许，考虑立即进行适当的二分。有关如何详细信息，请参阅“对回归的
特别关照”部分和文档“Documentation/translations/zh_CN/admin-guide/bug-bisect.rst”。
+如果成功二分的话，请将问题源头的作者添加到收件人中；同时抄送所有在signed-off-by
+链中的人，您可以在提交消息的末尾找到。
“报告仅在旧内核版本线中发生的问题”的参考
--
2.20.1
^ permalink raw reply related [relevance 8%]
* [PATCH v2 12/14] README.md: update mailing list and contributing information
@ 2023-10-26 17:41 8% ` mwilck
0 siblings, 0 replies; 200+ results
From: mwilck @ 2023-10-26 17:41 UTC (permalink / raw)
To: Christophe Varoqui, Benjamin Marzinski
Cc: dm-devel, Martin Wilck, Xose Vazquez Perez
From: Martin Wilck <mwilck@suse.com>
Create a "Contributing" section. Move the the current sections
related to contributing into that section.
Signed-off-by: Martin Wilck <mwilck@suse.com>
Cc: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
README.md | 56 ++++++++++++++++++++++++++++++++++++-------------------
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git a/README.md b/README.md
index 25ce963..b2ed1f2 100644
--- a/README.md
+++ b/README.md
@@ -42,14 +42,6 @@ Go to: https://github.com/opensvc/multipath-tools/tags
Select a release-tag and then click on "zip" or "tar.gz".
-Devel code
-==========
-
-To get latest devel code:
-
- git clone -b queue https://github.com/openSUSE/multipath-tools
-
-
Building multipath-tools
========================
@@ -188,19 +180,45 @@ The following targets are intended for developers only.
* `make compile-commands.json` to create input for [clangd](https://clangd.llvm.org/).
-Add storage devices
-===================
-
-Follow the instructions in the `libmultipath/hwtable.c` header.
-
-
-Mailing list
+Contributing
============
-(subscribers-only)
-To subscribe and archives: https://listman.redhat.com/mailman/listinfo/dm-devel
-Searchable: https://marc.info/?l=dm-devel
+Please send patches or contributions for general discussion about
+multipath tools to the mailing list (see below). You can also create
+issues or pull requests on
+[GitHub](https://github.com/opensvc/multipath-tools).
+You will be asked to send your patches to the mailing list
+unless your patch is trivial.
+Mailing list
+------------
+
+The mailing list for multipath-tools is `dm-devel@lists.linux.dev`.
+To subscribe, send an email to `dm-devel+subscribe@lists.linux.dev`.
+Mailing list archives are available on
+[lore.kernel.org](https://lore.kernel.org/dm-devel/) and
+[marc.info](https://marc.info/?l=dm-devel). See also the
+[lists.linux.dev home page](https://subspace.kernel.org/lists.linux.dev.html).
+
+When sending patches to the mailing list, lease add a `Signed-off-by:`
+tag, and add Benjamin Marzinski <bmarzins@redhat.com> and
+Martin Wilck <mwilck@suse.com> to the Cc list.
+
+Staging area
+------------
+
+Between releases, the latest reviewed code can be obtained from
+[the queue branch](https://github.com/openSUSE/multipath-tools/tree/queue)
+in the openSUSE/multipath-tools repository on GitHub. From there,
+pull requests for new releases in the master repository are
+created roughly every 3 months.
+
+Adding new storage devices
+--------------------------
+
+If you want to add special settings for a storage device which is
+new on the market, follow the instructions at the top of the
+file `libmultipath/hwtable.c`.
Changelog
=========
@@ -213,7 +231,7 @@ Maintainer
==========
Christophe Varoqui <christophe.varoqui@opensvc.com>
-Device-mapper development mailing list <dm-devel@redhat.com>
+Device-mapper development mailing list <dm-devel@lists.linux.dev>
Licence
--
2.42.0
^ permalink raw reply related [relevance 8%]
* [PATCH v3] wifi: cleanup brcm80211 drivers maintainer entry
@ 2024-01-26 10:57 8% Arend van Spriel
0 siblings, 0 replies; 200+ results
From: Arend van Spriel @ 2024-01-26 10:57 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel, brcm80211
[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]
There has been some discussion about what is expected from
a maintainer and so a cleanup seems to be in order. A dedicated
mailing list has been created to discuss brcm80211 specific
development issues. Keeping the status as Supported although
help in maintaining this driver is welcomed.
Cc: brcm80211@lists.linux.dev
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
changelog:
V2: let's not orphan the drivers for now
V3: switch to my Broadcom email
The discussion around the SAE password patch [1] was a lively one
and at some point I wanted to drop the ball and be done with it.
However, when the emotions subsided and people offered to help out
with maintaining the brcm80211 drivers I decided to stay on for the
job. The discussion had some valid points specifically on my actual
involvement. Hopefully I can improve in that aspect. I sharpened my
email filters to keep better eye on brcm80211 related queryies,
patches and what not.
Another step taken is the creation of a specific mailing list for
brcm80211 development topics:
<brcm80211@lists.linux.dev>
The driver wireless wiki can also use a cleanup. Probably will add
a list of people who volunteer to perform regression testing with
the chipsets they have available.
Hope we can move on in a relatively fresh new year and leave the
frustration behind us.
This patch was based on the wireless tree, but it probably applies
to wireless-next as well. I am fine either way.
Regards,
Arend
[1] https://lore.kernel.org/linux-wireless/20231107-brcmfmac-wpa3-v1-1-4c7db8636680@marcan.st/
---
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d8ca0e10c8d1..25d530ab90d7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4169,14 +4169,14 @@ F: drivers/firmware/broadcom/tee_bnxt_fw.c
F: drivers/net/ethernet/broadcom/bnxt/
F: include/linux/firmware/broadcom/tee_bnxt_fw.h
-BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
-M: Arend van Spriel <aspriel@gmail.com>
-M: Franky Lin <franky.lin@broadcom.com>
-M: Hante Meuleman <hante.meuleman@broadcom.com>
+BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS
+M: Arend van Spriel <arend.vanspriel@broadcom.com>
L: linux-wireless@vger.kernel.org
+L: brcm80211@lists.linux.dev
L: brcm80211-dev-list.pdl@broadcom.com
S: Supported
F: drivers/net/wireless/broadcom/brcm80211/
+F: include/linux/platform_data/brcmfmac.h
BROADCOM BRCMSTB GPIO DRIVER
M: Doug Berger <opendmb@gmail.com>
base-commit: 1b023d475ae928f3036cefee9ea0a499af1d8900
--
2.32.0
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]
^ permalink raw reply related [relevance 8%]
* [PATCH v2] wifi: cleanup brcm80211 drivers maintainer entry
@ 2024-01-26 10:51 8% Arend van Spriel
0 siblings, 0 replies; 200+ results
From: Arend van Spriel @ 2024-01-26 10:51 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel, brcm80211
[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]
There has been some discussion about what is expected from
a maintainer and so a cleanup seems to be in order. A dedicated
mailing list has been created to discuss brcm80211 specific
development issues. Keeping the status as Supported although
help in maintaining this driver is welcomed.
Cc: brcm80211@lists.linux.dev
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
changelog:
V2: let's not orphan the drivers for now
The discussion around the SAE password patch [1] was a lively one
and at some point I wanted to drop the ball and be done with it.
However, when the emotions subsided and people offered to help out
with maintaining the brcm80211 drivers I decided to stay on for the
job. The discussion had some valid points specifically on my actual
involvement. Hopefully I can improve in that aspect. I sharpened my
email filters to keep better eye on brcm80211 related queryies,
patches and what not.
Another step taken is the creation of a specific mailing list for
brcm80211 development topics:
<brcm80211@lists.linux.dev>
The driver wireless wiki can also use a cleanup. Probably will add
a list of people who volunteer to perform regression testing with
the chipsets they have available.
Hope we can move on in a relatively fresh new year and leave the
frustration behind us.
This patch was based on the wireless tree, but it probably applies
to wireless-next as well. I am fine either way.
Regards,
Arend
[1] https://lore.kernel.org/linux-wireless/20231107-brcmfmac-wpa3-v1-1-4c7db8636680@marcan.st/
---
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d8ca0e10c8d1..79a95a5156df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4169,14 +4169,14 @@ F: drivers/firmware/broadcom/tee_bnxt_fw.c
F: drivers/net/ethernet/broadcom/bnxt/
F: include/linux/firmware/broadcom/tee_bnxt_fw.h
-BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
+BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS
M: Arend van Spriel <aspriel@gmail.com>
-M: Franky Lin <franky.lin@broadcom.com>
-M: Hante Meuleman <hante.meuleman@broadcom.com>
L: linux-wireless@vger.kernel.org
+L: brcm80211@lists.linux.dev
L: brcm80211-dev-list.pdl@broadcom.com
S: Supported
F: drivers/net/wireless/broadcom/brcm80211/
+F: include/linux/platform_data/brcmfmac.h
BROADCOM BRCMSTB GPIO DRIVER
M: Doug Berger <opendmb@gmail.com>
base-commit: 1b023d475ae928f3036cefee9ea0a499af1d8900
--
2.32.0
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]
^ permalink raw reply related [relevance 8%]
* [RESEND PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries
@ 2021-09-03 5:09 8% ` Kajol Jain
0 siblings, 0 replies; 200+ results
From: Kajol Jain @ 2021-09-03 5:09 UTC (permalink / raw)
To: mpe, linuxppc-dev, nvdimm, linux-kernel, peterz, dan.j.williams,
ira.weiny, vishal.l.verma
Cc: maddy, santosh, aneesh.kumar, vaibhav, atrajeev, tglx, kjain,
rnsastry
Details is added for the event, cpumask and format attributes
in the ABI documentation.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 95254cec92bf..4d86252448f8 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -61,3 +61,34 @@ Description:
* "CchRHCnt" : Cache Read Hit Count
* "CchWHCnt" : Cache Write Hit Count
* "FastWCnt" : Fast Write Count
+
+What: /sys/devices/nmemX/format
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. Supported attribute is listed
+ below::
+
+ event = "config:0-4" - event ID
+
+ For example::
+ noopstat = "event=0x1"
+
+What: /sys/devices/nmemX/events
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe performance monitoring
+ events specific to papr-scm. Each attribute in this group describes
+ a single performance monitoring event supported by this nvdimm pmu.
+ The name of the file is the name of the event.
+ (See ABI/testing/sysfs-bus-event_source-devices-events).
+
+What: /sys/devices/nmemX/cpumask
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) This sysfs file exposes the cpumask which is designated to make
+ HCALLs to retrieve nvdimm pmu event counter data.
--
2.26.2
^ permalink raw reply related [relevance 8%]
* [PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries
@ 2021-08-02 7:39 8% ` Kajol Jain
0 siblings, 0 replies; 200+ results
From: Kajol Jain @ 2021-08-02 7:39 UTC (permalink / raw)
To: mpe, linuxppc-dev, nvdimm, linux-kernel, peterz, dan.j.williams,
ira.weiny, vishal.l.verma
Cc: maddy, santosh, aneesh.kumar, vaibhav, atrajeev, tglx, kjain,
rnsastry
Details is added for the event, cpumask and format attributes
in the ABI documentation.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 95254cec92bf..4d86252448f8 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -61,3 +61,34 @@ Description:
* "CchRHCnt" : Cache Read Hit Count
* "CchWHCnt" : Cache Write Hit Count
* "FastWCnt" : Fast Write Count
+
+What: /sys/devices/nmemX/format
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. Supported attribute is listed
+ below::
+
+ event = "config:0-4" - event ID
+
+ For example::
+ noopstat = "event=0x1"
+
+What: /sys/devices/nmemX/events
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe performance monitoring
+ events specific to papr-scm. Each attribute in this group describes
+ a single performance monitoring event supported by this nvdimm pmu.
+ The name of the file is the name of the event.
+ (See ABI/testing/sysfs-bus-event_source-devices-events).
+
+What: /sys/devices/nmemX/cpumask
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) This sysfs file exposes the cpumask which is designated to make
+ HCALLs to retrieve nvdimm pmu event counter data.
--
2.26.2
^ permalink raw reply related [relevance 8%]
* [merged] documentation-llvm-update-mailing-list.patch removed from -mm tree
@ 2021-09-09 21:04 8% akpm
0 siblings, 0 replies; 200+ results
From: akpm @ 2021-09-09 21:04 UTC (permalink / raw)
To: keescook, masahiroy, mm-commits, nathan, ndesaulniers,
samitolvanen
The patch titled
Subject: Documentation/llvm: update mailing list
has been removed from the -mm tree. Its filename was
documentation-llvm-update-mailing-list.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Nathan Chancellor <nathan@kernel.org>
Subject: Documentation/llvm: update mailing list
We are now at llvm@lists.linux.dev.
Link: https://lkml.kernel.org/r/20210825211823.6406-2-nathan@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/kbuild/llvm.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/Documentation/kbuild/llvm.rst~documentation-llvm-update-mailing-list
+++ a/Documentation/kbuild/llvm.rst
@@ -111,7 +111,8 @@ Getting Help
------------
- `Website <https://clangbuiltlinux.github.io/>`_
-- `Mailing List <https://groups.google.com/forum/#!forum/clang-built-linux>`_: <clang-built-linux@googlegroups.com>
+- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev>
+- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_
- `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_
- IRC: #clangbuiltlinux on chat.freenode.net
- `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux
_
Patches currently in -mm which might be from nathan@kernel.org are
^ permalink raw reply [relevance 8%]
* [RESEND PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries
@ 2021-09-03 5:09 8% ` Kajol Jain
0 siblings, 0 replies; 200+ results
From: Kajol Jain @ 2021-09-03 5:09 UTC (permalink / raw)
To: mpe, linuxppc-dev, nvdimm, linux-kernel, peterz, dan.j.williams,
ira.weiny, vishal.l.verma
Cc: santosh, maddy, rnsastry, aneesh.kumar, atrajeev, kjain, vaibhav,
tglx
Details is added for the event, cpumask and format attributes
in the ABI documentation.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 95254cec92bf..4d86252448f8 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -61,3 +61,34 @@ Description:
* "CchRHCnt" : Cache Read Hit Count
* "CchWHCnt" : Cache Write Hit Count
* "FastWCnt" : Fast Write Count
+
+What: /sys/devices/nmemX/format
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. Supported attribute is listed
+ below::
+
+ event = "config:0-4" - event ID
+
+ For example::
+ noopstat = "event=0x1"
+
+What: /sys/devices/nmemX/events
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe performance monitoring
+ events specific to papr-scm. Each attribute in this group describes
+ a single performance monitoring event supported by this nvdimm pmu.
+ The name of the file is the name of the event.
+ (See ABI/testing/sysfs-bus-event_source-devices-events).
+
+What: /sys/devices/nmemX/cpumask
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) This sysfs file exposes the cpumask which is designated to make
+ HCALLs to retrieve nvdimm pmu event counter data.
--
2.26.2
^ permalink raw reply related [relevance 8%]
* [PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries
@ 2021-08-02 7:39 8% ` Kajol Jain
0 siblings, 0 replies; 200+ results
From: Kajol Jain @ 2021-08-02 7:39 UTC (permalink / raw)
To: mpe, linuxppc-dev, nvdimm, linux-kernel, peterz, dan.j.williams,
ira.weiny, vishal.l.verma
Cc: santosh, maddy, rnsastry, aneesh.kumar, atrajeev, kjain, vaibhav,
tglx
Details is added for the event, cpumask and format attributes
in the ABI documentation.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 95254cec92bf..4d86252448f8 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -61,3 +61,34 @@ Description:
* "CchRHCnt" : Cache Read Hit Count
* "CchWHCnt" : Cache Write Hit Count
* "FastWCnt" : Fast Write Count
+
+What: /sys/devices/nmemX/format
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. Supported attribute is listed
+ below::
+
+ event = "config:0-4" - event ID
+
+ For example::
+ noopstat = "event=0x1"
+
+What: /sys/devices/nmemX/events
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe performance monitoring
+ events specific to papr-scm. Each attribute in this group describes
+ a single performance monitoring event supported by this nvdimm pmu.
+ The name of the file is the name of the event.
+ (See ABI/testing/sysfs-bus-event_source-devices-events).
+
+What: /sys/devices/nmemX/cpumask
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) This sysfs file exposes the cpumask which is designated to make
+ HCALLs to retrieve nvdimm pmu event counter data.
--
2.26.2
^ permalink raw reply related [relevance 8%]
* [PATCH net-next 2/5] MAINTAINERS: add git trees for MPTCP
@ 2023-04-14 15:47 8% ` Matthieu Baerts
0 siblings, 0 replies; 200+ results
From: Matthieu Baerts @ 2023-04-14 15:47 UTC (permalink / raw)
To: mptcp, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Shuah Khan
Cc: netdev, linux-kernel, linux-kselftest, Matthieu Baerts
This will help occasional developers to find our git repo without having
to look at our wiki.
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b8b275e27cdb..1c09473685b1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14617,6 +14617,8 @@ L: mptcp@lists.linux.dev
S: Maintained
W: https://github.com/multipath-tcp/mptcp_net-next/wiki
B: https://github.com/multipath-tcp/mptcp_net-next/issues
+T: git https://github.com/multipath-tcp/mptcp_net-next.git export-net
+T: git https://github.com/multipath-tcp/mptcp_net-next.git export
F: Documentation/networking/mptcp-sysctl.rst
F: include/net/mptcp.h
F: include/trace/events/mptcp.h
--
2.39.2
^ permalink raw reply related [relevance 8%]
* [PATCH v3 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries
@ 2021-06-17 13:26 8% ` Kajol Jain
0 siblings, 0 replies; 200+ results
From: Kajol Jain @ 2021-06-17 13:26 UTC (permalink / raw)
To: mpe, linuxppc-dev, nvdimm, linux-kernel, peterz
Cc: maddy, santosh, aneesh.kumar, vaibhav, dan.j.williams, ira.weiny,
atrajeev, tglx, kjain, rnsastry
Details is added for the event, cpumask and format attributes
in the ABI documentation.
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 92e2db0e2d3d..be91de341454 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -59,3 +59,34 @@ Description:
* "CchRHCnt" : Cache Read Hit Count
* "CchWHCnt" : Cache Write Hit Count
* "FastWCnt" : Fast Write Count
+
+What: /sys/devices/nmemX/format
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. Supported attribute is listed
+ below::
+
+ event = "config:0-4" - event ID
+
+ For example::
+ noopstat = "event=0x1"
+
+What: /sys/devices/nmemX/events
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe performance monitoring
+ events specific to papr-scm. Each attribute in this group describes
+ a single performance monitoring event supported by this nvdimm pmu.
+ The name of the file is the name of the event.
+ (See ABI/testing/sysfs-bus-event_source-devices-events).
+
+What: /sys/devices/nmemX/cpumask
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) This sysfs file exposes the cpumask which is designated to make
+ HCALLs to retrieve nvdimm pmu event counter data.
--
2.27.0
^ permalink raw reply related [relevance 8%]
* [PATCH 2/2] MAINTAINERS: Fix file pattern for ARM/APPLE MACHINE SOUND DRIVERS
@ 2022-09-01 11:34 8% ` Martin Povišer
0 siblings, 0 replies; 200+ results
From: Martin Povišer @ 2022-09-01 11:34 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: linux-kernel, asahi, alsa-devel, Martin Povišer
This is what was meant of course.
Fixes: 3df5d0d97289 ("ASoC: apple: mca: Start new platform driver")
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f91a6b62f2f..895e8ace80dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1905,7 +1905,7 @@ L: asahi@lists.linux.dev
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/sound/apple,*
-F: drivers/sound/apple/*
+F: sound/soc/apple/*
ARM/ARTPEC MACHINE SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
--
2.33.0
^ permalink raw reply related [relevance 8%]
* [PATCH 2/2] MAINTAINERS: Fix file pattern for ARM/APPLE MACHINE SOUND DRIVERS
@ 2022-09-01 11:34 8% ` Martin Povišer
0 siblings, 0 replies; 200+ results
From: Martin Povišer @ 2022-09-01 11:34 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Martin Povišer, alsa-devel, linux-kernel, asahi
This is what was meant of course.
Fixes: 3df5d0d97289 ("ASoC: apple: mca: Start new platform driver")
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f91a6b62f2f..895e8ace80dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1905,7 +1905,7 @@ L: asahi@lists.linux.dev
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/sound/apple,*
-F: drivers/sound/apple/*
+F: sound/soc/apple/*
ARM/ARTPEC MACHINE SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
--
2.33.0
^ permalink raw reply related [relevance 8%]
* [PATCH] MAINTAINERS: rectify entry in ARM/APPLE MACHINE SOUND DRIVERS
@ 2022-09-05 9:35 8% ` Lukas Bulwahn
0 siblings, 0 replies; 200+ results
From: Lukas Bulwahn @ 2022-09-05 9:35 UTC (permalink / raw)
To: Martin Povišer, Mark Brown, asahi, alsa-devel
Cc: kernel-janitors, linux-kernel, Lukas Bulwahn
Commit 3df5d0d97289 ("ASoC: apple: mca: Start new platform driver") adds
a new sound driver at the location "sound/soc/apple/", but it adds a file
entry referring to the non-existing location "drivers/sound/apple/*".
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a
broken reference.
Repair this file reference in ARM/APPLE MACHINE SOUND DRIVERS.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
---
Martin, please ack.
Mark, please pick this patch on top of the commit above.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 29443aad5031..c239d7e69158 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1904,7 +1904,7 @@ L: asahi@lists.linux.dev
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/sound/apple,*
-F: drivers/sound/apple/*
+F: sound/soc/apple/
ARM/ARTPEC MACHINE SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
--
2.17.1
^ permalink raw reply related [relevance 8%]
* [PATCH] MAINTAINERS: rectify entry in ARM/APPLE MACHINE SOUND DRIVERS
@ 2022-09-05 9:35 8% ` Lukas Bulwahn
0 siblings, 0 replies; 200+ results
From: Lukas Bulwahn @ 2022-09-05 9:35 UTC (permalink / raw)
To: Martin Povišer, Mark Brown, asahi, alsa-devel
Cc: Lukas Bulwahn, kernel-janitors, linux-kernel
Commit 3df5d0d97289 ("ASoC: apple: mca: Start new platform driver") adds
a new sound driver at the location "sound/soc/apple/", but it adds a file
entry referring to the non-existing location "drivers/sound/apple/*".
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a
broken reference.
Repair this file reference in ARM/APPLE MACHINE SOUND DRIVERS.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
---
Martin, please ack.
Mark, please pick this patch on top of the commit above.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 29443aad5031..c239d7e69158 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1904,7 +1904,7 @@ L: asahi@lists.linux.dev
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/sound/apple,*
-F: drivers/sound/apple/*
+F: sound/soc/apple/
ARM/ARTPEC MACHINE SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
--
2.17.1
^ permalink raw reply related [relevance 8%]
* [PATCH mptcp-next 1/3] MAINTAINERS: add git trees for MPTCP
@ 2023-03-29 13:17 8% ` Matthieu Baerts
0 siblings, 0 replies; 200+ results
From: Matthieu Baerts @ 2023-03-29 13:17 UTC (permalink / raw)
To: mptcp; +Cc: Matthieu Baerts
This will help occasional reviewers to find our git repo without having
to look at the wiki.
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 45fe6d7e918a..1b45ba8a1536 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14607,6 +14607,8 @@ L: mptcp@lists.linux.dev
S: Maintained
W: https://github.com/multipath-tcp/mptcp_net-next/wiki
B: https://github.com/multipath-tcp/mptcp_net-next/issues
+T: git https://github.com/multipath-tcp/mptcp_net-next.git export-net
+T: git https://github.com/multipath-tcp/mptcp_net-next.git export
F: Documentation/networking/mptcp-sysctl.rst
F: include/net/mptcp.h
F: include/trace/events/mptcp.h
--
2.39.2
^ permalink raw reply related [relevance 8%]
* [PATCH] MAINTAINERS: list all Qualcomm IOMMU drivers in the QUALCOMM IOMMU entry
@ 2023-11-03 22:54 8% Dmitry Baryshkov
0 siblings, 0 replies; 200+ results
From: Dmitry Baryshkov @ 2023-11-03 22:54 UTC (permalink / raw)
To: Rob Clark, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Joerg Roedel, Will Deacon
Cc: Robin Murphy, iommu, linux-arm-msm, linux-kernel
For historical reasons the 'QUALCOMM IOMMU' entry lists only one
Qualcomm IOMMU driver. However there are also the historical MSM IOMMU
driver, which is used for old 32-bit platforms, and the
Qualcomm-specific customisations for the generic ARM SMMU driver. List
all these files under the QUALCOMM IOMMU entry.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5a7dc3e56e1e..ed1c864794aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17888,6 +17888,8 @@ L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
F: drivers/iommu/arm/arm-smmu/qcom_iommu.c
+F: drivers/iommu/arm/arm-smmu/arm-smmu-qcom*
+F: drivers/iommu/msm_iommu*
QUALCOMM IPC ROUTER (QRTR) DRIVER
M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
--
2.42.0
^ permalink raw reply related [relevance 8%]
* [PATCH v3 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries
@ 2021-06-17 13:26 8% ` Kajol Jain
0 siblings, 0 replies; 200+ results
From: Kajol Jain @ 2021-06-17 13:26 UTC (permalink / raw)
To: mpe, linuxppc-dev, nvdimm, linux-kernel, peterz
Cc: santosh, maddy, rnsastry, aneesh.kumar, atrajeev, kjain, vaibhav,
dan.j.williams, ira.weiny, tglx
Details is added for the event, cpumask and format attributes
in the ABI documentation.
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 92e2db0e2d3d..be91de341454 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -59,3 +59,34 @@ Description:
* "CchRHCnt" : Cache Read Hit Count
* "CchWHCnt" : Cache Write Hit Count
* "FastWCnt" : Fast Write Count
+
+What: /sys/devices/nmemX/format
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. Supported attribute is listed
+ below::
+
+ event = "config:0-4" - event ID
+
+ For example::
+ noopstat = "event=0x1"
+
+What: /sys/devices/nmemX/events
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) Attribute group to describe performance monitoring
+ events specific to papr-scm. Each attribute in this group describes
+ a single performance monitoring event supported by this nvdimm pmu.
+ The name of the file is the name of the event.
+ (See ABI/testing/sysfs-bus-event_source-devices-events).
+
+What: /sys/devices/nmemX/cpumask
+Date: June 2021
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description: (RO) This sysfs file exposes the cpumask which is designated to make
+ HCALLs to retrieve nvdimm pmu event counter data.
--
2.27.0
^ permalink raw reply related [relevance 8%]
* [PATCH net] mptcp: Change mailing list address
@ 2021-03-19 18:33 8% Mat Martineau
0 siblings, 0 replies; 200+ results
From: Mat Martineau @ 2021-03-19 18:33 UTC (permalink / raw)
To: netdev; +Cc: Mat Martineau, davem, kuba, mptcp, mptcp, Matthieu Baerts
The mailing list for MPTCP maintenance has moved to the
kernel.org-supported mptcp@lists.linux.dev address.
Complete, combined archives for both lists are now hosted at
https://lore.kernel.org/mptcp
Cc: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d80d3dda3d0..8e43e0417335 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12539,7 +12539,7 @@ NETWORKING [MPTCP]
M: Mat Martineau <mathew.j.martineau@linux.intel.com>
M: Matthieu Baerts <matthieu.baerts@tessares.net>
L: netdev@vger.kernel.org
-L: mptcp@lists.01.org
+L: mptcp@lists.linux.dev
S: Maintained
W: https://github.com/multipath-tcp/mptcp_net-next/wiki
B: https://github.com/multipath-tcp/mptcp_net-next/issues
base-commit: c79a707072fe3fea0e3c92edee6ca85c1e53c29f
--
2.31.0
^ permalink raw reply related [relevance 8%]
* [PATCH] MAINTAINERS: Add new IOMMU development mailing list
@ 2022-06-22 8:26 8% Joerg Roedel
0 siblings, 0 replies; 200+ results
From: Joerg Roedel @ 2022-06-22 8:26 UTC (permalink / raw)
To: linux-kernel; +Cc: iommu, iommu, Joerg Roedel
From: Joerg Roedel <jroedel@suse.de>
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1fc9ead83d2a..b5bac297d63d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10354,6 +10354,7 @@ IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: Documentation/devicetree/bindings/iommu/
--
2.36.1
^ permalink raw reply related [relevance 8%]
* [RFC PATCH v1 1/2] MAINTAINERS: add regressions mailing list
@ 2021-04-07 9:21 8% ` Thorsten Leemhuis
2021-04-07 9:21 7% ` [RFC PATCH v1 2/2] docs: reporting-issues: make everyone CC the regressions list Thorsten Leemhuis
1 sibling, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2021-04-07 9:21 UTC (permalink / raw)
To: Jonathan Corbet, Greg KH, Linus Torvalds
Cc: Randy Dunlap, linux-doc, linux-kernel
Add the newly created regression mailing list finally created after it
already had been agreed on during the maintainers summit 2017 (see
https://lwn.net/Articles/738216/ ). The topic was recently discussed
again, where an idea to create a broader list for all issues was
discussed, but Linus preferred a more targeted list:
https://lkml.kernel.org/r/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fOsdc_ZJ7WF47wS73CA@mail.gmail.com/
Hence, the creation for that list was asked for and granted:
https://bugzilla.kernel.org/show_bug.cgi?id=212557
In the end it became regressions@lists.linux.dev instead of
linux-regressions@lists.linux.dev as 'Linux' is redundant in the latter
case.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
I was a bit unsure how to add that list to MAINTAINERS. I considered
adding a 'M:' with my name and email address there as well, but getting
CCed on a lot of regression reports might be a bit much. I also left a
'S: supported' out, as that doesn't make much sense in this case afaics;
and I checked, there are other entries that don't have those two (but
it's rare).
Ciao, Thorsten
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 03b2096a5f8f..dd5743d1f743 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15212,6 +15212,10 @@ F: Documentation/devicetree/bindings/regmap/
F: drivers/base/regmap/
F: include/linux/regmap.h
+REGRESSIONS
+L: regressions@lists.linux.dev
+K: regression
+
REISERFS FILE SYSTEM
L: reiserfs-devel@vger.kernel.org
S: Supported
--
2.30.2
^ permalink raw reply related [relevance 8%]
* [PATCH] Documentation: update mailing list addresses
@ 2024-02-14 20:09 8% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2024-02-14 20:09 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, Xuan Zhuo, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jonathan Corbet,
Theodore Ts'o, Greg Kroah-Hartman, Carlos Bilbao,
Avadhut Naik
Cc: virtualization, linux-kernel, netdev, linux-doc,
tech-board-discuss, workflows, Konstantin Ryabitsev
The mailman2 server running on lists.linuxfoundation.org will be shut
down in very imminent future. Update all instances of obsolete list
addresses throughout the tree with their new destinations.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
---
Jon, I am sending this primarily to linux-doc, since most of the changes
are in Documentation/* and only a handful in MAINTAINERS. I think it
makes most sense to bubble this up via the docs subsystem.
---
Documentation/ABI/testing/sysfs-bus-vdpa | 10 +++++-----
Documentation/networking/bridge.rst | 2 +-
Documentation/process/researcher-guidelines.rst | 2 +-
.../translations/sp_SP/process/researcher-guidelines.rst | 2 +-
MAINTAINERS | 6 +++---
5 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-vdpa b/Documentation/ABI/testing/sysfs-bus-vdpa
index 4da53878bff6..2c833b5163f2 100644
--- a/Documentation/ABI/testing/sysfs-bus-vdpa
+++ b/Documentation/ABI/testing/sysfs-bus-vdpa
@@ -1,6 +1,6 @@
What: /sys/bus/vdpa/drivers_autoprobe
Date: March 2020
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
This file determines whether new devices are immediately bound
to a driver after the creation. It initially contains 1, which
@@ -12,7 +12,7 @@ Description:
What: /sys/bus/vdpa/driver_probe
Date: March 2020
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
Writing a device name to this file will cause the kernel binds
devices to a compatible driver.
@@ -22,7 +22,7 @@ Description:
What: /sys/bus/vdpa/drivers/.../bind
Date: March 2020
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
Writing a device name to this file will cause the driver to
attempt to bind to the device. This is useful for overriding
@@ -30,7 +30,7 @@ Description:
What: /sys/bus/vdpa/drivers/.../unbind
Date: March 2020
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
Writing a device name to this file will cause the driver to
attempt to unbind from the device. This may be useful when
@@ -38,7 +38,7 @@ Description:
What: /sys/bus/vdpa/devices/.../driver_override
Date: November 2021
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
This file allows the driver for a device to be specified.
When specified, only a driver with a name matching the value
diff --git a/Documentation/networking/bridge.rst b/Documentation/networking/bridge.rst
index ba14e7b07869..ef8b73e157b2 100644
--- a/Documentation/networking/bridge.rst
+++ b/Documentation/networking/bridge.rst
@@ -324,7 +324,7 @@ Contact Info
The code is currently maintained by Roopa Prabhu <roopa@nvidia.com> and
Nikolay Aleksandrov <razor@blackwall.org>. Bridge bugs and enhancements
are discussed on the linux-netdev mailing list netdev@vger.kernel.org and
-bridge@lists.linux-foundation.org.
+bridge@lists.linux.dev.
The list is open to anyone interested: http://vger.kernel.org/vger-lists.html#netdev
diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst
index d159cd4f5e5b..beb484c5965d 100644
--- a/Documentation/process/researcher-guidelines.rst
+++ b/Documentation/process/researcher-guidelines.rst
@@ -167,4 +167,4 @@ If no one can be found to internally review patches and you need
help finding such a person, or if you have any other questions
related to this document and the developer community's expectations,
please reach out to the private Technical Advisory Board mailing list:
-<tech-board@lists.linux-foundation.org>.
+<tech-board@groups.linuxfoundation.org>.
diff --git a/Documentation/translations/sp_SP/process/researcher-guidelines.rst b/Documentation/translations/sp_SP/process/researcher-guidelines.rst
index 462b3290b7b8..deccc908a68d 100644
--- a/Documentation/translations/sp_SP/process/researcher-guidelines.rst
+++ b/Documentation/translations/sp_SP/process/researcher-guidelines.rst
@@ -147,4 +147,4 @@ Si no se puede encontrar a nadie para revisar internamente los parches y necesit
ayuda para encontrar a esa persona, o si tiene alguna otra pregunta relacionada
con este documento y las expectativas de la comunidad de desarrolladores, por
favor contacte con la lista de correo privada Technical Advisory Board:
-<tech-board@lists.linux-foundation.org>.
+<tech-board@groups.linuxfoundation.org>.
diff --git a/MAINTAINERS b/MAINTAINERS
index 73d898383e51..ffdfb311349f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14010,7 +14010,7 @@ F: include/uapi/rdma/mlx5-abi.h
MELLANOX MLX5 VDPA DRIVER
M: Dragos Tatulea <dtatulea@nvidia.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Supported
F: drivers/vdpa/mlx5/
@@ -21519,7 +21519,7 @@ F: tools/testing/selftests/drivers/net/team/
TECHNICAL ADVISORY BOARD PROCESS DOCS
M: "Theodore Ts'o" <tytso@mit.edu>
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-L: tech-board-discuss@lists.linux-foundation.org
+L: tech-board-discuss@lists.linux.dev
S: Maintained
F: Documentation/process/contribution-maturity-model.rst
F: Documentation/process/researcher-guidelines.rst
@@ -23078,7 +23078,7 @@ F: drivers/vfio/pci/mlx5/
VFIO VIRTIO PCI DRIVER
M: Yishai Hadas <yishaih@nvidia.com>
L: kvm@vger.kernel.org
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: drivers/vfio/pci/virtio
---
base-commit: 7e90b5c295ec1e47c8ad865429f046970c549a66
change-id: 20240214-lf-org-list-migration-0f81f19a1333
Best regards,
--
Konstantin Ryabitsev <konstantin@linuxfoundation.org>
^ permalink raw reply related [relevance 8%]
* [PATCH 1/2] MAINTAINERS: Add our new mailing-list
@ 2021-03-31 13:08 8% Maxime Ripard
0 siblings, 0 replies; 200+ results
From: Maxime Ripard @ 2021-03-31 13:08 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec; +Cc: linux-arm-kernel, linux-sunxi
We've been struggling to get an LF-hosted mailing list for a while, but
now that lists.linux.dev is there we opted in.
Let's add it to MAINTAINERS.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..d8c00df4045c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1576,6 +1576,7 @@ R: Jernej Skrabec <jernej.skrabec@siol.net>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
+L: linux-sunxi@lists.linux.dev
F: arch/arm/mach-sunxi/
F: arch/arm64/boot/dts/allwinner/
F: drivers/clk/sunxi-ng/
--
2.30.2
^ permalink raw reply related [relevance 8%]
* [PATCH 2/3] Documentation/llvm: Update mailing list
@ 2021-08-25 21:18 8% ` Nathan Chancellor
2021-08-25 21:18 6% ` [PATCH 3/3] Documentation/llvm: Update IRC location Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-08-25 21:18 UTC (permalink / raw)
To: Andrew Morton, Masahiro Yamada, Kees Cook
Cc: Sami Tolvanen, Nick Desaulniers, linux-kernel, llvm,
clang-built-linux, Nathan Chancellor
We are now at llvm@lists.linux.dev.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Documentation/kbuild/llvm.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
index b18401d2ba82..06b8f826e1a3 100644
--- a/Documentation/kbuild/llvm.rst
+++ b/Documentation/kbuild/llvm.rst
@@ -111,7 +111,8 @@ Getting Help
------------
- `Website <https://clangbuiltlinux.github.io/>`_
-- `Mailing List <https://groups.google.com/forum/#!forum/clang-built-linux>`_: <clang-built-linux@googlegroups.com>
+- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev>
+- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_
- `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_
- IRC: #clangbuiltlinux on chat.freenode.net
- `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux
--
2.33.0
^ permalink raw reply related [relevance 8%]
* [PATCH] MAINTAINERS: add Eugenio Pérez as reviewer
@ 2024-02-13 18:24 8% Eugenio Pérez
0 siblings, 0 replies; 200+ results
From: Eugenio Pérez @ 2024-02-13 18:24 UTC (permalink / raw)
To: mst; +Cc: Jason Wang, linux-kernel, virtualization
Add myself as a reviewer of some VirtIO areas I'm interested.
Until this point I've been scanning manually the list looking for
series that touches this area. Adding myself to make this task easier.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 61117c3afa80..d0789ecc4f70 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23219,6 +23219,7 @@ M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
R: Paolo Bonzini <pbonzini@redhat.com>
R: Stefan Hajnoczi <stefanha@redhat.com>
+R: Eugenio Pérez <eperezma@redhat.com>
L: virtualization@lists.linux.dev
S: Maintained
F: drivers/block/virtio_blk.c
@@ -23237,6 +23238,7 @@ VIRTIO CORE AND NET DRIVERS
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
R: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
+R: Eugenio Pérez <eperezma@redhat.com>
L: virtualization@lists.linux.dev
S: Maintained
F: Documentation/ABI/testing/sysfs-bus-vdpa
@@ -23277,6 +23279,7 @@ VIRTIO FILE SYSTEM
M: Vivek Goyal <vgoyal@redhat.com>
M: Stefan Hajnoczi <stefanha@redhat.com>
M: Miklos Szeredi <miklos@szeredi.hu>
+R: Eugenio Pérez <eperezma@redhat.com>
L: virtualization@lists.linux.dev
L: linux-fsdevel@vger.kernel.org
S: Supported
@@ -23310,6 +23313,7 @@ F: include/uapi/linux/virtio_gpu.h
VIRTIO HOST (VHOST)
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
+R: Eugenio Pérez <eperezma@redhat.com>
L: kvm@vger.kernel.org
L: virtualization@lists.linux.dev
L: netdev@vger.kernel.org
--
2.43.0
^ permalink raw reply related [relevance 8%]
* [patch 097/147] Documentation/llvm: update mailing list
@ 2021-09-08 2:58 8% ` Andrew Morton
2021-09-08 2:58 6% ` [patch 098/147] Documentation/llvm: update IRC location Andrew Morton
1 sibling, 0 replies; 200+ results
From: Andrew Morton @ 2021-09-08 2:58 UTC (permalink / raw)
To: akpm, keescook, linux-mm, masahiroy, mm-commits, nathan,
ndesaulniers, samitolvanen, torvalds
From: Nathan Chancellor <nathan@kernel.org>
Subject: Documentation/llvm: update mailing list
We are now at llvm@lists.linux.dev.
Link: https://lkml.kernel.org/r/20210825211823.6406-2-nathan@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/kbuild/llvm.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/Documentation/kbuild/llvm.rst~documentation-llvm-update-mailing-list
+++ a/Documentation/kbuild/llvm.rst
@@ -111,7 +111,8 @@ Getting Help
------------
- `Website <https://clangbuiltlinux.github.io/>`_
-- `Mailing List <https://groups.google.com/forum/#!forum/clang-built-linux>`_: <clang-built-linux@googlegroups.com>
+- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev>
+- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_
- `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_
- IRC: #clangbuiltlinux on chat.freenode.net
- `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux
_
^ permalink raw reply [relevance 8%]
Results 201-400 of ~10000 next [<= 6%] | prev [>= 8%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2022-06-15 23:53 8% [PATCH] HACKING: update to use new mailing list James Prestwood
2024-02-13 18:24 8% [PATCH] MAINTAINERS: add Eugenio Pérez as reviewer Eugenio Pérez
2023-11-03 22:54 8% [PATCH] MAINTAINERS: list all Qualcomm IOMMU drivers in the QUALCOMM IOMMU entry Dmitry Baryshkov
2024-02-14 20:09 8% [PATCH] Documentation: update mailing list addresses Konstantin Ryabitsev
2022-09-05 9:35 8% [PATCH] MAINTAINERS: rectify entry in ARM/APPLE MACHINE SOUND DRIVERS Lukas Bulwahn
2022-09-05 9:35 8% ` Lukas Bulwahn
2021-08-31 22:48 8% + documentation-llvm-update-mailing-list.patch added to -mm tree akpm
2023-01-03 12:39 8% [PATCH] MAINTAINERS: Add Zenghui Yu as a KVM/arm64 reviewer Marc Zyngier
2023-01-03 12:39 8% ` Marc Zyngier
2023-01-03 12:39 8% ` Marc Zyngier
2022-06-22 8:26 8% [PATCH] MAINTAINERS: Add new IOMMU development mailing list Joerg Roedel
2022-06-16 12:14 8% [PATCH] MAINTAINERS: Add maillist information for LoongArch Huacai Chen
2024-01-26 10:51 8% [PATCH v2] wifi: cleanup brcm80211 drivers maintainer entry Arend van Spriel
2024-01-26 10:57 8% [PATCH v3] " Arend van Spriel
2021-03-19 18:33 8% [PATCH net] mptcp: Change mailing list address Mat Martineau
2021-05-09 15:07 8% [PATCH] docs/zh_CN: sync reporting-issues.rst translation Wu XiangCheng
2021-05-11 11:51 8% ` [PATCH v2] docs/zh_CN: sync reporting-issues.rst Wu XiangCheng
2021-09-09 21:04 8% [merged] documentation-llvm-update-mailing-list.patch removed from -mm tree akpm
2022-06-17 2:12 8% [merged mm-hotfixes-stable] maintainers-add-maillist-information-for-loongarch.patch " Andrew Morton
2021-03-31 13:08 8% [PATCH 1/2] MAINTAINERS: Add our new mailing-list Maxime Ripard
2023-04-06 19:03 7% [I-PIPE] ipipe-core-4.19.279-cip95-x86-26 released xenomai
2022-08-03 4:51 7% [I-PIPE] ipipe-core-4.19.252-cip78-x86-23 released xenomai
2023-08-14 19:34 7% [I-PIPE] ipipe-core-4.19.288-cip101-x86-27 released xenomai
2023-11-07 18:40 7% The new list address is: linux-kernel-mentees@lists.linux.dev (old one still works) Konstantin Ryabitsev
2022-06-20 6:30 7% [I-PIPE] ipipe-core-4.4.302-cip69-arm-18 released xenomai
2022-10-13 15:32 7% [PATCH] MAINTAINERS: Move from git://github.com to https://github.com Palmer Dabbelt
2022-08-04 16:25 7% [I-PIPE] ipipe-core-4.4.302-cip70-x86-34 released xenomai
2023-04-02 23:53 7% [PATCH v2] Update email address and mailing list for v9fs Eric Van Hensbergen
2022-06-20 6:30 7% [I-PIPE] ipipe-core-4.19.246-cip75-x86-22 released xenomai
2022-05-28 3:49 7% Undelivered Mail Returned to Sender Mail Delivery System
2022-03-16 5:21 7% [PATCH] MAINTAINERS: remove section LIBNVDIMM BLK: MMIO-APERTURE DRIVER Lukas Bulwahn
2023-04-06 19:03 7% [I-PIPE] ipipe-core-5.4.239-x86-13 released xenomai
2023-08-14 19:34 7% [I-PIPE] ipipe-core-5.4.253-x86-14 released xenomai
2022-06-25 2:10 7% [PATCH] docs/zh_CN: Add a new translation of reporting-regressions.rst Wu XiangCheng
2022-07-07 14:30 7% ` [PATCH v2] " Wu XiangCheng
2024-04-05 18:22 7% [merged mm-hotfixes-stable] maintainers-change-vmwarecom-addresses-to-broadcomcom.patch removed from -mm tree Andrew Morton
2022-12-09 15:58 7% [I-PIPE] ipipe-core-4.19.266-cip86-x86-25 released xenomai
2022-06-20 6:30 7% [I-PIPE] ipipe-core-4.4.302-cip69-x86-33 released xenomai
2022-06-20 6:11 7% [I-PIPE] ipipe-core-5.4.198-x86-9 released xenomai
2022-08-04 16:25 7% [I-PIPE] ipipe-core-4.4.302-cip70-arm-19 released xenomai
2024-04-02 23:23 7% [PATCH] MAINTAINERS: change vmware.com addresses to broadcom.com Alexey Makhalov
2023-06-28 18:23 7% [PATCH] docs: ABI: sysfs-bus-mhi: Update contact info Jeffrey Hugo
2021-06-02 6:37 7% [PATCH v2] REAMDE: Announce new mailing list Daniel Wagner
[not found] <1628081824-28535-mlmmj-16bf2009@lists.linux.dev>
2021-08-04 13:45 ` Post to linux-staging@lists.linux.dev denied: [PATCH] staging: rtl8723bs: os_dep: remove unused variable SAURAV GIREPUNJE
2021-08-04 13:56 7% ` Greg KH
2021-08-04 17:20 7% ` SAURAV GIREPUNJE
2021-08-05 11:04 7% ` Greg KH
2021-08-07 4:14 7% ` SAURAV GIREPUNJE
2023-10-26 21:47 7% [PATCH] dm vdo: add MAINTAINERS file entry Matthew Sakai
[not found] <1620376201-3408-mlmmj-4f932172@lists.linux.dev>
2021-05-07 9:08 ` Bouncing messages from linux-staging@lists.linux.dev Fabio Aiuto
2021-05-07 11:42 7% ` Greg KH
2021-05-07 14:32 7% ` Fabio Aiuto
2021-05-07 16:10 7% ` Dan Carpenter
2021-05-07 16:31 7% ` Fabio Aiuto
2022-11-16 5:50 7% [I-PIPE] ipipe-core-5.4.223-x86-11 released xenomai
2022-06-16 18:36 7% + maintainers-add-maillist-information-for-loongarch.patch added to mm-hotfixes-unstable branch Andrew Morton
2023-04-06 19:13 7% [I-PIPE] ipipe-core-5.4.231-arm-6 released xenomai
2023-11-17 19:24 7% [PATCH] MAINTAINERS: refresh LLVM support ndesaulniers
2022-06-30 16:55 7% [DOVETAIL] 5.10.127-dovetail1 released xenomai
2022-08-10 19:44 7% Updated invitation: Justin Stitt's Intern Presentation @ Wed Aug 17, 2022 10am - 11am (PDT) (llvm@lists.linux.dev) Nick Desaulniers
2023-04-04 12:51 7% [kvm-unit-tests PATCH] MAINTAINERS: Add a catch-all entry for the kvm mailing list Thomas Huth
2024-02-01 1:06 6% [PATCH mptcp-net] MAINTAINERS: update Geliang's email address Geliang Tang
2023-02-13 23:55 6% [merged mm-stable] docs-admin-guide-mm-damon-usage-add-damon-debugfs-interface-deprecation-notice.patch removed from -mm tree Andrew Morton
2023-11-01 23:33 6% [PATCH] MAINTAINERS: Add Intel TDX entry Kirill A. Shutemov
2023-02-16 14:13 6% PURCHASE ORDER lists.linux.dev Jessica Hernandez
2023-11-30 11:30 6% [PATCH] tty: virtio: drop virtio_cons_early_init() Jiri Slaby (SUSE)
2023-06-09 23:29 6% [merged mm-stable] docs-mm-damon-maintainer-profile-fix-typos-and-grammar-errors.patch removed from -mm tree Andrew Morton
2021-09-15 18:23 6% Test delivery to ofono@lists.linux.dev Konstantin Ryabitsev
2021-09-15 18:25 6% Test delivery to ell@lists.linux.dev Konstantin Ryabitsev
2022-08-25 21:49 6% [PATCH 1/1] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2024-04-03 21:31 6% + maintainers-change-vmwarecom-addresses-to-broadcomcom.patch added to mm-hotfixes-unstable branch Andrew Morton
2023-02-14 11:29 6% Purchase Requirement lists.linux.dev Jessica Hernandez
2022-04-07 18:05 6% x86/coco MAINTAINERS mailing list Dave Hansen
2023-07-14 12:52 6% [kvm-unit-tests PATCH] arm/arm64: MAINTAINERS: Add reviewers Andrew Jones
2023-02-03 6:35 6% [merged mm-stable] docs-mm-damon-add-a-maintainer-profile-for-damon.patch removed from -mm tree Andrew Morton
[not found] <YMJLJR/atypu++qU@casper.infradead.org>
2021-06-10 19:44 6% ` Create mm@lists.linux.dev Johannes Weiner
2021-06-14 14:25 6% ` Jason Gunthorpe
2023-01-23 21:02 6% [PATCH] MAINTAINERS: Add Oliver Upton as co-maintainer of KVM/arm64 Oliver Upton
2023-01-23 21:02 6% ` Oliver Upton
2023-11-07 18:41 6% The new list address is: virtualization@lists.linux.dev (old one still works) Konstantin Ryabitsev
2023-08-03 10:08 6% [PATCH] MAINTAINERS: update maintainers of chrome-platform Tzung-Bi Shih
2021-09-09 21:04 6% [merged] documentation-llvm-update-irc-location.patch removed from -mm tree akpm
2021-09-15 18:26 6% Test delivery to iwd@lists.linux.dev Konstantin Ryabitsev
2022-08-25 21:37 6% [PATCH 1/1] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2023-10-03 15:29 6% [PATCH mptcp-net] MAINTAINERS: update Matthieu's email address Matthieu Baerts
2022-10-25 16:07 6% [kvm-unit-tests PATCH] MAINTAINERS: new kvmarm mailing list Cornelia Huck
2022-10-25 16:07 6% ` Cornelia Huck
[not found] <1657492202-18435-mlmmj-51d729a7@lists.linux.dev>
[not found] ` <CAFP8O3+Lw0wKfWY-VA+tuAnVcjyN17E=yk6-VU5WcWG1xdH+UA@mail.gmail.com>
2022-07-11 17:54 ` Fwd: Bouncing messages from llvm@lists.linux.dev Nick Desaulniers
2022-07-11 18:19 6% ` [sysadmin] " Konstantin Ryabitsev
2022-07-11 18:30 6% ` Nick Desaulniers
2022-07-11 18:34 6% ` Fangrui Song
2022-07-11 19:27 6% ` Konstantin Ryabitsev
2022-07-11 19:30 6% ` Nick Desaulniers
2022-07-11 19:31 6% ` Fangrui Song
2022-10-28 17:42 6% [PATCH] MAINTAINERS: Remove Hemant from MHI bus Manivannan Sadhasivam
[not found] <mailman.0.1697833396.3533474.lvm-devel@redhat.com>
2023-10-20 21:34 ` lvm-devel has migrated to lists.linux.dev [was: Re: Welcome to the "lvm-devel" mailing list] Mike Snitzer
2023-10-23 14:43 6% ` Konstantin Ryabitsev
2022-04-04 6:42 6% [PATCH] MAINTAINERS: Update Hemant's email id Manivannan Sadhasivam
2023-11-17 20:59 [PATCH v5 00/40] dm vdo: add the dm-vdo deduplication and compression DM target Matthew Sakai
2023-11-17 20:59 7% ` [PATCH v5 40/40] dm vdo: add MAINTAINERS file entry Matthew Sakai
2023-01-09 1:49 [PATCH 0/4] iommu/vt-d: SVM implementation cleanup Lu Baolu
2023-01-09 1:49 7% ` [PATCH 1/4] iommu/vt-d: Remove include/linux/intel-svm.h Lu Baolu
2022-01-07 14:21 [RFC PATCH v2 0/2] docs: add a text about regressions to the Linux kernel's documentation Thorsten Leemhuis
2022-01-07 14:21 7% ` [RFC PATCH v2 1/2] docs: add a document about regression handling Thorsten Leemhuis
2021-11-24 8:46 [PATCH v2 0/3] staging: zynpu: Add driver support for ARM(China) ZHOUYI AI accelerator Cai Huoqing
2021-11-24 8:46 6% ` [PATCH v2 3/3] MAINTAINERS: Add the driver info of the " Cai Huoqing
2022-12-28 0:45 [PATCH 00/10] platform/chrome: cros_ec_typec: VDM support Prashant Malani
2022-12-28 0:45 6% ` [PATCH 08/10] platform/chrome: cros_ec_typec: Add initial " Prashant Malani
2023-12-18 22:58 [Lvfs-announce] PSA: this list is moving to lists.linux.dev (no action requried) Konstantin Ryabitsev
2023-12-21 20:24 6% ` Konstantin Ryabitsev
2021-09-11 3:09 Invitation: [PATCH] staging: rtl8723bs: remove possible deadlock when... @ Sat 2021-09-11 05:30 - 06:30 (CEST) (linux-staging@lists.linux.dev) fmdefrancesco
2021-09-11 5:08 7% ` Fabio M. De Francesco
2023-04-14 0:44 [V6 0/9] Add Tegra234 HTE support Dipen Patel
2023-04-14 0:44 6% ` [V6 1/9] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2024-01-12 18:19 add volatile flag to PV/LVs (for cache) to avoid degraded state on reboot lists.linux.dev
2024-01-17 11:08 ` Zdenek Kabelac
2024-01-17 22:00 ` Gionatan Danti
2024-01-18 15:40 ` Zdenek Kabelac
2024-01-20 20:29 6% ` lists.linux.dev
2024-01-04 21:09 [PATCH v9 00/11] virtio: cleanup vhost-user-generic and reduce c&p + vhost-user-input Alex Bennée
2024-01-04 21:09 6% ` [PATCH v9 09/11] docs/system: Add vhost-user-input documentation Alex Bennée
2023-05-25 21:43 [PATCH 00/10] Docs/mm/damon: Minor fixes and design doc update SeongJae Park
2023-05-25 21:43 7% ` [PATCH 02/10] Docs/mm/damon/maintainer-profile: fix typos and grammar errors SeongJae Park
2023-11-21 20:57 [Fuego] PSA: the fuego list will be moving to lists.linux.dev Konstantin Ryabitsev
2023-12-18 22:46 6% ` Konstantin Ryabitsev
2023-12-21 20:19 6% ` Konstantin Ryabitsev
2022-02-01 10:26 [PATCH v4 0/3] docs: add two texts covering regressions Thorsten Leemhuis
2022-02-01 10:26 6% ` [PATCH v4 1/3] docs: add two documents about regression handling Thorsten Leemhuis
2023-03-29 13:17 [PATCH mptcp-next 0/3] mptcp: misc. small cleanups Matthieu Baerts
2023-03-29 13:17 8% ` [PATCH mptcp-next 1/3] MAINTAINERS: add git trees for MPTCP Matthieu Baerts
2023-11-01 19:47 PSA: the linux-kernel-mentees list is migrating to lists.linux.dev Konstantin Ryabitsev
2023-11-07 18:37 7% ` Konstantin Ryabitsev
2021-08-02 7:39 [PATCH v4 0/4] Add perf interface to expose nvdimm Kajol Jain
2021-08-02 7:39 8% ` [PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries Kajol Jain
2021-08-02 7:39 8% ` Kajol Jain
2022-01-03 9:50 [RFC PATCH v1 0/2] docs: add a document dedicated to regressions Thorsten Leemhuis
2022-01-03 9:50 7% ` [RFC PATCH v1 1/2] docs: add a document about regression handling Thorsten Leemhuis
2021-08-25 21:18 [PATCH 1/3] MAINTAINERS: Update ClangBuiltLinux mailing list Nathan Chancellor
2021-08-25 21:18 8% ` [PATCH 2/3] Documentation/llvm: Update " Nathan Chancellor
2021-08-25 21:18 6% ` [PATCH 3/3] Documentation/llvm: Update IRC location Nathan Chancellor
2023-11-21 21:38 [SPDK] PSA: the spdk list will be moving to lists.linux.dev Konstantin Ryabitsev
2023-12-21 20:33 6% ` Konstantin Ryabitsev
2023-12-18 23:04 6% ` [SPDK] " Konstantin Ryabitsev
2023-11-21 20:47 [Accel-config] PSA: the accel-config " Konstantin Ryabitsev
2023-12-18 22:44 6% ` Konstantin Ryabitsev
2023-12-21 19:57 6% ` Konstantin Ryabitsev
2023-12-21 20:15 6% ` Konstantin Ryabitsev
2023-11-01 18:17 PSA: this list is moving to virtualization@lists.linux.dev Konstantin Ryabitsev
2023-11-07 18:10 6% ` Konstantin Ryabitsev
2024-01-19 8:43 [PATCH v3 0/3] Introduce EC-based watchdog Lukasz Majczak
2024-01-19 8:43 6% ` [PATCH v3 2/3] watchdog: Add ChromeOS EC-based watchdog driver Lukasz Majczak
2023-09-26 4:16 [PATCH v4 0/6] configfs-tsm: Attestation Report ABI Dan Williams
2023-09-26 4:17 7% ` [PATCH v4 2/6] configfs-tsm: Introduce a shared ABI for attestation reports Dan Williams
2023-04-04 17:14 [RFC PATCH 0/5] fstests specific MAINTAINERS file Zorro Lang
2023-04-04 17:14 6% ` [Ocfs2-devel] [PATCH 4/5] fstests/MAINTAINERS: add some specific reviewers Zorro Lang via Ocfs2-devel
2023-04-04 17:14 6% ` Zorro Lang
2023-04-04 17:14 6% ` [f2fs-dev] " Zorro Lang
2023-04-04 17:14 6% ` [Ocfs2-devel] [PATCH 3/5] fstests/MAINTAINERS: add supported mailing list Zorro Lang via Ocfs2-devel
2023-04-04 17:14 6% ` Zorro Lang
2023-04-04 17:14 6% ` [f2fs-dev] " Zorro Lang
2023-12-18 23:00 [Opae] PSA: this list is moving to lists.linux.dev Konstantin Ryabitsev
2023-12-21 20:25 6% ` Konstantin Ryabitsev
2024-04-02 14:33 [PATCH v3 00/11] PCI: imx6: Fix\rename\clean up and add lut information for imx95 Frank Li
2024-04-02 14:33 8% ` [PATCH v3 05/11] MAINTAINERS: pci: imx: update imx6* to imx* since rename driver file Frank Li
2024-04-02 14:33 7% ` Frank Li
2022-02-16 6:51 [PATCH v5 0/3] docs: add two texts covering regressions Thorsten Leemhuis
2022-02-16 6:51 6% ` [PATCH v5 1/3] docs: add two documents about regression handling Thorsten Leemhuis
2023-12-18 22:54 [LVFS] PSA: this list is moving to lists.linux.dev (no action required) Konstantin Ryabitsev
2023-12-21 20:21 6% ` Konstantin Ryabitsev
2023-10-13 2:13 [PATCH v6 0/7] configfs-tsm: Attestation Report ABI Dan Williams
2023-10-13 2:14 7% ` [PATCH v6 3/7] configfs-tsm: Introduce a shared ABI for attestation reports Dan Williams
2024-01-26 9:57 [PATCH v4 0/3] Introduce EC-based watchdog Lukasz Majczak
2024-01-26 9:57 6% ` [PATCH v4 2/3] watchdog: Add ChromeOS EC-based watchdog driver Lukasz Majczak
2023-01-10 19:03 [PATCH 0/8] mm/damon: trivial fixups SeongJae Park
2023-01-10 19:03 6% ` [PATCH 6/8] MAINTAINERS/DAMON: link maintainer profile, git trees, and website SeongJae Park
2023-01-10 19:03 6% ` [PATCH 5/8] Docs/mm/damon: add a maintainer-profile for DAMON SeongJae Park
2024-03-04 20:25 [PATCH v2 0/6] PCI: imx6: rename\clean up and add lut information for imx95 Frank Li
2024-03-04 20:25 8% ` [PATCH v2 3/6] MAINTAINERS: pci: imx: update imx6* to imx* since rename driver file Frank Li
2024-03-04 20:25 7% ` Frank Li
2022-03-16 18:49 [PATCH] MAINTAINERS: Add chrome-platform@lists.linux.dev to all Chrome OS entries Guenter Roeck
2022-03-16 20:17 6% ` Benson Leung
2022-03-16 22:00 6% ` Guenter Roeck
2021-04-16 20:58 Subscriber actions for migrating lists to lists.linux.dev James Bottomley
2021-04-16 21:16 ` Konstantin Ryabitsev
2021-04-16 21:22 7% ` James Bottomley
2021-11-24 6:57 [PATCH 0/3] staging: zynpu: Add driver support for ARM(China) ZHOUYI AI accelerator Cai Huoqing
2021-11-24 6:57 6% ` [PATCH 3/3] MAINTAINERS: Add the driver info of the " Cai Huoqing
2023-08-23 17:57 [PATCH 5.15 0/2] Fixup IOMMU list in MAINTAINERS Easwar Hariharan
2023-08-23 17:57 7% ` [PATCH 5.15 1/2] MAINTAINERS: update maintainer list of DMA MAPPING BENCHMARK Easwar Hariharan
2023-10-14 9:23 Is the data rate estimation for 5GHz channels overly pessimistic? Simonas Kazlauskas
2023-10-14 16:02 ` James Prestwood
2023-10-14 17:36 ` Denis Kenzior
2023-10-14 17:45 7% ` Simonas Kazlauskas
2023-10-14 18:07 ` Denis Kenzior
2023-10-15 19:40 ` Simonas Kazlauskas
2023-10-16 11:35 ` James Prestwood
2023-10-16 12:38 ` James Prestwood
2023-10-16 19:12 ` Denis Kenzior
2023-10-16 20:20 7% ` Simonas Kazlauskas
2023-10-21 23:23 ` Simonas Kazlauskas
2023-10-22 20:14 ` Denis Kenzior
2023-10-24 12:32 ` James Prestwood
2023-10-24 14:26 ` Denis Kenzior
2023-10-24 15:19 6% ` Simonas Kazlauskas
2022-05-17 13:16 [PATCH 0/2] docs/zh_CN: sync reporting-issues.rst to 247097e2bbff4 Wu XiangCheng
2022-05-17 17:08 8% ` [PATCH 1/2] docs/zh_CN: sync reporting-issues.rst Wu XiangCheng
2022-05-18 3:16 7% ` [PATCH v2] docs/zh_CN: Update translation of reporting-issues.rst to 5.18 Wu XiangCheng
2023-10-26 17:41 [PATCH v2 00/14] multipath: aio, systemd, and documentation improvements mwilck
2023-10-26 17:41 8% ` [PATCH v2 12/14] README.md: update mailing list and contributing information mwilck
2023-10-06 23:29 dm-devel has migrated to lists.linux.dev Mike Snitzer
2023-10-06 23:43 ` Mike Snitzer
2023-10-11 18:28 6% ` Konstantin Ryabitsev
2023-10-11 18:41 ` Mike Snitzer
2023-10-11 18:52 6% ` Konstantin Ryabitsev
2023-10-11 20:08 6% ` Mike Snitzer
2024-01-30 9:23 [RFC PATCH 0/5] Towards a shared TSM sysfs-ABI for Confidential Computing Dan Williams
2024-01-30 9:24 6% ` [RFC PATCH 5/5] PCI/TSM: Authenticate devices via platform TSM Dan Williams
2024-02-20 8:49 drm-misc migration to Gitlab server Maxime Ripard
2024-03-06 15:38 7% ` [PATCH v2 1/2] MAINTAINERS: Update drm-misc.git URL Maxime Ripard
2023-12-18 23:07 [Tech-board-discuss] PSA: this list is moving to lists.linux.dev (no action required) Konstantin Ryabitsev
2023-12-21 20:35 6% ` Konstantin Ryabitsev
2023-10-11 5:27 [PATCH v5 0/7] configfs-tsm: Attestation Report ABI Dan Williams
2023-10-11 5:27 7% ` [PATCH v5 3/7] configfs-tsm: Introduce a shared ABI for attestation reports Dan Williams
2023-08-30 19:33 [PATCH v3 0/5] configfs-tsm: Attestation Report ABI Dan Williams
2023-08-30 19:33 7% ` [PATCH v3 2/5] configfs-tsm: Introduce a shared ABI for attestation reports Dan Williams
2023-02-09 19:20 SeongJae Park
2023-02-09 19:20 7% ` [PATCH 1/3] Docs/admin-guide/mm/damon/usage: add DAMON debugfs interface deprecation notice SeongJae Park
2023-11-21 20:43 [diamon-discuss] PSA: the diamon-discuss list will be moving to lists.linux.dev Konstantin Ryabitsev
2023-12-18 22:45 6% ` Konstantin Ryabitsev
2023-12-21 20:17 6% ` Konstantin Ryabitsev
2023-12-18 23:02 [Printing-architecture] PSA: this list is moving to lists.linux.dev (no action required) Konstantin Ryabitsev
2023-12-21 20:30 6% ` Konstantin Ryabitsev
2023-12-23 1:01 6% ` Till Kamppeter
2023-12-18 23:46 6% ` [Printing-architecture] " Ira McDonald
2022-01-25 11:44 [PATCH v3 0/2] docs: add a text about regressions to the Linux kernel's documentation Thorsten Leemhuis
2022-01-25 11:44 6% ` [PATCH v3 1/2] docs: add a document about regression handling Thorsten Leemhuis
2023-10-04 20:38 [PATCH net 0/3] mptcp: Fixes and maintainer email update for v6.6 Mat Martineau
2023-10-04 20:38 6% ` [PATCH net 3/3] MAINTAINERS: update Matthieu's email address Mat Martineau
2021-09-08 2:52 incoming Andrew Morton
2021-09-08 2:58 8% ` [patch 097/147] Documentation/llvm: update mailing list Andrew Morton
2021-09-08 2:58 6% ` [patch 098/147] Documentation/llvm: update IRC location Andrew Morton
2023-02-10 4:48 [PATCH v2 0/3] mm/damon: deprecate DAMON debugfs interface SeongJae Park
2023-02-10 4:48 7% ` [PATCH v2 1/3] Docs/admin-guide/mm/damon/usage: add DAMON debugfs interface deprecation notice SeongJae Park
2023-04-06 17:18 [V5 00/10] Add Tegra234 HTE support Dipen Patel
2023-04-06 17:18 6% ` [V5 01/10] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2023-03-10 19:06 [PATCH V3 0/6] Add Tegra234 HTE support Dipen Patel
2023-03-10 19:06 6% ` [PATCH V3 1/6] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2024-02-14 11:13 [PULL 00/60] virtio,pc,pci: features, cleanups, fixes Michael S. Tsirkin
2024-02-14 11:13 6% ` [PULL 09/60] docs/system: Add vhost-user-input documentation Michael S. Tsirkin
2024-01-18 19:53 [PATCH v2 0/3] Introduce EC-based watchdog Lukasz Majczak
2024-01-18 19:53 6% ` [PATCH v2 2/3] watchdog: Add ChromeOS EC-based watchdog driver Lukasz Majczak
2021-11-26 2:18 [PATCH v3 0/3] staging: zynpu: Add driver support for ARM(China) ZHOUYI AI accelerator Cai Huoqing
2021-11-26 2:19 6% ` [PATCH v2 3/3] MAINTAINERS: Add the driver info of the " Cai Huoqing
2024-02-27 21:47 [PATCH 0/6] PCI: imx6: rename\clean up and add lut information for imx95 Frank Li
2024-02-27 21:47 8% ` [PATCH 3/6] MAINTAINERS: pci: imx: update imx6* to imx* since rename driver file Frank Li
2024-02-27 21:47 7% ` Frank Li
2021-04-07 9:21 [RFC PATCH v1 0/2] Add regression mailing list with basics for tracking Thorsten Leemhuis
2021-04-07 9:21 8% ` [RFC PATCH v1 1/2] MAINTAINERS: add regressions mailing list Thorsten Leemhuis
2021-04-07 9:21 7% ` [RFC PATCH v1 2/2] docs: reporting-issues: make everyone CC the regressions list Thorsten Leemhuis
2022-11-03 17:46 [PATCH 0/7] Add Tegra234 HTE support Dipen Patel
2022-11-03 17:46 6% ` [PATCH 1/7] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2021-09-03 5:09 [RESEND PATCH v4 0/4] Add perf interface to expose nvdimm Kajol Jain
2021-09-03 5:09 8% ` [RESEND PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries Kajol Jain
2021-09-03 5:09 8% ` Kajol Jain
2023-02-14 11:55 [PATCH V2 0/6] Add Tegra234 HTE support Dipen Patel
2023-02-14 11:55 6% ` [PATCH V2 1/6] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2023-04-14 15:47 [PATCH net-next 0/5] mptcp: various small cleanups Matthieu Baerts
2023-04-14 15:47 8% ` [PATCH net-next 2/5] MAINTAINERS: add git trees for MPTCP Matthieu Baerts
2023-01-31 7:37 [PATCH 00/12] [PULL REQUEST] Intel IOMMU updates for Linux v6.3 Lu Baolu
2023-01-31 7:37 7% ` [PATCH 01/12] iommu/vt-d: Remove include/linux/intel-svm.h Lu Baolu
2022-09-01 11:34 [PATCH 1/2] ASoC: apple: mca: Unselect COMMON_CLK in Kconfig Martin Povišer
2022-09-01 11:34 8% ` [PATCH 2/2] MAINTAINERS: Fix file pattern for ARM/APPLE MACHINE SOUND DRIVERS Martin Povišer
2022-09-01 11:34 8% ` Martin Povišer
2022-01-26 22:22 [PATCH] MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list Benson Leung
2022-01-27 3:06 6% ` Prashant Malani
2022-01-27 1:58 6% ` Benson Leung
2022-11-03 17:45 [PATCH 0/7] Add Tegra234 HTE support Dipen Patel
2022-11-03 17:45 6% ` [PATCH 1/7] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2023-03-23 1:29 [PATCH V4 00/10] Add Tegra234 HTE support Dipen Patel
2023-03-23 1:29 6% ` [PATCH V4 01/10] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2023-10-20 1:16 [PATCH v7 0/7] configfs-tsm: Attestation Report ABI Dan Williams
2023-10-20 1:16 7% ` [PATCH v7 3/7] configfs-tsm: Introduce a shared ABI for attestation reports Dan Williams
2021-06-17 13:26 [PATCH v3 0/4] Add perf interface to expose nvdimm Kajol Jain
2021-06-17 13:26 8% ` [PATCH v3 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries Kajol Jain
2021-06-17 13:26 8% ` Kajol Jain
2022-07-14 8:26 KernelCI at lists.linux.dev Guillaume Tucker
2022-07-14 14:51 ` Konstantin Ryabitsev
2022-07-15 5:12 6% ` Guillaume Tucker
2022-07-29 15:06 6% ` Guillaume Tucker
2023-11-21 21:21 [Tpm2] PSA: the tpm2 list will be moving to lists.linux.dev Konstantin Ryabitsev
2023-12-21 20:36 6% ` Konstantin Ryabitsev
2023-12-18 23:05 6% ` [Tpm2] " Konstantin Ryabitsev
2023-11-20 4:37 [PATCH v3 0/4] virtio: Refactor vhost input stub Leo Yan
2023-11-20 4:37 7% ` [PATCH v3 2/4] docs/system: Add vhost-user-input documentation Leo Yan
2021-04-09 11:47 [PATCH v2 0/2] Mention regression mailing list in reporting-bugs and MAINTAINERS Thorsten Leemhuis
2021-04-09 11:47 7% ` [PATCH v2 2/2] docs: reporting-issues: make people CC the regressions list Thorsten Leemhuis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.