* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Jonathan Cameron @ 2026-06-21 14:33 UTC (permalink / raw)
To: Nuno Sá
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <ajVlD-j0nIGrRVow@nsa>
On Fri, 19 Jun 2026 16:54:11 +0100
Nuno Sá <noname.nuno@gmail.com> wrote:
> On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > >
> > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > >
> > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > integrated precision reference.
> > > > > > > > > ...
> > > > > > > > > Probably others may comment on that, but...
> > > > > > > > >
> > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > >
> > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > +
> > > > > > > > > > +patternProperties:
> > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > + type: object
> > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > +
> > > > > > > > > > + properties:
> > > > > > > > > > + reg:
> > > > > > > > > > + description: Channel number.
> > > > > > > > > > + minimum: 0
> > > > > > > > > > + maximum: 15
> > > > > > > > > > +
> > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > + description: |
> > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > + oneOf:
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: 0
> > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: -5000000
> > > > > > > > > > + - const: 5000000
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: -10000000
> > > > > > > > > > + - const: 10000000
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: -15000000
> > > > > > > > > > + - const: 15000000
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: -20000000
> > > > > > > > > > + - const: 20000000
> > > > > > > > > > +
> > > > > > > > > > + required:
> > > > > > > > > > + - reg
> > > > > > > > > > +
> > > > > > > > > > + additionalProperties: false
> > > > > > > > > > +
> > > > > > > > > > +required:
> > > > > > > > > > + - compatible
> > > > > > > > > > + - reg
> > > > > > > > > > + - vdd-supply
> > > > > > > > > > + - avdd-supply
> > > > > > > > > > + - hvdd-supply
> > > > > > > > > > +
> > > > > > > > > > +dependencies:
> > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > +
> > > > > > > > > > +allOf:
> > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > +
> > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > +
> > > > > > > > > > +examples:
> > > > > > > > > > + - |
> > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > +
> > > > > > > > > > + spi {
> > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > +
> > > > > > > > > > + dac@0 {
> > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > + reg = <0>;
> > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > +
> > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > +
> > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > +
> > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > +
> > > > > > > > > > + channel@0 {
> > > > > > > > > > + reg = <0>;
> > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > + };
> > > > > > > > > > +
> > > > > > > > > > + channel@1 {
> > > > > > > > > > + reg = <1>;
> > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > + };
> > > > > > > > > > +
> > > > > > > > > > + channel@2 {
> > > > > > > > > > + reg = <2>;
> > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > + };
> > > > > > > > > > + };
> > > > > > > > > > + };
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > spi {
> > > > > > > > > #address-cells = <1>;
> > > > > > > > > #size-cells = <0>;
> > > > > > > > >
> > > > > > > > > multi-dac@0 {
> > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > reg = <0>;
> > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > >
> > > > > > > > > #address-cells = <1>;
> > > > > > > > > #size-cells = <0>;
> > > > > > > > >
> > > > > > > > > dac@0 {
> > > > > > > > > reg = <0>;
> > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > >
> > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > >
> > > > > > > > > #address-cells = <1>;
> > > > > > > > > #size-cells = <0>;
> > > > > > > > >
> > > > > > > > > channel@0 {
> > > > > > > > > reg = <0>;
> > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > channel@1 {
> > > > > > > > > reg = <1>;
> > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > channel@2 {
> > > > > > > > > reg = <2>;
> > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > };
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > dac@1 {
> > > > > > > > > reg = <1>;
> > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > >
> > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > >
> > > > > > > > > #address-cells = <1>;
> > > > > > > > > #size-cells = <0>;
> > > > > > > > >
> > > > > > > > > channel@0 {
> > > > > > > > > reg = <0>;
> > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > channel@1 {
> > > > > > > > > reg = <1>;
> > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > };
> > > > > > > > > }
> > > > > > > > > };
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > then you might need something like:
> > > > > > > > >
> > > > > > > > > patternProperties:
> > > > > > > > > "^dac@[0-3]$":
> > > > > > > > >
> > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > >
> > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > >
> > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > Hi Rodrigo,
> > > > > > > >
> > > > > > > > Thank you for looking at this.
> > > > > > > >
> > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > speculatively without a validating use case.
> > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > >
> > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > in all devices in the chain as one big SPI message.
> > > > > > >
> > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > longer term how to support it cleanly in SPI.
> > > > >
> > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > see if I can find what I am thinking of...
> > > >
> > > >
> > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > slightly different properties.
> > > >
> > > > microchip,device-addr:
> > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > enum: [0, 1, 2, 3]
> > > > default: 0
> > > >
> > > > and
> > > >
> > > >
> > > > microchip,hw-device-address:
> > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > minimum: 0
> > > > maximum: 3
> > > > description:
> > > > The address is set on a per-device basis by fuses in the factory,
> > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > The device address is part of the device markings to avoid
> > > > potential confusion. This address is coded on two bits, so four possible
> > > > addresses are available when multiple devices are present on the same
> > > > SPI bus with only one Chip Select line for all devices.
> > > > Each device communication starts by a CS falling edge, followed by the
> > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > which is first one on the wire).
> > > >
> > > > This sounds exactly like the sort of feature that you're dealing with
> > > > here?
> > > >
> > >
> > > The core idea yes but for this chip, things are a bit more annoying (but
> > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > have it's own supplies, pins and at the very least, channels with maybe
> > > different scales. That is why Janani is proposing dac nodes. Given I
> > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > about solving this at the spi level.
> > >
> > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > together in the same bus.
> >
> > I'm definitely missing something, because that property for the
> > microchip devices is not impacted what else is on the bus. AFAICT, you
> > could have an mcp3911 and an mcp3564 on the same bus even though both
> > are completely different devices with different drivers. They have
> > individual device nodes and their own supplies etc etc. These aren't
> > per-channel properties on an adc or dac, they're per child device on a
> > spi bus.
>
> Maybe I'm the one missing something :). IIRC, spi would not allow two
> devices on the same CS right? Because for this chip we would need
> something like:
>
> spi {
> dac@0 {
> reg = <0>;
> adi,pin-id = <0>;
> };
>
> dac@1 {
> reg = <0>; // which seems already problematic?
> adi,pin-id <1>;
> };
>
> ...
>
> //up to 4
> };
Yeah. It's not clear to me how that works for the microchip devices
(I suspect it doesn't!)
Just thinking as I type, but could we do something a bit nasty with
a gpio mux that doesn't actually switch but represents the GPIO being
shared? Given this is all tied to the spi bus that should all happen
under serializing locks.
Agreed though that this would be nicer as an SPI thing that let
us specify that a single CS is share by multiple devices and their
is some other signal acting to select which one we are talking to.
Jonathan
>
> - Nuno Sá
>
>
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Move non-trace_printk prototypes back to kernel.h
From: Steven Rostedt @ 2026-06-21 13:24 UTC (permalink / raw)
To: Yury Norov, Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <ajfiVTlCIVlqW3sh@yury>
On June 21, 2026 2:08:37 PM GMT+01:00, Yury Norov <yury.norov@gmail.com> wrote:
>On Sun, Jun 21, 2026 at 05:34:31AM -0400, Steven Rostedt wrote:
>> From: Steven Rostedt <rostedt@goodmis.org>
>>
>> In order to remove the include to trace_printk.h from kernel.h the tracing
>> control prototypes need to be moved back into kernel.h. That's because
>
>Please don't. Instead, you can split them out to trace_control.h, and
>include where needed. I actually have a prototype for it, FYI:
>
>https://github.com/norov/linux/tree/trace_pritk3
>
Sure, I have no problem adding another header for this.
>> they are used in other common header files like rcu.h. There's no point in
>> removing trace_printk.h from kernel.h if it just gets added back to other
>> common headers.
>>
>> Prototypes are very cheap for the compiler and should not be an issue.
>
>It's not about cost, it's about mess. kernel.h is included everywhere.
>Is that API needed everywhere? No, it's needed in literally 10 files.
>So, no place in kernel.h.
>
Well one of those files is rcu.h which is also pretty much included everywhere. But OK.
-- Steve
>>
>> 2.53.0
>>
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Yury Norov @ 2026-06-21 13:57 UTC (permalink / raw)
To: Yury Norov
Cc: Steven Rostedt, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, linux-doc,
linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <ajfphe4Z8BrfYoUX@yury>
On Sun, Jun 21, 2026 at 09:39:17AM -0400, Yury Norov wrote:
> On Sun, Jun 21, 2026 at 05:47:21AM -0400, Steven Rostedt wrote:
> > On Sun, 21 Jun 2026 05:34:32 -0400
> > Steven Rostedt <rostedt@kernel.org> wrote:
> >
> > > Instead of having trace_printk.h included in kernel.h, create a config
> > > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> > > Makefile to allow developers to add trace_printk() without the need to add
> > > the include for it. Having it included in the Makefile keeps it from being
> > > in the dependency chain and it will not waste extra CPU cycles for those
> > > building the kernel without using trace_printk.
> >
> > Bah, I only tested with the config option enabled, and missed some
> > dependencies with it disabled.
>
> Yes you did.
>
> > For instance, rcu.h also uses ftrace_dump() so that too needs to go
> > into kernel.h.
>
> No, it shouldn't.
>
> > I also need to add a few more includes to trace_printk.h.
>
> > OK, I need to run this through all my tests to find where else I missed
> > adding the includes. But the idea should hopefully satisfy everyone.
>
> If you include it under config in kernel.h, to make the kernel buildable,
I mean: in kernel.h or in Makefile.
> you need to include trace_printk.h explicitly where it's actually used.
> IOW, apply my patch v4-7.
>
> Then, developers who use trace_printk() on their development machine,
> will be really frustrated when their debugging code will break client
> build just because CONFIG_TRACE_PRINTK_DEBUGGING is disabled there.
> They will spend a day, at best, communicating with remote managers,
> and end up with adding #include <linux/trace_printk.h> in the files
> they touch. Is that your plan?
>
> If I was one of those developers, the solution would be simple for me:
> don't use trace_printk() at all.
>
> Thanks,
> Yury
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Yury Norov @ 2026-06-21 13:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621054721.7cde38f0@fedora>
On Sun, Jun 21, 2026 at 05:47:21AM -0400, Steven Rostedt wrote:
> On Sun, 21 Jun 2026 05:34:32 -0400
> Steven Rostedt <rostedt@kernel.org> wrote:
>
> > Instead of having trace_printk.h included in kernel.h, create a config
> > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> > Makefile to allow developers to add trace_printk() without the need to add
> > the include for it. Having it included in the Makefile keeps it from being
> > in the dependency chain and it will not waste extra CPU cycles for those
> > building the kernel without using trace_printk.
>
> Bah, I only tested with the config option enabled, and missed some
> dependencies with it disabled.
Yes you did.
> For instance, rcu.h also uses ftrace_dump() so that too needs to go
> into kernel.h.
No, it shouldn't.
> I also need to add a few more includes to trace_printk.h.
> OK, I need to run this through all my tests to find where else I missed
> adding the includes. But the idea should hopefully satisfy everyone.
If you include it under config in kernel.h, to make the kernel buildable,
you need to include trace_printk.h explicitly where it's actually used.
IOW, apply my patch v4-7.
Then, developers who use trace_printk() on their development machine,
will be really frustrated when their debugging code will break client
build just because CONFIG_TRACE_PRINTK_DEBUGGING is disabled there.
They will spend a day, at best, communicating with remote managers,
and end up with adding #include <linux/trace_printk.h> in the files
they touch. Is that your plan?
If I was one of those developers, the solution would be simple for me:
don't use trace_printk() at all.
Thanks,
Yury
^ permalink raw reply
* [PATCH v2 2/2] docs/zh_CN: update sphinx.rst translation
From: Jiandong Qiu @ 2026-06-21 13:12 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260621131215.1303439-1-qiujiandong1998@gmail.com>
Update the zh_CN translation of doc-guide/sphinx.rst.
Update this translation through commit f1c2db1f145b
("docs: move test_doc_build.py to tools/docs")
- clean up the file header anchor `_sphinxdoc_zh`
- sync the Chinese translation with the current Sphinx build requirements
- add sections on HTML math rendering and minimum-version testing
- refresh guidance for tables, cross-references, and commit references
Assisted-by: Codex:GPT-5.4
Signed-off-by: Jiandong Qiu <qiujiandong1998@gmail.com>
---
.../translations/zh_CN/doc-guide/sphinx.rst | 167 ++++++++++++++----
1 file changed, 133 insertions(+), 34 deletions(-)
diff --git a/Documentation/translations/zh_CN/doc-guide/sphinx.rst b/Documentation/translations/zh_CN/doc-guide/sphinx.rst
index 3375c6f3a811..11e846fc97e4 100644
--- a/Documentation/translations/zh_CN/doc-guide/sphinx.rst
+++ b/Documentation/translations/zh_CN/doc-guide/sphinx.rst
@@ -1,10 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
.. include:: ../disclaimer-zh_CN.rst
:Original: Documentation/doc-guide/sphinx.rst
-:译者: 吴想成 Wu XiangCheng <bobwxc@email.cn>
-
-.. _sphinxdoc_zh:
+:译者:
+ - 吴想成 Wu XiangCheng <bobwxc@email.cn>
+ - 裘剑东 Jiandong Qiu <qiujiandong1998@gmail.com>
简介
====
@@ -14,7 +15,7 @@ Linux内核使用 `Sphinx <http://www.sphinx-doc.org/>`_ 来把 ``Documentation`
换成漂亮的文档。使用 ``make htmldocs`` 或 ``make pdfdocs`` 命令即可构建HTML
或PDF格式的文档。生成的文档放在 ``Documentation/output`` 文件夹中。
-reStructuredText文件可能包含包含来自源文件的结构化文档注释或kernel-doc注释。
+reStructuredText文件可能包含来自源文件的结构化文档注释或kernel-doc注释。
通常它们用于描述代码的功能、类型和设计。kernel-doc注释有一些特殊的结构和
格式，但除此之外，它们还被作为reStructuredText处理。
@@ -26,7 +27,7 @@ reStructuredText文件可能包含包含来自源文件的结构化文档注释
安装Sphinx
==========
-Documentation/ 下的ReST文件现在使用sphinx1.7或更高版本构建。
+Documentation/ 下的ReST文件现在使用 ``sphinx`` 3.4.3 或更高版本构建。
这有一个脚本可以检查Sphinx的依赖项。更多详细信息见
:ref:`sphinx-pre-install_zh` 。
@@ -38,21 +39,13 @@ Documentation/ 下的ReST文件现在使用sphinx1.7或更高版本构建。
``virtualenv-3`` 或 ``virtualenv`` 在虚拟环境中安装Sphinx，具体取决于发行版
如何打包Python3。
-.. note::
-
- #) html输出建议使用RTD主题。根据Sphinx版本的不同，它应该用
- ``pip install sphinx_rtd_theme`` 单独安装。
+总之，如您要安装最新版的Sphinx，应执行::
- #) 一些ReST页面包含数学表达式。由于Sphinx的工作方式，这些表达式是使用 LaTeX
- 编写的。它需要安装amsfonts和amsmath宏包，以便显示。
+ $ virtualenv sphinx_latest
+ $ . sphinx_latest/bin/activate
+ (sphinx_latest) $ pip install -r Documentation/sphinx/requirements.txt
-总之，如您要安装Sphinx 2.4.4版本，应执行::
-
- $ virtualenv sphinx_2.4.4
- $ . sphinx_2.4.4/bin/activate
- (sphinx_2.4.4) $ pip install -r Documentation/sphinx/requirements.txt
-
-在运行 ``. sphinx_2.4.4/bin/activate`` 之后，提示符将变化，以指示您正在使用新
+在运行 ``. sphinx_latest/bin/activate`` 之后，提示符将变化，以指示您正在使用新
环境。如果您打开了一个新的shell，那么在构建文档之前，您需要重新运行此命令以再
次进入虚拟环境中。
@@ -76,6 +69,23 @@ PDF和LaTeX构建
根据发行版的不同，您可能还需要安装一系列 ``texlive`` 软件包，这些软件包提供了
``XeLaTeX`` 工作所需的最小功能集。
+HTML中的数学表达式
+------------------
+
+有些ReST页面中包含数学表达式。由于Sphinx的工作方式，这些表达式使用LaTeX
+符号书写。Sphinx在HTML输出中渲染数学表达式有两种方式：一种是名为 `imgmath`_
+的扩展，它将数学表达式转换成图像并嵌入到HTML页面中。
+另一种是名为 `mathjax`_ 的扩展，它将数学表达式的渲染交由支持 JavaScript
+的浏览器处理。
+在6.1版内核文档之前，前者是唯一可用的方式，并且需要安装大量texlive软件包，
+其中包括amsfonts和amsmath等。
+
+自内核6.1版本起，无需安装任何texlive软件包即可构建包含数学表达式的HTML
+页面。更多信息请参阅 :ref:`choice_of_math_renderer_zh`。
+
+.. _imgmath: https://www.sphinx-doc.org/en/master/usage/extensions/math.html#module-sphinx.ext.imgmath
+.. _mathjax: https://www.sphinx-doc.org/en/master/usage/extensions/math.html#module-sphinx.ext.mathjax
+
.. _sphinx-pre-install_zh:
检查Sphinx依赖项
@@ -108,7 +118,29 @@ PDF和LaTeX构建
``--no-virtualenv``
- 使用Sphinx的系统打包，而不是Python虚拟环境。
+ 使用系统发行版提供的Sphinx软件包，而不是Python虚拟环境。
+
+安装最小版本的Sphinx
+--------------------
+
+在修改Sphinx构建系统时，确保其最小支持版本仍然可用非常重要。
+然而，在现代发行版上，这样做正变得越来越困难，因为在Python 3.13及以上版本
+环境下，已经无法安装该最小版本。
+
+要按照 Documentation/translations/zh_CN/process/changes.rst
+中定义的最低支持Python版本进行测试，可以使用该版本创建一个虚拟环境，
+并安装最小依赖::
+
+ /usr/bin/python3.9 -m venv sphinx_min
+ . sphinx_min/bin/activate
+ pip install -r Documentation/sphinx/min_requirements.txt
+
+更全面的测试可以使用以下脚本完成:
+
+ tools/docs/test_doc_build.py
+
+该脚本会为每个受支持的Python版本创建一个虚拟环境，并可选择针对一定范围内的
+Sphinx版本构建文档。
Sphinx构建
==========
@@ -117,17 +149,66 @@ Sphinx构建
的格式：请参阅 ``make help`` 的文档部分。生成的文档放在 ``Documentation/output``
下相应格式的子目录中。
-要生成文档，显然必须安装Sphinx（ ``sphinx-build`` ）。要让HTML输出更漂亮，可以
-使用Read the Docs Sphinx主题（ ``sphinx_rtd_theme`` ）。对于PDF输出，您还需要
-``XeLaTeX`` 和来自ImageMagick（https://www.imagemagick.org）的 ``convert(1)`` 。
-所有这些软件在大多发行版中都可用或已打包。
+要生成文档，显然必须安装Sphinx（ ``sphinx-build`` ）。对于PDF输出，您还需
+要 ``XeLaTeX`` 和来自 ImageMagick（https://www.imagemagick.org）的
+``convert(1)`` 。\ [#ink]_ 所有这些软件在各大发行版中都很常见，
+也都有对应的软件包。
要传递额外的选项给Sphinx，可以使用make变量 ``SPHINXOPTS`` 。例如，使用
``make SPHINXOPTS=-v htmldocs`` 获得更详细的输出。
+也可以通过make变量 ``DOCS_CSS`` 传入一个额外的DOCS_CSS覆盖文件，以自定义
+html布局。
+
+默认情况下，构建HTML文档时使用的是"Alabaster"主题；该主题随Sphinx一同提供，
+无需单独安装。也可以通过make变量 ``DOCS_THEME`` 覆盖Sphinx主题。
+
+.. note::
+
+ 有些人可能更喜欢在html输出中使用RTD主题。根据Sphinx版本的不同，它可能需要
+ 单独安装，可使用 ``pip install sphinx_rtd_theme`` 进行安装。
+
+还有一个make变量 ``SPHINXDIRS`` ，在测试构建某个文档子集时很有用。例如，您可
+以通过运行 ``make SPHINXDIRS=doc-guide htmldocs`` 构建
+``Documentation/doc-guide`` 下的文档。 ``make help`` 的文档部分会显示可指定的
+子目录列表。
要删除生成的文档，请运行 ``make cleandocs`` 。
+.. [#ink] 如果还安装了来自 Inkscape（https://inkscape.org）的 ``inkscape(1)`` ，
+ 则能够提升嵌入到PDF文档中的图像质量，尤其是在5.18及之后的内核版本中。
+
+.. _choice_of_math_renderer_zh:
+
+数学渲染器的选择
+----------------
+
+自内核 6.1 版本起， ``mathjax`` 可作为html输出中数学渲染器的后备方案。\ [#sph1_8_zh]_
+
+数学渲染器会根据可用命令按如下方式选择：
+
+.. table:: HTML 中数学渲染器的选择
+
+ ============ ================= ============
+ 数学渲染器 所需命令 图像格式
+ ============ ================= ============
+ imgmath latex, dvipng PNG（栅格）
+ mathjax
+ ============ ================= ============
+
+也可以通过设置环境变量 ``SPHINX_IMGMATH`` 来覆盖该选择，如下所示：
+
+.. table:: 设置 ``SPHINX_IMGMATH`` 的效果
+
+ ====================== ==========
+ 设置 渲染器
+ ====================== ==========
+ ``SPHINX_IMGMATH=yes`` imgmath
+ ``SPHINX_IMGMATH=no`` mathjax
+ ====================== ==========
+
+.. [#sph1_8_zh] 数学渲染器的后备机制要求Sphinx >= 1.8。
+
编写文档
========
@@ -187,7 +268,8 @@ Sphinx构建
~~~~~~~~
尽管RST没有规定具体的顺序（“没有强加一个固定数量和顺序的节标题装饰风格，最终
- 按照的顺序将是实际遇到的顺序。”），但是拥有一个通用级别的文档更容易遵循。
+ 按照的顺序将是实际遇到的顺序。”），但整体上让较高层级的标题样式保持一致，
+ 会更便于阅读和理解文档结构。
* 对于插入固定宽度的文本块（用于代码样例、用例等）： ``::`` 用于语法高亮意义不
大的内容，尤其是短代码段； ``.. code-block:: <language>`` 用于需要语法高亮的
@@ -218,15 +300,24 @@ C域
神奇力量，如果给定函数名的索引项存在，文档构建系统会自动将对 ``function()``
的引用转换为交叉引用。如果在内核文档中看到 ``c:func:`` 的用法，请删除它。
-
-列表
+表格
----
-我们建议使用 *列式表* 格式。 *列式表* 格式是二级列表。与ASCII艺术相比，它们对
-文本文件的读者来说可能没有那么舒适。但其优点是易于创建或修改，而且修改的差异
-（diff）更有意义，因为差异仅限于修改的内容。
+reStructuredText 为表格语法提供了多种选项。内核文档中的表格通常优先使用
+*simple table* 或 *grid table* 语法。更多细节请参阅
+`reStructuredText 用户参考中的表格语法`_ 。
+
+.. _reStructuredText 用户参考中的表格语法:
+ https://docutils.sourceforge.io/docs/user/rst/quickref.html#tables
-*平铺表* 也是一个二级列表，类似于 *列式表* ，但具有一些额外特性：
+列式表
+~~~~~~
+
+列式表（``list-table``）格式对于无法用常规Sphinx ASCII艺术格式轻松排版的表格来说
+可能很有用。然而，这种格式对于纯文本文档的读者来说几乎无法理解，因此，
+除非有充分的理由，否则应避免使用。
+
+``flat-table`` 也是一个二级列表，类似于 ``list-table`` ，但具有一些额外特性：
* 列范围：使用 ``cspan`` 修饰，可以通过其他列扩展单元格
@@ -302,15 +393,15 @@ C域
从一页文档到另一页文档的交叉引用可以通过简单地写出文件路径来完成，无特殊格式
要求。路径可以是绝对路径或相对路径。绝对路径从“Documentation/”开始。例如，要
-交叉引用此页，以下写法皆可，取决于具体的文档目录（注意 ``.rst`` 扩展名是可选
+交叉引用此页，以下写法皆可，取决于具体的文档目录（注意 ``.rst`` 扩展名是必需
的）::
参见 Documentation/doc-guide/sphinx.rst 。此法始终可用。
请查看 sphinx.rst ，仅在同级目录中有效。
请阅读 ../sphinx.rst ，上级目录中的文件。
-如果要使用相对路径，则需要使用Sphinx的 ``doc`` 修饰。例如，从同一目录引用此页
-的操作如下::
+如果希望链接显示的文本不同于文档标题，则需要使用 Sphinx 的 ``doc`` 修饰。例
+如::
参见 :doc:`sphinx文档的自定义链接文本 <sphinx>`.
@@ -318,7 +409,15 @@ C域
个没有任何特殊作用的 ``:doc:`` 用法，请将其转换为文档路径。
有关交叉引用kernel-doc函数或类型的信息，请参阅
-Documentation/doc-guide/kernel-doc.rst 。
+Documentation/translations/zh_CN/doc-guide/kernel-doc.rst 。
+
+引用提交
+~~~~~~~~
+
+对 git 提交的引用如果采用以下格式书写，会自动转换为超链接::
+
+ commit 72bf4f1767f0
+ commit 72bf4f1767f0 ("net: do not leave an empty skb in write queue")
.. _sphinx_kfigure_zh:
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply related
* [PATCH v2 1/2] docs/zh_CN: add process/changes.rst translation
From: Jiandong Qiu @ 2026-06-21 13:12 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260621131215.1303439-1-qiujiandong1998@gmail.com>
Add the zh_CN translation of process/changes.rst.
Update this translation through commit ece7e57afd51
("docs: changes.rst and ver_linux: sort the lists")
Assisted-by: Codex:GPT-5.4
Signed-off-by: Jiandong Qiu <qiujiandong1998@gmail.com>
---
.../translations/zh_CN/process/changes.rst | 528 ++++++++++++++++++
1 file changed, 528 insertions(+)
create mode 100644 Documentation/translations/zh_CN/process/changes.rst
diff --git a/Documentation/translations/zh_CN/process/changes.rst b/Documentation/translations/zh_CN/process/changes.rst
new file mode 100644
index 000000000000..62ec7f0e3533
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/changes.rst
@@ -0,0 +1,528 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/process/changes.rst
+
+:翻译: 裘剑东 Jiandong Qiu <qiujiandong1998@gmail.com>
+
+==================
+编译内核的最小需求
+==================
+
+引言
+====
+
+本文旨在给出运行当前内核版本所需的最低软件版本列表。
+
+本文最初基于 Linus 为 2.0.x 内核编写的 “Changes” 文件，因此也应将功劳归于
+与该文件相关的同一批人（Jared Mauch、Axel Boldt、Alessandro Sigala，
+以及互联网上无数其他用户）。
+
+当前最低需求
+------------
+
+在认为自己碰到了一个bug之前，请先至少升级到以下软件版本。
+如果你不确定当前运行的版本，建议使用右侧命令进行检查。
+若要列出系统中的程序及其版本，请执行 ``./scripts/ver_linux``
+
+再次提醒，本列表假定你已经能够正常运行一个Linux内核。另外，
+并非所有工具在所有系统上都是必需的；例如，如果你的机器没有任何
+PC Card硬件，那么大概无需关心 pcmciautils。
+
+====================== =============== ========================================
+ 程序 最低版本 版本检查命令
+====================== =============== ========================================
+bash 4.2 bash --version
+bc 1.06.95 bc --version
+bindgen（可选） 0.65.1 bindgen --version
+binutils 2.30 ld -v
+bison 2.0 bison --version
+btrfs-progs 0.18 btrfs --version
+Clang/LLVM（可选） 15.0.0 clang --version
+e2fsprogs 1.41.4 e2fsck -V
+flex 2.5.35 flex --version
+gdb 7.2 gdb --version
+GNU awk（可选） 5.1.0 gawk --version
+GNU C 8.1 gcc --version
+GNU make 4.0 make --version
+GNU tar 1.28 tar --version
+GRUB 0.93 grub --version || grub-install --version
+gtags（可选） 6.6.5 gtags --version
+iptables 1.4.2 iptables -V
+jfsutils 1.1.3 fsck.jfs -V
+kmod 13 kmod -V
+mcelog 0.6 mcelog --version
+mkimage（可选） 2017.01 mkimage --version
+nfs-utils 1.0.5 showmount --version
+openssl & libcrypto 1.0.0 openssl version
+pahole 1.22 pahole --version
+pcmciautils 004 pccardctl -V
+PPP 2.4.0 pppd --version
+procps 3.2.0 ps --version
+Python 3.9.x python3 --version
+quota-tools 3.09 quota -V
+Rust（可选） 1.78.0 rustc --version
+Sphinx\ [#f1]_ 3.4.3 sphinx-build --version
+squashfs-tools 4.0 mksquashfs -version
+udev 081 udevadm --version
+util-linux 2.10o mount --version
+xfsprogs 2.6.0 xfs_db -V
+====================== =============== ========================================
+
+.. [#f1] Sphinx 仅在构建内核文档时需要
+
+内核编译
+--------
+
+GCC
+~~~
+
+gcc 的版本要求可能会因你计算机中CPU的类型不同而有所变化。
+
+Clang/LLVM（可选）
+~~~~~~~~~~~~~~~~~~
+
+clang和LLVM工具的最新正式发行版（依据
+`releases.llvm.org <https://releases.llvm.org>`_）支持用于构建内核。
+较旧版本并不保证可用，我们也可能移除内核中为支持旧版而加入的兼容性处理。
+更多信息请参阅 Documentation/translations/zh_CN/kbuild/llvm.rst
+
+Rust（可选）
+~~~~~~~~~~~~
+
+需要较新的 Rust 编译器版本。
+
+关于如何满足 Rust 支持的构建需求，请参阅
+Documentation/translations/zh_CN/rust/quick-start.rst。其中，``Makefile`` 目标
+``rustavailable`` 可用于检查 Rust 工具链为何未被检测到。
+
+bindgen（可选）
+~~~~~~~~~~~~~~~
+
+``bindgen`` 用于为内核的 C 侧生成Rust绑定。它依赖 ``libclang``。
+
+Make
+~~~~
+
+要构建内核，你需要 GNU make 4.0 或更高版本。
+
+Bash
+~~~~
+
+内核构建会使用一些 bash 脚本。需要 Bash 4.2 或更新版本。
+
+Binutils
+~~~~~~~~
+
+构建内核需要 Binutils 2.30 或更新版本。
+
+pkg-config
+~~~~~~~~~~
+
+从 Linux 4.18 起，构建系统需要 pkg-config 来检查已安装的 kconfig 工具，并确定用于
+'make {g,x}config' 的标志设置。此前虽然已经在使用 pkg-config，
+但并未进行检查或文档说明。
+
+Flex
+~~~~
+
+自 Linux 4.16 起，构建系统会在构建过程中生成词法分析器。这需要
+flex 2.5.35 或更高版本。
+
+
+Bison
+~~~~~
+
+自 Linux 4.16 起，构建系统会在构建过程中生成语法解析器。这需要 bison 2.0
+或更高版本。
+
+pahole
+~~~~~~
+
+自 Linux 5.2 起，如果选择了 CONFIG_DEBUG_INFO_BTF，构建系统会从 vmlinux 中的
+DWARF 生成 BTF（BPF Type Format），稍后也会为内核模块生成。这需要 pahole
+v1.22 或更高版本。
+
+它可从发行版中的 'dwarves' 或 'pahole' 软件包获得，或从
+https://fedorapeople.org/~acme/dwarves/ 获取。
+
+Perl
+~~~~
+
+要构建内核，你需要 perl 5 以及以下模块：``Getopt::Long``、
+``Getopt::Std``、``File::Basename`` 和 ``File::Find``。
+
+Python
+~~~~~~
+
+若干配置选项需要它：例如 arm/arm64 默认配置、CONFIG_LTO_CLANG、某些
+DRM 可选配置、kernel-doc 工具以及文档构建（Sphinx）等。
+
+BC
+~~
+
+构建 3.10 及以上版本内核时需要 bc。
+
+
+OpenSSL
+~~~~~~~
+
+模块签名和外部证书处理使用OpenSSL程序及其加密库来创建密钥并生成签名。
+
+如果启用了模块签名，那么构建 3.7 及以上版本内核时需要 openssl。构建
+4.3 及以上版本内核时，还需要 openssl 的开发包。
+
+Tar
+~~~
+
+如果你想通过 sysfs 启用对内核头文件的访问（CONFIG_IKHEADERS），则需要 GNU tar。
+
+gtags / GNU GLOBAL（可选）
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+内核构建要求 GNU GLOBAL 版本 6.6.5 或更高，以便通过 ``make gtags``
+生成标签文件。这是因为它使用了 gtags 的 ``-C (--directory)`` 选项。
+
+mkimage
+~~~~~~~
+
+该工具用于构建 Flat Image Tree（FIT），常见于 ARM 平台。该工具可通过
+``u-boot-tools`` 软件包获得，也可以从 U-Boot 源码构建。详见
+https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
+
+GNU AWK
+~~~~~~~
+
+如果你希望内核构建为内建模块生成地址范围数据（CONFIG_BUILTIN_MODULE_RANGES），
+则需要GNU AWK。
+
+系统工具
+--------
+
+架构方面的变化
+~~~~~~~~~~~~~~
+
+DevFS 已被废弃，转而使用 udev
+（https://www.kernel.org/pub/linux/utils/kernel/hotplug/）
+
+现在已经支持 32 位 UID。尽情享用！
+
+Linux 中函数的文档正在转向以内联文档形式存在，即在源码定义附近使用特殊格式的
+注释。这些注释可以与 Documentation/ 目录中的 ReST 文件结合，生成更丰富的文档，
+随后可以再转换为 PostScript、HTML、LaTex、ePUB 和 PDF 文件。若要将 ReST
+格式转换为你所需的格式，需要Sphinx。
+
+Util-linux
+~~~~~~~~~~
+
+较新的 util-linux 版本为更大容量磁盘提供 ``fdisk`` 支持，支持更多的 mount 选项，
+识别更多分区类型，以及其他类似改进。你大概会想升级它。
+
+Ksymoops
+~~~~~~~~
+
+如果发生了最糟糕的情况，内核出现 oops，你可能需要 ksymoops 工具来解码它，
+但在大多数情况下并不需要。通常更推荐在构建内核时启用 ``CONFIG_KALLSYMS``，
+这样可以产生可直接使用的可读转储（而且输出比 ksymoops 更好）。
+如果由于某种原因你的内核不是以 ``CONFIG_KALLSYMS`` 构建的，
+并且你也没有办法重新构建并在启用该选项的情况下重新复现Oops，
+那么你仍然可以使用 ksymoops 对该 Oops 进行解码。
+
+Mkinitrd
+~~~~~~~~
+
+``/lib/modules`` 文件树布局的这些变化同样要求升级 mkinitrd。
+
+E2fsprogs
+~~~~~~~~~
+
+最新版 ``e2fsprogs`` 修复了 fsck 和 debugfs 中的若干bug。显然，升级它是个好主意。
+
+JFSutils
+~~~~~~~~
+
+``jfsutils`` 软件包包含该文件系统的工具。可用工具如下：
+
+ - ``fsck.jfs`` - 启动事务日志重放，并检查和修复 JFS 格式分区。
+ - ``mkfs.jfs`` - 创建 JFS 格式分区。
+ - 该软件包中还提供了其他文件系统工具。
+
+Xfsprogs
+~~~~~~~~
+
+最新版 ``xfsprogs`` 包含 ``mkfs.xfs``、``xfs_db`` 和 ``xfs_repair`` 等
+XFS文件系统工具。它与架构无关，2.0.0 及以上的任何版本都应能与当前版本的
+XFS内核代码正常配合使用（推荐 2.6.0 或更高版本，因为其包含一些重要改进）。
+
+PCMCIAutils
+~~~~~~~~~~~
+
+PCMCIAutils取代了 ``pcmcia-cs``。它会在系统启动时正确设置 PCMCIA插槽；
+如果内核采用模块化并使用了 hotplug 子系统，它还会为16位PCMCIA设备加载相应模块。
+
+Quota-tools
+~~~~~~~~~~~
+
+如果你想使用较新的 version 2 配额格式，就需要支持 32 位 uid 和 gid。
+Quota-tools 3.07 及更新版本提供了该支持。请使用上表中推荐版本或更新版本。
+
+Intel IA32 微码
+~~~~~~~~~~~~~~~
+
+新增了一个驱动，可用于更新 Intel IA32 微码，并以普通（misc）
+字符设备的形式提供访问。如果你没有使用udev，则在使用前可能需要以root身份执行::
+
+ mkdir /dev/cpu
+ mknod /dev/cpu/microcode c 10 184
+ chmod 0644 /dev/cpu/microcode
+
+你可能还会希望获取用户空间的 microcode_ctl 工具来配合使用。
+
+udev
+~~~~
+
+``udev`` 是一个用户空间程序，用于动态填充 ``/dev``，
+仅为实际存在的设备创建设备节点。``udev`` 替代了 devfs 的基本功能，
+同时允许为设备提供持久化命名。
+
+FUSE
+~~~~
+
+需要 libfuse 2.4.0 或更高版本。绝对最低要求是 2.3.0，但 mount 选项
+``direct_io`` 和 ``kernel_cache`` 将无法工作。
+
+网络
+----
+
+通用变化
+~~~~~~~~
+
+如果你有较复杂的网络配置需求，应该考虑使用 ip-route2 中的网络工具。
+
+包过滤 / NAT
+~~~~~~~~~~~~
+
+数据包过滤和 NAT 代码使用的工具与此前的 2.4.x 内核系列相同（iptables）。
+它仍然包含与 2.2.x 风格 ipchains 以及 2.0.x 风格ipfwadm 的向后兼容模块。
+
+PPP
+~~~
+
+PPP 驱动已经过重构，以支持 multilink 并使其能够运行在多种介质层之上。如
+果你使用 PPP，请将 pppd 至少升级到2.4.0。
+
+如果你没有使用 udev，则必须拥有设备文件 /dev/ppp，可以通过以下命令创建::
+
+ mknod /dev/ppp c 108 0
+
+需要以 root 身份执行。
+
+NFS-utils
+~~~~~~~~~
+
+在很早期的内核（2.4 及更早版本）中，nfs 服务器需要知道哪些客户端希望通
+过 NFS 访问文件。这些信息会在客户端挂载文件系统时由 ``mountd`` 提供
+给内核，或者在系统启动时由 ``exportfs`` 提供。exportfs 会从
+``/var/lib/nfs/rmtab`` 中获取活跃客户端信息。
+
+这种方法相当脆弱，因为它依赖于 rmtab 的正确性，而这并不总是容易保证，
+尤其是在尝试实现故障切换时。即便系统运行正常，``rmtab``
+也会积累大量从未被移除的旧条目。
+
+在现代内核中，我们可以选择让内核在收到未知主机请求时通知 mountd，
+再由 mountd 将合适的导出信息提供给内核。这样就不再依赖 ``rmtab``，
+并且内核只需要知道当前活跃的客户端。
+
+要启用这一新功能，你需要在运行 exportfs 或 mountd 之前执行::
+
+ mount -t nfsd nfsd /proc/fs/nfsd
+
+建议尽可能使用防火墙将所有NFS服务与公共互联网隔离。
+
+mcelog
+~~~~~~
+
+在x86内核上，如果启用了 ``CONFIG_X86_MCE``，则需要 mcelog 工具来处理和
+记录机器检查事件。机器检查事件是CPU报告的错误，强烈建议对其进行处理。
+
+内核文档
+--------
+
+Sphinx
+~~~~~~
+
+关于Sphinx需求的详细信息，请参阅
+Documentation/translations/zh_CN/doc-guide/sphinx.rst 中的 :ref:`sphinx_install_zh`。
+
+rustdoc
+~~~~~~~
+
+``rustdoc`` 用于为 Rust 代码生成文档。更多信息请参阅
+Documentation/translations/zh_CN/rust/general-information.rst。
+
+获取更新的软件
+==============
+
+内核编译
+--------
+
+gcc
+~~~
+
+- <ftp://ftp.gnu.org/gnu/gcc/>
+
+Clang/LLVM
+~~~~~~~~~~
+
+- :ref:`获取 LLVM <zh_cn_getting_llvm>`。
+
+Rust
+~~~~
+
+- Documentation/rust/quick-start.rst。
+
+bindgen
+~~~~~~~
+
+- Documentation/rust/quick-start.rst。
+
+Make
+~~~~
+
+- <ftp://ftp.gnu.org/gnu/make/>
+
+Bash
+~~~~
+
+- <ftp://ftp.gnu.org/gnu/bash/>
+
+Binutils
+~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/devel/binutils/>
+
+Flex
+~~~~
+
+- <https://github.com/westes/flex/releases>
+
+Bison
+~~~~~
+
+- <ftp://ftp.gnu.org/gnu/bison/>
+
+OpenSSL
+~~~~~~~
+
+- <https://www.openssl.org/>
+
+系统工具
+--------
+
+Util-linux
+~~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/util-linux/>
+
+Kmod
+~~~~
+
+- <https://www.kernel.org/pub/linux/utils/kernel/kmod/>
+- <https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git>
+
+Ksymoops
+~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/>
+
+Mkinitrd
+~~~~~~~~
+
+- <https://code.launchpad.net/initrd-tools/main>
+
+E2fsprogs
+~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/>
+- <https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/>
+
+JFSutils
+~~~~~~~~
+
+- <https://jfs.sourceforge.net/>
+
+Xfsprogs
+~~~~~~~~
+
+- <https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git>
+- <https://www.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/>
+
+Pcmciautils
+~~~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/kernel/pcmcia/>
+
+Quota-tools
+~~~~~~~~~~~
+
+- <https://sourceforge.net/projects/linuxquota/>
+
+
+Intel P6 微码
+~~~~~~~~~~~~~
+
+- <https://downloadcenter.intel.com/>
+
+udev
+~~~~
+
+- <https://www.freedesktop.org/software/systemd/man/udev.html>
+
+FUSE
+~~~~
+
+- <https://github.com/libfuse/libfuse/releases>
+
+mcelog
+~~~~~~
+
+- <https://www.mcelog.org/>
+
+网络
+----
+
+PPP
+~~~
+
+- <https://download.samba.org/pub/ppp/>
+- <https://git.ozlabs.org/?p=ppp.git>
+- <https://github.com/paulusmack/ppp/>
+
+NFS-utils
+~~~~~~~~~
+
+- <https://sourceforge.net/project/showfiles.php?group_id=14>
+- <https://nfs.sourceforge.net/>
+
+Iptables
+~~~~~~~~
+
+- <https://netfilter.org/projects/iptables/index.html>
+
+Ip-route2
+~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/net/iproute2/>
+
+OProfile
+~~~~~~~~
+
+- <https://oprofile.sf.net/download/>
+
+内核文档
+--------
+
+Sphinx
+~~~~~~
+
+- <https://www.sphinx-doc.org/>
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply related
* [PATCH v2 0/2] docs/zh_CN: update translations for process/changes.rst and sphinx.rst
From: Jiandong Qiu @ 2026-06-21 13:12 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
Hi all,
This series refreshes the translation of doc-guide/sphinx.rst, I noticed
that it refers to process/changes.rst, which did not yet have a zh_CN
translation, so I added one as well.
Changes in v2:
Link: https://lore.kernel.org/linux-doc/20260619140245.1982921-1-qiujiandong1998@gmail.com/
- drop the separate llvm.rst anchor patch
- remove the `_sphinxdoc_zh` anchor from .../zh_CN/doc-guide/sphinx.rst
- add Assisted-by tags
Jiandong Qiu (2):
docs/zh_CN: add process/changes.rst translation
docs/zh_CN: update sphinx.rst translation
.../translations/zh_CN/doc-guide/sphinx.rst | 167 ++++--
.../translations/zh_CN/process/changes.rst | 528 ++++++++++++++++++
2 files changed, 661 insertions(+), 34 deletions(-)
create mode 100644 Documentation/translations/zh_CN/process/changes.rst
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Move non-trace_printk prototypes back to kernel.h
From: Yury Norov @ 2026-06-21 13:08 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621093811.007634476@kernel.org>
On Sun, Jun 21, 2026 at 05:34:31AM -0400, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> In order to remove the include to trace_printk.h from kernel.h the tracing
> control prototypes need to be moved back into kernel.h. That's because
Please don't. Instead, you can split them out to trace_control.h, and
include where needed. I actually have a prototype for it, FYI:
https://github.com/norov/linux/tree/trace_pritk3
> they are used in other common header files like rcu.h. There's no point in
> removing trace_printk.h from kernel.h if it just gets added back to other
> common headers.
>
> Prototypes are very cheap for the compiler and should not be an issue.
It's not about cost, it's about mess. kernel.h is included everywhere.
Is that API needed everywhere? No, it's needed in literally 10 files.
So, no place in kernel.h.
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> include/linux/kernel.h | 18 ++++++++++++++++++
> include/linux/trace_printk.h | 17 -----------------
> 2 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e5570a16cbb1..c3c68128827c 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -194,4 +194,22 @@ extern enum system_states system_state;
> # define REBUILD_DUE_TO_DYNAMIC_FTRACE
> #endif
>
> +#ifdef CONFIG_TRACING
> +void tracing_on(void);
> +void tracing_off(void);
> +int tracing_is_on(void);
> +void tracing_snapshot(void);
> +void tracing_snapshot_alloc(void);
> +void tracing_start(void);
> +void tracing_stop(void);
> +#else
> +static inline void tracing_start(void) { }
> +static inline void tracing_stop(void) { }
> +static inline void tracing_on(void) { }
> +static inline void tracing_off(void) { }
> +static inline int tracing_is_on(void) { return 0; }
> +static inline void tracing_snapshot(void) { }
> +static inline void tracing_snapshot_alloc(void) { }
> +#endif
> +
> #endif
> diff --git a/include/linux/trace_printk.h b/include/linux/trace_printk.h
> index 3d54f440dccf..879fed0805fd 100644
> --- a/include/linux/trace_printk.h
> +++ b/include/linux/trace_printk.h
> @@ -35,15 +35,6 @@ enum ftrace_dump_mode {
> };
>
> #ifdef CONFIG_TRACING
> -void tracing_on(void);
> -void tracing_off(void);
> -int tracing_is_on(void);
> -void tracing_snapshot(void);
> -void tracing_snapshot_alloc(void);
> -
> -extern void tracing_start(void);
> -extern void tracing_stop(void);
> -
> static inline __printf(1, 2)
> void ____trace_printk_check_format(const char *fmt, ...)
> {
> @@ -176,16 +167,8 @@ __ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
>
> extern void ftrace_dump(enum ftrace_dump_mode oops_dump_mode);
> #else
> -static inline void tracing_start(void) { }
> -static inline void tracing_stop(void) { }
> static inline void trace_dump_stack(int skip) { }
>
> -static inline void tracing_on(void) { }
> -static inline void tracing_off(void) { }
> -static inline int tracing_is_on(void) { return 0; }
> -static inline void tracing_snapshot(void) { }
> -static inline void tracing_snapshot_alloc(void) { }
> -
> static inline __printf(1, 2)
> int trace_printk(const char *fmt, ...)
> {
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 13:03 UTC (permalink / raw)
To: David Laight
Cc: Thomas Gleixner, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621135531.243375d9@pumpkin>
On Sun, 21 Jun 2026 13:55:31 +0100
David Laight <david.laight.linux@gmail.com> wrote:
> Indeed...
> Isn't trace_printk() just an extern?
> Having it defined somewhere isn't going to make any difference to build times.
No it is not. It is a macro to cut as many nanoseconds as possible as
trace_printk() was created to debug tight race conditions and any added
latency can make the race go away.
-- Steve
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: David Laight @ 2026-06-21 12:55 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Steven Rostedt, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <87ik7cmcb7.ffs@fw13>
On Sun, 21 Jun 2026 12:13:00 +0200
Thomas Gleixner <tglx@kernel.org> wrote:
> On Sun, Jun 21 2026 at 05:34, Steven Rostedt wrote:
> > Instead of having trace_printk.h included in kernel.h, create a config
> > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> > Makefile to allow developers to add trace_printk() without the need to add
> > the include for it. Having it included in the Makefile keeps it from being
> > in the dependency chain and it will not waste extra CPU cycles for those
> > building the kernel without using trace_printk.
>
> IOW, you make it worse just because.
>
> With the header being separate I add the three trace_printk()s and the
> include to the source file I'm investigating. The recompile will build
> exactly this source file.
>
> Having to enable the config knob will result in a full kernel rebuild
> for no value.
Indeed...
Isn't trace_printk() just an extern?
Having it defined somewhere isn't going to make any difference to build times.
David
>
> Seriously?
>
> Thanks,
>
> tglx
>
>
>
^ permalink raw reply
* Re: [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Thomas Gleixner @ 2026-06-21 10:59 UTC (permalink / raw)
To: Marek Vasut, linux-pci
Cc: Marek Vasut, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-4-marek.vasut+renesas@mailbox.org>
On Fri, Jun 19 2026 at 00:02, Marek Vasut wrote:
> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> or APB interface configured to 32 bit, it can therefore access only
> the first 4 GiB of physical address space. This information comes from
> R-Car V4H Interface Specification sheet, there is currently no technical
> update number assigned to this limitation. Further input from hardware
> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> limitation.
>
> The quirk is keyed on the combination of the GIC implementation
> and the platform identification in the device tree.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This SOB chain is broken.
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 10:38 UTC (permalink / raw)
To: Thomas Gleixner, Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <87ik7cmcb7.ffs@fw13>
On June 21, 2026 11:13:00 AM GMT+01:00, Thomas Gleixner <tglx@kernel.org> wrote:
>On Sun, Jun 21 2026 at 05:34, Steven Rostedt wrote:
>> Instead of having trace_printk.h included in kernel.h, create a config
>> TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
>> Makefile to allow developers to add trace_printk() without the need to add
>> the include for it. Having it included in the Makefile keeps it from being
>> in the dependency chain and it will not waste extra CPU cycles for those
>> building the kernel without using trace_printk.
>
>IOW, you make it worse just because.
>
>With the header being separate I add the three trace_printk()s and the
>include to the source file I'm investigating. The recompile will build
>exactly this source file.
>
>Having to enable the config knob will result in a full kernel rebuild
>for no value.
>
>Seriously?
Like having lockdep enabled, this would always be set in the development environment. It's not something to only enable when you need to add a trace_printk. If you don't want to rebuild everything, by all means add the include file by file. There's nothing preventing you to do that with this solution.
-- Steve
P.S. I'm replying on my phone as I'm in the London Tube. Thus why I'm not trimming my email.
>
>Thanks,
>
> tglx
>
^ permalink raw reply
* Re: [RFC v2 PATCH] reserve_mem: add support for static memory
From: Mike Rapoport @ 2026-06-21 10:36 UTC (permalink / raw)
To: Shyam Saini
Cc: linux-mm, linux-doc, linux-kernel, akpm, tgopinath, bboscaccy,
kees, tony.luck, gpiccoli, bp, rdunlap, peterz, feng.tang,
dapeng1.mi, elver, enelsonmoore, kuba, lirongqing, ebiggers
In-Reply-To: <20260619062331.348789-1-shyamsaini@linux.microsoft.com>
On Thu, Jun 18, 2026 at 11:23:31PM -0700, Shyam Saini wrote:
> reserve_mem relies on dynamic memory allocation, this limits the
> usecase where memory is required to be preserved across the boots.
> Eg: ramoops memory reservation on ACPI platforms
>
> So add support to pass a pre-determined static address and reserve
> memory at a specified location. This enables use case like ramoops
> on ACPI platforms to reliably access ramoops region with previous
> boot logs.
>
> Also skip the parsing of <align> when static address is passed.
>
> Example syntax for static address
> reserve_mem=4M@0x1E0000000:oops
reserve_mem is best effort by design because such hacks as well as memmap=
cannot guarantee this memory is actually free.
If you want to preserve ramoops reliably, use KHO with reserve_mem.
The first kernel will allocate memory, this memory will be preserved by KHO
and could be picked up by the second kernel.
> Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> ---
> v1: https://lore.kernel.org/lkml/0eaf3be2-5121-48b7-aeed-196405c0a480@infradead.org/
> v2: Fix code logic and incorporate Randy's suggestion
> ---
> .../admin-guide/kernel-parameters.txt | 15 ++++++
> mm/memblock.c | 47 +++++++++++++------
> 2 files changed, 47 insertions(+), 15 deletions(-)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Thomas Gleixner @ 2026-06-21 10:13 UTC (permalink / raw)
To: Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621093811.168514984@kernel.org>
On Sun, Jun 21 2026 at 05:34, Steven Rostedt wrote:
> Instead of having trace_printk.h included in kernel.h, create a config
> TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> Makefile to allow developers to add trace_printk() without the need to add
> the include for it. Having it included in the Makefile keeps it from being
> in the dependency chain and it will not waste extra CPU cycles for those
> building the kernel without using trace_printk.
IOW, you make it worse just because.
With the header being separate I add the three trace_printk()s and the
include to the source file I'm investigating. The recompile will build
exactly this source file.
Having to enable the config knob will result in a full kernel rebuild
for no value.
Seriously?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 9:47 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov,
linux-doc, linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <20260621093811.168514984@kernel.org>
On Sun, 21 Jun 2026 05:34:32 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> Instead of having trace_printk.h included in kernel.h, create a config
> TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> Makefile to allow developers to add trace_printk() without the need to add
> the include for it. Having it included in the Makefile keeps it from being
> in the dependency chain and it will not waste extra CPU cycles for those
> building the kernel without using trace_printk.
Bah, I only tested with the config option enabled, and missed some
dependencies with it disabled.
For instance, rcu.h also uses ftrace_dump() so that too needs to go
into kernel.h. I also need to add a few more includes to trace_printk.h.
OK, I need to run this through all my tests to find where else I missed
adding the includes. But the idea should hopefully satisfy everyone.
-- Steve
^ permalink raw reply
* [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 9:34 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov,
linux-doc, linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <20260621093430.264983361@kernel.org>
From: Steven Rostedt <rostedt@goodmis.org>
Instead of having trace_printk.h included in kernel.h, create a config
TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
Makefile to allow developers to add trace_printk() without the need to add
the include for it. Having it included in the Makefile keeps it from being
in the dependency chain and it will not waste extra CPU cycles for those
building the kernel without using trace_printk.
Link: https://lore.kernel.org/all/CAHk-=wikCBeVFjVXiY4o-oepdbjAoir5+TcAgtL12c4u1TpZLQ@mail.gmail.com/
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
.../debugging/driver_development_debugging_guide.rst | 2 +-
Makefile | 5 +++++
arch/powerpc/kvm/book3s_xics.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
drivers/gpu/drm/i915/i915_gem.h | 1 +
drivers/hwtracing/stm/dummy_stm.c | 4 ++++
drivers/infiniband/hw/hfi1/trace_dbg.h | 1 +
drivers/usb/early/xhci-dbc.c | 1 +
fs/ext4/inline.c | 1 +
include/linux/kernel.h | 1 -
include/linux/sunrpc/debug.h | 1 +
include/linux/trace_printk.h | 5 +++--
kernel/trace/Kconfig | 10 ++++++++++
kernel/trace/ring_buffer_benchmark.c | 1 +
kernel/trace/trace.h | 1 +
samples/fprobe/fprobe_example.c | 1 +
samples/ftrace/ftrace-direct-modify.c | 1 +
samples/ftrace/ftrace-direct-multi-modify.c | 1 +
samples/ftrace/ftrace-direct-multi.c | 2 +-
samples/ftrace/ftrace-direct-too.c | 2 +-
samples/ftrace/ftrace-direct.c | 2 +-
21 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/Documentation/process/debugging/driver_development_debugging_guide.rst b/Documentation/process/debugging/driver_development_debugging_guide.rst
index aca08f457793..3c87aa03622f 100644
--- a/Documentation/process/debugging/driver_development_debugging_guide.rst
+++ b/Documentation/process/debugging/driver_development_debugging_guide.rst
@@ -52,7 +52,7 @@ For the full documentation see :doc:`/core-api/printk-basics`
Trace_printk
~~~~~~~~~~~~
-Prerequisite: ``CONFIG_DYNAMIC_FTRACE`` & ``#include <linux/ftrace.h>``
+Prerequisite: ``CONFIG_TRACE_PRINTK_DEBUGGING``
It is a tiny bit less comfortable to use than printk(), because you will have
to read the messages from the trace file (See: :ref:`read_ftrace_log`
diff --git a/Makefile b/Makefile
index d1c595db55c9..2f5923d5393b 100644
--- a/Makefile
+++ b/Makefile
@@ -840,6 +840,11 @@ ifdef CONFIG_FUNCTION_TRACER
CC_FLAGS_FTRACE := -pg
endif
+ifdef CONFIG_TRACE_PRINTK_DEBUGGING
+ # Allow trace_printk() to be used anywhere without including the header.
+ LINUXINCLUDE += -include $(srctree)/include/linux/trace_printk.h
+endif
+
ifdef CONFIG_TRACEPOINTS
# To check for unused tracepoints (tracepoints that are defined but never
# called), run with:
diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c
index 74a44fa702b0..ef5eb596a56e 100644
--- a/arch/powerpc/kvm/book3s_xics.c
+++ b/arch/powerpc/kvm/book3s_xics.c
@@ -26,6 +26,7 @@
#if 1
#define XICS_DBG(fmt...) do { } while (0)
#else
+#include <linux/trace_printk.h>
#define XICS_DBG(fmt...) trace_printk(fmt)
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index b54ee4f25af1..f6f223090760 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -35,6 +35,7 @@
#define I915_GFP_ALLOW_FAIL (GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN)
#if IS_ENABLED(CONFIG_DRM_I915_TRACE_GTT)
+#include <linux/trace_printk.h>
#define GTT_TRACE(...) trace_printk(__VA_ARGS__)
#else
#define GTT_TRACE(...)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 20b3cb29cfff..5cab1836dc1d 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -116,6 +116,7 @@ int i915_gem_open(struct drm_i915_private *i915, struct drm_file *file);
#endif
#if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
+#include <linux/trace_printk.h>
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
#define GEM_TRACE_ERR(...) do { \
pr_err(__VA_ARGS__); \
diff --git a/drivers/hwtracing/stm/dummy_stm.c b/drivers/hwtracing/stm/dummy_stm.c
index 38528ffdc0b3..784f9af7ccba 100644
--- a/drivers/hwtracing/stm/dummy_stm.c
+++ b/drivers/hwtracing/stm/dummy_stm.c
@@ -14,6 +14,10 @@
#include <linux/stm.h>
#include <uapi/linux/stm.h>
+#ifdef DEBUG
+#include <linux/trace_printk.h>
+#endif
+
static ssize_t notrace
dummy_stm_packet(struct stm_data *stm_data, unsigned int master,
unsigned int channel, unsigned int packet, unsigned int flags,
diff --git a/drivers/infiniband/hw/hfi1/trace_dbg.h b/drivers/infiniband/hw/hfi1/trace_dbg.h
index 58304b91380f..30df5e246586 100644
--- a/drivers/infiniband/hw/hfi1/trace_dbg.h
+++ b/drivers/infiniband/hw/hfi1/trace_dbg.h
@@ -103,6 +103,7 @@ __hfi1_trace_def(IOCTL);
*/
#ifdef HFI1_EARLY_DBG
+#include <linux/trace_printk.h>
#define hfi1_dbg_early(fmt, ...) \
trace_printk(fmt, ##__VA_ARGS__)
#else
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 41118bba9197..955c73bd601f 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -30,6 +30,7 @@ static struct xdbc_state xdbc;
static bool early_console_keep;
#ifdef XDBC_TRACE
+#include <linux/trace_printk.h>
#define xdbc_trace trace_printk
#else
static inline void xdbc_trace(const char *fmt, ...) { }
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 8045e4ff270c..0eff4a0c6a6c 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -934,6 +934,7 @@ static int ext4_da_convert_inline_data_to_extent(struct address_space *mapping,
}
#ifdef INLINE_DIR_DEBUG
+#include <linux/trace_printk.h>
void ext4_show_inline_dir(struct inode *dir, struct buffer_head *bh,
void *inline_start, int inline_size)
{
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index c3c68128827c..538655385089 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -31,7 +31,6 @@
#include <linux/build_bug.h>
#include <linux/sprintf.h>
#include <linux/static_call_types.h>
-#include <linux/trace_printk.h>
#include <linux/util_macros.h>
#include <linux/wordpart.h>
diff --git a/include/linux/sunrpc/debug.h b/include/linux/sunrpc/debug.h
index ab61bed2f7af..7524f5d82fba 100644
--- a/include/linux/sunrpc/debug.h
+++ b/include/linux/sunrpc/debug.h
@@ -29,6 +29,7 @@ extern unsigned int nlm_debug;
# define ifdebug(fac) if (unlikely(rpc_debug & RPCDBG_##fac))
# if IS_ENABLED(CONFIG_SUNRPC_DEBUG_TRACE)
+# include <linux/trace_printk.h>
# define __sunrpc_printk(fmt, ...) trace_printk(fmt, ##__VA_ARGS__)
# else
# define __sunrpc_printk(fmt, ...) printk(KERN_DEFAULT fmt, ##__VA_ARGS__)
diff --git a/include/linux/trace_printk.h b/include/linux/trace_printk.h
index 879fed0805fd..66edec6d5dbf 100644
--- a/include/linux/trace_printk.h
+++ b/include/linux/trace_printk.h
@@ -1,11 +1,12 @@
/* SPDX-License-Identifier: GPL-2.0 */
#ifndef _LINUX_TRACE_PRINTK_H
#define _LINUX_TRACE_PRINTK_H
+#if !defined(__ASSEMBLY__) && !defined(__GENKSYMS__) && !defined(BUILD_VDSO)
-#include <linux/compiler_attributes.h>
#include <linux/instruction_pointer.h>
#include <linux/stddef.h>
#include <linux/stringify.h>
+#include <linux/stdarg.h>
/*
* General tracing related utility functions - trace_printk(),
@@ -181,5 +182,5 @@ ftrace_vprintk(const char *fmt, va_list ap)
}
static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
#endif /* CONFIG_TRACING */
-
+#endif /* !defined(__ASSEMBLY__) && !defined(__GENKSYMS__) */
#endif
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 084f34dc6c9f..ffbd1b0ce66e 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -210,6 +210,16 @@ menuconfig FTRACE
if FTRACE
+config TRACE_PRINTK_DEBUGGING
+ bool "Debug with trace_printk()"
+ help
+ If you need to debug with trace_printk(), instead of adding
+ include <linux/trace_printk.h> to every file you add a trace_printk
+ to, select this option and it will add trace_printk.h to all code
+ to allow tracing with trace_printk() with.
+
+ If in doubt, select N
+
config TRACEFS_AUTOMOUNT_DEPRECATED
bool "Automount tracefs on debugfs [DEPRECATED]"
depends on TRACING
diff --git a/kernel/trace/ring_buffer_benchmark.c b/kernel/trace/ring_buffer_benchmark.c
index 593e3b59e42e..2bb25caebb75 100644
--- a/kernel/trace/ring_buffer_benchmark.c
+++ b/kernel/trace/ring_buffer_benchmark.c
@@ -5,6 +5,7 @@
* Copyright (C) 2009 Steven Rostedt <srostedt@redhat.com>
*/
#include <linux/ring_buffer.h>
+#include <linux/trace_printk.h>
#include <linux/completion.h>
#include <linux/kthread.h>
#include <uapi/linux/sched/types.h>
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 80fe152af1dd..580a3deab1e9 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -13,6 +13,7 @@
#include <linux/ftrace.h>
#include <linux/trace.h>
#include <linux/hw_breakpoint.h>
+#include <linux/trace_printk.h>
#include <linux/trace_seq.h>
#include <linux/trace_events.h>
#include <linux/compiler.h>
diff --git a/samples/fprobe/fprobe_example.c b/samples/fprobe/fprobe_example.c
index bfe98ce826f3..de81b9b4ca7d 100644
--- a/samples/fprobe/fprobe_example.c
+++ b/samples/fprobe/fprobe_example.c
@@ -12,6 +12,7 @@
#define pr_fmt(fmt) "%s: " fmt, __func__
+#include <linux/trace_printk.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/fprobe.h>
diff --git a/samples/ftrace/ftrace-direct-modify.c b/samples/ftrace/ftrace-direct-modify.c
index 1ba1927b548e..30d0f8e644c8 100644
--- a/samples/ftrace/ftrace-direct-modify.c
+++ b/samples/ftrace/ftrace-direct-modify.c
@@ -1,4 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/trace_printk.h>
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/ftrace.h>
diff --git a/samples/ftrace/ftrace-direct-multi-modify.c b/samples/ftrace/ftrace-direct-multi-modify.c
index 7a7822dfeb50..f64b929e19ec 100644
--- a/samples/ftrace/ftrace-direct-multi-modify.c
+++ b/samples/ftrace/ftrace-direct-multi-modify.c
@@ -1,4 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/trace_printk.h>
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/ftrace.h>
diff --git a/samples/ftrace/ftrace-direct-multi.c b/samples/ftrace/ftrace-direct-multi.c
index 3fe6ddaf0b69..d32644a49554 100644
--- a/samples/ftrace/ftrace-direct-multi.c
+++ b/samples/ftrace/ftrace-direct-multi.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/trace_printk.h>
#include <linux/module.h>
-
#include <linux/mm.h> /* for handle_mm_fault() */
#include <linux/ftrace.h>
#include <linux/sched/stat.h>
diff --git a/samples/ftrace/ftrace-direct-too.c b/samples/ftrace/ftrace-direct-too.c
index bf2411aa6fd7..266fcb233301 100644
--- a/samples/ftrace/ftrace-direct-too.c
+++ b/samples/ftrace/ftrace-direct-too.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/trace_printk.h>
#include <linux/module.h>
-
#include <linux/mm.h> /* for handle_mm_fault() */
#include <linux/ftrace.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
diff --git a/samples/ftrace/ftrace-direct.c b/samples/ftrace/ftrace-direct.c
index 5368c8c39cbb..85e0dff9b691 100644
--- a/samples/ftrace/ftrace-direct.c
+++ b/samples/ftrace/ftrace-direct.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/trace_printk.h>
#include <linux/module.h>
-
#include <linux/sched.h> /* for wake_up_process() */
#include <linux/ftrace.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] tracing: Move non-trace_printk prototypes back to kernel.h
From: Steven Rostedt @ 2026-06-21 9:34 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov,
linux-doc, linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <20260621093430.264983361@kernel.org>
From: Steven Rostedt <rostedt@goodmis.org>
In order to remove the include to trace_printk.h from kernel.h the tracing
control prototypes need to be moved back into kernel.h. That's because
they are used in other common header files like rcu.h. There's no point in
removing trace_printk.h from kernel.h if it just gets added back to other
common headers.
Prototypes are very cheap for the compiler and should not be an issue.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
include/linux/kernel.h | 18 ++++++++++++++++++
include/linux/trace_printk.h | 17 -----------------
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index e5570a16cbb1..c3c68128827c 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -194,4 +194,22 @@ extern enum system_states system_state;
# define REBUILD_DUE_TO_DYNAMIC_FTRACE
#endif
+#ifdef CONFIG_TRACING
+void tracing_on(void);
+void tracing_off(void);
+int tracing_is_on(void);
+void tracing_snapshot(void);
+void tracing_snapshot_alloc(void);
+void tracing_start(void);
+void tracing_stop(void);
+#else
+static inline void tracing_start(void) { }
+static inline void tracing_stop(void) { }
+static inline void tracing_on(void) { }
+static inline void tracing_off(void) { }
+static inline int tracing_is_on(void) { return 0; }
+static inline void tracing_snapshot(void) { }
+static inline void tracing_snapshot_alloc(void) { }
+#endif
+
#endif
diff --git a/include/linux/trace_printk.h b/include/linux/trace_printk.h
index 3d54f440dccf..879fed0805fd 100644
--- a/include/linux/trace_printk.h
+++ b/include/linux/trace_printk.h
@@ -35,15 +35,6 @@ enum ftrace_dump_mode {
};
#ifdef CONFIG_TRACING
-void tracing_on(void);
-void tracing_off(void);
-int tracing_is_on(void);
-void tracing_snapshot(void);
-void tracing_snapshot_alloc(void);
-
-extern void tracing_start(void);
-extern void tracing_stop(void);
-
static inline __printf(1, 2)
void ____trace_printk_check_format(const char *fmt, ...)
{
@@ -176,16 +167,8 @@ __ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
extern void ftrace_dump(enum ftrace_dump_mode oops_dump_mode);
#else
-static inline void tracing_start(void) { }
-static inline void tracing_stop(void) { }
static inline void trace_dump_stack(int skip) { }
-static inline void tracing_on(void) { }
-static inline void tracing_off(void) { }
-static inline int tracing_is_on(void) { return 0; }
-static inline void tracing_snapshot(void) { }
-static inline void tracing_snapshot_alloc(void) { }
-
static inline __printf(1, 2)
int trace_printk(const char *fmt, ...)
{
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Steven Rostedt @ 2026-06-21 9:34 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov,
linux-doc, linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
There's been complaints about trace_printk() being defined in kernel.h as it
can increase the compilation time. As it is only used by some developers for
debugging purposes, it should not be in kernel.h causing lots of wasted CPU
cycles for those that do not ever care about it.
Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do
use it can set and not have to always remember to add #include <linux/trace_printk.h>
to the files they add trace_printk() while debugging. It also means that
those that do not have that config set will not have to worry about wasted
CPU cycles as it is only include in the CFLAGS when the option is set, and
its completely ignored otherwise.
Steven Rostedt (2):
tracing: Move non-trace_printk prototypes back to kernel.h
tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
----
.../driver_development_debugging_guide.rst | 2 +-
Makefile | 5 +++++
arch/powerpc/kvm/book3s_xics.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
drivers/gpu/drm/i915/i915_gem.h | 1 +
drivers/hwtracing/stm/dummy_stm.c | 4 ++++
drivers/infiniband/hw/hfi1/trace_dbg.h | 1 +
drivers/usb/early/xhci-dbc.c | 1 +
fs/ext4/inline.c | 1 +
include/linux/kernel.h | 19 ++++++++++++++++++-
include/linux/sunrpc/debug.h | 1 +
include/linux/trace_printk.h | 22 +++-------------------
kernel/trace/Kconfig | 10 ++++++++++
kernel/trace/ring_buffer_benchmark.c | 1 +
kernel/trace/trace.h | 1 +
samples/fprobe/fprobe_example.c | 1 +
samples/ftrace/ftrace-direct-modify.c | 1 +
samples/ftrace/ftrace-direct-multi-modify.c | 1 +
samples/ftrace/ftrace-direct-multi.c | 2 +-
samples/ftrace/ftrace-direct-too.c | 2 +-
samples/ftrace/ftrace-direct.c | 2 +-
21 files changed, 56 insertions(+), 24 deletions(-)
^ permalink raw reply
* Re: [PATCH] Documentation: admin-guide: pm: cpufreq: fix sampling_rate example command
From: Zhongqiu Han @ 2026-06-21 5:57 UTC (permalink / raw)
To: Randy Dunlap, wangxiaodong, rafael, viresh.kumar
Cc: corbet, skhan, linux-pm, linux-doc, linux-kernel, zhongqiu.han
In-Reply-To: <10a04e7d-31b4-4c51-bf68-298f517fbab6@infradead.org>
On 6/21/2026 11:52 AM, Randy Dunlap wrote:
>
>
> On 6/20/26 7:25 PM, wangxiaodong wrote:
>> The example shell command for setting ondemand's sampling_rate wraps an
>> arithmetic expansion $((...)) in command-substitution backticks. The
>> arithmetic result is then executed as a command, which fails and writes
>> an empty value. Drop the surrounding backticks so the computed value is
>> passed to echo as intended.
>>
>> Signed-off-by: wangxiaodong <wangxiaodong827546786@gmail.com>
>> ---
>> Documentation/admin-guide/pm/cpufreq.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
>> index 8831cface585..34baf20cc202 100644
>> --- a/Documentation/admin-guide/pm/cpufreq.rst
>> +++ b/Documentation/admin-guide/pm/cpufreq.rst
>> @@ -497,7 +497,7 @@ This governor exposes the following tunables:
>> represented by it to be 1.5 times as high as the transition latency
>> (the default)::
>>
>> - # echo `$(($(cat cpuinfo_transition_latency) * 3 / 2))` > ondemand/sampling_rate
>> + # echo $(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate
>
> Ugh. Thanks.
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>
> and possibly:
> Fixes: e54ac586674d ("cpufreq: editing corrections to cpufreq.rst")
Thanks Randy,
Just to back up Randy's Fixes suggestion, the line evolved as follows
(most recent first):
2025/04/04 e54ac586674d: #echo `$((.. * 3 / 2))` > (trailing ` added)
2024/10/17 29dcbea92460: #echo `$((.. * 3 / 2)) > (still dangling `)
2017/03/13 2a0e49279850: #echo `$((.. * 750 / 1000)) > (dangling leading `)
The stray backtick can be traced back to 2a0e49279850, but it was just a
dangling backtick then. The closed command-substitution form fixed here
was only reached after e54ac586674d added the trailing backtick. Note
that the "750/1000 -> 3/2" change in 29dcbea92460 was not just a doc
edit: it reflects an actual change in the kernel's behaviour. So on the
older trees the underlying logic - and hence this documented example -
is genuinely different, and this patch wouldn't apply cleanly there
anyway. Pointing Fixes at 2a0e49279850 therefore wouldn't help
backports.
So using
Fixes: e54ac586674d ("cpufreq: editing corrections to cpufreq.rst")
seems reasonable.
Either way, the fix is fine to me:
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
>
>>
>> ``up_threshold``
>> If the estimated CPU load is above this value (in percent), the governor
>
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* Re: [PATCH v4 0/5] mm/zswap: Implement per-cgroup proactive writeback
From: Muchun Song @ 2026-06-21 4:20 UTC (permalink / raw)
To: Hao Jia
Cc: akpm, tj, hannes, shakeel.butt, mhocko, yosry, mkoutny, nphamcs,
chengming.zhou, roman.gushchin, linux-mm, linux-kernel, linux-doc,
Hao Jia
In-Reply-To: <20260618044857.69439-1-jiahao.kernel@gmail.com>
> On Jun 18, 2026, at 12:48, Hao Jia <jiahao.kernel@gmail.com> wrote:
>
> From: Hao Jia <jiahao1@lixiang.com>
>
> Zswap currently writes back pages to backing swap reactively, triggered
> either by the shrinker or by the pool reaching its size limit. Although
> proactive memory reclaim can automatically write back a portion of zswap
> pages via the shrinker, it cannot explicitly control the amount of
> writeback for a specific memory cgroup. Moreover, proactive memory reclaim
> may not always be triggered during a steady state.
>
> In certain scenarios, it is desirable to trigger writeback in advance to
> free up memory. For example, users may want to prepare for an upcoming
> memory-intensive workload by flushing cold memory to the backing storage
> when the system is relatively idle.
>
> This patch series introduces a "zswap_writeback_only" key to memory.reclaim
> cgroup interface, allowing users to proactively write back cold compressed
> data from zswap to the backing swap device. When specified, this key
> bypasses standard memory reclaim and exclusively performs proactive zswap
> writeback up to the requested budget. If omitted, the default reclaim
> behavior remains unchanged.
>
> Example usage:
> # Write back 10MB of compressed data from zswap to the backing swap
> echo "10M zswap_writeback_only" > memory.reclaim
I’m not entirely sure if other candidate names were already brought up
in previous discussions, so my apologies if I'm repeating something here!
I do think expanding memory.reclaim is a great approach. That said, I
was wondering if we could make the interface a bit more concise while
keeping it flexible for future extensions.
Essentially, what we want is to control the specific targets of the reclaim
process—such as file, anon, or zswap. What do you think about using
something like "source=zswap"? For instance, if we want to reclaim 10M from
zswap, the command would look like this:
echo "10M source=zswap" > memory.reclaim
If we only want to reclaim 10M from file pages, we could easily extend the
syntax:
echo "10M source=file" > memory.reclaim
And of course, we could even combine them down the road:
echo "10M source=anon,file" > memory.reclaim
to only reclaim anon and file but bypass zswap.
Just some thoughts of mine.
Muchun,
Thanks
>
> Patch 1: Extend shrink_memcg() to support batch writeback based on a
> compressed-size budget and update its return value semantics, thereby
> improving the writeback efficiency in the shrink_worker() path.
> Patch 2: Extract the memcg iteration and writeback loop into helper
> functions to prepare for proactive writeback.
> Patch 3: Extend the memory.reclaim cgroup v2 interface with a new
> "zswap_writeback_only" key, allowing users to trigger proactive zswap
> writeback up to a requested budget.
> Patch 4: Add the zswpwb_proactive_b stat to track the compressed bytes
> of proactive writeback for better monitoring and tuning.
> Patch 5:
> Add tests for zswap proactive writeback.
>
> v3->v4:
> - Drop the per-memcg cursor and keep the root cgroup cursor
> (zswap_next_shrink) logic intact.
> - Stick to using the zswap_writeback_only key, and change the proactive
> writeback size to use the compressed size.
> - Consolidate and reuse the logic between shrink_worker() and
> shrink_memcg(). Enable batch writeback in the shrink_worker() path,
> while maintaining a low writeback budget in the zswap_store() path.
>
> v2->v3:
> - Align the return value of zswap_proactive_writeback() with
> memory.reclaim and update the corresponding documentation accordingly.
> - Resolve conflicts in test_zswap.c on the mm-unstable branch.
> - Enhance the zswap proactive writeback selftests to guard against potential
> future regressions.
>
> v1->v2:
> - As suggested by Yosry and Nhat, extend the memory.reclaim cgroup v2
> interface with a "zswap_writeback_only" key instead of adding a new
> dedicated cgroup interface.
> - Update the zswap documentation and add selftests for proactive writeback.
>
> [v3] https://lore.kernel.org/all/20260526114601.67041-1-jiahao.kernel@gmail.com
> [v2] https://lore.kernel.org/all/20260525122242.36127-1-jiahao.kernel@gmail.com
> [v1] https://lore.kernel.org/all/20260511105149.75584-1-jiahao.kernel@gmail.com
>
> Hao Jia (5):
> mm/zswap: Extend shrink_memcg() writeback capability
> mm/zswap: Factor writeback loop out of shrink_worker()
> mm/zswap: Implement proactive writeback
> mm/zswap: Add per-memcg stat for proactive writeback
> selftests/cgroup: Add tests for zswap proactive writeback
>
> Documentation/admin-guide/cgroup-v2.rst | 22 +-
> Documentation/admin-guide/mm/zswap.rst | 11 +-
> include/linux/memcontrol.h | 1 +
> include/linux/zswap.h | 7 +
> mm/memcontrol.c | 3 +
> mm/vmscan.c | 14 +
> mm/zswap.c | 322 +++++++++++++++-----
> tools/testing/selftests/cgroup/test_zswap.c | 153 +++++++++-
> 8 files changed, 456 insertions(+), 77 deletions(-)
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH] Documentation: admin-guide: pm: cpufreq: fix sampling_rate example command
From: Randy Dunlap @ 2026-06-21 3:52 UTC (permalink / raw)
To: wangxiaodong, rafael, viresh.kumar
Cc: corbet, skhan, linux-pm, linux-doc, linux-kernel
In-Reply-To: <20260621022515.10137-1-wangxiaodong827546786@gmail.com>
On 6/20/26 7:25 PM, wangxiaodong wrote:
> The example shell command for setting ondemand's sampling_rate wraps an
> arithmetic expansion $((...)) in command-substitution backticks. The
> arithmetic result is then executed as a command, which fails and writes
> an empty value. Drop the surrounding backticks so the computed value is
> passed to echo as intended.
>
> Signed-off-by: wangxiaodong <wangxiaodong827546786@gmail.com>
> ---
> Documentation/admin-guide/pm/cpufreq.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
> index 8831cface585..34baf20cc202 100644
> --- a/Documentation/admin-guide/pm/cpufreq.rst
> +++ b/Documentation/admin-guide/pm/cpufreq.rst
> @@ -497,7 +497,7 @@ This governor exposes the following tunables:
> represented by it to be 1.5 times as high as the transition latency
> (the default)::
>
> - # echo `$(($(cat cpuinfo_transition_latency) * 3 / 2))` > ondemand/sampling_rate
> + # echo $(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate
Ugh. Thanks.
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
and possibly:
Fixes: e54ac586674d ("cpufreq: editing corrections to cpufreq.rst")
>
> ``up_threshold``
> If the estimated CPU load is above this value (in percent), the governor
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: xe_drm: fix chars used for subsection
From: Randy Dunlap @ 2026-06-21 3:43 UTC (permalink / raw)
To: Rafael Passos, linux-doc; +Cc: corbet, skhan
In-Reply-To: <DJEDNH9TR3ZE.QO68KQ89RX4O@rcpassos.me>
On 6/20/26 7:38 PM, Rafael Passos wrote:
> Hi,
>
> On Sat Jun 20, 2026 at 6:42 PM -03, Randy Dunlap wrote:
>> Hi,
>>
>> It would be helpful to include the warnings here (but maybe not
>> all 10 lines of each warning).
>
> Ok, I will add them.
>
>> scripts/get_maintainer.pl should have told you that. (It does for me.)
>
> It did, but I made the (wrong) choice of sending it only to the docs
> list, beucase I had 3 patches with nothing but doc fixes.
>
> In cases like this, should I:
>
> 1. send a patchset, including the maintainers only on the patch related
> to them ?
> 2. send the patchset including everyone involved ?
> 3. not sent a patchset at all, and send separate patches for each list?
IMO you could do 1. or 3.
For #1, send the cover letter to anyone who is receiving
any one patch.
> In this case, the other two patches will be dropped. So I will send a
> V2 for this one, and for the correct audience.
--
~Randy
^ permalink raw reply
* [RESEND PATCH v6 8/8] tracing/probes: Add a new testcase for BTF typecasts
From: Masami Hiramatsu (Google) @ 2026-06-21 3:27 UTC (permalink / raw)
To: Steven Rostedt, Mathieu Desnoyers
Cc: Jonathan Corbet, Shuah Khan, Masami Hiramatsu, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <178201238795.570818.15573963115625446598.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
With the introduction of container_of-style BTF typecasting and
per-CPU variable access support in trace probes, we need a way to
verify their functionality and prevent regressions.
Add a new ftrace kselftest and update the trace event sample module
to test and validate these features.
Specifically, update the trace-events-sample module to set up a
periodic timer whose callback accesses a per-CPU counter. Introduce
a new sample trace event, foo_timer_fn, to trace this callback
and log the current counter value.
Then, add a new test case, btf_probe_event.tc, which defines a
dynamic probe on the timer callback. The probe uses BTF typecasting
to recover the parent structure from the timer argument and
this_cpu_read() to fetch the per-CPU counter. The test verifies
the integrity of the implementation by ensuring the values
recorded by the dynamic probe match those from the static tracepoint.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
Changes in v6:
- Update testcase according to changes.
Changes in v5:
- Add more syntax test cases.
Changes in v4:
- Fix uprobe $current test.
Changes in v3:
- Add syntax test case.
- Update testcase to use this_cpu_read()
Changes in v2:
- Use timer_shutdown_sync() instead of timer_delete_sync() for teardown.
---
samples/trace_events/trace-events-sample.c | 40 +++++++++++++++-
samples/trace_events/trace-events-sample.h | 34 ++++++++++++-
.../ftrace/test.d/dynevent/btf_probe_event.tc | 51 ++++++++++++++++++++
.../ftrace/test.d/dynevent/fprobe_syntax_errors.tc | 11 ++++
.../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 11 ++++
.../ftrace/test.d/kprobe/uprobe_syntax_errors.tc | 5 ++
6 files changed, 147 insertions(+), 5 deletions(-)
create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/btf_probe_event.tc
diff --git a/samples/trace_events/trace-events-sample.c b/samples/trace_events/trace-events-sample.c
index 0b7a6efdb247..ca5d98c360cb 100644
--- a/samples/trace_events/trace-events-sample.c
+++ b/samples/trace_events/trace-events-sample.c
@@ -94,6 +94,20 @@ static int simple_thread_fn(void *arg)
static DEFINE_MUTEX(thread_mutex);
static int simple_thread_cnt;
+static struct foo_timer_data *foo_timer_data;
+
+static void sample_timer_cb(struct timer_list *t)
+{
+ struct foo_timer_data *data = container_of(t, struct foo_timer_data, timer);
+
+ get_cpu();
+ trace_foo_timer_fn(data);
+ (*this_cpu_ptr(data->counter))++;
+ put_cpu();
+
+ mod_timer(t, jiffies + HZ);
+}
+
int foo_bar_reg(void)
{
mutex_lock(&thread_mutex);
@@ -132,9 +146,27 @@ void foo_bar_unreg(void)
static int __init trace_event_init(void)
{
+ foo_timer_data = kzalloc_obj(*foo_timer_data, GFP_KERNEL);
+ if (!foo_timer_data)
+ return -ENOMEM;
+
+ foo_timer_data->name = "sample_timer_counter";
+ foo_timer_data->counter = alloc_percpu(int);
+ if (!foo_timer_data->counter) {
+ kfree(foo_timer_data);
+ return -ENOMEM;
+ }
+
+ timer_setup(&foo_timer_data->timer, sample_timer_cb, 0);
+ mod_timer(&foo_timer_data->timer, jiffies + HZ);
+
simple_tsk = kthread_run(simple_thread, NULL, "event-sample");
- if (IS_ERR(simple_tsk))
- return -1;
+ if (IS_ERR(simple_tsk)) {
+ timer_shutdown_sync(&foo_timer_data->timer);
+ free_percpu(foo_timer_data->counter);
+ kfree(foo_timer_data);
+ return PTR_ERR(simple_tsk);
+ }
return 0;
}
@@ -147,6 +179,10 @@ static void __exit trace_event_exit(void)
kthread_stop(simple_tsk_fn);
simple_tsk_fn = NULL;
mutex_unlock(&thread_mutex);
+
+ timer_shutdown_sync(&foo_timer_data->timer);
+ free_percpu(foo_timer_data->counter);
+ kfree(foo_timer_data);
}
module_init(trace_event_init);
diff --git a/samples/trace_events/trace-events-sample.h b/samples/trace_events/trace-events-sample.h
index 1a05fc153353..816848a456a2 100644
--- a/samples/trace_events/trace-events-sample.h
+++ b/samples/trace_events/trace-events-sample.h
@@ -247,12 +247,14 @@
*/
/*
- * It is OK to have helper functions in the file, but they need to be protected
- * from being defined more than once. Remember, this file gets included more
- * than once.
+ * It is OK to have helper functions and data structures in the file, but they
+ * need to be protected from being defined more than once. Remember, this file
+ * gets included more than once.
*/
#ifndef __TRACE_EVENT_SAMPLE_HELPER_FUNCTIONS
#define __TRACE_EVENT_SAMPLE_HELPER_FUNCTIONS
+#include <linux/timer.h>
+
static inline int __length_of(const int *list)
{
int i;
@@ -270,6 +272,13 @@ enum {
TRACE_SAMPLE_BAR = 4,
TRACE_SAMPLE_ZOO = 8,
};
+
+struct foo_timer_data {
+ const char *name;
+ struct timer_list timer;
+ int __percpu *counter;
+};
+
#endif
/*
@@ -595,6 +604,25 @@ TRACE_EVENT(foo_rel_loc,
__get_rel_bitmask(bitmask),
__get_rel_cpumask(cpumask))
);
+
+TRACE_EVENT(foo_timer_fn,
+
+ TP_PROTO(struct foo_timer_data *data),
+
+ TP_ARGS(data),
+
+ TP_STRUCT__entry(
+ __string( name, data->name )
+ __field( int, count )
+ ),
+
+ TP_fast_assign(
+ __assign_str(name);
+ __entry->count = *this_cpu_ptr(data->counter);
+ ),
+
+ TP_printk("name=%s count=%d", __get_str(name), __entry->count)
+);
#endif
/***** NOTICE! The #if protection ends here. *****/
diff --git a/tools/testing/selftests/ftrace/test.d/dynevent/btf_probe_event.tc b/tools/testing/selftests/ftrace/test.d/dynevent/btf_probe_event.tc
new file mode 100644
index 000000000000..96791e120b7d
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/dynevent/btf_probe_event.tc
@@ -0,0 +1,51 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# description: BTF event with typecast and percpu access
+# requires: dynamic_events "this_cpu_read(<fetcharg>)":README "[(structname[,field])]<argname>[->field[->field|.field...]]":README
+
+# Check if the sample module is loaded
+if ! lsmod | grep -q trace_events_sample; then
+ modprobe trace-events-sample || exit_unsupported
+fi
+
+echo 0 > events/enable
+echo > dynamic_events
+
+# The sample_timer_cb(struct timer_list *t) is called.
+# We want to check (STRUCT,FIELD)VAR typecast and this_cpu_read() access.
+# (foo_timer_data,timer)t converts t to struct foo_timer_data * using container_of.
+# data->counter is a per-cpu pointer to int.
+# this_cpu_read(data->counter) should give the value of the counter.
+
+echo 'f:mysample/myevent sample_timer_cb name=(foo_timer_data,timer)t->name:string count=this_cpu_read((foo_timer_data,timer)t->counter)' >> dynamic_events
+
+echo 1 > events/mysample/myevent/enable
+echo 1 > events/sample-trace/foo_timer_fn/enable
+
+sleep 2
+
+echo 0 > events/mysample/myevent/enable
+echo 0 > events/sample-trace/foo_timer_fn/enable
+
+# Compare the values.
+MATCH=0
+while read line; do
+ if echo $line | grep -q "foo_timer_fn:"; then
+ NAME=`echo $line | sed 's/.*name=\([^ ]*\) .*/\1/'`
+ COUNT=`echo $line | sed 's/.*count=\([^ ]*\).*/\1/'`
+ if grep -q "myevent:.*name=\"${NAME}\" count=$COUNT" trace; then
+ MATCH=$((MATCH+1))
+ fi
+ fi
+done < trace
+
+if [ $MATCH -eq 0 ]; then
+ echo "No matching events found"
+ exit_fail
+fi
+
+# Clean up
+echo 0 > events/mysample/myevent/enable
+echo 0 > events/sample-trace/foo_timer_fn/enable
+echo > dynamic_events
+clear_trace
diff --git a/tools/testing/selftests/ftrace/test.d/dynevent/fprobe_syntax_errors.tc b/tools/testing/selftests/ftrace/test.d/dynevent/fprobe_syntax_errors.tc
index fee479295e2f..e111d426a984 100644
--- a/tools/testing/selftests/ftrace/test.d/dynevent/fprobe_syntax_errors.tc
+++ b/tools/testing/selftests/ftrace/test.d/dynevent/fprobe_syntax_errors.tc
@@ -112,6 +112,17 @@ check_error 'f vfs_read%return $retval->^foo' # NO_PTR_STRCT
check_error 'f vfs_read file->^foo' # NO_BTF_FIELD
check_error 'f vfs_read file^-.foo' # BAD_HYPHEN
check_error 'f vfs_read ^file:string' # BAD_TYPE4STR
+if grep -qF "[(structname" README ; then
+check_error 'f vfs_read arg1=(task_struct)file^' # TYPECAST_REQ_FIELD
+check_error 'f vfs_read arg1=(a)((b)((c)(^(d)file->d)->c)->b)->a' # TOO_MANY_NESTED
+check_error 'f vfs_read arg1=(task_struct,^in_execve)file->comm' # TYPECAST_NOT_ALIGNED
+check_error 'f vfs_read arg1=(task_struct,^foo_bar)file->pid' # NO_BTF_FIELD
+check_error 'f vfs_read arg1=(^task_struct1234)file->pid' # NO_PTR_STRCT
+check_error 'f vfs_read arg1=(task_struct,se^->group_node)file->comm' # TYPECAST_BAD_ARROW
+check_error 'f vfs_read arg1=(task_struct,^->pid)file->comm' # NO_BTF_FIELD
+check_error 'f vfs_read arg1=(task_struct,^.pid)file->comm' # NO_BTF_FIELD
+check_error 'f vfs_read arg1=(task_struct,^.)file->comm' # NO_BTF_FIELD
+fi
fi
else
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
index 8f1c58f0c239..626adeb2e840 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
@@ -115,6 +115,17 @@ check_error 'p vfs_read+20 ^$arg*' # NOFENTRY_ARGS
check_error 'p vfs_read ^hoge' # NO_BTFARG
check_error 'p kfree ^$arg10' # NO_BTFARG (exceed the number of parameters)
check_error 'r kfree ^$retval' # NO_RETVAL
+if grep -qF "[(structname" README ; then
+check_error 'p vfs_read arg1=(task_struct)file^' # TYPECAST_REQ_FIELD
+check_error 'p vfs_read arg1=(a)((b)((c)(^(d)file->d)->c)->b)->a' # TOO_MANY_NESTED
+check_error 'p vfs_read arg1=(task_struct,^in_execve)file->comm' # TYPECAST_NOT_ALIGNED
+check_error 'p vfs_read arg1=(task_struct,^foo_bar)file->pid' # NO_BTF_FIELD
+check_error 'p vfs_read arg1=(^task_struct1234)file->pid' # NO_PTR_STRCT
+check_error 'p vfs_read arg1=(task_struct,se^->group_node)file->comm' # TYPECAST_BAD_ARROW
+check_error 'p vfs_read arg1=(task_struct,^->pid)file->comm' # NO_BTF_FIELD
+check_error 'p vfs_read arg1=(task_struct,^.pid)file->comm' # NO_BTF_FIELD
+check_error 'p vfs_read arg1=(task_struct,^.)file->comm' # NO_BTF_FIELD
+fi
else
check_error 'p vfs_read ^$arg*' # NOSUP_BTFARG
fi
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/uprobe_syntax_errors.tc b/tools/testing/selftests/ftrace/test.d/kprobe/uprobe_syntax_errors.tc
index c817158b99db..e12dc967ec76 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/uprobe_syntax_errors.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/uprobe_syntax_errors.tc
@@ -28,4 +28,9 @@ if grep -q ".*symstr.*" README; then
check_error 'p /bin/sh:10 $stack0:^symstr' # BAD_TYPE
fi
+# $current is not supported by uprobe
+if grep -q "\$current.*" README; then
+check_error 'p /bin/sh:10 ^$current:u8' # BAD_VAR
+fi
+
exit 0
^ permalink raw reply related
* [RESEND PATCH v6 7/8] tracing/probes: Add this_cpu_read() and this_cpu_ptr() dereference method to fetcharg
From: Masami Hiramatsu (Google) @ 2026-06-21 3:27 UTC (permalink / raw)
To: Steven Rostedt, Mathieu Desnoyers
Cc: Jonathan Corbet, Shuah Khan, Masami Hiramatsu, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <178201238795.570818.15573963115625446598.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
When tracing the kernel local variables, sometimes we need to get the
CPU local variables. To access it, current simple dereference is not
enough.
Thus, introduce a special this_cpu_read() dereference to access per-cpu
variable for the current CPU (accessing other CPU variable may race with
updates on other CPUs). Also this_cpu_ptr() is for accessing per-cpu
pointer.
Those are working as same as the kernel percpu macro.
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
Changes in v6:
- Rebased on dump fetcharg patch.
- Fix to fetch static percpu variable with @SYM correctly.
Changes in v5:
- Simplify this_cpu_read() into +0(this_cpu_ptr()).
Changes in v3:
- Remove NULL check for percpu var because it is just an offset, could be 0.
- Simplify process_fetch_insn_bottom() code.
- If the last operation is this_cpu_read(), read only memory of the specific
size (of type).
Changes in v2:
- Drop +CPU/+PCPU and introduce this_cpu_read() and this_cpu_ptr().
- Support these method with BTF typecast.
- Just check the base address is NOT NULL instead of is_kernel_percpu_address().
---
Documentation/trace/eprobetrace.rst | 2
Documentation/trace/fprobetrace.rst | 2
Documentation/trace/kprobetrace.rst | 2
kernel/trace/trace.c | 1
kernel/trace/trace_probe.c | 143 ++++++++++++++++++++++++++---------
kernel/trace/trace_probe.h | 1
kernel/trace/trace_probe_tmpl.h | 22 ++++-
7 files changed, 129 insertions(+), 44 deletions(-)
diff --git a/Documentation/trace/eprobetrace.rst b/Documentation/trace/eprobetrace.rst
index 680e0af43d5d..279396951b34 100644
--- a/Documentation/trace/eprobetrace.rst
+++ b/Documentation/trace/eprobetrace.rst
@@ -39,6 +39,8 @@ Synopsis of eprobe_events
@SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)
$comm : Fetch current task comm.
+|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*3)(\*4)
+ this_cpu_read(FETCHARG) : Read the value of the per-CPU variable FETCHARG on the current CPU.
+ this_cpu_ptr(FETCHARG) : Get the address of the per-CPU variable FETCHARG on the current CPU.
\IMM : Store an immediate value to the argument.
NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types
diff --git a/Documentation/trace/fprobetrace.rst b/Documentation/trace/fprobetrace.rst
index 3392cab016b3..3439bc9bd351 100644
--- a/Documentation/trace/fprobetrace.rst
+++ b/Documentation/trace/fprobetrace.rst
@@ -52,6 +52,8 @@ Synopsis of fprobe-events
$comm : Fetch current task comm.
$current : Fetch the address of the current task_struct.
+|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*4)(\*5)
+ this_cpu_read(FETCHARG) : Read the value of the per-CPU variable FETCHARG on the current CPU.
+ this_cpu_ptr(FETCHARG) : Get the address of the per-CPU variable FETCHARG on the current CPU.
\IMM : Store an immediate value to the argument.
NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types
diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst
index 81e4fe38791d..9ae330eb0a52 100644
--- a/Documentation/trace/kprobetrace.rst
+++ b/Documentation/trace/kprobetrace.rst
@@ -55,6 +55,8 @@ Synopsis of kprobe_events
$comm : Fetch current task comm.
$current : Fetch the address of the current task_struct.
+|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*3)(\*4)
+ this_cpu_read(FETCHARG) : Read the value of the per-CPU variable FETCHARG on the current CPU.
+ this_cpu_ptr(FETCHARG) : Get the address of the per-CPU variable FETCHARG on the current CPU.
\IMM : Store an immediate value to the argument.
NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7a5676524f1a..d4121acc2938 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4332,6 +4332,7 @@ static const char readme_msg[] =
"\t $stack<index>, $stack, $retval, $comm, $current\n"
#endif
"\t +|-[u]<offset>(<fetcharg>), \\imm-value, \\\"imm-string\"\n"
+ "\t this_cpu_read(<fetcharg>), this_cpu_ptr(<fetcharg>)\n"
"\t kernel return probes support: $retval, $arg<N>, $comm\n"
"\t type: s8/16/32/64, u8/16/32/64, x8/16/32/64, char, string, symbol,\n"
"\t b<bit-width>@<bit-offset>/<container-size>, ustring,\n"
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 1ddd0a804e39..a64edb0c6baa 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -349,6 +349,100 @@ static int parse_trace_event(char *arg, struct fetch_insn *code,
return -EINVAL;
}
+/* this_cpu_* parser */
+#define THIS_CPU_PTR_PREFIX "this_cpu_ptr("
+#define THIS_CPU_READ_PREFIX "this_cpu_read("
+#define THIS_CPU_PTR_LEN (sizeof(THIS_CPU_PTR_PREFIX) - 1)
+#define THIS_CPU_READ_LEN (sizeof(THIS_CPU_READ_PREFIX) - 1)
+
+static int
+parse_probe_arg(char *arg, const struct fetch_type *type,
+ struct fetch_insn **pcode, struct fetch_insn *end,
+ struct traceprobe_parse_context *ctx);
+
+/* handle dereference nested call */
+static inline int handle_dereference(char *arg, struct fetch_insn **pcode,
+ struct fetch_insn *end, struct traceprobe_parse_context *ctx,
+ int deref, long offset)
+{
+ const struct fetch_type *type = find_fetch_type(NULL, ctx->flags);
+ struct fetch_insn *code = *pcode;
+ int cur_offs = ctx->offset;
+ char *tmp;
+ int ret;
+
+ tmp = strrchr(arg, ')');
+ if (!tmp) {
+ trace_probe_log_err(ctx->offset + strlen(arg),
+ DEREF_OPEN_BRACE);
+ return -EINVAL;
+ }
+
+ *tmp = '\0';
+ ret = parse_probe_arg(arg, type, &code, end, ctx);
+ if (ret)
+ return ret;
+ ctx->offset = cur_offs;
+ if (code->op == FETCH_OP_COMM || code->op == FETCH_OP_DATA) {
+ trace_probe_log_err(ctx->offset, COMM_CANT_DEREF);
+ return -EINVAL;
+ }
+
+ /*
+ * this_cpu_ptr(@SYM) does not use SYM value, but use SYM address.
+ * So we overwrite the last FETCH_OP_DEREF with FETCH_OP_CPU_PTR.
+ */
+ if (!(deref == FETCH_OP_CPU_PTR && *arg == '@')) {
+ code++;
+ if (code == end) {
+ trace_probe_log_err(ctx->offset, TOO_MANY_OPS);
+ return -EINVAL;
+ }
+ *pcode = code;
+ }
+
+ code->op = deref;
+ code->offset = offset;
+ /* Reset the last type if used */
+ ctx->last_type = NULL;
+ return 0;
+}
+
+static int parse_this_cpu(char *arg, struct fetch_insn **pcode,
+ struct fetch_insn *end,
+ struct traceprobe_parse_context *ctx)
+{
+ struct fetch_insn *code;
+ bool is_ptr = false;
+ int ret;
+
+ if (str_has_prefix(arg, THIS_CPU_PTR_PREFIX)) {
+ arg += THIS_CPU_PTR_LEN;
+ ctx->offset += THIS_CPU_PTR_LEN;
+ is_ptr = true;
+ } else if (str_has_prefix(arg, THIS_CPU_READ_PREFIX)) {
+ arg += THIS_CPU_READ_LEN;
+ ctx->offset += THIS_CPU_READ_LEN;
+ } else
+ return -EINVAL;
+
+ ret = handle_dereference(arg, pcode, end, ctx, FETCH_OP_CPU_PTR, 0);
+ if (ret || is_ptr)
+ return ret;
+
+ /* this_cpu_read(VAR) -> +0(this_cpu_ptr(VAR)) */
+ code = *pcode;
+ code++;
+ if (code == end) {
+ trace_probe_log_err(ctx->offset, TOO_MANY_OPS);
+ return -EINVAL;
+ }
+ code->op = FETCH_OP_DEREF;
+ code->offset = 0;
+ *pcode = code;
+ return 0;
+}
+
#ifdef CONFIG_PROBE_EVENTS_BTF_ARGS
static u32 btf_type_int(const struct btf_type *t)
@@ -925,11 +1019,6 @@ static char *find_matched_close_paren(char *s)
return NULL;
}
-static int
-parse_probe_arg(char *arg, const struct fetch_type *type,
- struct fetch_insn **pcode, struct fetch_insn *end,
- struct traceprobe_parse_context *ctx);
-
static int handle_typecast(char *arg, struct fetch_insn **pcode,
struct fetch_insn *end,
struct traceprobe_parse_context *ctx)
@@ -982,7 +1071,9 @@ static int handle_typecast(char *arg, struct fetch_insn **pcode,
/* Skip '(' */
ctx->offset += 1;
tmp++;
- } else if (*tmp == '+' || *tmp == '-') {
+ } else if (*tmp == '+' || *tmp == '-' ||
+ str_has_prefix(tmp, THIS_CPU_PTR_PREFIX) ||
+ str_has_prefix(tmp, THIS_CPU_READ_PREFIX)) {
/* Dereference can have another field access inside it. */
char *open = strchr(tmp + 1, '(');
@@ -1486,36 +1577,9 @@ parse_probe_arg(char *arg, const struct fetch_type *type,
}
ctx->offset += (tmp + 1 - arg) + (arg[0] != '-' ? 1 : 0);
arg = tmp + 1;
- tmp = strrchr(arg, ')');
- if (!tmp) {
- trace_probe_log_err(ctx->offset + strlen(arg),
- DEREF_OPEN_BRACE);
- return -EINVAL;
- } else {
- const struct fetch_type *t2 = find_fetch_type(NULL, ctx->flags);
- int cur_offs = ctx->offset;
-
- *tmp = '\0';
- ret = parse_probe_arg(arg, t2, &code, end, ctx);
- if (ret)
- break;
- ctx->offset = cur_offs;
- if (code->op == FETCH_OP_COMM ||
- code->op == FETCH_OP_DATA) {
- trace_probe_log_err(ctx->offset, COMM_CANT_DEREF);
- return -EINVAL;
- }
- if (++code == end) {
- trace_probe_log_err(ctx->offset, TOO_MANY_OPS);
- return -EINVAL;
- }
- *pcode = code;
-
- code->op = deref;
- code->offset = offset;
- /* Reset the last type if used */
- ctx->last_type = NULL;
- }
+ ret = handle_dereference(arg, pcode, end, ctx, deref, offset);
+ if (ret < 0)
+ return ret;
break;
case '\\': /* Immediate value */
if (arg[1] == '"') { /* Immediate string */
@@ -1536,15 +1600,18 @@ parse_probe_arg(char *arg, const struct fetch_type *type,
ret = handle_typecast(arg, pcode, end, ctx);
break;
default:
- if (isalpha(arg[0]) || arg[0] == '_') { /* BTF variable */
+ if (str_has_prefix(arg, THIS_CPU_PTR_PREFIX) ||
+ str_has_prefix(arg, THIS_CPU_READ_PREFIX)) {
+ ret = parse_this_cpu(arg, pcode, end, ctx);
+ } else if (isalpha(arg[0]) || arg[0] == '_') { /* BTF variable */
if (!tparg_is_function_entry(ctx->flags) &&
!tparg_is_function_return(ctx->flags)) {
trace_probe_log_err(ctx->offset, NOSUP_BTFARG);
return -EINVAL;
}
ret = parse_btf_arg(arg, pcode, end, ctx);
- break;
}
+ break;
}
if (!ret && code->op == FETCH_OP_NOP) {
/* Parsed, but do not find fetch method */
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index 488d6790b5ef..e79e019b922d 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -101,6 +101,7 @@ typedef int (*print_type_func_t)(struct trace_seq *, void *, void *);
/* Stage 2 (dereference) ops */ \
FETCH_OP(DEREF, offset) /* Dereference: .offset */ \
FETCH_OP(UDEREF, offset) /* User-space dereference: .offset */\
+ FETCH_OP(CPU_PTR, none) /* Per-CPU pointer: .offset */ \
/* Stage 3 (store) ops */ \
FETCH_OP(ST_RAW, store) /* Raw value: .size */ \
FETCH_OP(ST_MEM, store) /* Memory: .offset, .size */ \
diff --git a/kernel/trace/trace_probe_tmpl.h b/kernel/trace/trace_probe_tmpl.h
index f630930288d2..9265b03cf19d 100644
--- a/kernel/trace/trace_probe_tmpl.h
+++ b/kernel/trace/trace_probe_tmpl.h
@@ -129,25 +129,35 @@ process_fetch_insn_bottom(struct fetch_insn *code, unsigned long val,
struct fetch_insn *s3 = NULL;
int total = 0, ret = 0, i = 0;
u32 loc = 0;
- unsigned long lval = val;
+ unsigned long lval, llval = val;
stage2:
/* 2nd stage: dereference memory if needed */
do {
- if (code->op == FETCH_OP_DEREF) {
- lval = val;
+ lval = val;
+ switch (code->op) {
+ case FETCH_OP_DEREF:
ret = probe_mem_read(&val, (void *)val + code->offset,
sizeof(val));
- } else if (code->op == FETCH_OP_UDEREF) {
- lval = val;
+ break;
+ case FETCH_OP_UDEREF:
ret = probe_mem_read_user(&val,
(void *)val + code->offset, sizeof(val));
- } else
break;
+ case FETCH_OP_CPU_PTR:
+ val = (unsigned long)this_cpu_ptr((void __percpu *)val);
+ ret = 0;
+ break;
+ default:
+ lval = llval;
+ goto out;
+ }
if (ret)
return ret;
+ llval = lval;
code++;
} while (1);
+out:
s3 = code;
stage3:
^ permalink raw reply related
* [RESEND PATCH v6 6/8] tracing/probes: Add $current variable support
From: Masami Hiramatsu (Google) @ 2026-06-21 3:27 UTC (permalink / raw)
To: Steven Rostedt, Mathieu Desnoyers
Cc: Jonathan Corbet, Shuah Khan, Masami Hiramatsu, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <178201238795.570818.15573963115625446598.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Since we can use the BTF to cast value to a structure pointer type,
it is useful to introduce "$current" special variable support to
fetcharg.
User can define a fetcharg to access current task_struct properties
using BTF info. e.g.
$current->cpus_ptr
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
Changes in v6:
- Rebased on dump fetcharg patch.
- Remove function name/eprobe requirement for $current.
Changes in v5:
- Use s32 for bof_find_btf_id().
Changes in v4:
- Add $current in README when CONFIG_HAVE_FUNCTION_ARG_ACCESS_API=y case.
- Fix to prohibit using $current in eprobes and address based kprobes.
Changes in v3:
- Remove $current support from eprobes (because eprobes is only for event)
- Prohibit uprobes to use $current.
Changes in v2:
- Support to parse $current in parse_btf_arg().
- If no typecast on $current, it automatically casted to task_struct.
- Check error case if $current follows something except for "-".
---
Documentation/trace/fprobetrace.rst | 1 +
Documentation/trace/kprobetrace.rst | 1 +
kernel/trace/trace.c | 4 ++--
kernel/trace/trace_probe.c | 40 ++++++++++++++++++++++++++++++++++-
kernel/trace/trace_probe.h | 1 +
kernel/trace/trace_probe_tmpl.h | 3 +++
6 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/Documentation/trace/fprobetrace.rst b/Documentation/trace/fprobetrace.rst
index 290a9e6f7491..3392cab016b3 100644
--- a/Documentation/trace/fprobetrace.rst
+++ b/Documentation/trace/fprobetrace.rst
@@ -50,6 +50,7 @@ Synopsis of fprobe-events
$argN : Fetch the Nth function argument. (N >= 1) (\*2)
$retval : Fetch return value.(\*3)
$comm : Fetch current task comm.
+ $current : Fetch the address of the current task_struct.
+|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*4)(\*5)
\IMM : Store an immediate value to the argument.
NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst
index a62707e6a9f2..81e4fe38791d 100644
--- a/Documentation/trace/kprobetrace.rst
+++ b/Documentation/trace/kprobetrace.rst
@@ -53,6 +53,7 @@ Synopsis of kprobe_events
$argN : Fetch the Nth function argument. (N >= 1) (\*1)
$retval : Fetch return value.(\*2)
$comm : Fetch current task comm.
+ $current : Fetch the address of the current task_struct.
+|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*3)(\*4)
\IMM : Store an immediate value to the argument.
NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 0e36af853199..7a5676524f1a 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4323,13 +4323,13 @@ static const char readme_msg[] =
"\t args: <name>=fetcharg[:type]\n"
"\t fetcharg: (%<register>|$<efield>), @<address>, @<symbol>[+|-<offset>],\n"
#ifdef CONFIG_HAVE_FUNCTION_ARG_ACCESS_API
- "\t $stack<index>, $stack, $retval, $comm, $arg<N>,\n"
+ "\t $stack<index>, $stack, $retval, $comm, $arg<N>, $current\n"
#ifdef CONFIG_PROBE_EVENTS_BTF_ARGS
"\t [(structname[,field])]<argname>[->field[->field|.field...]],\n"
"\t [(structname[,field])](fetcharg)->field[->field|.field...],\n"
#endif
#else
- "\t $stack<index>, $stack, $retval, $comm,\n"
+ "\t $stack<index>, $stack, $retval, $comm, $current\n"
#endif
"\t +|-[u]<offset>(<fetcharg>), \\imm-value, \\\"imm-string\"\n"
"\t kernel return probes support: $retval, $arg<N>, $comm\n"
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 8c21c378fac7..1ddd0a804e39 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -700,7 +700,9 @@ static int parse_btf_arg(char *varname,
int i, is_ptr, ret;
u32 tid;
- if (!ctx->funcname && !(ctx->flags & TPARG_FL_TEVENT))
+ /* Note: field is not separated at this point, so check prefix. */
+ if (!str_has_prefix(varname, "$current") &&
+ !ctx->funcname && !(ctx->flags & TPARG_FL_TEVENT))
return -EINVAL;
is_ptr = split_next_field(varname, &field, ctx);
@@ -713,6 +715,24 @@ static int parse_btf_arg(char *varname,
return -EOPNOTSUPP;
}
+ if (!strcmp(varname, "$current")) {
+ code->op = FETCH_OP_CURRENT;
+ /* If no typecast is specified for $current, use task_struct by default */
+ if (!ctx->struct_btf) {
+ s32 ttid = bpf_find_btf_id("task_struct", BTF_KIND_STRUCT,
+ &ctx->struct_btf);
+
+ if (ttid < 0) {
+ trace_probe_log_err(ctx->offset, NO_BTF_ENTRY);
+ return -ENOENT;
+ }
+ /* btf_type_skip_modifier() requires u32 for type id. */
+ tid = ttid;
+ ctx->last_struct = btf_type_skip_modifiers(ctx->struct_btf, tid, &tid);
+ }
+ goto found;
+ }
+
if (ctx->flags & TPARG_FL_RETURN && !strcmp(varname, "$retval")) {
code->op = FETCH_OP_RETVAL;
/* Check whether the function return type is not void, even with typecast. */
@@ -1273,6 +1293,24 @@ static int parse_probe_vars(char *orig_arg, const struct fetch_type *t,
return 0;
}
+ /* $current returns the address of the current task_struct. */
+ if (str_has_prefix(arg, "current")) {
+ /* $current is only supported by kernel probe. */
+ if (!(ctx->flags & TPARG_FL_KERNEL)) {
+ err = TP_ERR_BAD_VAR;
+ goto inval;
+ }
+ arg += strlen("current");
+ if (*arg == '-' && IS_ENABLED(CONFIG_PROBE_EVENTS_BTF_ARGS))
+ return parse_btf_arg(orig_arg, pcode, end, ctx);
+
+ if (*arg != '\0')
+ goto inval;
+
+ code->op = FETCH_OP_CURRENT;
+ return 0;
+ }
+
#ifdef CONFIG_HAVE_FUNCTION_ARG_ACCESS_API
len = str_has_prefix(arg, "arg");
if (len) {
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index bc3ac148a655..488d6790b5ef 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -92,6 +92,7 @@ typedef int (*print_type_func_t)(struct trace_seq *, void *, void *);
FETCH_OP(RETVAL, none) /* Return value */ \
FETCH_OP(IMM, imm) /* Immediate: .immediate */ \
FETCH_OP(COMM, none) /* Current comm */ \
+ FETCH_OP(CURRENT, none) /* Current task_struct address */\
FETCH_OP(ARG, param) /* Argument: .param = index */ \
FETCH_OP(FOFFS, imm) /* File offset: .immediate */ \
FETCH_OP(DATA, ptr) /* Allocated data: .data */ \
diff --git a/kernel/trace/trace_probe_tmpl.h b/kernel/trace/trace_probe_tmpl.h
index f39b37fcdb3b..f630930288d2 100644
--- a/kernel/trace/trace_probe_tmpl.h
+++ b/kernel/trace/trace_probe_tmpl.h
@@ -112,6 +112,9 @@ process_common_fetch_insn(struct fetch_insn *code, unsigned long *val)
case FETCH_OP_DATA:
*val = (unsigned long)code->data;
break;
+ case FETCH_OP_CURRENT:
+ *val = (unsigned long)current;
+ break;
default:
return -EILSEQ;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox