* [PATCH net-next 0/9] RFC 6724 rule 5.5 support
From: David 'equinox' Lamparter @ 2026-07-14 9:40 UTC (permalink / raw)
To: Paolo Abeni, Jakub Kicinski, Ido Schimmel
Cc: David Ahern, David S. Miller, Eric Dumazet, Simon Horman,
Jonathan Corbet, Shuah Khan, Fernando Fernandez Mancera,
Lorenzo Colitti, Maciej Żenczykowski, Patrick Rohr, netdev,
linux-doc, linux-kselftest
Hi all,
this patchset implements RFC6724 rule 5.5. For the unaquainted:
Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
If SA or SA's prefix is assigned by the selected next-hop that will
be used to send to D and SB or SB's prefix is assigned by a different
next-hop, then prefer SA. Similarly, if SB or SB's prefix is
assigned by the next-hop that will be used to send to D and SA or
SA's prefix is assigned by a different next-hop, then prefer SB.
The way this is done is through IPv6 subtree routes. If a router
advertises some prefix in its RA/PIOs, source specific subtree routes
should be created for the default route (and RIOs) installed as a result
of processing that RA.
This may initially sound like a weird way to do it, but for one RFC8028
requires the subtree routes anyway, and also I did try the more obvious
approaches (explicitly tracking it, putting it on the address, putting
it on the neighbor entry) and all of them break in some scenarios.
I've put together a selftest, there's also a rather hacky test suite
created for an IETF hackathon: https://github.com/eqvinox/rule5p5-tests
(it's not specific to this patchset.) I've also been dogfooding these
patches on my personal devices for more than a year.
Rule 5.5 itself has extensive history at the IETF, including changing
from optional to mandatory in the recent 6724 update. It is immensely
useful (really: required) to make multihoming, renumbering and failover
work.
@Jakub you had previously asked me to resubmit the "prep" patches since
it was at a poor time (cf. Fri, Jul 25, 2025 at 05:39:58PM -0700).
(I had tried submitting the preparation bits on its own.)
@Paolo you had looked at the lookup fix:
On Tue, Nov 11, 2025 at 11:13:30AM +0100, Paolo Abeni wrote:
> The patch LGTM, and I agree this should go via net-next, given that it's
> really a corner case and I could miss nasty side-effects.
>
> It looks like you have some testing scenario handy: it would be great to
> include it as a paired self-test; could you please add it?
Cheers,
equi (David)
P.S.: I also happen to be around at netdevconf in Rome, in case anyone
happens to see this and have questions. Of course being at a conference
generally means not looking at random patch mails, so this is mostly
just in case you see the Subject lines or this cover letter. Apologies,
it wasn't possible for me to submit this ahead of the conference.
diffstat:
Documentation/networking/ipv6-addrsel.rst | 75 ++++++++++++++++++++++++++++++++
MAINTAINERS | 1 +
include/net/addrconf.h | 4 ++
include/net/ip6_route.h | 26 ------------
net/ipv6/Kconfig | 18 ++++++--
net/ipv6/addrconf.c | 144 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
net/ipv6/ip6_fib.c | 5 ++-
net/ipv6/ip6_output.c | 26 +++++++++---
net/ipv6/route.c | 16 +++++--
tools/testing/selftests/net/Makefile | 1 +
tools/testing/selftests/net/config | 1 +
tools/testing/selftests/net/ipv6_saddr_rfc6724rule5p5.py | 231 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
12 files changed, 497 insertions(+), 51 deletions(-)
^ permalink raw reply
* [PATCH net-next 1/9] net/ipv6: fix lookup for ::/0 (non-)subtree route
From: David 'equinox' Lamparter @ 2026-07-14 9:40 UTC (permalink / raw)
To: Paolo Abeni, Jakub Kicinski, Ido Schimmel
Cc: David Ahern, David S. Miller, Eric Dumazet, Simon Horman,
Jonathan Corbet, Shuah Khan, Fernando Fernandez Mancera,
Lorenzo Colitti, Maciej Żenczykowski, Patrick Rohr, netdev,
linux-doc, linux-kselftest, David 'equinox' Lamparter
In-Reply-To: <20260714094030.136317-1-equinox@diac24.net>
Assume a scenario with something like the following routes:
default via fe80::1 dev dummy0
2001:db8:1::/48 via fe80::10 dev dummy0
2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0
Now if a lookup happens for 2001:db8:1::2345, but with a source address
*not* covered by the third route, the expectation is to hit the second
one. Unfortunately, this was broken since the code, on failing the
lookup in the subtree, didn't consider the node itself which the subtree
is attached to, i.e. route #2 above.
The fix is simple, check if the subtree is attached to a node that is
itself a valid route before backtracking to less specific destination
prefixes.
This case is somewhat rare for several reasons. To begin with, subtree
routes are most commonly attached to the default destination.
Additionally, in the rare cases where a non-default destination prefix
is host to subtree routes, the fallback on not hitting any subtree route
is commonly a default route (or a subtree route on that).
(Note that this was working for the "::/0 from ::/0" case since the root
node is special-cased. The issue was discovered during RFC 6724 rule
5.5 testing, trying to find edge cases.)
Signed-off-by: David 'equinox' Lamparter <equinox@diac24.net>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Patrick Rohr <prohr@google.com>
Cc: Maciej Żenczykowski <maze@google.com>
---
net/ipv6/ip6_fib.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index a130cdfaebfb..273f2bfc5286 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1656,8 +1656,11 @@ static struct fib6_node *fib6_node_lookup_1(struct fib6_node *root,
struct fib6_node *sfn;
sfn = fib6_node_lookup_1(subtree,
args + 1);
- if (!sfn)
+ if (!sfn) {
+ if (fn->fn_flags & RTN_RTINFO)
+ return fn;
goto backtrack;
+ }
fn = sfn;
}
#endif
--
2.53.0
^ permalink raw reply related
* Re: What's cooking in zh_CN (Jul 2026)
From: Dongliang Mu @ 2026-07-14 9:32 UTC (permalink / raw)
To: Weijie Yuan
Cc: linux-doc, Alex Shi, Yanteng Si, Dongliang Mu, Ben Guo, Gary Guo,
Yan Zhu, Doehyun Baek, Jiandong Qiu, chengyaqiang
In-Reply-To: <alUXH8qRRjno2eZG@wyuan.org>
On Tue, Jul 14, 2026 at 12:51 AM Weijie Yuan <wy@wyuan.org> wrote:
>
> Hi all,
>
> Since I made many noise these days on the list, which took up a lot of
> maintainers' time. This email summarizes the patches for zh_CN that are
> currently pending on the mailing list.
This is awesome. Maybe we can establish a dashboard for the activities
in zh_CN/TW related patches of linux-doc.
I personally kept a knowledge base in the IMA (an app for storing
knowledge base in the cloud) in our club to monitor these activities.
Dongliang Mu
>
> -----------------------------------------------------------------------
>
> * Ben Guo (2026-07-13) 4 commits
> [PATCH v2 0/4] docs/zh_CN: update rust documentation translations
> [PATCH v2 1/4] docs/zh_CN: Update rust/quick-start.rst translation
> [PATCH v2 2/4] docs/zh_CN: Update rust/general-information.rst translation
> [PATCH v2 3/4] docs/zh_CN: Update rust/arch-support.rst translation
> [PATCH v2 4/4] docs/zh_CN: Update rust/testing.rst translation
>
> Reviewed by Dongliang, a part needs to be revised. Expecting a reroll.
>
> cf. https://lore.kernel.org/linux-doc/17094968-1385-4dba-aae8-5d93a2aaf59e@hust.edu.cn/
> source: https://lore.kernel.org/linux-doc/cover.1783905132.git.ben.guo@openatom.club/
>
> * Doehyun Baek (2026-07-08) 7 commits
> [PATCH v6 0/7] docs/zh_CN: update DAMON translations
> [PATCH v6 1/7] docs/zh_CN: update DAMON design translation
> [PATCH v6 2/7] docs/zh_CN: add DAMON_STAT usage translation
> [PATCH v6 3/7] docs/zh_CN: update DAMON index translation
> [PATCH v6 4/7] docs/zh_CN: update DAMON start translation
> [PATCH v6 5/7] docs/zh_CN: update DAMON usage translation
> [PATCH v6 6/7] docs/zh_CN: update DAMON reclaim translation
> [PATCH v6 7/7] docs/zh_CN: update DAMON LRU sort translation
Maybe I can take a review tomorrow.
>
> Needs review.
>
> source: https://lore.kernel.org/linux-doc/20260708073246.1652828-1-doehyunbaek@gmail.com/
>
> * Jiandong Qiu 2026-07-06 2 commits
> [PATCH v3 0/2] docs/zh_CN: update translation of doc-guide/sphinx.rst
> [PATCH v3 1/2] docs/zh_CN: add process/changes.rst translation
> [PATCH v3 2/2] docs/zh_CN: update sphinx.rst translation
>
> Waiting for response(s) to review comment(s). & Needs review.
>
> cf. https://lore.kernel.org/linux-doc/ak1SG5mw7y2UZrvR@wyuan.org/
> source: https://lore.kernel.org/linux-doc/20260706151358.2103703-1-qiujiandong1998@gmail.com/
>
> * Yan Zhu (2026-06-12) 10 commits
> [not found] <cover.1781105672.git.zhuyan2015@qq.com>
> [PATCH 01/10] docs/zh_CN: add LSM/index Chinese translation
> [PATCH 02/10] docs/zh_CN: add LSM/apparmor Chinese translation
> [PATCH 03/10] docs/zh_CN: add LSM/LoadPin Chinese translation
> [PATCH 04/10] docs/zh_CN: add LSM/SELinux Chinese translation
> [PATCH 05/10] docs/zh_CN: add LSM/Smack Chinese translation
> [PATCH 06/10] docs/zh_CN: add LSM/tomoyo Chinese translation
> [PATCH 07/10] docs/zh_CN: add LSM/Yama Chinese translation
> [PATCH 08/10] docs/zh_CN: add LSM/SafeSetID Chinese translation
> [PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
> [PATCH 10/10] docs/zh_CN: add LSM/landlock Chinese translation
>
> Needs review.
>
> source: https://lore.kernel.org/linux-doc/tencent_7080BF6BB8F05936649DDC091FFD8C45210A@qq.com/
> Note: cover letter missing on lore archive.
>
> * chengyaqiang (2026-05-22) 1 commit
> [PATCH] docs/zh_CN: fix KASAN SW_TAGS mode description
>
> Reviewed by Dongliang and Zenghui, will merge to docs-next @alex ?
>
> source: https://lore.kernel.org/linux-doc/20260522075735.2022734-1-chengyaqiang@chengyaqiang.com/
>
> * Haoyang Liu (2026-03-05) 1 commit
> [PATCH] docs/zh_CN: fix an inconsistent statement in dev-tools/testing-overview
>
> Expecting a reroll.
>
> cf. https://lore.kernel.org/linux-doc/29bd0dbc-c6f9-43ce-b95f-4e787e3fe9c3@gmail.com/
> source: https://lore.kernel.org/linux-doc/20260305192048.16405-1-tttturtleruss@gmail.com/
>
> -----------------------------------------------------------------------
>
> Okay, I have checked the 200 most recent messages on the mailing list,
> going back to 15:09 UTC on February 25, 2026. If I have missed anything,
> or I made a mistake somewhere, please let me know.
>
> As you may have noticed, I borrowed (stole) this idea from Junio C
> Hamano. Sending this kind of message, somewhat like a weekly status
> report, not only helps maintainers keep track of outstanding work, but
> also lets contributors know the current status of their patches.
As mentioned before, can we have a dashboard to see the status of
patches in zh_CN/TW? This is more useful in my mind.
>
> More importantly, it gives newcomers an overview of the current state of
> the project. New contributors can begin not only by submitting patches,
> but also by reviewing patches already posted to the mailing list,
> thereby learning how our workflow operates. This may also help reduce
> the review burden on our friendly maintainers.
>
> I would like to try this kind of periodic report as an experimental
> effort, with its frequency adjusted according to the size of the patch
> backlog and the level of activity on the mailing list. What do you
> think? Please feel free to make comments.
I think this is fine since linux-doc or narrowly zh_CN/TW do not have
many volumes of patches per day.
>
> By the way, I borrowed the subject line directly from Git's "What's
> cooking in git.git". Does anyone have a better suggestion for the name? ;-)
fine with this title
>
> Thanks,
> Weijie
>
^ permalink raw reply
* Re: [PATCH v7 06/10] ACPI: APEI: GHES: move CXL CPER helpers
From: Ahmed Tiba @ 2026-07-14 9:27 UTC (permalink / raw)
To: Alison Schofield
Cc: Rafael J. Wysocki, Tony Luck, Borislav Petkov, Hanjun Guo,
Mauro Carvalho Chehab, Shuai Xue, Len Brown, Saket Dumbre,
Davidlohr Bueso, Jonathan Cameron, Dave Jiang, Vishal Verma,
Dan Williams, Ira Weiny, Li Ming, Mahesh J Salgaonkar,
Oliver O'Halloran, Bjorn Helgaas, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
linux-kernel, linux-acpi, acpica-devel, linux-cxl, linuxppc-dev,
linux-pci, devicetree, linux-edac, linux-doc, Dmitry.Lamerov
In-Reply-To: <alWi5hvXYT0-ZPyV@aschofie-mobl2.lan>
On 14/07/2026 03:45, Alison Schofield wrote:
> On Wed, Jul 08, 2026 at 02:59:05PM +0100, Ahmed Tiba wrote:
>> Move the CXL CPER handling paths out of ghes.c and into ghes_cper.c so the
>> helpers can be reused. The code is moved as-is, with the public
>> prototypes updated so GHES keeps calling into the new translation unit.
>>
>> While moving this code, also add CXL CPER section length checks and use
>> spinlock_irqsave() in CXL register/unregister paths for locking
>> consistency.
>
> NAK on moving and changing in the same patch, and esp in a patch
> whose subject only says MOVE.
Hi Alison,
I understand the concern.
I kept those changes in 06/10 because they address pre-existing issues
reported specifically against this patch by Sashiko, and I wanted to
avoid carrying known defects forward in the series. I did this following
Boris' feedback to address review-reported issues in-series rather than
carry them forward unchanged.
I can also add a dedicated "Sashiko findings addressed" section and
update the commit description to state clearly that this patch is not
pure move.
Please advise your preferred way to address Sashiko findings per patch
in this series.
Thanks,
Ahmed
^ permalink raw reply
* Re: [PATCH v3 0/4] docs/zh_CN: update rust documentation translations
From: Alex Shi @ 2026-07-14 8:59 UTC (permalink / raw)
To: Ben Guo, Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet
Cc: Gary Guo, linux-doc, linux-kernel, rust-for-linux,
hust-os-kernel-patches
In-Reply-To: <cover.1784000217.git.ben.guo@openatom.club>
Applied, thanks!
On 2026/7/14 15:00, Ben Guo wrote:
> Update Chinese translations for the Rust subsystem documentation,
> syncing with the latest upstream changes.
>
> - quick-start.rst: update distro-specific install instructions, Ubuntu
> package versions, openSUSE rust-src package, and remove GDB/Binutils note
> - general-information.rst: add no_std section, rustdoc links, abstractions
> and bindings diagram, Bindings/Abstractions sections, and Kconfig example
> - arch-support.rst: add s390 support note
> - testing.rst: add Kconfig guidance for KUnit test suites
>
> Changes in v3:
> - Add Reviewed-by from Dongliang Mu
> - Add spaces around "HTML" in general-information.rst
>
> Changes in v2:
> - Add Reviewed-by from Gary Guo
> - Translate "sound" as "可靠" in general-information.rst
>
> Ben Guo (4):
> docs/zh_CN: Update rust/quick-start.rst translation
> docs/zh_CN: Update rust/general-information.rst translation
> docs/zh_CN: Update rust/arch-support.rst translation
> docs/zh_CN: Update rust/testing.rst translation
>
> .../translations/zh_CN/rust/arch-support.rst | 1 +
> .../zh_CN/rust/general-information.rst | 82 ++++++++++++++++++-
> .../translations/zh_CN/rust/quick-start.rst | 48 +++++------
> .../translations/zh_CN/rust/testing.rst | 4 +
> 4 files changed, 103 insertions(+), 32 deletions(-)
>
> --
^ permalink raw reply
* [PATCH 4/4] hwmon: (kb9002) Add documentation
From: Andy Chung via B4 Relay @ 2026-07-14 8:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
In-Reply-To: <20260714-kb9002-upstream-v1-0-8fd2f0b135d8@amd.com>
From: Andy Chung <Andy.Chung@amd.com>
Document the sysfs and debugfs interfaces of the Kandou KB9002 hwmon
driver.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/kb9002.rst | 65 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 226789376217..9dc796d087dc 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -112,6 +112,7 @@ Hardware Monitoring Kernel Drivers
jc42
k10temp
k8temp
+ kb9002
kbatt
kfan
lan966x
diff --git a/Documentation/hwmon/kb9002.rst b/Documentation/hwmon/kb9002.rst
new file mode 100644
index 000000000000..e6d8d9c78923
--- /dev/null
+++ b/Documentation/hwmon/kb9002.rst
@@ -0,0 +1,65 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver kb9002
+====================
+
+Supported chips:
+
+ * Kandou KB9002
+
+ Prefix: 'kb9002'
+
+ Addresses scanned: -
+
+ Datasheet: KA-015171-PD (available from Kandou under NDA)
+
+Author: Andy Chung <andy.chung@amd.com>
+
+Description
+-----------
+
+The Kandou KB9002 is an 8-lane PCIe 5.0 retimer with an integrated
+microcontroller. It exposes an SMBus 3.0 target (with mandatory PEC)
+on its sideband interface. The internal firmware aggregates per-lane
+die temperatures and publishes the maximum value through a 16-bit
+addressed register window.
+
+This driver reports that aggregated maximum as the only hwmon
+temperature channel. The running firmware version and the firmware
+boot status are exposed under debugfs.
+
+sysfs interface
+---------------
+
+================== ===============================================
+temp1_input Aggregated maximum die temperature across all
+ active lanes (millidegrees Celsius).
+temp1_label Always "kb9002".
+================== ===============================================
+
+debugfs interface
+-----------------
+
+Files live in the per-client debugfs directory created by the I2C
+core: ``/sys/kernel/debug/i2c/i2c-<bus>/<bus>-<addr>/``.
+
+================== ===============================================
+fw_ver Running firmware version in
+ "major.minor.patch.suffix" format. Read-only.
+fw_load_status Firmware boot status: "normal" once firmware has
+ finished initialising, "abnormal" otherwise.
+ Read-only.
+================== ===============================================
+
+Notes
+-----
+
+The driver requires ``I2C_FUNC_SMBUS_BLOCK_DATA``,
+``I2C_FUNC_SMBUS_PEC`` and ``I2C_FUNC_I2C`` from the host adapter. The
+last is needed only during probe for the host-interface mode switch;
+runtime accesses use SMBus block transactions exclusively.
+
+The retimer's SMBus address is configurable on three strap pins and
+ranges from 0x20 to 0x27. The address is selected through device tree
+(or i2c board info) the same way as any other I2C device; the driver
+does not auto-detect.
--
2.34.1
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: hwmon: Add Kandou KB9002
From: Andy Chung via B4 Relay @ 2026-07-14 8:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
In-Reply-To: <20260714-kb9002-upstream-v1-0-8fd2f0b135d8@amd.com>
From: Andy Chung <Andy.Chung@amd.com>
Add device tree bindings for the Kandou KB9002 PCIe 5.0 retimer, an
SMBus target that exposes an aggregated die temperature.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
.../devicetree/bindings/hwmon/kandou,kb9002.yaml | 45 ++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/kandou,kb9002.yaml b/Documentation/devicetree/bindings/hwmon/kandou,kb9002.yaml
new file mode 100644
index 000000000000..67859e9d63c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/kandou,kb9002.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/kandou,kb9002.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kandou KB9002 PCIe 5.0 retimer
+
+maintainers:
+ - Andy Chung <andy.chung@amd.com>
+
+description: |
+ The Kandou KB9002 is an 8-lane PCIe 5.0 retimer that exposes a
+ firmware-controlled SMBus 3.0 target on its sideband interface.
+ The host can query the aggregated maximum die temperature and the
+ running firmware version through that target.
+
+ The 7-bit SMBus address is selected by three SMB_ADDR straps and
+ ranges from 0x20 to 0x27.
+
+properties:
+ compatible:
+ const: kandou,kb9002
+
+ reg:
+ minimum: 0x20
+ maximum: 0x27
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ retimer@20 {
+ compatible = "kandou,kb9002";
+ reg = <0x20>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: Add vendor prefix for Kandou
From: Andy Chung via B4 Relay @ 2026-07-14 8:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
In-Reply-To: <20260714-kb9002-upstream-v1-0-8fd2f0b135d8@amd.com>
From: Andy Chung <Andy.Chung@amd.com>
Kandou Bus, S.A. is the vendor of the KB9002 PCIe retimer.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f368e7..727871970d97 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -879,6 +879,8 @@ patternProperties:
description: JuTouch Technology Co., Ltd.
"^kam,.*":
description: Kamstrup A/S
+ "^kandou,.*":
+ description: Kandou Bus, S.A.
"^karo,.*":
description: Ka-Ro electronics GmbH
"^keithkoep,.*":
--
2.34.1
^ permalink raw reply related
* [PATCH 3/4] hwmon: (kb9002) Add driver for Kandou KB9002 retimer
From: Andy Chung via B4 Relay @ 2026-07-14 8:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
In-Reply-To: <20260714-kb9002-upstream-v1-0-8fd2f0b135d8@amd.com>
From: Andy Chung <Andy.Chung@amd.com>
The Kandou KB9002 is an 8-lane PCIe 5.0 retimer that exposes an SMBus
target with mandatory PEC. Add a hwmon driver reporting the firmware
aggregated maximum die temperature as temp1_input, with the firmware
version and boot status under debugfs.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 11 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/kb9002.c | 473 +++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 493 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9b4b1575bdbd..1d80ac2660e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13931,6 +13931,14 @@ S: Maintained
F: Documentation/hwmon/k8temp.rst
F: drivers/hwmon/k8temp.c
+KANDOU KB9002 PCIE RETIMER HWMON DRIVER
+M: Andy Chung <andy.chung@amd.com>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/kandou,kb9002.yaml
+F: Documentation/hwmon/kb9002.rst
+F: drivers/hwmon/kb9002.c
+
KASAN
M: Andrey Ryabinin <ryabinin.a.a@gmail.com>
R: Alexander Potapenko <glider@google.com>
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08c29685126a..300329773e87 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -335,6 +335,17 @@ config SENSORS_K10TEMP
This driver can also be built as a module. If so, the module
will be called k10temp.
+config SENSORS_KB9002
+ tristate "Kandou KB9002 PCIe retimer"
+ depends on I2C
+ help
+ If you say yes here you get support for the integrated
+ temperature sensor and firmware version readout on Kandou
+ KB9002 PCIe 5.0 retimers, accessed over SMBus.
+
+ This driver can also be built as a module. If so, the module
+ will be called kb9002.
+
config SENSORS_KBATT
tristate "KEBA battery controller support"
depends on KEBA_CP500
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 63809eeec2f4..0cad7e21634c 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -113,6 +113,7 @@ obj-$(CONFIG_SENSORS_IT87) += it87.o
obj-$(CONFIG_SENSORS_JC42) += jc42.o
obj-$(CONFIG_SENSORS_K8TEMP) += k8temp.o
obj-$(CONFIG_SENSORS_K10TEMP) += k10temp.o
+obj-$(CONFIG_SENSORS_KB9002) += kb9002.o
obj-$(CONFIG_SENSORS_KBATT) += kbatt.o
obj-$(CONFIG_SENSORS_KFAN) += kfan.o
obj-$(CONFIG_SENSORS_LAN966X) += lan966x-hwmon.o
diff --git a/drivers/hwmon/kb9002.c b/drivers/hwmon/kb9002.c
new file mode 100644
index 000000000000..2a3dffe52a62
--- /dev/null
+++ b/drivers/hwmon/kb9002.c
@@ -0,0 +1,473 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Kandou KB9002 PCIe 5.0 retimer hwmon driver.
+ *
+ * The retimer exposes a system management bus (SMBus 3.0 with PEC)
+ * target for firmware-managed status registers. This driver assumes
+ * the chip is strapped to SMBus mode and exports the aggregated
+ * maximum die temperature as hwmon temp1_input (millidegrees Celsius)
+ * plus the firmware version and boot status under debugfs.
+ *
+ * Datasheet: Kandou KB9002 PCIe retimer (KA-015171-PD).
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/debugfs.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/i2c.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/seq_file.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+
+#define KB9002_DEV_NAME "kb9002"
+
+/*
+ * SMBus read command codes. Each read is a two-phase PEC-protected
+ * transaction: prime writes the target address, data reads it back with
+ * the register contents. FW reads use a 16-bit address, HW reads 32-bit.
+ */
+#define KB9002_CC_FW_READ_PRIME 0x82
+#define KB9002_CC_FW_READ_DATA 0x81
+#define KB9002_CC_HW_READ_PRIME 0x8a
+#define KB9002_CC_HW_READ_DATA 0x89
+
+/* Firmware register offsets (16-bit). */
+#define KB9002_FW_REG_VID 0x0004
+#define KB9002_FW_REG_FW_VERSION 0x0500
+#define KB9002_FW_REG_TEMP_MAXIMUM 0x0550
+
+#define KB9002_VID_MASK GENMASK(31, 16)
+#define KB9002_VID_KANDOU 0x1e6f
+
+/* Firmware boot status: 0xe8 in the top byte means init completed OK. */
+#define KB9002_HW_REG_FW_BOOT_STATUS 0xe0090008
+#define KB9002_FW_BOOT_STATUS_OK_MSB 0xe8
+
+/*
+ * Hardware registers reached over raw I2C (32-bit addressing). The
+ * host-interface bit selects SMBus (set) vs raw-I2C target; parts
+ * strapped to raw I2C need it set before SMBus access works.
+ */
+#define KB9002_HW_REG_REVID 0x00480004
+#define KB9002_HW_REG_HOST_IF 0x00480008
+#define KB9002_HOST_IF_SMBUS BIT(1)
+
+#define KB9002_REVID_MASK GENMASK(7, 0)
+#define KB9002_REVID_B0 0x10
+#define KB9002_REVID_B1 0x11
+
+/* Retries to drain a stray leading 0xff from the raw-I2C FIFO. */
+#define KB9002_REVID_READ_RETRIES 16
+
+/* Temperature: 32-bit Q16.16 absolute Kelvin. */
+#define KB9002_TEMP_FRAC_BITS 16
+#define KB9002_ABS_ZERO_MILLI_C (-273150)
+
+/* Firmware takes up to ~2s to respond after a host-interface change. */
+#define KB9002_FW_READY_POLL_US (25 * USEC_PER_MSEC)
+#define KB9002_FW_READY_TIMEOUT_US (2 * USEC_PER_SEC)
+
+struct kb9002_data {
+ struct i2c_client *client;
+ struct mutex lock; /* serialises register accesses */
+};
+
+/* Raw-I2C read: write the 32-bit BE address, then read 4 BE data bytes. */
+static int kb9002_i2c_read(struct i2c_client *client, u32 reg, u32 *val)
+{
+ u8 addr[4];
+ u8 rbuf[4];
+ struct i2c_msg msgs[2] = {
+ {
+ .addr = client->addr,
+ .flags = 0,
+ .len = sizeof(addr),
+ .buf = addr,
+ },
+ {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(rbuf),
+ .buf = rbuf,
+ },
+ };
+ int ret;
+
+ put_unaligned_be32(reg, addr);
+
+ ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
+ if (ret < 0)
+ return ret;
+ if (ret != ARRAY_SIZE(msgs))
+ return -EIO;
+
+ *val = get_unaligned_be32(rbuf);
+ return 0;
+}
+
+/* Raw-I2C write: 4 BE address bytes followed by 4 BE data bytes. */
+static int kb9002_i2c_write(struct i2c_client *client, u32 reg, u32 val)
+{
+ u8 buf[8];
+ struct i2c_msg msg = {
+ .addr = client->addr,
+ .flags = 0,
+ .len = sizeof(buf),
+ .buf = buf,
+ };
+ int ret;
+
+ put_unaligned_be32(reg, &buf[0]);
+ put_unaligned_be32(val, &buf[4]);
+
+ ret = i2c_transfer(client->adapter, &msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ return 0;
+}
+
+/*
+ * Read the silicon revision ID. A fresh FIFO may start with a stray
+ * 0xff that shifts the result, so drain one byte between retries until
+ * the top byte is no longer 0xff.
+ */
+static int kb9002_read_revid(struct i2c_client *client, u32 *revid)
+{
+ u8 dummy;
+ int ret;
+ int i;
+
+ for (i = 0; i < KB9002_REVID_READ_RETRIES; i++) {
+ ret = kb9002_i2c_read(client, KB9002_HW_REG_REVID, revid);
+ if (!ret && (*revid >> 24) != 0xff)
+ return 0;
+ /* Drain one byte from the chip to re-align the I2C FIFO. */
+ i2c_master_recv(client, &dummy, 1);
+ }
+
+ return ret ? ret : -EIO;
+}
+
+/*
+ * Read a 32-bit firmware register over SMBus: block-write the 16-bit LE
+ * address, then block-read the echoed address plus 4 LE data bytes.
+ */
+static int kb9002_fw_read(struct kb9002_data *data, u16 reg, u32 *val)
+{
+ struct i2c_client *client = data->client;
+ u8 addr[2];
+ u8 rbuf[I2C_SMBUS_BLOCK_MAX];
+ int ret;
+
+ put_unaligned_le16(reg, addr);
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_block_data(client, KB9002_CC_FW_READ_PRIME,
+ sizeof(addr), addr);
+ if (ret < 0)
+ goto out;
+
+ ret = i2c_smbus_read_block_data(client, KB9002_CC_FW_READ_DATA, rbuf);
+ if (ret < 0)
+ goto out;
+ if (ret < (int)(sizeof(addr) + sizeof(*val))) {
+ ret = -EIO;
+ goto out;
+ }
+
+ *val = get_unaligned_le32(&rbuf[sizeof(addr)]);
+ ret = 0;
+out:
+ mutex_unlock(&data->lock);
+ return ret;
+}
+
+/* Like kb9002_fw_read but for a hardware register (32-bit LE address). */
+static int kb9002_smbus_hw_read(struct kb9002_data *data, u32 reg, u32 *val)
+{
+ struct i2c_client *client = data->client;
+ u8 addr[4];
+ u8 rbuf[I2C_SMBUS_BLOCK_MAX];
+ int ret;
+
+ put_unaligned_le32(reg, addr);
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_block_data(client, KB9002_CC_HW_READ_PRIME,
+ sizeof(addr), addr);
+ if (ret < 0)
+ goto out;
+
+ ret = i2c_smbus_read_block_data(client, KB9002_CC_HW_READ_DATA, rbuf);
+ if (ret < 0)
+ goto out;
+ if (ret < (int)(sizeof(addr) + sizeof(*val))) {
+ ret = -EIO;
+ goto out;
+ }
+
+ *val = get_unaligned_le32(&rbuf[sizeof(addr)]);
+ ret = 0;
+out:
+ mutex_unlock(&data->lock);
+ return ret;
+}
+
+/*
+ * Switch the host interface from raw-I2C to SMBus and wait for firmware
+ * to come back up. Called only when SMBus access failed in probe, i.e.
+ * the chip is strapped to raw-I2C mode. Confirms the revision, sets the
+ * SMBus-mode bit, then polls until firmware responds again.
+ */
+static int kb9002_enable_smbus_target(struct kb9002_data *data)
+{
+ struct i2c_client *client = data->client;
+ u32 revid;
+ u32 val;
+ int op_ret;
+ int ret;
+
+ ret = kb9002_read_revid(client, &revid);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "revision ID read failed\n");
+
+ switch (FIELD_GET(KB9002_REVID_MASK, revid)) {
+ case KB9002_REVID_B0:
+ case KB9002_REVID_B1:
+ break;
+ default:
+ return dev_err_probe(&client->dev, -ENODEV,
+ "unsupported revision ID 0x%08x\n", revid);
+ }
+
+ ret = kb9002_i2c_read(client, KB9002_HW_REG_HOST_IF, &val);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "host interface read failed\n");
+
+ val |= KB9002_HOST_IF_SMBUS;
+
+ ret = kb9002_i2c_write(client, KB9002_HW_REG_HOST_IF, val);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "host interface write failed\n");
+
+ /* Wait until firmware re-initialisation completes. */
+ ret = read_poll_timeout(kb9002_fw_read, op_ret, op_ret == 0,
+ KB9002_FW_READY_POLL_US,
+ KB9002_FW_READY_TIMEOUT_US, true,
+ data, KB9002_FW_REG_VID, &val);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "firmware not responding over SMBus\n");
+
+ return 0;
+}
+
+/* Convert Q16.16 absolute Kelvin to millidegrees Celsius. */
+static long kb9002_temp_to_milli_c(u32 raw)
+{
+ s64 milli_k = ((s64)raw * 1000) >> KB9002_TEMP_FRAC_BITS;
+
+ return (long)milli_k + KB9002_ABS_ZERO_MILLI_C;
+}
+
+static int kb9002_read_temp(struct kb9002_data *data, long *val)
+{
+ u32 raw;
+ int ret;
+
+ ret = kb9002_fw_read(data, KB9002_FW_REG_TEMP_MAXIMUM, &raw);
+ if (ret)
+ return ret;
+
+ *val = kb9002_temp_to_milli_c(raw);
+ return 0;
+}
+
+static umode_t kb9002_is_visible(const void *drvdata,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ if (type == hwmon_temp &&
+ (attr == hwmon_temp_input || attr == hwmon_temp_label))
+ return 0444;
+ return 0;
+}
+
+static int kb9002_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ struct kb9002_data *data = dev_get_drvdata(dev);
+
+ if (type == hwmon_temp && attr == hwmon_temp_input)
+ return kb9002_read_temp(data, val);
+
+ return -EOPNOTSUPP;
+}
+
+static int kb9002_read_string(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ if (type == hwmon_temp && attr == hwmon_temp_label) {
+ *str = KB9002_DEV_NAME;
+ return 0;
+ }
+ return -EOPNOTSUPP;
+}
+
+static const struct hwmon_ops kb9002_hwmon_ops = {
+ .is_visible = kb9002_is_visible,
+ .read = kb9002_read,
+ .read_string = kb9002_read_string,
+};
+
+static const struct hwmon_channel_info * const kb9002_hwmon_info[] = {
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
+ NULL,
+};
+
+static const struct hwmon_chip_info kb9002_chip_info = {
+ .ops = &kb9002_hwmon_ops,
+ .info = kb9002_hwmon_info,
+};
+
+static int kb9002_fw_version_show(struct seq_file *s, void *unused)
+{
+ struct kb9002_data *data = s->private;
+ u32 ver;
+ int ret;
+
+ ret = kb9002_fw_read(data, KB9002_FW_REG_FW_VERSION, &ver);
+ if (ret)
+ return ret;
+
+ seq_printf(s, "%u.%02u.%02u.%u\n",
+ (ver >> 24) & 0xff, (ver >> 16) & 0xff,
+ (ver >> 8) & 0xff, (ver >> 0) & 0xff);
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(kb9002_fw_version);
+
+static int kb9002_fw_load_status_show(struct seq_file *s, void *unused)
+{
+ struct kb9002_data *data = s->private;
+ u32 status;
+ int ret;
+
+ ret = kb9002_smbus_hw_read(data, KB9002_HW_REG_FW_BOOT_STATUS, &status);
+ if (ret)
+ return ret;
+
+ seq_printf(s, "%s\n",
+ (status >> 24) == KB9002_FW_BOOT_STATUS_OK_MSB ?
+ "normal" : "abnormal");
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(kb9002_fw_load_status);
+
+static void kb9002_debugfs_init(struct kb9002_data *data)
+{
+ struct dentry *dir = data->client->debugfs;
+
+ debugfs_create_file("fw_ver", 0444, dir, data,
+ &kb9002_fw_version_fops);
+ debugfs_create_file("fw_load_status", 0444, dir, data,
+ &kb9002_fw_load_status_fops);
+}
+
+static int kb9002_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct kb9002_data *data;
+ struct device *hwmon_dev;
+ u32 vid;
+ int ret;
+
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BLOCK_DATA |
+ I2C_FUNC_SMBUS_PEC | I2C_FUNC_I2C))
+ return -ENODEV;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->client = client;
+ mutex_init(&data->lock);
+
+ /* All firmware register accesses are PEC-protected. */
+ client->flags |= I2C_CLIENT_PEC;
+
+ i2c_set_clientdata(client, data);
+
+ /*
+ * Try SMBus first. If the chip is strapped to raw-I2C mode it
+ * will not respond to SMBus framing, so fall back to switching
+ * the host interface over raw I2C and retry.
+ */
+ ret = kb9002_fw_read(data, KB9002_FW_REG_VID, &vid);
+ if (ret) {
+ dev_dbg(dev, "SMBus probe failed (%d), trying raw-I2C host-interface switch\n",
+ ret);
+ ret = kb9002_enable_smbus_target(data);
+ if (ret)
+ return ret;
+ ret = kb9002_fw_read(data, KB9002_FW_REG_VID, &vid);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "VID read failed after host-interface switch\n");
+ }
+ if (FIELD_GET(KB9002_VID_MASK, vid) != KB9002_VID_KANDOU)
+ return dev_err_probe(dev, -ENODEV,
+ "unexpected VID 0x%08x\n", vid);
+
+ hwmon_dev = devm_hwmon_device_register_with_info(dev, KB9002_DEV_NAME,
+ data,
+ &kb9002_chip_info,
+ NULL);
+ if (IS_ERR(hwmon_dev))
+ return PTR_ERR(hwmon_dev);
+
+ kb9002_debugfs_init(data);
+ return 0;
+}
+
+static const struct i2c_device_id kb9002_id[] = {
+ { KB9002_DEV_NAME },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, kb9002_id);
+
+static const struct of_device_id kb9002_of_match[] = {
+ { .compatible = "kandou,kb9002" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, kb9002_of_match);
+
+static struct i2c_driver kb9002_driver = {
+ .driver = {
+ .name = KB9002_DEV_NAME,
+ .of_match_table = kb9002_of_match,
+ },
+ .probe = kb9002_probe,
+ .id_table = kb9002_id,
+};
+module_i2c_driver(kb9002_driver);
+
+MODULE_AUTHOR("Andy Chung <andy.chung@amd.com>");
+MODULE_DESCRIPTION("Kandou KB9002 PCIe retimer hwmon driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH 0/4] hwmon: Add Kandou KB9002 PCIe retimer driver
From: Andy Chung via B4 Relay @ 2026-07-14 8:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
The Kandou KB9002 is an 8-lane PCIe 5.0 retimer with an integrated
microcontroller that exposes an SMBus 3.0 target (with mandatory PEC)
on its sideband interface. Its firmware aggregates per-lane die
temperatures and publishes the maximum through a register window.
This series adds a hwmon driver for it. The driver reports the
aggregated maximum die temperature as temp1_input, and exposes the
running firmware version and boot status under debugfs.
The series is organised as:
1/4 add the "kandou" vendor prefix
2/4 device tree binding for the retimer
3/4 the driver, Kconfig/Makefile and MAINTAINERS entry
4/4 hwmon documentation
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
Andy Chung (4):
dt-bindings: Add vendor prefix for Kandou
dt-bindings: hwmon: Add Kandou KB9002
hwmon: (kb9002) Add driver for Kandou KB9002 retimer
hwmon: (kb9002) Add documentation
.../devicetree/bindings/hwmon/kandou,kb9002.yaml | 45 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/kb9002.rst | 65 +++
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/kb9002.c | 473 +++++++++++++++++++++
8 files changed, 606 insertions(+)
---
base-commit: ca078d004cf58137bcf8cb24a8b271397431ba58
change-id: 20260713-kb9002-upstream-06c686e37833
Best regards,
--
Andy Chung <Andy.Chung@amd.com>
^ permalink raw reply
* Re: [patch 13/18] entry: Make trace_syscall_enter() return type bool
From: Michal Suchánek @ 2026-07-14 8:20 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Peter Zijlstra, Michael Ellerman, Shrikanth Hegde,
linuxppc-dev, Kees Cook, Huacai Chen, loongarch, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Sven Schnelle, linux-s390, x86,
Mark Rutland, Jinjie Ruan, Andy Lutomirski, Oleg Nesterov,
Richard Henderson, Russell King, Catalin Marinas, Guo Ren,
Geert Uytterhoeven, Thomas Bogendoerfer, Helge Deller,
Yoshinori Sato, Richard Weinberger, Chris Zankel,
linux-arm-kernel, linux-alpha, linux-csky, linux-m68k, linux-mips,
linux-parisc, linux-sh, linux-um, Arnd Bergmann, Vineet Gupta,
Will Deacon, Brian Cain, Michal Simek, Dinh Nguyen,
David S. Miller, Andreas Larsson, linux-snps-arc, linux-hexagon,
linux-openrisc, sparclinux, linux-arch, Jonathan Corbet,
linux-doc
In-Reply-To: <87a4rxqnar.ffs@fw13>
On Sat, Jul 11, 2026 at 10:33:16PM +0200, Thomas Gleixner wrote:
> Michal!
>
> On Fri, Jul 10 2026 at 13:01, Michal Suchánek wrote:
> > On Wed, Jul 08, 2026 at 10:34:38PM +0200, Thomas Gleixner wrote:
> >> does not make #2 magically go away. It's still the same problem whether
> >> you like it or not.
> >
> > However, reading the syscall number from pt_regs only after
> > syscall_enter_from_user_mode exits does.
>
> That does not solve anything at all.
>
> TBH, your communication style is annoying as hell. You fail to provide
> any useful arguments and explanations despite me giving you a proper
> analysis. And I'm absolutely tired of this.
>
> So let me try again for _ONE_ last time to explain you why your ppc/s390
> world view is broken and let's look at the current code (irrelevant
> portions omitted).
>
> static __always_inline long syscall_trace_enter(struct pt_regs *regs, unsigned long work)
> {
> if (work & SYSCALL_WORK_SYSCALL_USER_DISPATCH) {
> #1 if (syscall_user_dispatch(regs))
> return -1L;
> }
>
> if (work & (SYSCALL_WORK_SYSCALL_TRACE | SYSCALL_WORK_SYSCALL_EMU)) {
> #2 ret = arch_ptrace_report_syscall_entry(regs);
> if (ret || (work & SYSCALL_WORK_SYSCALL_EMU))
> return -1L;
> }
>
> /* Do seccomp after ptrace, to catch any tracer changes. */
> if (work & SYSCALL_WORK_SECCOMP) {
> #3 ret = __secure_computing();
> if (ret == -1L)
> return ret;
> }
>
> /* Either of the above might have changed the syscall number */
> #4 syscall = syscall_get_nr(current, regs);
>
> if (unlikely(work & SYSCALL_WORK_SYSCALL_TRACEPOINT))
> #5 syscall = trace_syscall_enter(regs, syscall);
>
> return syscall;
> }
>
> #1) The user dispatch mechanism does not modify the syscall return
> value, but it can rollback the syscall and tell the call site to
> skip the invocation.
>
> The mechanism used in upstream today is to return -1L as the syscall
> number which makes the architecture specific entry code skip the
> syscall and refrain from touching the return value.
>
> #2) ptrace
>
> ptrace can poke whatever it wants into the syscall number storage
> via ptrace_set_syscall_info_entry() -> syscall_set_nr()
>
> It does not set the return code.
>
> It does not abort the syscall when the poked syscall number is -1L.
Indeed, it does not abort on -1 syscall number anymore although there
are still comments around that claim that setting the syscall number to
-1 is special.
Thanks
Michal
^ permalink raw reply
* [PATCH 2/2] mm/zswap: Support batch writeback in shrink_memcg()
From: Hao Jia @ 2026-07-14 8:15 UTC (permalink / raw)
To: akpm, tj, hannes, shakeel.butt, mhocko, yosry, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin
Cc: linux-mm, linux-kernel, linux-doc, Hao Jia
In-Reply-To: <20260714081510.16895-1-jiahao.kernel@gmail.com>
From: Hao Jia <jiahao1@lixiang.com>
Currently, shrink_memcg() writes back at most one entry per-node during
its traversal. This makes shrink_worker() inefficient, as it must
repeatedly re-enter shrink_memcg() to make any substantial progress.
To address this, extend shrink_memcg() and rewrite its LRU iteration logic
to support batch writeback. Introduce the nr_to_scan parameter to bound how
many pages are scanned per call. This enables batch writeback in the
shrink_worker() path, while maintaining a low scan budget in the
zswap_store() path.
Additionally, to prepare for future proactive writeback, update the return
value semantics of shrink_memcg(): a positive value now represents the
actual number of compressed bytes written back, 0 indicates that candidates
existed but no writeback succeeded, and a negative value represents an
error code.
Test Setup:
Total memory: 32 GB.
zswap settings: max_pool_percent=1, accept_threshold_percent=50,
shrinker_enabled=N.
Allocate 512MB of anonymous pages and fill them with random data (to avoid
compression), then use cgroup memory.reclaim to force a large amount of
anonymous pages into zswap. At an interval of 2ms, allocate a 4K anonymous
page where the first 4 bytes are random numbers and the rest are zeros, and
then trigger a reclamation of this 4K anonymous page through cgroup
memory.reclaim. When the pool threshold is reached, shrink_memcg() will
be triggered.
The test data after running for 120s is as follows:
Baseline Patched
shrink_worker wakeups 5363 85
shrink_memcg calls 11,345,012 188,264
written_back 40214 40275
Conclusion:
Under the same workload and run duration, the patched kernel shows a
significant reduction in both shrink_worker wakeups and shrink_memcg calls.
Suggested-by: Yosry Ahmed <yosry@kernel.org>
Signed-off-by: Hao Jia <jiahao1@lixiang.com>
---
mm/zswap.c | 89 ++++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 69 insertions(+), 20 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index 3d697a1a5365..6d492762957a 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -160,6 +160,11 @@ struct zswap_pool {
char tfm_name[CRYPTO_MAX_ALG_NAME];
};
+struct zswap_shrink_walk_arg {
+ unsigned long bytes_written;
+ bool encountered_page_in_swapcache;
+};
+
/* Global LRU lists shared by all zswap pools. */
static struct list_lru zswap_list_lru;
@@ -1089,8 +1094,9 @@ static enum lru_status shrink_memcg_cb(struct list_head *item, struct list_lru_o
void *arg)
{
struct zswap_entry *entry = container_of(item, struct zswap_entry, lru);
- bool *encountered_page_in_swapcache = (bool *)arg;
+ struct zswap_shrink_walk_arg *walk_arg = arg;
swp_entry_t swpentry;
+ unsigned int length;
enum lru_status ret = LRU_REMOVED_RETRY;
int writeback_result;
@@ -1133,10 +1139,11 @@ static enum lru_status shrink_memcg_cb(struct list_head *item, struct list_lru_o
/*
* Once the lru lock is dropped, the entry might get freed. The
- * swpentry is copied to the stack, and entry isn't deref'd again
- * until the entry is verified to still be alive in the tree.
+ * needed fields are copied to the stack, and entry isn't deref'd
+ * again until it is verified to still be alive in the tree.
*/
swpentry = entry->swpentry;
+ length = entry->length;
/*
* It's safe to drop the lock here because we return either
@@ -1155,12 +1162,13 @@ static enum lru_status shrink_memcg_cb(struct list_head *item, struct list_lru_o
* into the warmer region. We should terminate shrinking (if we're in the dynamic
* shrinker context).
*/
- if (writeback_result == -EEXIST && encountered_page_in_swapcache) {
+ if (writeback_result == -EEXIST) {
ret = LRU_STOP;
- *encountered_page_in_swapcache = true;
+ walk_arg->encountered_page_in_swapcache = true;
}
} else {
zswap_written_back_pages++;
+ walk_arg->bytes_written += length;
}
return ret;
@@ -1169,8 +1177,11 @@ static enum lru_status shrink_memcg_cb(struct list_head *item, struct list_lru_o
static unsigned long zswap_shrinker_scan(struct shrinker *shrinker,
struct shrink_control *sc)
{
+ struct zswap_shrink_walk_arg walk_arg = {
+ .bytes_written = 0,
+ .encountered_page_in_swapcache = false,
+ };
unsigned long shrink_ret;
- bool encountered_page_in_swapcache = false;
if (!zswap_shrinker_enabled ||
!mem_cgroup_zswap_writeback_enabled(sc->memcg)) {
@@ -1179,9 +1190,9 @@ static unsigned long zswap_shrinker_scan(struct shrinker *shrinker,
}
shrink_ret = list_lru_shrink_walk(&zswap_list_lru, sc, &shrink_memcg_cb,
- &encountered_page_in_swapcache);
+ &walk_arg);
- if (encountered_page_in_swapcache)
+ if (walk_arg.encountered_page_in_swapcache)
return SHRINK_STOP;
return shrink_ret ? shrink_ret : SHRINK_STOP;
@@ -1275,9 +1286,31 @@ static struct shrinker *zswap_alloc_shrinker(void)
return shrinker;
}
-static int shrink_memcg(struct mem_cgroup *memcg)
+#define NR_ZSWAP_WB_BATCH 64UL
+
+/*
+ * Scan up to @nr_to_scan pages across the per-node zswap LRUs of @memcg
+ * and write back the reclaimable ones.
+ *
+ * Since the second-chance algorithm rotates referenced entries to the
+ * LRU tail, the per-node scan is capped at the current LRU length so
+ * each entry is scanned at most once per call. It is up to the caller
+ * to handle retries, deciding whether to scan another memcg to complete
+ * the full iteration, or to rescan the current memcg to drain its zswap
+ * entries.
+ *
+ * Return: The number of compressed bytes written back (>= 0), or -ENOENT
+ * if @memcg has writeback disabled, is a zombie cgroup, or has empty
+ * zswap LRUs.
+ */
+static long shrink_memcg(struct mem_cgroup *memcg, unsigned long nr_to_scan)
{
- int nid, shrunk = 0, scanned = 0;
+ struct zswap_shrink_walk_arg walk_arg = {
+ .bytes_written = 0,
+ .encountered_page_in_swapcache = false,
+ };
+ unsigned long nr_remaining = nr_to_scan;
+ int nid;
if (!mem_cgroup_zswap_writeback_enabled(memcg))
return -ENOENT;
@@ -1290,24 +1323,40 @@ static int shrink_memcg(struct mem_cgroup *memcg)
return -ENOENT;
for_each_node_state(nid, N_NORMAL_MEMORY) {
- unsigned long nr_to_walk = 1;
+ unsigned long nr_to_walk;
- shrunk += list_lru_walk_one(&zswap_list_lru, nid, memcg,
- &shrink_memcg_cb, NULL, &nr_to_walk);
- scanned += 1 - nr_to_walk;
+ /*
+ * Cap the scan at per-node LRU length so each entry is scanned
+ * at most once per call.
+ */
+ nr_to_walk = min(nr_remaining,
+ list_lru_count_one(&zswap_list_lru, nid, memcg));
+ if (!nr_to_walk)
+ continue;
+
+ nr_remaining -= nr_to_walk;
+ list_lru_walk_one(&zswap_list_lru, nid, memcg, &shrink_memcg_cb,
+ &walk_arg, &nr_to_walk);
+ /* Return the unused share of the budget to the pool. */
+ nr_remaining += nr_to_walk;
+
+ if (!nr_remaining)
+ break;
}
- if (!scanned)
+ /* Nothing was scanned: every LRU under @memcg was empty. */
+ if (nr_remaining == nr_to_scan)
return -ENOENT;
- return shrunk ? 0 : -EAGAIN;
+ return walk_arg.bytes_written;
}
static void shrink_worker(struct work_struct *w)
{
struct mem_cgroup *memcg;
- int ret, failures = 0, attempts = 0;
+ int failures = 0, attempts = 0;
unsigned long thr;
+ long ret;
/* Reclaim down to the accept threshold */
thr = zswap_accept_thr_pages();
@@ -1369,7 +1418,7 @@ static void shrink_worker(struct work_struct *w)
goto resched;
}
- ret = shrink_memcg(memcg);
+ ret = shrink_memcg(memcg, NR_ZSWAP_WB_BATCH);
/* drop the extra reference */
mem_cgroup_put(memcg);
@@ -1383,7 +1432,7 @@ static void shrink_worker(struct work_struct *w)
continue;
++attempts;
- if (ret && ++failures == MAX_RECLAIM_RETRIES)
+ if (ret <= 0 && ++failures == MAX_RECLAIM_RETRIES)
break;
resched:
cond_resched();
@@ -1493,7 +1542,7 @@ bool zswap_store(struct folio *folio)
objcg = get_obj_cgroup_from_folio(folio);
if (objcg && !obj_cgroup_may_zswap(objcg)) {
memcg = get_mem_cgroup_from_objcg(objcg);
- if (shrink_memcg(memcg)) {
+ if (shrink_memcg(memcg, 1) <= 0) {
mem_cgroup_put(memcg);
goto put_objcg;
}
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] mm/zswap: Fix global shrinker when memory cgroup is disabled
From: Hao Jia @ 2026-07-14 8:15 UTC (permalink / raw)
To: akpm, tj, hannes, shakeel.butt, mhocko, yosry, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin
Cc: linux-mm, linux-kernel, linux-doc, Hao Jia, stable
In-Reply-To: <20260714081510.16895-1-jiahao.kernel@gmail.com>
From: Hao Jia <jiahao1@lixiang.com>
When memory cgroup is disabled, mem_cgroup_iter() always returns NULL.
Therefore, the global shrinker shrink_worker() always takes the !memcg
branch. After MAX_RECLAIM_RETRIES empty walks, the worker simply gives up,
so it fails to write back anything.
Therefore, when memory cgroup is disabled, fall through with the !memcg
branch and shrink the root memcg directly.
With memcg disabled, shrink_memcg() only returns -ENOENT when the root
LRU is empty, which means the total pages are already below thr. The
loop then safely bails out via the zswap_total_pages() <= thr check.
For any other return value from shrink_memcg(), the loop is guaranteed
to terminate, either after MAX_RECLAIM_RETRIES failures or once the
threshold is met.
Fixes: a65b0e7607cc ("zswap: make shrinking memcg-aware")
Cc: stable@vger.kernel.org
Suggested-by: Nhat Pham <nphamcs@gmail.com>
Acked-by: Nhat Pham <nphamcs@gmail.com>
Acked-by: Yosry Ahmed <yosry@kernel.org>
Reported-by: Yosry Ahmed <yosry@kernel.org>
Closes: https://lore.kernel.org/all/CAO9r8zPVzMKFbCixxD-qgtRrkFxWVrHiZZeLc=eyTPKPVQgX4g@mail.gmail.com
Signed-off-by: Hao Jia <jiahao1@lixiang.com>
---
mm/zswap.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index b5a17ea20237..3d697a1a5365 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -1356,11 +1356,12 @@ static void shrink_worker(struct work_struct *w)
} while (memcg && !mem_cgroup_tryget_online(memcg));
spin_unlock(&zswap_shrink_lock);
- if (!memcg) {
- /*
- * Continue shrinking without incrementing failures if
- * we found candidate memcgs in the last tree walk.
- */
+ /*
+ * A NULL memcg ends a full hierarchy pass (except when memcg is
+ * disabled, where it is always NULL: fall through to the root LRU).
+ * Count a failure only if the last pass found no candidates.
+ */
+ if (!memcg && !mem_cgroup_disabled()) {
if (!attempts && ++failures == MAX_RECLAIM_RETRIES)
break;
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] mm/zswap: Fixes and improves the zswap global shrinker
From: Hao Jia @ 2026-07-14 8:15 UTC (permalink / raw)
To: akpm, tj, hannes, shakeel.butt, mhocko, yosry, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin
Cc: linux-mm, linux-kernel, linux-doc, Hao Jia
From: Hao Jia <jiahao1@lixiang.com>
This is the first half of the patch series[1]. The remaining part,
which covers proactive writeback, will be submitted later once the
swap tiering design is finalized.
This series fixes and improves the zswap global shrinker (shrink_worker()):
Patch 1: Fix missing global shrinker when memory cgroup is disabled.
Patch 2: Extend shrink_memcg() to support batch writeback and update its
return value semantics, thereby improving the writeback efficiency
in the shrink_worker() path.
[1] https://lore.kernel.org/all/20260629112032.20423-1-jiahao.kernel@gmail.com
Hao Jia (2):
mm/zswap: Fix global shrinker when memory cgroup is disabled
mm/zswap: Support batch writeback in shrink_memcg()
mm/zswap.c | 100 +++++++++++++++++++++++++++++++++++++++--------------
1 file changed, 75 insertions(+), 25 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
From: Geert Uytterhoeven @ 2026-07-14 7:54 UTC (permalink / raw)
To: Marek Vasut
Cc: Bjorn Helgaas, Marc Zyngier, linux-pci, kernel test robot,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring,
Yoshihiro Shimoda, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <2013cac8-d887-4a09-b1c5-6dc9606f16f0@mailbox.org>
Hi Marek,
On Tue, 14 Jul 2026 at 01:27, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 7/13/26 7:54 PM, Bjorn Helgaas wrote:
> > On Fri, Jul 10, 2026 at 03:35:10PM +0200, Marek Vasut wrote:
> >> On 7/10/26 10:30 AM, Marc Zyngier wrote:
> >>> On Thu, 09 Jul 2026 21:10:03 +0100,
> >>> Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
> >>>>
> >>>> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h ,
> >>>> copy the one GITS_TRANSLATER register offset macro directly into
> >>>> the driver. This repairs the ability to build the driver on
> >>>> non-ARM non-GIC targets the way it was possible until now, which
> >>>> retains good build test coverage.
> >> ...
> >
> >> So in the end, it is either this patch or limit the build to
> >> arm/arm64 . At least this patch still allows building this driver
> >> with more compilers on the various build bots, so I would opt for
> >> this patch here.
> >
> > I like the build coverage, but duplicating the #define doesn't really
> > seem good to me. It makes readability worse because cscope/tags now
> > sees two definitions without an obvious reason.
>
> I can rename the macro, or ... sigh ... I can reduce the driver to build
That would obfuscate the code?
> only on ARM/ARM64. Which one do you prefer ?
Just add the dependency for compile-testing, just like
PCIE_IPROC_PLATFORM does.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Weijie Yuan @ 2026-07-14 7:42 UTC (permalink / raw)
To: 葉宸佑
Cc: Dongliang Mu, Alex Shi, Hu Haowen, Jonathan Corbet, Shuah Khan,
Dongliang Mu, linux-doc, linux-kernel, Yuchen Tian, Alex Shi,
Yanteng Si
In-Reply-To: <CAKspUhJTGXzM=UeKTTZYX69NttBuCnAezz=ZOM9imPWLSP5g9A@mail.gmail.com>
Sorry for replying late.
On Tue, Jul 14, 2026 at 03:47:58AM +0800, 葉宸佑 wrote:
> So, to keep everything in one place, my understanding of the plan:
>
> - Chen-Yu: terminology series for process/ (14 files), folding in the
> pending 8.Conclusion changes, glossary included; adopt the
> "update to commit HASH" convention from now on
> - Chen-Yu: read Jon's advice for new-language efforts (Spanish thread)
> - later: a zh_TW how-to document
> - Weijie: investigate which documents may not need translation;
> monitor the CN/TW lists during the trial period
> - Dongliang: review; patches routed through Alex's tree (pending
> Alex's confirmation)
I have nothing to correct now. But clear to see you are the one who gets
the most tasks to do. Appreciate it! ;-)
Today I have sent the first "What's cooking in zh_CN", but once your
work showing up on the list, I will simultaneously record and update
information from both sides, simplified and traditional, during this
transitional period, until later decisions.
Best regards,
Weijie
^ permalink raw reply
* Re: (subset) [PATCH v25 0/7] firmware: imx: driver for NXP secure-enclave
From: Frieder Schrempf @ 2026-07-14 7:27 UTC (permalink / raw)
To: Frank Li, Jonathan Corbet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Pankaj Gupta
Cc: linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel
In-Reply-To: <177799642393.1381528.2137639571938103661.b4-ty@nxp.com>
On 05.05.26 17:53, Frank Li wrote:
>
> On Thu, 22 Jan 2026 17:19:12 +0530, Pankaj Gupta wrote:
>> The NXP's i.MX EdgeLock Enclave, a HW IP creating an embedded secure
>> enclave within the SoC boundary to enable features like
>> - HSM
>> - SHE
>> - V2X
>>
>> Communicates via message unit with linux kernel. This driver is
>> enables communication ensuring well defined message sequence protocol
>> between Application Core and enclave's firmware.
>>
>> [...]
>
> Applied, thanks!
>
> [1/7] Documentation/firmware: add imx/se to other_interfaces
> commit: 3b4531c6e0f4c8874f0266853a410438eda1fc24
> [2/7] dt-bindings: arm: fsl: add imx-se-fw binding doc
> commit: 4d7bcf0869686d7d7fbf16244453b987e5ca6d14
> [3/7] firmware: imx: add driver for NXP EdgeLock Enclave
> commit: 338529a73c2bf2c277013b745cfe6f19b84b70af
> [4/7] firmware: imx: device context dedicated to priv
> commit: 2d733ed67f608ee85abb854157011f88d7f280a8
> [5/7] firmware: drivers: imx: adds miscdev
> commit: 4de71839142b5f43846e3593f4eb236e1d733885
What happened to these patches?
They were part of linux-next for quite some time (up to next-20260630)
and then they disappeared (missing in next-20260701).
I didn't find any hint where or why they were dropped.
^ permalink raw reply
* Re: [PATCH 0/2] nvme: Introduce service-time iopolicy
From: Guixin Liu @ 2026-07-14 7:01 UTC (permalink / raw)
To: Keith Busch, Jens Axboe, Christoph Hellwig, Sagi Grimberg,
onathan Corbet, Shuah Khan
Cc: linux-nvme, linux-doc
In-Reply-To: <20260617114602.2224074-1-kanie@linux.alibaba.com>
Hi, gently ping, all comments are wellcome.
Best Regards,
Guixin Liu
在 2026/6/17 19:45, Guixin Liu 写道:
> Hi all,
> I developed the service-time iopolicy in nvme native
> multipath, please review, all comments are wellcome.
>
> Guixin Liu (2):
> nvme-multipath: add service-time I/O policy
> docs: nvme-multipath: document service-time I/O policy
>
> Documentation/admin-guide/nvme-multipath.rst | 31 +++-
> drivers/nvme/host/multipath.c | 165 ++++++++++++++++++-
> drivers/nvme/host/nvme.h | 6 +
> drivers/nvme/host/sysfs.c | 5 +-
> 4 files changed, 202 insertions(+), 5 deletions(-)
>
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: Simon Schippers @ 2026-07-14 6:57 UTC (permalink / raw)
To: Michael S . Tsirkin
Cc: Simon Horman, Jonathan Corbet, Shuah Khan, Andrew Lunn,
Tim Gebauer, Brett Sheffield, linux-doc, linux-kernel,
Willem de Bruijn, Jason Wang, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20260709095511.168235-1-simon.schippers@tu-dortmund.de>
On 7/9/26 11:55, Simon Schippers wrote:
> Commit 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop
> when a qdisc is present") did not show a relevant performance regression
> in my testing but on Brett Sheffield's librecast testbed it shows a
> significant performance drop in a IPv6 multicast testcase. The regression
> can be pinpointed when multiple iperf3 TCP threads are sending. For 8
> threads the performance dropped from 13.5 Gbit/s to 9.13 Gbit/s. This is
> the reason why this patch makes the qdisc backpressure behavior opt-in.
>
> One option to accomplish the opt-in would be to set the default qdisc to
> noqueue at init. However this may also break userspace as users might
> have chosen a custom qdisc even though most of the qdiscs did nothing
> for tun/tap in the past due to missing backpressure...
>
> This is the reason why in this patch, the flag IFF_BACKPRESSURE is
> introduced instead which is required to enable the backpressure logic.
> This means the stopping logic in tun_net_xmit() and the waking logic in
> __tun_wake_queue() are skipped if the flag is disabled. Setting
> IFF_BACKPRESSURE makes an attached qdisc effective by stopping the queue
> instead of tail-dropping when the internal ring is full.
>
> To avoid a possible stall due to disabling IFF_BACKPRESSURE, the new
> helper tun_force_wake_queue() is implemented. The helper safely wakes the
> respective netdev queue and resets cons_cnt while the consumer_lock and
> the producer_lock of the ring are held. The helper is run in tun_attach()
> when a queue (re)attaches, in tun_set_iff() for attached tfiles, and
> in tun_queue_resize().
>
> The documentation in tuntap.rst is updated accordingly.
>
> Fixes: 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present")
> Reported-by: Brett Sheffield <brett@librecast.net>
> Closes: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/T/#u
> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
> ---
> V2 -> V3:
> - As suggested by MST: Clarify in tuntap.rst and the UAPI header what
> enabling IFF_BACKPRESSURE opts into: an attached qdisc becomes effective
> instead of the driver tail-dropping when the internal ring is full.
> - Avoid lines over 75 characters.
> - Update comment in tun_net_xmit() to include IFF_BACKPRESSURE.
> - Brett: Update in commit message that the referenced tests were TCP.
>
> V1 -> V2:
> - Sashiko: Ensure detached queues are woken on re-attach by calling the
> new tun_force_wake_queue() helper from tun_attach(), and reuse it
> across the existing wake paths.
> - Specify the failing test case in the commit message.
>
> V1: https://lore.kernel.org/netdev/20260704112058.95421-1-simon.schippers@tu-dortmund.de/T/#u
> V2: https://lore.kernel.org/netdev/20260706094242.115992-1-simon.schippers@tu-dortmund.de/T/#u
>
> Documentation/networking/tuntap.rst | 22 +++++++++++++
> drivers/net/tun.c | 51 ++++++++++++++++++++---------
> include/uapi/linux/if_tun.h | 4 +++
> tools/include/uapi/linux/if_tun.h | 1 +
> 4 files changed, 62 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/networking/tuntap.rst b/Documentation/networking/tuntap.rst
> index 4d7087f727be..5921a924c2ae 100644
> --- a/Documentation/networking/tuntap.rst
> +++ b/Documentation/networking/tuntap.rst
> @@ -206,6 +206,28 @@ enable is true we enable it, otherwise we disable it::
> return ioctl(fd, TUNSETQUEUE, (void *)&ifr);
> }
>
> +3.4 qdisc backpressure
> +----------------------
> +
> +Starting with Linux 7.2, IFF_BACKPRESSURE can be set to enable qdisc
> +backpressure. Without it, TX drops occur when the internal ring buffer
> +is full, so any attached qdisc is effectively bypassed and applications
> +only learn about congestion through those drops.
> +
> +With it, the kernel stops instead, letting the qdisc hold and schedule
> +packets, so its AQM, shaping and fairness actually apply. This helps
> +protocols like TCP, which cut throughput in reaction to packet drops.
> +With IFF_BACKPRESSURE, drops then only occur as a rare race. Backpressure
> +requires a qdisc to be attached and has no effect with noqueue.
> +
> +The txqueuelen can be reduced alongside this flag to further shift
> +buffering into the qdisc and reduce bufferbloat, but comes at possible
> +performance cost.
> +
> +When running multiple network streams in parallel through a single
> +TUN/TAP queue, the flag may reduce performance due to the extra overhead
> +of the backpressure mechanism.
> +
> Universal TUN/TAP device driver Frequently Asked Question
> =========================================================
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index ffbe6f13fb1f..5941e8f302ea 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -98,7 +98,8 @@ static void tun_default_link_ksettings(struct net_device *dev,
> #define TUN_FASYNC IFF_ATTACH_QUEUE
>
> #define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
> - IFF_MULTI_QUEUE | IFF_NAPI | IFF_NAPI_FRAGS)
> + IFF_MULTI_QUEUE | IFF_NAPI | IFF_NAPI_FRAGS | \
> + IFF_BACKPRESSURE)
>
> #define GOODCOPY_LEN 128
>
> @@ -694,6 +695,20 @@ static void tun_detach_all(struct net_device *dev)
> module_put(THIS_MODULE);
> }
>
> +static void tun_force_wake_queue(struct tun_struct *tun,
> + struct tun_file *tfile)
> +{
> + /* Ensure that the producer can not stop the
> + * queue concurrently by taking locks.
> + */
> + spin_lock_bh(&tfile->tx_ring.consumer_lock);
> + spin_lock(&tfile->tx_ring.producer_lock);
> + netif_wake_subqueue(tun->dev, tfile->queue_index);
> + tfile->cons_cnt = 0;
> + spin_unlock(&tfile->tx_ring.producer_lock);
> + spin_unlock_bh(&tfile->tx_ring.consumer_lock);
> +}
> +
> static int tun_attach(struct tun_struct *tun, struct file *file,
> bool skip_filter, bool napi, bool napi_frags,
> bool publish_tun)
> @@ -737,11 +752,9 @@ static int tun_attach(struct tun_struct *tun, struct file *file,
> goto out;
> }
>
> - spin_lock(&tfile->tx_ring.consumer_lock);
> - tfile->cons_cnt = 0;
> - spin_unlock(&tfile->tx_ring.consumer_lock);
> tfile->queue_index = tun->numqueues;
> tfile->socket.sk->sk_shutdown &= ~RCV_SHUTDOWN;
> + tun_force_wake_queue(tun, tfile);
>
> if (tfile->detached) {
> /* Re-attach detached tfile, updating XDP queue_index */
> @@ -1077,7 +1090,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>
> spin_lock(&tfile->tx_ring.producer_lock);
> ret = __ptr_ring_produce(&tfile->tx_ring, skb);
> - if (!qdisc_txq_has_no_queue(queue) &&
> + if ((tun->flags & IFF_BACKPRESSURE) &&
> + !qdisc_txq_has_no_queue(queue) &&
> __ptr_ring_check_produce(&tfile->tx_ring) == -ENOSPC) {
> netif_tx_stop_queue(queue);
> /* Paired with smp_mb() in __tun_wake_queue() */
> @@ -1088,8 +1102,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> spin_unlock(&tfile->tx_ring.producer_lock);
>
> if (ret) {
> - /* This should be a rare case if a qdisc is present, but
> - * can happen due to lltx.
> + /* This should be a rare case if IFF_BACKPRESSURE is enabled and
> + * a qdisc is present, but can happen due to lltx.
> * Since skb_tx_timestamp(), skb_orphan(),
> * run_ebpf_filter() and pskb_trim() could have tinkered
> * with the SKB, returning NETDEV_TX_BUSY is unsafe and
> @@ -2151,8 +2165,12 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> static void __tun_wake_queue(struct tun_struct *tun,
> struct tun_file *tfile, int consumed)
> {
> - struct netdev_queue *txq = netdev_get_tx_queue(tun->dev,
> - tfile->queue_index);
> + struct netdev_queue *txq;
> +
> + if (!(tun->flags & IFF_BACKPRESSURE))
> + return;
> +
> + txq = netdev_get_tx_queue(tun->dev, tfile->queue_index);
>
> /* Paired with smp_mb__after_atomic() in tun_net_xmit() */
> smp_mb();
> @@ -2764,7 +2782,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> struct tun_struct *tun;
> struct tun_file *tfile = file->private_data;
> struct net_device *dev;
> - int err;
> + int err, i;
>
> if (tfile->detached)
> return -EINVAL;
> @@ -2893,8 +2911,12 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> /* Make sure persistent devices do not get stuck in
> * xoff state.
> */
> - if (netif_running(tun->dev))
> - netif_tx_wake_all_queues(tun->dev);
> + if (netif_running(tun->dev)) {
> + for (i = 0; i < tun->numqueues; i++) {
> + tfile = rtnl_dereference(tun->tfiles[i]);
> + tun_force_wake_queue(tun, tfile);
> + }
> + }
>
> strscpy(ifr->ifr_name, tun->dev->name);
> return 0;
> @@ -3693,10 +3715,7 @@ static int tun_queue_resize(struct tun_struct *tun)
> if (!ret) {
> for (i = 0; i < tun->numqueues; i++) {
> tfile = rtnl_dereference(tun->tfiles[i]);
> - spin_lock(&tfile->tx_ring.consumer_lock);
> - netif_wake_subqueue(tun->dev, tfile->queue_index);
> - tfile->cons_cnt = 0;
> - spin_unlock(&tfile->tx_ring.consumer_lock);
> + tun_force_wake_queue(tun, tfile);
> }
> }
>
> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> index 79d53c7a1ebd..a0ddc50a7534 100644
> --- a/include/uapi/linux/if_tun.h
> +++ b/include/uapi/linux/if_tun.h
> @@ -69,6 +69,10 @@
> #define IFF_NAPI_FRAGS 0x0020
> /* Used in TUNSETIFF to bring up tun/tap without carrier */
> #define IFF_NO_CARRIER 0x0040
> +/* Stop the queue instead of dropping when the internal ring is full, so an
> + * attached qdisc applies backpressure instead of being bypassed.
> + */
> +#define IFF_BACKPRESSURE 0x0080
> #define IFF_NO_PI 0x1000
> /* This flag has no real effect */
> #define IFF_ONE_QUEUE 0x2000
> diff --git a/tools/include/uapi/linux/if_tun.h b/tools/include/uapi/linux/if_tun.h
> index 2ec07de1d73b..97b670f5bc0a 100644
> --- a/tools/include/uapi/linux/if_tun.h
> +++ b/tools/include/uapi/linux/if_tun.h
> @@ -67,6 +67,7 @@
> #define IFF_TAP 0x0002
> #define IFF_NAPI 0x0010
> #define IFF_NAPI_FRAGS 0x0020
> +#define IFF_BACKPRESSURE 0x0080
> #define IFF_NO_PI 0x1000
> /* This flag has no real effect */
> #define IFF_ONE_QUEUE 0x2000
Hi Michael, WDYT?
Thanks!
^ permalink raw reply
* [PATCH v3 4/4] docs/zh_CN: Update rust/testing.rst translation
From: Ben Guo @ 2026-07-14 7:00 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet
Cc: Gary Guo, linux-doc, linux-kernel, rust-for-linux,
hust-os-kernel-patches
In-Reply-To: <cover.1784000217.git.ben.guo@openatom.club>
Update Documentation/rust/testing.rst translation.
Update the translation through commit 09699b24199a
("Documentation: rust: testing: add Kconfig guidance")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Signed-off-by: Ben Guo <ben.guo@openatom.club>
---
Documentation/translations/zh_CN/rust/testing.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/translations/zh_CN/rust/testing.rst b/Documentation/translations/zh_CN/rust/testing.rst
index ca81f1cef6e..6747d001299 100644
--- a/Documentation/translations/zh_CN/rust/testing.rst
+++ b/Documentation/translations/zh_CN/rust/testing.rst
@@ -128,10 +128,13 @@ Rust 测试中常用的断言宏是来自 Rust 标准库（ ``core`` ）中的 `
这些测试通过 ``kunit_tests`` 过程宏引入，该宏将测试套件的名称作为参数。
+每个测试套件都应该由 ``rust/kernel/Kconfig.test`` 中的 Kconfig 选项保护。
+
例如，假设想要测试前面文档测试示例中的函数 ``f``，我们可以在定义该函数的同一文件中编写：
.. code-block:: rust
+ #[cfg(CONFIG_RUST_MYMOD_KUNIT_TEST)]
#[kunit_tests(rust_kernel_mymod)]
mod tests {
use super::*;
@@ -158,6 +161,7 @@ Rust 测试中常用的断言宏是来自 Rust 标准库（ ``core`` ）中的 `
.. code-block:: rust
+ #[cfg(CONFIG_RUST_MYMOD_KUNIT_TEST)]
#[kunit_tests(rust_kernel_mymod)]
mod tests {
use super::*;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 3/4] docs/zh_CN: Update rust/arch-support.rst translation
From: Ben Guo @ 2026-07-14 7:00 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet
Cc: Gary Guo, linux-doc, linux-kernel, rust-for-linux,
hust-os-kernel-patches
In-Reply-To: <cover.1784000217.git.ben.guo@openatom.club>
Update Documentation/rust/arch-support.rst translation.
Update the translation through commit 3f70ebe63858
("s390: Enable Rust support")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Signed-off-by: Ben Guo <ben.guo@openatom.club>
---
Documentation/translations/zh_CN/rust/arch-support.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/translations/zh_CN/rust/arch-support.rst b/Documentation/translations/zh_CN/rust/arch-support.rst
index f5ae44588a5..0ca4be6e176 100644
--- a/Documentation/translations/zh_CN/rust/arch-support.rst
+++ b/Documentation/translations/zh_CN/rust/arch-support.rst
@@ -23,6 +23,7 @@
``arm64`` Maintained 仅小端序。
``loongarch`` Maintained \-
``riscv`` Maintained 仅 ``riscv64``，且仅限 LLVM/Clang。
+``s390`` Maintained 必须禁用 ``CONFIG_EXPOLINE``。
``um`` Maintained \-
``x86`` Maintained 仅 ``x86_64``。
============= ================ ==============================================
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/4] docs/zh_CN: Update rust/general-information.rst translation
From: Ben Guo @ 2026-07-14 7:00 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet
Cc: Gary Guo, linux-doc, linux-kernel, rust-for-linux,
hust-os-kernel-patches
In-Reply-To: <cover.1784000217.git.ben.guo@openatom.club>
Update Documentation/rust/general-information.rst translation.
Update the translation through commit 86c5d1c6740c
("docs: rust: general-information: use real example")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Signed-off-by: Ben Guo <ben.guo@openatom.club>
---
.../zh_CN/rust/general-information.rst | 82 ++++++++++++++++++-
1 file changed, 79 insertions(+), 3 deletions(-)
diff --git a/Documentation/translations/zh_CN/rust/general-information.rst b/Documentation/translations/zh_CN/rust/general-information.rst
index 9b5e37e13f3..a8c1a226ed4 100644
--- a/Documentation/translations/zh_CN/rust/general-information.rst
+++ b/Documentation/translations/zh_CN/rust/general-information.rst
@@ -13,6 +13,14 @@
本文档包含了在内核中使用Rust支持时需要了解的有用信息。
+``no_std``
+----------
+
+内核中的 Rust 支持只能链接 `core <https://doc.rust-lang.org/core/>`_，
+而不能链接 `std <https://doc.rust-lang.org/std/>`_。供内核使用的 crate
+必须使用 ``#![no_std]`` 属性选择这种行为。
+
+
.. _rust_code_documentation_zh_cn:
代码文档
@@ -20,10 +28,18 @@
Rust内核代码使用其内置的文档生成器 ``rustdoc`` 进行记录。
-生成的HTML文档包括集成搜索、链接项（如类型、函数、常量）、源代码等。它们可以在以下地址阅读
-（TODO：当在主线中时链接，与其他文档一起生成）：
+生成的 HTML 文档包括集成搜索、链接项（如类型、函数、常量）、源代码等。
+它们可以在以下地址阅读：
+
+ https://rust.docs.kernel.org
+
+对于 linux-next，请参阅：
- http://kernel.org/
+ https://rust.docs.kernel.org/next/
+
+每个主要版本也有对应的标签，例如：
+
+ https://rust.docs.kernel.org/6.10/
这些文档也可以很容易地在本地生成和阅读。这相当快（与编译代码本身的顺序相同），而且不需要特
殊的工具或环境。这有一个额外的好处，那就是它们将根据所使用的特定内核配置进行定制。要生成它
@@ -62,6 +78,58 @@ Rust内核代码使用其内置的文档生成器 ``rustdoc`` 进行记录。
模块（例如，驱动程序）不应该直接使用C语言的绑定。相反，子系统应该根据需要提供尽可能安
全的抽象。
+.. code-block::
+
+ rust/bindings/
+ (rust/helpers/)
+
+ include/ -----+ <-+
+ | |
+ drivers/ rust/kernel/ +----------+ <-+ |
+ fs/ | bindgen | |
+ .../ +-------------------+ +----------+ --+ |
+ | Abstractions | | |
+ +---------+ | +------+ +------+ | +----------+ | |
+ | my_foo | -----> | | foo | | bar | | -------> | Bindings | <-+ |
+ | driver | Safe | | sub- | | sub- | | Unsafe | | |
+ +---------+ | |system| |system| | | bindings | <-----+
+ | | +------+ +------+ | | crate | |
+ | | kernel crate | +----------+ |
+ | +-------------------+ |
+ | |
+ +------------------# FORBIDDEN #--------------------------------+
+
+主要思想是将所有与内核 C API 的直接交互封装到经过仔细审查和文档化的抽象
+中。这样，只要满足以下条件，这些抽象的用户就不能引入未定义行为
+（undefined behavior，UB）：
+
+#. 抽象是正确的（"可靠"）。
+#. 任何 ``unsafe`` 块都遵守调用块内操作所需的安全契约。类似地，任何
+ ``unsafe impl`` 都遵守实现该特性所需的安全契约。
+
+绑定
+~~~~
+
+通过从 ``include/`` 中将 C 头文件包含到
+``rust/bindings/bindings_helper.h``， ``bindgen`` 工具将为所包含的子系统
+自动生成绑定。构建后，请查看 ``rust/bindings/`` 目录中的
+``*_generated.rs`` 输出文件。
+
+对于 ``bindgen`` 不会自动生成的 C 头文件部分，例如 C ``inline`` 函数或
+非平凡宏，可以在 ``rust/helpers/`` 中添加一个小型包装函数，使其也可供
+Rust 端使用。
+
+抽象
+~~~~
+
+抽象是绑定和内核内用户之间的层。它们位于 ``rust/kernel/`` 中，其作用是
+将对绑定的不安全访问封装到尽可能安全并暴露给用户的 API 中。抽象的用户
+包括用 Rust 编写的驱动程序或文件系统等。
+
+除了安全方面，这些抽象还应该易于使用，也就是说，把 C 接口转换为符合
+Rust 惯例的代码。基本示例包括将 C 的资源获取和释放转换为 Rust 的初始化
+和清理模式，或者将 C 整数错误码转换为 Rust 的 ``Result``。
+
有条件的编译
------------
@@ -74,3 +142,11 @@ Rust代码可以访问基于内核配置的条件性编译:
#[cfg(CONFIG_X="y")] // Enabled as a built-in (`y`)
#[cfg(CONFIG_X="m")] // Enabled as a module (`m`)
#[cfg(not(CONFIG_X))] // Disabled
+
+对于 Rust 的 ``cfg`` 不支持的其他条件，例如带有数值比较的表达式，可以
+定义一个新的 Kconfig 符号：
+
+.. code-block:: kconfig
+
+ config RUSTC_HAS_SPAN_FILE
+ def_bool RUSTC_VERSION >= 108800
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/4] docs/zh_CN: Update rust/quick-start.rst translation
From: Ben Guo @ 2026-07-14 7:00 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet
Cc: Gary Guo, linux-doc, linux-kernel, rust-for-linux,
hust-os-kernel-patches
In-Reply-To: <cover.1784000217.git.ben.guo@openatom.club>
Update Documentation/rust/quick-start.rst translation.
Update the translation through commit a4392ed1c8b9
("docs: rust: quick-start: remove GDB/Binutils mention")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Signed-off-by: Ben Guo <ben.guo@openatom.club>
---
.../translations/zh_CN/rust/quick-start.rst | 48 ++++++++-----------
1 file changed, 19 insertions(+), 29 deletions(-)
diff --git a/Documentation/translations/zh_CN/rust/quick-start.rst b/Documentation/translations/zh_CN/rust/quick-start.rst
index 5f0ece6411f..0396137f3c1 100644
--- a/Documentation/translations/zh_CN/rust/quick-start.rst
+++ b/Documentation/translations/zh_CN/rust/quick-start.rst
@@ -59,7 +59,7 @@ Fedora Linux 提供较新的 Rust 版本，因此通常开箱即用，例如::
Gentoo Linux
************
-Gentoo Linux（尤其是 testing 分支）提供较新的 Rust 版本，因此通常开箱即用，
+Gentoo Linux 提供较新的 Rust 版本，因此通常开箱即用，
例如::
USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen
@@ -70,7 +70,7 @@ Gentoo Linux（尤其是 testing 分支）提供较新的 Rust 版本，因此
Nix
***
-Nix（unstable 频道）提供较新的 Rust 版本，因此通常开箱即用，例如::
+Nix 提供较新的 Rust 版本，因此通常开箱即用，例如::
{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
@@ -85,16 +85,14 @@ openSUSE
openSUSE Slowroll 和 openSUSE Tumbleweed 提供较新的 Rust 版本，因此通常开箱
即用，例如::
- zypper install rust rust1.79-src rust-bindgen clang
+ zypper install rust rust-src rust-bindgen clang
Ubuntu
******
-25.04
-~~~~~
-
-最新的 Ubuntu 版本提供较新的 Rust 版本，因此通常开箱即用，例如::
+Ubuntu 25.10 和 26.04 LTS 提供较新的 Rust 版本，因此通常开箱即用，
+例如::
apt install rustc rust-src bindgen rustfmt rust-clippy
@@ -111,32 +109,32 @@ Ubuntu
虽然 Ubuntu 24.04 LTS 及更早版本仍然提供较新的 Rust 版本，但它们需要一些额外的配
置，使用带版本号的软件包，例如::
- apt install rustc-1.80 rust-1.80-src bindgen-0.65 rustfmt-1.80 \
- rust-1.80-clippy
- ln -s /usr/lib/rust-1.80/bin/rustfmt /usr/bin/rustfmt-1.80
- ln -s /usr/lib/rust-1.80/bin/clippy-driver /usr/bin/clippy-driver-1.80
+ apt install rustc-1.85 rust-1.85-src bindgen-0.71 rustfmt-1.85 \
+ rust-1.85-clippy
+ ln -s /usr/lib/rust-1.85/bin/rustfmt /usr/bin/rustfmt-1.85
+ ln -s /usr/lib/rust-1.85/bin/clippy-driver /usr/bin/clippy-driver-1.85
这些软件包都不会将其工具设置为默认值；因此应该显式指定它们，例如::
- make LLVM=1 RUSTC=rustc-1.80 RUSTDOC=rustdoc-1.80 RUSTFMT=rustfmt-1.80 \
- CLIPPY_DRIVER=clippy-driver-1.80 BINDGEN=bindgen-0.65
+ make LLVM=1 RUSTC=rustc-1.85 RUSTDOC=rustdoc-1.85 RUSTFMT=rustfmt-1.85 \
+ CLIPPY_DRIVER=clippy-driver-1.85 BINDGEN=bindgen-0.71
-或者，修改 ``PATH`` 变量将 Rust 1.80 的二进制文件放在前面，并将 ``bindgen`` 设
+或者，修改 ``PATH`` 变量将 Rust 1.85 的二进制文件放在前面，并将 ``bindgen`` 设
置为默认值，例如::
- PATH=/usr/lib/rust-1.80/bin:$PATH
+ PATH=/usr/lib/rust-1.85/bin:$PATH
update-alternatives --install /usr/bin/bindgen bindgen \
- /usr/bin/bindgen-0.65 100
- update-alternatives --set bindgen /usr/bin/bindgen-0.65
+ /usr/bin/bindgen-0.71 100
+ update-alternatives --set bindgen /usr/bin/bindgen-0.71
-使用带版本号的软件包时需要设置 ``RUST_LIB_SRC``，例如::
+使用带版本号的软件包时可能需要设置 ``RUST_LIB_SRC``，例如::
- RUST_LIB_SRC=/usr/src/rustc-$(rustc-1.80 --version | cut -d' ' -f2)/library
+ RUST_LIB_SRC=/usr/src/rustc-$(rustc-1.85 --version | cut -d' ' -f2)/library
为方便起见，可以将 ``RUST_LIB_SRC`` 导出到全局环境中。
-此外， ``bindgen-0.65`` 在较新的版本（24.04 LTS 和 24.10）中可用，但在更早的版
-本（20.04 LTS 和 22.04 LTS）中可能不可用，因此可能需要手动构建 ``bindgen``
+此外， ``bindgen-0.71`` 在较新的版本（24.04 LTS）中可用，但在更早的版本
+（20.04 LTS 和 22.04 LTS）中可能不可用，因此可能需要手动构建 ``bindgen``
（请参见下文）。
@@ -325,11 +323,3 @@ Rust支持（CONFIG_RUST）需要在 ``General setup`` 菜单中启用。在其
要想深入了解，请看 ``samples/rust/`` 下的样例源代码、 ``rust/`` 下的Rust支持代码和
``Kernel hacking`` 下的 ``Rust hacking`` 菜单。
-
-如果使用的是GDB/Binutils，而Rust符号没有被demangled，原因是工具链还不支持Rust的新v0
-mangling方案。有几个办法可以解决：
-
-- 安装一个较新的版本（GDB >= 10.2, Binutils >= 2.36）。
-
-- 一些版本的GDB（例如vanilla GDB 10.1）能够使用嵌入在调试信息(``CONFIG_DEBUG_INFO``)
- 中的pre-demangled的名字。
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/4] docs/zh_CN: update rust documentation translations
From: Ben Guo @ 2026-07-14 7:00 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet
Cc: Gary Guo, linux-doc, linux-kernel, rust-for-linux,
hust-os-kernel-patches
Update Chinese translations for the Rust subsystem documentation,
syncing with the latest upstream changes.
- quick-start.rst: update distro-specific install instructions, Ubuntu
package versions, openSUSE rust-src package, and remove GDB/Binutils note
- general-information.rst: add no_std section, rustdoc links, abstractions
and bindings diagram, Bindings/Abstractions sections, and Kconfig example
- arch-support.rst: add s390 support note
- testing.rst: add Kconfig guidance for KUnit test suites
Changes in v3:
- Add Reviewed-by from Dongliang Mu
- Add spaces around "HTML" in general-information.rst
Changes in v2:
- Add Reviewed-by from Gary Guo
- Translate "sound" as "可靠" in general-information.rst
Ben Guo (4):
docs/zh_CN: Update rust/quick-start.rst translation
docs/zh_CN: Update rust/general-information.rst translation
docs/zh_CN: Update rust/arch-support.rst translation
docs/zh_CN: Update rust/testing.rst translation
.../translations/zh_CN/rust/arch-support.rst | 1 +
.../zh_CN/rust/general-information.rst | 82 ++++++++++++++++++-
.../translations/zh_CN/rust/quick-start.rst | 48 +++++------
.../translations/zh_CN/rust/testing.rst | 4 +
4 files changed, 103 insertions(+), 32 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v7 02/12] cpumask: Introduce cpu_preferred_mask
From: Shrikanth Hegde @ 2026-07-14 6:30 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, mingo, peterz, juri.lelli, vincent.guittot,
yury.norov, kprateek.nayak, iii, corbet, tglx, gregkh, pbonzini,
seanjc, vschneid, huschle, rostedt, dietmar.eggemann, maddy,
srikar, hdanton, chleroy, vineeth, frederic, arighi, pauld,
christian.loehle, tj, tommaso.cucinotta, maz, rafael, rdunlap,
kernellwp, linux-doc
In-Reply-To: <alT78Nzt3xa-7G5Y@yury>
Hi Yury,
On 7/13/26 8:23 PM, Yury Norov wrote:
> On Fri, Jul 10, 2026 at 03:26:38AM +0530, Shrikanth Hegde wrote:
>> Provide cpu_preferred_mask infrastructure. Define get/set macros
>> which could be used to get/set CPU state as preferred.
>>
>> PREFERRED_CPU config will be selected by the driver which handles
>> steal time values. It is going to set/clear preferred CPU state.
>> This driver will be called steal_monitor and it is introduced in
>> subsequent patches. It periodically samples the steal time and
>> decides on preferred CPU state.
>>
>> A CPU is set to preferred when it becomes active. Later it may be
>> marked as non-preferred depending on steal time values with
>> steal_monitor being enabled.
>>
>> Always maintain design construct of preferred is subset of active.
>> i.e. preferred ⊆ active ⊆ online ⊆ present ⊆ possible
>>
>> With PREFERRED_CPU=n, ensure set_cpu_preferred is a nop and get
>> method returns the active state in that case.
>>
>> Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
>> ---
>> v6->v7:
>> - removed CONFIG_PREFERRED_CPU as user option.
>> - Use do { } while (0) for nop
>>
>> include/linux/cpumask.h | 24 ++++++++++++++++++++++++
>> kernel/Kconfig.preempt | 3 +++
>> kernel/cpu.c | 6 ++++++
>> kernel/sched/core.c | 5 +++++
>> 4 files changed, 38 insertions(+)
>>
>> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
>> index d3cda0544954..34d08a3d80e1 100644
>> --- a/include/linux/cpumask.h
>> +++ b/include/linux/cpumask.h
>> @@ -122,12 +122,20 @@ extern struct cpumask __cpu_enabled_mask;
>> extern struct cpumask __cpu_present_mask;
>> extern struct cpumask __cpu_active_mask;
>> extern struct cpumask __cpu_dying_mask;
>> +
>> +#ifdef CONFIG_PREFERRED_CPU
>> +extern struct cpumask __cpu_preferred_mask;
>> +#else
>> +#define __cpu_preferred_mask __cpu_active_mask
>> +#endif
>> +
>> #define cpu_possible_mask ((const struct cpumask *)&__cpu_possible_mask)
>> #define cpu_online_mask ((const struct cpumask *)&__cpu_online_mask)
>> #define cpu_enabled_mask ((const struct cpumask *)&__cpu_enabled_mask)
>> #define cpu_present_mask ((const struct cpumask *)&__cpu_present_mask)
>> #define cpu_active_mask ((const struct cpumask *)&__cpu_active_mask)
>> #define cpu_dying_mask ((const struct cpumask *)&__cpu_dying_mask)
>> +#define cpu_preferred_mask ((const struct cpumask *)&__cpu_preferred_mask)
>>
>> extern atomic_t __num_online_cpus;
>> extern unsigned int __num_possible_cpus;
>> @@ -1164,6 +1172,12 @@ void init_cpu_possible(const struct cpumask *src);
>> #define set_cpu_active(cpu, active) assign_cpu((cpu), &__cpu_active_mask, (active))
>> #define set_cpu_dying(cpu, dying) assign_cpu((cpu), &__cpu_dying_mask, (dying))
>>
>> +#ifdef CONFIG_PREFERRED_CPU
>> +#define set_cpu_preferred(cpu, preferred) assign_cpu((cpu), &__cpu_preferred_mask, (preferred))
>> +#else
>> +#define set_cpu_preferred(cpu, preferred) do { } while (0)
>> +#endif
>> +
>> void set_cpu_online(unsigned int cpu, bool online);
>> void set_cpu_possible(unsigned int cpu, bool possible);
>>
>> @@ -1258,6 +1272,11 @@ static __always_inline bool cpu_dying(unsigned int cpu)
>> return cpumask_test_cpu(cpu, cpu_dying_mask);
>> }
>>
>> +static __always_inline bool cpu_preferred(unsigned int cpu)
>> +{
>> + return cpumask_test_cpu(cpu, cpu_preferred_mask);
>> +}
>> +
>> #else
>>
>> #define num_online_cpus() 1U
>> @@ -1296,6 +1315,11 @@ static __always_inline bool cpu_dying(unsigned int cpu)
>> return false;
>> }
>>
>> +static __always_inline bool cpu_preferred(unsigned int cpu)
>> +{
>> + return cpu == 0;
>> +}
>> +
>> #endif /* NR_CPUS > 1 */
>>
>> #define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
>> diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
>> index 88c594c6d7fc..ed02e4431230 100644
>> --- a/kernel/Kconfig.preempt
>> +++ b/kernel/Kconfig.preempt
>> @@ -192,3 +192,6 @@ config SCHED_CLASS_EXT
>> For more information:
>> Documentation/scheduler/sched-ext.rst
>> https://github.com/sched-ext/scx
>> +
>> +config PREFERRED_CPU
>> + bool
>
> This still should depend on PARAVIRT and SMP. And maybe to enforce it
> even stronger, your driver should fail to build if PREFERRED_CPU is
> disabled. Imagine a scenario when someone makes PREFERRED_CPU
> depending on some other config, but doesn't modify your driver. That
> way you'll build the STEAL_MONITOR successfully, but because
> PREFERRED_CPU is off, you'll end up with non-working functionality at
> best, or corrupted cpu_active_mask at worst.
>
Sorry, i may not understand all the intricacies of kconfigs.
But, Since driver selects PREFERRED_CPU, and PREFERRED_CPU can't be enabled
individually, driver again can't depend on PREFERRED_CPU right?
As per previous discussion, it is probably better that driver selects PREFERRED_CPU.
Keeping them both independent and selectable brings too many variations.
No?
I guess you meant below.
In kernel/Kconfig.preempt:
config PREFERRED_CPU
bool
depends on SMP && PARAVIRT
Driver's Kconfig (this is there already)
config VIRT_STEAL_GOVERNOR
tristate "Virtual Steal Time Governor"
depends on SMP && PARAVIRT
select PREFERRED_CPU
> Also, the name 'steal monitor' implies monitoring, while in fact
> you're actively affecting the scheduling process.
>
> Maybe 'steal governor'?
>
Make sense. Will do.
> Thanks,
> Yury
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox