* Re: [patch 13/18] entry: Make trace_syscall_enter() return type bool
From: Thomas Gleixner @ 2026-07-11 20:33 UTC (permalink / raw)
To: Michal Suchánek
Cc: LKML, Peter Zijlstra, Michael Ellerman, Shrikanth Hegde,
linuxppc-dev, Kees Cook, Huacai Chen, loongarch, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Sven Schnelle, linux-s390, x86,
Mark Rutland, Jinjie Ruan, Andy Lutomirski, Oleg Nesterov,
Richard Henderson, Russell King, Catalin Marinas, Guo Ren,
Geert Uytterhoeven, Thomas Bogendoerfer, Helge Deller,
Yoshinori Sato, Richard Weinberger, Chris Zankel,
linux-arm-kernel, linux-alpha, linux-csky, linux-m68k, linux-mips,
linux-parisc, linux-sh, linux-um, Arnd Bergmann, Vineet Gupta,
Will Deacon, Brian Cain, Michal Simek, Dinh Nguyen,
David S. Miller, Andreas Larsson, linux-snps-arc, linux-hexagon,
linux-openrisc, sparclinux, linux-arch, Jonathan Corbet,
linux-doc
In-Reply-To: <alDQ7isUKJFl8Va4@kunlun.suse.cz>
Michal!
On Fri, Jul 10 2026 at 13:01, Michal Suchánek wrote:
> On Wed, Jul 08, 2026 at 10:34:38PM +0200, Thomas Gleixner wrote:
>> does not make #2 magically go away. It's still the same problem whether
>> you like it or not.
>
> However, reading the syscall number from pt_regs only after
> syscall_enter_from_user_mode exits does.
That does not solve anything at all.
TBH, your communication style is annoying as hell. You fail to provide
any useful arguments and explanations despite me giving you a proper
analysis. And I'm absolutely tired of this.
So let me try again for _ONE_ last time to explain you why your ppc/s390
world view is broken and let's look at the current code (irrelevant
portions omitted).
static __always_inline long syscall_trace_enter(struct pt_regs *regs, unsigned long work)
{
if (work & SYSCALL_WORK_SYSCALL_USER_DISPATCH) {
#1 if (syscall_user_dispatch(regs))
return -1L;
}
if (work & (SYSCALL_WORK_SYSCALL_TRACE | SYSCALL_WORK_SYSCALL_EMU)) {
#2 ret = arch_ptrace_report_syscall_entry(regs);
if (ret || (work & SYSCALL_WORK_SYSCALL_EMU))
return -1L;
}
/* Do seccomp after ptrace, to catch any tracer changes. */
if (work & SYSCALL_WORK_SECCOMP) {
#3 ret = __secure_computing();
if (ret == -1L)
return ret;
}
/* Either of the above might have changed the syscall number */
#4 syscall = syscall_get_nr(current, regs);
if (unlikely(work & SYSCALL_WORK_SYSCALL_TRACEPOINT))
#5 syscall = trace_syscall_enter(regs, syscall);
return syscall;
}
#1) The user dispatch mechanism does not modify the syscall return
value, but it can rollback the syscall and tell the call site to
skip the invocation.
The mechanism used in upstream today is to return -1L as the syscall
number which makes the architecture specific entry code skip the
syscall and refrain from touching the return value.
#2) ptrace
ptrace can poke whatever it wants into the syscall number storage
via ptrace_set_syscall_info_entry() -> syscall_set_nr()
It does not set the return code.
It does not abort the syscall when the poked syscall number is -1L.
It only aborts when a fatal signal is pending.
#3) seccomp
seccomp reads the syscall number, which might have been modified by
ptrace and acts upon it.
It can rewrite the syscall number even if it is -1 to begin with.
It can rewrite the return code if it decides to refuse the syscall
to be executed.
If it refuses the syscall to be executed it returns -1L.
#4) Rereading the syscall number after ptrace/seccomp
That's required to give the eventually modified number to the
tracer.
Obviously the tracer could do that on it's own, but with the current
implementation it expects the eventually modified syscall number
Changing that to make the tracer do it, is possible but does not
change any of the actual expectations. That's just cosmetic wankery.
#5) tracing
tracing can have a probe or bpf attached, which in turn can
- rewrite the syscall number
- set the return code in case that it sets the syscall number to
-1L
It can even set it in case it sets it to some other value, but
the architecture code has to be resilent against that no matter
what.
- if it does not set the return code when it sets the syscall
number to -1L then it has a historical expectation that the
syscall returns -ENOSYS
That's how it is and you can argue in circles and it's not going
away unless you have a great argument why you can break existing
user space probes/bpf scripts.
So now please provide in coherent sentences the argument why this solves
anything:
> However, reading the syscall number from pt_regs only after
> syscall_enter_from_user_mode exits does.
If you can, which I doubt, then please send a patch [series] against:
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git entry/rework
with proper change logs explaining the superiour solution.
If not, please spare us the next set of incoherent "I wan't a pony"
mails.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Jonathan Corbet @ 2026-07-11 20:04 UTC (permalink / raw)
To: Weijie Yuan, 葉宸佑
Cc: Dongliang Mu, Hu Haowen, Shuah Khan, Dongliang Mu, linux-doc,
linux-kernel, Yuchen Tian, Alex Shi, Yanteng Si
In-Reply-To: <alJ7ocaqtpUkCGrd@wyuan.org>
Weijie Yuan <wy@wyuan.org> writes:
> How exactly we define the position of Traditional Chinese or zh_TW?
>
> 1. Simple conversion between simplified and traditional Chinese
> characters
> 2. Taiwanese localized traditional Chinese
>
> This issue needs to be confirmed by the senior maintenance personnel.
> (I will review the archives to confirm. If there is already a clear
> definition, please forgive me.)
"Senior maintenance personnel" in this case is the people who actually
step up to maintain this translation. There is no higher level of
authority that needs to somehow sign off on it. The existing
translation is essentially abandoned; if somebody wants to carry it
forward -- and stay with it -- with a shift in focus, I think that is
just fine.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Weijie Yuan @ 2026-07-11 17:21 UTC (permalink / raw)
To: 葉宸佑
Cc: Dongliang Mu, Hu Haowen, Jonathan Corbet, Shuah Khan,
Dongliang Mu, linux-doc, linux-kernel, Yuchen Tian, Alex Shi,
Yanteng Si
In-Reply-To: <CAKspUhKh=cT_ks1hH9B4G8KppR=XT+THHsmNUFH_irX6xo1SZw@mail.gmail.com>
On Sat, Jul 11, 2026 at 02:01:46AM +0800, 葉宸佑 wrote:
> Hi Weijie,
>
> > I think currently having Alex apply your patch is a temporary measure,
> > because the maintainer of traditional Chinese seems unlikely to be
> > available in the near future.
>
> Thanks for taking the time to explain the bigger picture in such detail.
> Details. I understand the concern: accepting individual fixes doesn’t…
> Solve the underlying problem that zh_TW documents have been facing.
> Stagnant for a long time.
So I'm very glad and grateful to hear more people's opinions. Of course,
that's only my wish, I have no intention of forcing anyone.
> > So if we are doing zh_TW instead of a direct simplified and
> > traditional Chinese conversion, I don't think we can handle this
> > properly without the help of Taiwanese friends.
>
> For what it's worth, I am from Taiwan and a native zh_TW speaker.
> That is actually what motivated this patch: much of the current text
> reads like converted zh_CN rather than natural Taiwanese Mandarin,
So, back to my confusion again, and quote myself:
How exactly we define the position of Traditional Chinese or zh_TW?
1. Simple conversion between simplified and traditional Chinese
characters
2. Taiwanese localized traditional Chinese
This issue needs to be confirmed by the senior maintenance personnel.
(I will review the archives to confirm. If there is already a clear
definition, please forgive me.)
> and 8.Conclusion was simply where I started. Within my ability as a
> newcomer, I would be happy to help review zh_TW patches or keep
> improving the process/ documents, if that is useful to the discussion
> you are planning to start.
If we are conducting the localization of the traditional Chinese version
for Taiwan, then it would be a good idea to start by continuing
identifying these terminology issues now. However, for such similar
terminology issues, using a series of patches in bulk is better than
sending out one word correction at a time, like previous similar single
patches.
> This is also my first kernel patch, so naturally I would be glad to
> see it applied. That said, I fully respect whatever direction you and
> the docs maintainers decide is best for zh_TW as a whole, and I am
> happy to rebase or adjust it if the discussion lands somewhere that
> requires changes.
Congrats! You have made your first step.
btw, I have no say in any decision, i.e. my proposed direction has no
effect at all. I respect maintainers' decision. At the same time, I feel
ashamed that I haven't made any contribution yet.
> > I can help review patches in traditional Chinese. With the help of
> > LLM, it is fine for me to handle local terminologies in zh_TW.
>
> Thank you for offering to help with review, and thanks again for your
> comments on v1.
>
> Thanks,
> Chen-Yu
Yes, thank you very much, Dongliang! But it seems that finding a more
reasonable workflow is the best way to solve the problem. This would
also relieve the burden on our reviewers. The current situation might
not be too bad, but if it keeps going like this, it could be a problem.
^ permalink raw reply
* Re: [PATCH v3 25/26] dt-bindings: reserved-memory: Add Google Kinfo Pixel reserved memory
From: Krzysztof Kozlowski @ 2026-07-11 15:43 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Jonathan Corbet, Shuah Khan, Eugen Hristev, Arnd Bergmann,
Dennis Zhou, Tejun Heo, Christoph Lameter, Andrew Morton,
Thomas Gleixner, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, John Stultz, Stephen Boyd, Kees Cook,
Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, Barry Song, Youngjun Park, Petr Mladek,
John Ogness, Sergey Senozhatsky, Bjorn Andersson, Mathieu Poirier,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, workflows, linux-doc, linux-kernel, linux-arch,
linux-mm, linux-arm-msm, linux-remoteproc, devicetree
In-Reply-To: <20260708-meminspect-v3-v3-25-7aa5a0a74d5c@oss.qualcomm.com>
On Wed, Jul 08, 2026 at 11:02:04AM +0530, Mukesh Ojha wrote:
> +maintainers:
> + - Eugen Hristev <eugen.hristev@linaro.org>
> + - Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> +
> +description:
> + Reserved memory region for storing kernel debugging information that
> + can be read by firmware and bootloader on Google Pixel platforms.
> +
> +allOf:
> + - $ref: reserved-memory.yaml
> +
> +properties:
> + compatible:
> + const: google,debug-kinfo
I guess: google,pixel-debug-kinfo
Or maybe even specific SoC. Both title and description suggest this does
not apply to other Google devices (makes sense), so compatible should be
somehow more specific, unless debug-kinfo is already enough to identify
possible users and there is no conflict with debug-kinfo in Chromebooks,
for example?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: iio: adc: Add AD7768
From: David Lechner @ 2026-07-11 14:40 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Janani Sunil, Nuno Sá, Michael Hennerich, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Olivier Moysan,
Philipp Zabel, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Shuah Khan, linux, linux-iio, devicetree,
linux-kernel, linux-gpio, linux-doc, jananisunil.dev
In-Reply-To: <20260710013322.595f8ee4@jic23-huawei>
On 7/9/26 7:33 PM, Jonathan Cameron wrote:
>>> + adi,common-mode-output:
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum:
>>> + - avdd-avss-half
>>> + - 1.65V
>>> + - 2.5V
>>> + - 2.14V
>>> + description:
>>> + Common mode voltage output selection.
>>
>> Why not using standard regulator provider bindings for this?
>
> Interesting question. If that was done there would need to be
> a consumer which means explicit modelling of any analog circuit.
> We do that in a few cases but so far (and yup this is a driver thing
> in a dt-binding) I don't think we have any way to consumer data when
> a backend is involved.
There is also the regulator-always-on property, so strictly speaking,
a consumer is not required.
>
>>
>>> +
>>> + adi,vcm-power-down:
>>> + type: boolean
>>> + description: Power down the common mode output buffer
>>
>> Is the buffer separate from the output? In that case I would expect
>> buffer to be in the property name, otherwise this should just be
>> part of the enum options above (and the default one at that).
>>
^ permalink raw reply
* [Resend PATCH] dt-bindings: fix typos and brackets
From: Manuel Ebner @ 2026-07-11 13:38 UTC (permalink / raw)
To: Conor Dooley, Krzysztof Kozlowski, Rob Herring
Cc: devicetree, Jonathan Corbet, linux-doc, linux-kernel,
Liam Girdwood, Mark Brown, Randy Dunlap, Manuel Ebner
Add missing '(', ')', '}'
Remove needless '(', ')', '{', '}'
'lover voltage' -> 'lower voltage'
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Sorry for the resend - e-mail clients ...
Sorry for the noise the last days. When sending Documentation/ABI/ patches I got
the advice to send each change in a seperate patch. For ABI it worked very
well. That's why I did it.
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 2 +-
.../devicetree/bindings/arm/qcom,coresight-tpdm.yaml | 2 +-
.../bindings/clock/renesas,rcar-usb2-clock-sel.yaml | 4 ++--
.../devicetree/bindings/input/gpio-charlieplex-keypad.yaml | 2 +-
Documentation/devicetree/bindings/leds/backlight/88pm860x.txt | 1 +
.../devicetree/bindings/memory-controllers/renesas,dbsc.yaml | 2 +-
.../devicetree/bindings/memory-controllers/ti-aemif.txt | 4 ++--
Documentation/devicetree/bindings/mips/brcm/soc.txt | 2 +-
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 1 +
Documentation/devicetree/bindings/phy/phy-miphy365x.txt | 2 +-
Documentation/devicetree/bindings/powerpc/ibm,vas.txt | 2 +-
Documentation/devicetree/bindings/regulator/max8907.txt | 1 -
.../bindings/regulator/mediatek,mt6358-regulator.yaml | 2 +-
.../devicetree/bindings/regulator/pbias-regulator.txt | 1 +
.../devicetree/bindings/regulator/rohm,bd71837-regulator.yaml | 4 ++--
.../devicetree/bindings/regulator/rohm,bd71847-regulator.yaml | 4 ++--
.../devicetree/bindings/sound/mikroe,mikroe-proto.txt | 1 -
Documentation/devicetree/bindings/usb/iproc-udc.txt | 1 +
18 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml
b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 382d0eb4d0af..cd4040ad3437 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -314,7 +314,7 @@ properties:
- const: google,steelix-sku196608
- const: google,steelix
- const: mediatek,mt8186
- - description: Google Squirtle (Acer Chromebook Spin 311 (R724T)
+ - description: Google Squirtle (Acer Chromebook Spin 311 (R724T))
items:
- const: google,squirtle
- const: mediatek,mt8186
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
index 152403f548c3..c7301f1b28c1 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
@@ -9,7 +9,7 @@ title: Trace, Profiling and Diagnostics Monitor - TPDM
description: |
The TPDM or Monitor serves as data collection component for various dataset
- types specified in the QPMDA spec. It covers Implementation defined ((ImplDef),
+ types specified in the QPMDA spec. It covers Implementation defined (ImplDef),
Basic Counts (BC), Tenure Counts (TC), Continuous Multi-Bit (CMB), and Discrete
Single Bit (DSB). It performs data collection in the data producing clock
domain and transfers it to the data collection time domain, generally ATB
diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
index c84f29f1810f..a14be249fa33 100644
--- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
@@ -13,8 +13,8 @@ description: |
If you connect an external clock to the USB_EXTAL pin only, you should set
the clock rate to "usb_extal" node only.
If you connect an oscillator to both the USB_XTAL and USB_EXTAL, this module
- is not needed because this is default setting. (Of course, you can set the
- clock rates to both "usb_extal" and "usb_xtal" nodes.
+ is not needed because this is default setting (Of course, you can set the
+ clock rates to both "usb_extal" and "usb_xtal" nodes).
Case 1: An external clock connects to R-Car SoC
+----------+ +--- R-Car ---------------------+
diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
index c085de6dab85..c6842c017934 100644
--- a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
+++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
@@ -11,7 +11,7 @@ maintainers:
- Hugo Villeneuve <hvilleneuve@dimonoff.com>
description: |
- The charlieplex keypad supports N^2)-N different key combinations (where N is
+ The charlieplex keypad supports (N^2)-N different key combinations (where N is
the number of I/O lines). Key presses and releases are detected by configuring
only one line as output at a time, and reading other line states. This process
is repeated for each line. Diodes are required to ensure current flows in only
diff --git a/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
b/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
index 261df2799315..9e17807d2ce5 100644
--- a/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
@@ -13,3 +13,4 @@ Example:
};
backlight-2 {
};
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
index 8e3822314b25..30ad2a858844 100644
--- a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
@@ -13,7 +13,7 @@ description: |
Renesas SoCs contain one or more memory controllers. These memory
controllers differ from one SoC variant to another, and are called by
different names, e.g. "DDR Bus Controller (DBSC)", "DDR3 Bus State Controller
- (DBSC3)", or "SDRAM Bus State Controller (SBSC)").
+ (DBSC3)", or "SDRAM Bus State Controller (SBSC)".
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
index 190437a0c146..3ec0a43d4e67 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
@@ -111,7 +111,7 @@ Optional child cs node properties:
- ti,cs-read-hold-ns: read hold width, ns
Time between the deactivation of the read
- strobe and the end of the cycle (which may be
+ strobe and the end of the cycle which may be
either an address change or the deactivation of
the chip select signal.
Minimum value is 1 (0 treated as 1).
@@ -128,7 +128,7 @@ Optional child cs node properties:
- ti,cs-write-hold-ns: write hold width, ns
Time between the deactivation of the write
- strobe and the end of the cycle (which may be
+ strobe and the end of the cycle which may be
either an address change or the deactivation of
the chip select signal.
Minimum value is 1 (0 treated as 1).
diff --git a/Documentation/devicetree/bindings/mips/brcm/soc.txt
b/Documentation/devicetree/bindings/mips/brcm/soc.txt
index 3a66d3c483e1..70cd69a4f173 100644
--- a/Documentation/devicetree/bindings/mips/brcm/soc.txt
+++ b/Documentation/devicetree/bindings/mips/brcm/soc.txt
@@ -45,7 +45,7 @@ each of which may have several associated hardware blocks, which are
versioned
independently (control registers, DDR PHYs, etc.). One might consider
describing these controllers as a parent "memory controllers" block, which
contains N sub-nodes (one for each controller in the system), each of which is
-associated with a number of hardware register resources (e.g., its PHY.
+associated with a number of hardware register resources (e.g., its PHY).
== MEMC (MEMory Controller)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
index ccf82b4ee838..5927abf0c634 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
@@ -71,6 +71,7 @@ mmc0: sdhci@fe81e000 {
clock-names = "mmc";
clocks = <&clk_s_a1_ls 1>;
bus-width = <8>
+};
/* Example SD stih407 family configuration */
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
index 8772900e056a..e36fac92f0fa 100644
--- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -31,7 +31,7 @@ Required properties (port (child) node):
Optional properties (port (child) node):
- st,sata-gen : Generation of locally attached SATA IP. Expected values
- are {1,2,3). If not supplied generation 1 hardware will
+ are (1,2,3). If not supplied generation 1 hardware will
be expected
- st,pcie-tx-pol-inv : Bool property to invert the polarity PCIe Tx (Txn/Txp)
- st,sata-tx-pol-inv : Bool property to invert the polarity SATA Tx (Txn/Txp)
diff --git a/Documentation/devicetree/bindings/powerpc/ibm,vas.txt
b/Documentation/devicetree/bindings/powerpc/ibm,vas.txt
index bf11d2faf7b8..80ea975697ac 100644
--- a/Documentation/devicetree/bindings/powerpc/ibm,vas.txt
+++ b/Documentation/devicetree/bindings/powerpc/ibm,vas.txt
@@ -10,7 +10,7 @@ Required properties:
- reg : Should contain 4 pairs of 64-bit fields specifying the Hypervisor
window context start and length, OS/User window context start and length,
"Paste address" start and length, "Paste window id" start bit and number
- of bits)
+ of bits
Example:
diff --git a/Documentation/devicetree/bindings/regulator/max8907.txt
b/Documentation/devicetree/bindings/regulator/max8907.txt
index 371eccd1cd68..b04c9edd3dcd 100644
--- a/Documentation/devicetree/bindings/regulator/max8907.txt
+++ b/Documentation/devicetree/bindings/regulator/max8907.txt
@@ -66,4 +66,3 @@ Example:
...
};
};
- };
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
b/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
index c50402fcba72..4eb635179b6a 100644
--- a/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
@@ -145,7 +145,7 @@ allOf:
then:
patternProperties:
# Old regulator node name scheme (with prefix and underscores) only
- # ([^y-] is used to avoid matching -supply
+ # ([^y-]) is used to avoid matching -supply
"^(?<!buck_)(?<!ldo_)v.*[^y-](?!-supply)$": false
"^ldo_vsram-": false
# vsram_core regulator doesn't exist on MT6358
diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
index acbcb452a69a..09b07f7ab94a 100644
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
@@ -30,3 +30,4 @@ Example:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3000000>;
};
+ };
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
index 29b350a4f88a..9942ee6c60f3 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
@@ -108,8 +108,8 @@ patternProperties:
# Setups where regulator (especially the buck8) output voltage is scaled
# by adding external connection where some other regulator output is
# connected to feedback-pin (over suitable resistors) is getting popular
- # amongst users of BD71837. (This allows for example scaling down the
- # buck8 voltages to suit lover GPU voltages for projects where buck8 is
+ # amongst users of BD71837. This allows for example scaling down the
+ # buck8 voltages to suit lower GPU voltages for projects where buck8 is
# (ab)used to supply power for GPU.
#
# So we allow describing this external connection from DT and scale the
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
index 7ba4ccf723d8..158d749edaa3 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
@@ -103,8 +103,8 @@ patternProperties:
# Setups where regulator (especially the buck8) output voltage is scaled
# by adding external connection where some other regulator output is
# connected to feedback-pin (over suitable resistors) is getting popular
- # amongst users of BD71837. (This allows for example scaling down the
- # buck8 voltages to suit lover GPU voltages for projects where buck8 is
+ # amongst users of BD71837. This allows for example scaling down the
+ # buck8 voltages to suit lower GPU voltages for projects where buck8 is
# (ab)used to supply power for GPU.
#
# So we allow describing this external connection from DT and scale the
diff --git a/Documentation/devicetree/bindings/sound/mikroe,mikroe-proto.txt
b/Documentation/devicetree/bindings/sound/mikroe,mikroe-proto.txt
index 912f8fae11c5..d6fdcf457926 100644
--- a/Documentation/devicetree/bindings/sound/mikroe,mikroe-proto.txt
+++ b/Documentation/devicetree/bindings/sound/mikroe,mikroe-proto.txt
@@ -20,4 +20,3 @@ Example:
audio-codec = <&wm8731>;
dai-format = "i2s";
};
-};
diff --git a/Documentation/devicetree/bindings/usb/iproc-udc.txt
b/Documentation/devicetree/bindings/usb/iproc-udc.txt
index 272d7faf1a97..6a701ce29ff1 100644
--- a/Documentation/devicetree/bindings/usb/iproc-udc.txt
+++ b/Documentation/devicetree/bindings/usb/iproc-udc.txt
@@ -19,3 +19,4 @@ Example:
reg = <0x664e0000 0x2000>;
interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbdrd_phy>;
+ };
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: fix typos and brackets
From: Krzysztof Kozlowski @ 2026-07-11 13:27 UTC (permalink / raw)
To: Manuel Ebner, Conor Dooley, Krzysztof Kozlowski, Rob Herring
Cc: devicetree, Jonathan Corbet, linux-doc, linux-kernel,
Liam Girdwood, Mark Brown, Randy Dunlap
In-Reply-To: <3f51a907c0a5e9c44d169d67d43ebff36f8f42c8.camel@mailbox.org>
On 11/07/2026 15:18, Manuel Ebner wrote:
> - The charlieplex keypad supports N^2)-N different key combinations (where N is
> + The charlieplex keypad supports (N^2)-N different key combinations (where N is
> the number of I/O lines). Key presses and releases are detected by configuring
> only one line as output at a time, and reading other line states. This process
> is repeated for each line. Diodes are required to ensure current flows in only
> diff --git a/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
> b/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
> index 261df2799315..9e17807d2ce5 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
> @@ -13,3 +13,4 @@ Example:
> };
> backlight-2 {
> };
> + };
There is no such context in that file. Your patch looks corrupted.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: fix typos and brackets
From: Manuel Ebner @ 2026-07-11 13:18 UTC (permalink / raw)
To: Conor Dooley, Krzysztof Kozlowski, Rob Herring
Cc: devicetree, Jonathan Corbet, linux-doc, linux-kernel,
Liam Girdwood, Mark Brown, Randy Dunlap, Manuel Ebner
Add missing '(', ')', '}'
Remove needless '(', ')', '{', '}'
'lover voltage' -> 'lower voltage'
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Sorry for the noise earlier. When sending "Documentation/ABI/"-patches I got
the advice to send each change in a seperate patch. For ABI it worked very
well. That's why I did it.
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 2 +-
.../devicetree/bindings/arm/qcom,coresight-tpdm.yaml | 2 +-
.../bindings/clock/renesas,rcar-usb2-clock-sel.yaml | 4 ++--
.../devicetree/bindings/input/gpio-charlieplex-keypad.yaml | 2 +-
Documentation/devicetree/bindings/leds/backlight/88pm860x.txt | 1 +
.../devicetree/bindings/memory-controllers/renesas,dbsc.yaml | 2 +-
.../devicetree/bindings/memory-controllers/ti-aemif.txt | 4 ++--
Documentation/devicetree/bindings/mips/brcm/soc.txt | 2 +-
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 1 +
Documentation/devicetree/bindings/phy/phy-miphy365x.txt | 2 +-
Documentation/devicetree/bindings/powerpc/ibm,vas.txt | 2 +-
Documentation/devicetree/bindings/regulator/max8907.txt | 1 -
.../bindings/regulator/mediatek,mt6358-regulator.yaml | 2 +-
.../devicetree/bindings/regulator/pbias-regulator.txt | 1 +
.../devicetree/bindings/regulator/rohm,bd71837-regulator.yaml | 4 ++--
.../devicetree/bindings/regulator/rohm,bd71847-regulator.yaml | 4 ++--
.../devicetree/bindings/sound/mikroe,mikroe-proto.txt | 1 -
Documentation/devicetree/bindings/usb/iproc-udc.txt | 1 +
18 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml
b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 382d0eb4d0af..cd4040ad3437 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -314,7 +314,7 @@ properties:
- const: google,steelix-sku196608
- const: google,steelix
- const: mediatek,mt8186
- - description: Google Squirtle (Acer Chromebook Spin 311 (R724T)
+ - description: Google Squirtle (Acer Chromebook Spin 311 (R724T))
items:
- const: google,squirtle
- const: mediatek,mt8186
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
index 152403f548c3..c7301f1b28c1 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
@@ -9,7 +9,7 @@ title: Trace, Profiling and Diagnostics Monitor - TPDM
description: |
The TPDM or Monitor serves as data collection component for various dataset
- types specified in the QPMDA spec. It covers Implementation defined ((ImplDef),
+ types specified in the QPMDA spec. It covers Implementation defined (ImplDef),
Basic Counts (BC), Tenure Counts (TC), Continuous Multi-Bit (CMB), and Discrete
Single Bit (DSB). It performs data collection in the data producing clock
domain and transfers it to the data collection time domain, generally ATB
diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
index c84f29f1810f..a14be249fa33 100644
--- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
@@ -13,8 +13,8 @@ description: |
If you connect an external clock to the USB_EXTAL pin only, you should set
the clock rate to "usb_extal" node only.
If you connect an oscillator to both the USB_XTAL and USB_EXTAL, this module
- is not needed because this is default setting. (Of course, you can set the
- clock rates to both "usb_extal" and "usb_xtal" nodes.
+ is not needed because this is default setting (Of course, you can set the
+ clock rates to both "usb_extal" and "usb_xtal" nodes).
Case 1: An external clock connects to R-Car SoC
+----------+ +--- R-Car ---------------------+
diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
index c085de6dab85..c6842c017934 100644
--- a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
+++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
@@ -11,7 +11,7 @@ maintainers:
- Hugo Villeneuve <hvilleneuve@dimonoff.com>
description: |
- The charlieplex keypad supports N^2)-N different key combinations (where N is
+ The charlieplex keypad supports (N^2)-N different key combinations (where N is
the number of I/O lines). Key presses and releases are detected by configuring
only one line as output at a time, and reading other line states. This process
is repeated for each line. Diodes are required to ensure current flows in only
diff --git a/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
b/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
index 261df2799315..9e17807d2ce5 100644
--- a/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
@@ -13,3 +13,4 @@ Example:
};
backlight-2 {
};
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
index 8e3822314b25..30ad2a858844 100644
--- a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
@@ -13,7 +13,7 @@ description: |
Renesas SoCs contain one or more memory controllers. These memory
controllers differ from one SoC variant to another, and are called by
different names, e.g. "DDR Bus Controller (DBSC)", "DDR3 Bus State Controller
- (DBSC3)", or "SDRAM Bus State Controller (SBSC)").
+ (DBSC3)", or "SDRAM Bus State Controller (SBSC)".
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
index 190437a0c146..3ec0a43d4e67 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
@@ -111,7 +111,7 @@ Optional child cs node properties:
- ti,cs-read-hold-ns: read hold width, ns
Time between the deactivation of the read
- strobe and the end of the cycle (which may be
+ strobe and the end of the cycle which may be
either an address change or the deactivation of
the chip select signal.
Minimum value is 1 (0 treated as 1).
@@ -128,7 +128,7 @@ Optional child cs node properties:
- ti,cs-write-hold-ns: write hold width, ns
Time between the deactivation of the write
- strobe and the end of the cycle (which may be
+ strobe and the end of the cycle which may be
either an address change or the deactivation of
the chip select signal.
Minimum value is 1 (0 treated as 1).
diff --git a/Documentation/devicetree/bindings/mips/brcm/soc.txt
b/Documentation/devicetree/bindings/mips/brcm/soc.txt
index 3a66d3c483e1..70cd69a4f173 100644
--- a/Documentation/devicetree/bindings/mips/brcm/soc.txt
+++ b/Documentation/devicetree/bindings/mips/brcm/soc.txt
@@ -45,7 +45,7 @@ each of which may have several associated hardware blocks, which are
versioned
independently (control registers, DDR PHYs, etc.). One might consider
describing these controllers as a parent "memory controllers" block, which
contains N sub-nodes (one for each controller in the system), each of which is
-associated with a number of hardware register resources (e.g., its PHY.
+associated with a number of hardware register resources (e.g., its PHY).
== MEMC (MEMory Controller)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
index ccf82b4ee838..5927abf0c634 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
@@ -71,6 +71,7 @@ mmc0: sdhci@fe81e000 {
clock-names = "mmc";
clocks = <&clk_s_a1_ls 1>;
bus-width = <8>
+};
/* Example SD stih407 family configuration */
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
index 8772900e056a..e36fac92f0fa 100644
--- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -31,7 +31,7 @@ Required properties (port (child) node):
Optional properties (port (child) node):
- st,sata-gen : Generation of locally attached SATA IP. Expected values
- are {1,2,3). If not supplied generation 1 hardware will
+ are (1,2,3). If not supplied generation 1 hardware will
be expected
- st,pcie-tx-pol-inv : Bool property to invert the polarity PCIe Tx (Txn/Txp)
- st,sata-tx-pol-inv : Bool property to invert the polarity SATA Tx (Txn/Txp)
diff --git a/Documentation/devicetree/bindings/powerpc/ibm,vas.txt
b/Documentation/devicetree/bindings/powerpc/ibm,vas.txt
index bf11d2faf7b8..80ea975697ac 100644
--- a/Documentation/devicetree/bindings/powerpc/ibm,vas.txt
+++ b/Documentation/devicetree/bindings/powerpc/ibm,vas.txt
@@ -10,7 +10,7 @@ Required properties:
- reg : Should contain 4 pairs of 64-bit fields specifying the Hypervisor
window context start and length, OS/User window context start and length,
"Paste address" start and length, "Paste window id" start bit and number
- of bits)
+ of bits
Example:
diff --git a/Documentation/devicetree/bindings/regulator/max8907.txt
b/Documentation/devicetree/bindings/regulator/max8907.txt
index 371eccd1cd68..b04c9edd3dcd 100644
--- a/Documentation/devicetree/bindings/regulator/max8907.txt
+++ b/Documentation/devicetree/bindings/regulator/max8907.txt
@@ -66,4 +66,3 @@ Example:
...
};
};
- };
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
b/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
index c50402fcba72..4eb635179b6a 100644
--- a/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
@@ -145,7 +145,7 @@ allOf:
then:
patternProperties:
# Old regulator node name scheme (with prefix and underscores) only
- # ([^y-] is used to avoid matching -supply
+ # ([^y-]) is used to avoid matching -supply
"^(?<!buck_)(?<!ldo_)v.*[^y-](?!-supply)$": false
"^ldo_vsram-": false
# vsram_core regulator doesn't exist on MT6358
diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
index acbcb452a69a..09b07f7ab94a 100644
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
@@ -30,3 +30,4 @@ Example:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3000000>;
};
+ };
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
index 29b350a4f88a..9942ee6c60f3 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
@@ -108,8 +108,8 @@ patternProperties:
# Setups where regulator (especially the buck8) output voltage is scaled
# by adding external connection where some other regulator output is
# connected to feedback-pin (over suitable resistors) is getting popular
- # amongst users of BD71837. (This allows for example scaling down the
- # buck8 voltages to suit lover GPU voltages for projects where buck8 is
+ # amongst users of BD71837. This allows for example scaling down the
+ # buck8 voltages to suit lower GPU voltages for projects where buck8 is
# (ab)used to supply power for GPU.
#
# So we allow describing this external connection from DT and scale the
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
index 7ba4ccf723d8..158d749edaa3 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
@@ -103,8 +103,8 @@ patternProperties:
# Setups where regulator (especially the buck8) output voltage is scaled
# by adding external connection where some other regulator output is
# connected to feedback-pin (over suitable resistors) is getting popular
- # amongst users of BD71837. (This allows for example scaling down the
- # buck8 voltages to suit lover GPU voltages for projects where buck8 is
+ # amongst users of BD71837. This allows for example scaling down the
+ # buck8 voltages to suit lower GPU voltages for projects where buck8 is
# (ab)used to supply power for GPU.
#
# So we allow describing this external connection from DT and scale the
diff --git a/Documentation/devicetree/bindings/sound/mikroe,mikroe-proto.txt
b/Documentation/devicetree/bindings/sound/mikroe,mikroe-proto.txt
index 912f8fae11c5..d6fdcf457926 100644
--- a/Documentation/devicetree/bindings/sound/mikroe,mikroe-proto.txt
+++ b/Documentation/devicetree/bindings/sound/mikroe,mikroe-proto.txt
@@ -20,4 +20,3 @@ Example:
audio-codec = <&wm8731>;
dai-format = "i2s";
};
-};
diff --git a/Documentation/devicetree/bindings/usb/iproc-udc.txt
b/Documentation/devicetree/bindings/usb/iproc-udc.txt
index 272d7faf1a97..6a701ce29ff1 100644
--- a/Documentation/devicetree/bindings/usb/iproc-udc.txt
+++ b/Documentation/devicetree/bindings/usb/iproc-udc.txt
@@ -19,3 +19,4 @@ Example:
reg = <0x664e0000 0x2000>;
interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbdrd_phy>;
+ };
^ permalink raw reply related
* Re: [patch 00/18] entry: Consolidate and rework syscall entry handling
From: Magnus Lindholm @ 2026-07-11 12:29 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Peter Zijlstra, Michael Ellerman, Shrikanth Hegde,
linuxppc-dev, Kees Cook, Huacai Chen, loongarch, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Sven Schnelle, linux-s390, x86,
Mark Rutland, Jinjie Ruan, Andy Lutomirski, Oleg Nesterov,
Richard Henderson, Russell King, Catalin Marinas, Guo Ren,
Geert Uytterhoeven, Thomas Bogendoerfer, Helge Deller,
Yoshinori Sato, Richard Weinberger, Chris Zankel,
linux-arm-kernel, linux-alpha, linux-csky, linux-m68k, linux-mips,
linux-parisc, linux-sh, linux-um, Arnd Bergmann, Vineet Gupta,
Will Deacon, Brian Cain, Michal Simek, Dinh Nguyen,
David S. Miller, Andreas Larsson, linux-snps-arc, linux-hexagon,
linux-openrisc, sparclinux, linux-arch, Michal Suchánek,
Jonathan Corbet, linux-doc
In-Reply-To: <20260707181957.433213175@kernel.org>
>
> With that all architectures using the generic syscall entry code follow the
> same scheme, apply stack randomization at the correct and earliest possible
> place and skip syscall processing depending on the boolean return value of
> syscall_enter_from_user_mode[_work]().
>
> There should be no functional changes, at least there are none intended.
>
> The resulting text size for the syscall entry code on x8664 is slightly
> smaller than before these changes.
>
> Testing syscall heavy workloads and micro benchmarks shows a small
> performance gain for the general rework, but the last patch, which changes
> the logic to be more understandable has no measurable impact in either
> direction.
>
> The series applies on Linus tree and is also available from git:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git entry-rework-v1
>
Hi Thomas,
Thanks for the series.
I have an Alpha GENERIC_ENTRY series posted and planned for the next
merge window:
https://lore.kernel.org/linux-alpha/20260706170019.2941459-1-linmag7@gmail.com/T/#t
Only its final patch intersects with this work.
That patch removes Alpha's architecture-specific syscall_trace_enter()
and syscall_trace_leave() implementations, so the Alpha changes in
patches 11 and 12 will disappear once the GENERIC_ENTRY conversion is
applied.
It also currently uses syscall_enter_from_user_mode(), so I will need to
rebase it onto the new entry interface introduced by this series. I
expect the integration to be confined to the final GENERIC_ENTRY patch.
The Alpha-specific changes in patches 11 and 12 look correct to me.
Acked-by: Magnus Lindholm <linmag7@gmail.com>
^ permalink raw reply
* Re: [PATCH v19 39/40] rust: completion: Add __rust_helper to rust_helper_wait_for_completion()
From: Miguel Ojeda @ 2026-07-11 12:13 UTC (permalink / raw)
To: Byungchul Park, Gary Guo
Cc: linux-kernel, max.byungchul.park, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, boqun.feng, longman, yunseong.kim, ysk,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, neilb, bagasdotme, wsa+renesas, dave.hansen,
geert, ojeda, alex.gaynor, bjorn3_gh, lossin, a.hindborg,
aliceryhl, tmgross, rust-for-linux
In-Reply-To: <20260706061928.66713-40-byungchul@sk.com>
On Mon, Jul 6, 2026 at 8:22 AM Byungchul Park <byungchul@sk.com> wrote:
>
> This is needed to inline these helpers into Rust code, which is required
> for DEPT to play with wait_for_completion().
>
> Signed-off-by: Byungchul Park <byungchul@sk.com>
Apart from what Gary said -- why did you need to do this in a separate
patch in the same series?
Cheers,
Miguel
^ permalink raw reply
* [PATCH 3/3] tools/accounting: simplify 32-bit time_t overflow check in format_timespec()
From: wang.yaxin @ 2026-07-11 9:34 UTC (permalink / raw)
To: wang.yaxin
Cc: akpm, fan.yu9, yang.yang29, corbet, linux-kernel, linux-doc,
xu.xin16
In-Reply-To: <20260711173112482SCQEM08VED2PT1pxUYOXk@zte.com.cn>
From: Wang Yaxin <wang.yaxin@zte.com.cn>
Replace the Y2038 overflow guard in format_timespec() with a direct
narrowing truncation check ((long long)time_sec != ts->tv_sec), which
is both simpler and more robust across platforms. Also move the
time_sec assignment earlier to avoid duplication.
While at it, fix a minor alignment issue in delaytop.c by adding a
leading space to the output format string.
Signed-off-by: Wang Yaxin <wang.yaxin@zte.com.cn>
---
tools/accounting/delaytop.c | 2 +-
tools/accounting/format_timespec.c | 12 +++++-------
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/tools/accounting/delaytop.c b/tools/accounting/delaytop.c
index 1144ca325447..097b57887147 100644
--- a/tools/accounting/delaytop.c
+++ b/tools/accounting/delaytop.c
@@ -1099,7 +1099,7 @@ static void display_results(int psi_ret)
get_field_delay_values(&tasks[i], cfg.type_field, &avg_ms,
&max_ms, &max_ts);
- suc &= BOOL_FPRINT(out, "%12.2f %12.2f %20s\n",
+ suc &= BOOL_FPRINT(out, " %12.2f %12.2f %20s\n",
avg_ms, max_ms, format_timespec(&max_ts));
} else if (cfg.display_mode == MODE_MEMVERBOSE) {
suc &= BOOL_FPRINT(out, DELAY_FMT_MEMVERBOSE,
diff --git a/tools/accounting/format_timespec.c b/tools/accounting/format_timespec.c
index 1dba50cac895..d7bfd307c00b 100644
--- a/tools/accounting/format_timespec.c
+++ b/tools/accounting/format_timespec.c
@@ -14,22 +14,20 @@ const char *format_timespec(const struct __kernel_timespec *ts)
{
static char buffer[32];
struct tm tm_info;
- time_t time_sec;
+ time_t time_sec = ts->tv_sec;
if (ts->tv_sec == 0 && ts->tv_nsec == 0)
return "N/A";
/*
* On 32-bit platforms time_t is 32-bit and cannot represent
- * dates beyond Y2038. The kernel timestamp is always 64-bit,
- * so reject values that would overflow.
+ * timestamps outside [INT32_MIN, INT32_MAX]. A 64-bit kernel
+ * timestamp that does not survive the narrowing truncation is
+ * rejected to avoid silent data corruption.
*/
- if (sizeof(time_t) < sizeof(ts->tv_sec) &&
- ts->tv_sec > (__u64)((1ULL << (sizeof(time_t) * 8 - 1)) - 1))
+ if ((long long)time_sec != ts->tv_sec)
return "N/A";
- time_sec = ts->tv_sec;
-
if (!localtime_r(&time_sec, &tm_info))
return "N/A";
--
2.27.0
^ permalink raw reply related
* [PATCH 2/3] tools/accounting: factor out shared format_timespec() implementation
From: wang.yaxin @ 2026-07-11 9:33 UTC (permalink / raw)
To: wang.yaxin
Cc: akpm, fan.yu9, yang.yang29, corbet, linux-kernel, linux-doc,
xu.xin16
In-Reply-To: <20260711173112482SCQEM08VED2PT1pxUYOXk@zte.com.cn>
From: Wang Yaxin <wang.yaxin@zte.com.cn>
The same __kernel_timespec formatting logic existed independently in
both getdelays.c and delaytop.c with minor differences (strftime vs
snprintf, __kernel_time64_t vs time_t).
Create a shared format_timespec.c/h with a canonical implementation
(strftime + time_t), remove the static copies from both files, and
link both programs against the common object.
Also simplify the Makefile with a pattern rule for %.o and a static
pattern rule for the two programs that need format_timespec.o.
Signed-off-by: Wang Yaxin <wang.yaxin@zte.com.cn>
---
tools/accounting/Makefile | 12 ++++++++-
tools/accounting/delaytop.c | 39 +++------------------------
tools/accounting/format_timespec.c | 39 +++++++++++++++++++++++++++
tools/accounting/format_timespec.h | 9 +++++++
tools/accounting/getdelays.c | 32 ++--------------------
tools/include/uapi/linux/time_types.h | 18 +++++++++++++
6 files changed, 82 insertions(+), 67 deletions(-)
create mode 100644 tools/accounting/format_timespec.c
create mode 100644 tools/accounting/format_timespec.h
create mode 100644 tools/include/uapi/linux/time_types.h
diff --git a/tools/accounting/Makefile b/tools/accounting/Makefile
index 007c0bb8cbbb..22e690c853a5 100644
--- a/tools/accounting/Makefile
+++ b/tools/accounting/Makefile
@@ -3,8 +3,18 @@ CC := $(CROSS_COMPILE)gcc
CFLAGS := -I../include/uapi/
PROGS := getdelays procacct delaytop
+OBJS := format_timespec.o
all: $(PROGS)
+getdelays delaytop: %: %.o $(OBJS)
+ $(CC) $(CFLAGS) -o $@ $^
+
+procacct: procacct.o
+ $(CC) $(CFLAGS) -o $@ $^
+
+%.o: %.c
+ $(CC) $(CFLAGS) -c -o $@ $<
+
clean:
- rm -fr $(PROGS)
+ rm -fr $(PROGS) *.o
diff --git a/tools/accounting/delaytop.c b/tools/accounting/delaytop.c
index f1d26ff98792..1144ca325447 100644
--- a/tools/accounting/delaytop.c
+++ b/tools/accounting/delaytop.c
@@ -44,6 +44,8 @@
#include <linux/cgroupstats.h>
#include <stddef.h>
+#include "format_timespec.h"
+
#define PSI_PATH "/proc/pressure"
#define PSI_CPU_PATH "/proc/pressure/cpu"
#define PSI_MEMORY_PATH "/proc/pressure/memory"
@@ -817,41 +819,6 @@ static double average_ms(unsigned long long total, unsigned long long count)
return (double)total / 1000000.0 / count;
}
-/*
- * Format __kernel_timespec to human readable string (YYYY-MM-DDTHH:MM:SS)
- * Returns formatted string or "N/A" if timestamp is zero
- */
-static const char *format_kernel_timespec(struct __kernel_timespec *ts)
-{
- static char buffer[32];
- time_t time_sec;
- struct tm tm_info;
-
- /* Check if timestamp is zero (not set) */
- if (ts->tv_sec == 0 && ts->tv_nsec == 0)
- return "N/A";
-
- /* Avoid Y2038 truncation: check if timestamp fits in time_t on 32-bit platforms */
- if (sizeof(time_t) < sizeof(ts->tv_sec) &&
- ts->tv_sec > (__u64)((1ULL << (sizeof(time_t) * 8 - 1)) - 1))
- return "N/A";
-
- time_sec = (time_t)ts->tv_sec;
-
- if (localtime_r(&time_sec, &tm_info) == NULL)
- return "N/A";
-
- snprintf(buffer, sizeof(buffer), "%04d-%02d-%02dT%02d:%02d:%02d",
- tm_info.tm_year + 1900,
- tm_info.tm_mon + 1,
- tm_info.tm_mday,
- tm_info.tm_hour,
- tm_info.tm_min,
- tm_info.tm_sec);
-
- return buffer;
-}
-
/* Comparison function for sorting tasks */
static int compare_tasks(const void *a, const void *b)
{
@@ -1133,7 +1100,7 @@ static void display_results(int psi_ret)
&max_ms, &max_ts);
suc &= BOOL_FPRINT(out, "%12.2f %12.2f %20s\n",
- avg_ms, max_ms, format_kernel_timespec(&max_ts));
+ avg_ms, max_ms, format_timespec(&max_ts));
} else if (cfg.display_mode == MODE_MEMVERBOSE) {
suc &= BOOL_FPRINT(out, DELAY_FMT_MEMVERBOSE,
TASK_AVG(tasks[i], MEM),
diff --git a/tools/accounting/format_timespec.c b/tools/accounting/format_timespec.c
new file mode 100644
index 000000000000..1dba50cac895
--- /dev/null
+++ b/tools/accounting/format_timespec.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Shared __kernel_timespec formatting for tools/accounting/
+ *
+ * Formats a __kernel_timespec to an ISO 8601 timestamp string
+ * (YYYY-MM-DDTHH:MM:SS). Returns "N/A" if the timestamp is zero
+ * or does not fit in time_t.
+ */
+#include <time.h>
+#include <linux/time_types.h>
+#include "format_timespec.h"
+
+const char *format_timespec(const struct __kernel_timespec *ts)
+{
+ static char buffer[32];
+ struct tm tm_info;
+ time_t time_sec;
+
+ if (ts->tv_sec == 0 && ts->tv_nsec == 0)
+ return "N/A";
+
+ /*
+ * On 32-bit platforms time_t is 32-bit and cannot represent
+ * dates beyond Y2038. The kernel timestamp is always 64-bit,
+ * so reject values that would overflow.
+ */
+ if (sizeof(time_t) < sizeof(ts->tv_sec) &&
+ ts->tv_sec > (__u64)((1ULL << (sizeof(time_t) * 8 - 1)) - 1))
+ return "N/A";
+
+ time_sec = ts->tv_sec;
+
+ if (!localtime_r(&time_sec, &tm_info))
+ return "N/A";
+
+ strftime(buffer, sizeof(buffer), "%Y-%m-%dT%H:%M:%S", &tm_info);
+
+ return buffer;
+}
diff --git a/tools/accounting/format_timespec.h b/tools/accounting/format_timespec.h
new file mode 100644
index 000000000000..960496ebf5c2
--- /dev/null
+++ b/tools/accounting/format_timespec.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef FORMAT_TIMESPEC_H
+#define FORMAT_TIMESPEC_H
+
+#include <linux/time_types.h>
+
+const char *format_timespec(const struct __kernel_timespec *ts);
+
+#endif
diff --git a/tools/accounting/getdelays.c b/tools/accounting/getdelays.c
index 6ac30d4f96f7..d3193f670d89 100644
--- a/tools/accounting/getdelays.c
+++ b/tools/accounting/getdelays.c
@@ -30,6 +30,8 @@
#include <linux/taskstats.h>
#include <linux/cgroupstats.h>
+#include "format_timespec.h"
+
/*
* Generic macros for dealing with netlink sockets. Might be duplicated
* elsewhere. It is recommended that commercial grade applications use
@@ -221,36 +223,6 @@ static int get_family_id(int sd)
#define average_ms(t, c) (t / 1000000ULL / (c ? c : 1))
#define delay_ms(t) (t / 1000000ULL)
-/*
- * Format __kernel_timespec to human readable string (YYYY-MM-DD HH:MM:SS)
- * Returns formatted string or "N/A" if timestamp is zero
- */
-static const char *format_timespec(struct __kernel_timespec *ts)
-{
- static char buffer[32];
- struct tm tm_info;
- __kernel_time_t time_sec;
-
- /* Check if timestamp is zero (not set) */
- if (ts->tv_sec == 0 && ts->tv_nsec == 0)
- return "N/A";
-
- /* Avoid Y2038 truncation on 32-bit platforms */
- if (sizeof(time_sec) < sizeof(ts->tv_sec) &&
- ts->tv_sec > (__u64)((1ULL << (sizeof(time_sec) * 8 - 1)) - 1))
- return "N/A";
-
- time_sec = ts->tv_sec;
-
- /* Use thread-safe localtime_r */
- if (localtime_r(&time_sec, &tm_info) == NULL)
- return "N/A";
-
- strftime(buffer, sizeof(buffer), "%Y-%m-%dT%H:%M:%S", &tm_info);
-
- return buffer;
-}
-
/*
* Version compatibility note:
* Field availability depends on taskstats version (t->version),
diff --git a/tools/include/uapi/linux/time_types.h b/tools/include/uapi/linux/time_types.h
new file mode 100644
index 000000000000..375cfbdd8387
--- /dev/null
+++ b/tools/include/uapi/linux/time_types.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _TOOLS_UAPI_LINUX_TIME_TYPES_H
+#define _TOOLS_UAPI_LINUX_TIME_TYPES_H
+
+#include <linux/types.h>
+
+/*
+ * Minimal definition for use by tools/.
+ * __kernel_time64_t is always 'long long' on all architectures,
+ * so we avoid pulling in kernel-private type definitions.
+ */
+
+struct __kernel_timespec {
+ long long tv_sec;
+ long long tv_nsec;
+};
+
+#endif /* _TOOLS_UAPI_LINUX_TIME_TYPES_H */
--
2.27.0
^ permalink raw reply related
* [PATCH 1/3] delaytop: refactor repetitive delay fields into array with enum
From: wang.yaxin @ 2026-07-11 9:32 UTC (permalink / raw)
To: wang.yaxin
Cc: akpm, fan.yu9, yang.yang29, corbet, linux-kernel, linux-doc,
xu.xin16
In-Reply-To: <20260711173112482SCQEM08VED2PT1pxUYOXk@zte.com.cn>
From: Wang Yaxin <wang.yaxin@zte.com.cn>
Replace the 9 groups of (count, delay_total, delay_max, delay_max_ts)
named fields in struct task_info with a struct delay_metrics array
indexed by enum delay_type. This eliminates all unsafe pointer
arithmetic via offsetof() from compare_tasks(),
field_delay_max_and_ts(), and get_field_delay_values().
The struct field_desc now stores an enum delay_type index instead of
four separate unsigned long offset values.
Signed-off-by: Wang Yaxin <wang.yaxin@zte.com.cn>
---
tools/accounting/delaytop.c | 220 +++++++++++++++---------------------
1 file changed, 88 insertions(+), 132 deletions(-)
diff --git a/tools/accounting/delaytop.c b/tools/accounting/delaytop.c
index 1c40bb477320..f1d26ff98792 100644
--- a/tools/accounting/delaytop.c
+++ b/tools/accounting/delaytop.c
@@ -61,31 +61,51 @@
#define MAX_MSG_SIZE 1024
#define MAX_TASKS 1000
#define MAX_BUF_LEN 256
-#define SET_TASK_STAT(task_count, field) tasks[task_count].field = stats.field
#define BOOL_FPRINT(stream, fmt, ...) \
({ \
int ret = fprintf(stream, fmt, ##__VA_ARGS__); \
ret >= 0; \
})
-#define TASK_AVG(task, field) average_ms((task).field##_delay_total, (task).field##_count)
+#define TASK_AVG(task, type) \
+ average_ms((task).delays[DELAY_##type].delay_total, \
+ (task).delays[DELAY_##type].count)
#define PSI_LINE_FORMAT "%-12s %6.1f%%/%6.1f%%/%6.1f%%/%8llu(ms)\n"
#define DELAY_FMT_DEFAULT "%8.2f %8.2f %8.2f %8.2f\n"
#define DELAY_FMT_MEMVERBOSE "%8.2f %8.2f %8.2f %8.2f %8.2f %8.2f\n"
-#define SORT_FIELD(name, cmd, modes) \
- {#name, #cmd, \
- offsetof(struct task_info, name##_delay_total), \
- offsetof(struct task_info, name##_count), \
- offsetof(struct task_info, name##_delay_max), \
- offsetof(struct task_info, name##_delay_max_ts), \
- modes}
-#define SORT_FIELD_NO_MAX(name, cmd, modes) \
- {#name, #cmd, \
- offsetof(struct task_info, name##_delay_total), \
- offsetof(struct task_info, name##_count), \
- 0, \
- 0, \
- modes}
-#define END_FIELD {NULL, 0, 0, 0, 0, 0, 0}
+#define COPY_DELAY(task_idx, type, stats_prefix) \
+ do { \
+ tasks[task_idx].delays[DELAY_##type].count = \
+ stats.stats_prefix##_count; \
+ tasks[task_idx].delays[DELAY_##type].delay_total = \
+ stats.stats_prefix##_delay_total; \
+ tasks[task_idx].delays[DELAY_##type].delay_max = \
+ stats.stats_prefix##_delay_max; \
+ tasks[task_idx].delays[DELAY_##type].delay_max_ts = \
+ stats.stats_prefix##_delay_max_ts; \
+ } while (0)
+#define SORT_FIELD(name, cmd, type, modes, has_max) \
+ {#name, #cmd, type, modes, has_max}
+#define END_FIELD {NULL, 0, 0, 0, false}
+
+enum delay_type {
+ DELAY_CPU,
+ DELAY_BLKIO,
+ DELAY_SWAPIN,
+ DELAY_FREEPAGES,
+ DELAY_THRASHING,
+ DELAY_COMPACT,
+ DELAY_WPCOPY,
+ DELAY_IRQ,
+ DELAY_MEM,
+ NUM_DELAY_TYPES
+};
+
+struct delay_metrics {
+ unsigned long long count;
+ unsigned long long delay_total;
+ unsigned long long delay_max;
+ struct __kernel_timespec delay_max_ts;
+};
/* Display mode types */
#define MODE_TYPE_ALL (0xFFFFFFFF)
@@ -116,40 +136,7 @@ struct task_info {
int pid;
int tgid;
char command[TASK_COMM_LEN];
- unsigned long long cpu_count;
- unsigned long long cpu_delay_total;
- unsigned long long cpu_delay_max;
- struct __kernel_timespec cpu_delay_max_ts;
- unsigned long long blkio_count;
- unsigned long long blkio_delay_total;
- unsigned long long blkio_delay_max;
- struct __kernel_timespec blkio_delay_max_ts;
- unsigned long long swapin_count;
- unsigned long long swapin_delay_total;
- unsigned long long swapin_delay_max;
- struct __kernel_timespec swapin_delay_max_ts;
- unsigned long long freepages_count;
- unsigned long long freepages_delay_total;
- unsigned long long freepages_delay_max;
- struct __kernel_timespec freepages_delay_max_ts;
- unsigned long long thrashing_count;
- unsigned long long thrashing_delay_total;
- unsigned long long thrashing_delay_max;
- struct __kernel_timespec thrashing_delay_max_ts;
- unsigned long long compact_count;
- unsigned long long compact_delay_total;
- unsigned long long compact_delay_max;
- struct __kernel_timespec compact_delay_max_ts;
- unsigned long long wpcopy_count;
- unsigned long long wpcopy_delay_total;
- unsigned long long wpcopy_delay_max;
- struct __kernel_timespec wpcopy_delay_max_ts;
- unsigned long long irq_count;
- unsigned long long irq_delay_total;
- unsigned long long irq_delay_max;
- struct __kernel_timespec irq_delay_max_ts;
- unsigned long long mem_count;
- unsigned long long mem_delay_total;
+ struct delay_metrics delays[NUM_DELAY_TYPES];
};
/* Container statistics structure */
@@ -165,11 +152,9 @@ struct container_stats {
struct field_desc {
const char *name; /* Field name for cmdline argument */
const char *cmd_char; /* Interactive command */
- unsigned long total_offset; /* Offset of total delay in task_info */
- unsigned long count_offset; /* Offset of count in task_info */
- unsigned long max_offset; /* Offset of max delay in task_info */
- unsigned long max_ts_offset; /* Offset of max delay timestamp in task_info */
+ enum delay_type type; /* Index into task_info.delays[] */
size_t supported_modes; /* Supported display modes */
+ bool has_max; /* Whether this field has max/ts */
};
/* Program settings structure */
@@ -193,15 +178,15 @@ static int task_count;
static int running = 1;
static struct container_stats container_stats;
static const struct field_desc sort_fields[] = {
- SORT_FIELD(cpu, c, MODE_DEFAULT | MODE_TYPE),
- SORT_FIELD(blkio, i, MODE_DEFAULT | MODE_TYPE),
- SORT_FIELD(irq, q, MODE_DEFAULT | MODE_TYPE),
- SORT_FIELD_NO_MAX(mem, m, MODE_DEFAULT | MODE_MEMVERBOSE),
- SORT_FIELD(swapin, s, MODE_MEMVERBOSE | MODE_TYPE),
- SORT_FIELD(freepages, r, MODE_MEMVERBOSE | MODE_TYPE),
- SORT_FIELD(thrashing, t, MODE_MEMVERBOSE | MODE_TYPE),
- SORT_FIELD(compact, p, MODE_MEMVERBOSE | MODE_TYPE),
- SORT_FIELD(wpcopy, w, MODE_MEMVERBOSE | MODE_TYPE),
+ SORT_FIELD(cpu, c, DELAY_CPU, MODE_DEFAULT | MODE_TYPE, true),
+ SORT_FIELD(blkio, i, DELAY_BLKIO, MODE_DEFAULT | MODE_TYPE, true),
+ SORT_FIELD(irq, q, DELAY_IRQ, MODE_DEFAULT | MODE_TYPE, true),
+ SORT_FIELD(mem, m, DELAY_MEM, MODE_DEFAULT | MODE_MEMVERBOSE, false),
+ SORT_FIELD(swapin, s, DELAY_SWAPIN, MODE_MEMVERBOSE | MODE_TYPE, true),
+ SORT_FIELD(freepages, r, DELAY_FREEPAGES, MODE_MEMVERBOSE | MODE_TYPE, true),
+ SORT_FIELD(thrashing, t, DELAY_THRASHING, MODE_MEMVERBOSE | MODE_TYPE, true),
+ SORT_FIELD(compact, p, DELAY_COMPACT, MODE_MEMVERBOSE | MODE_TYPE, true),
+ SORT_FIELD(wpcopy, w, DELAY_WPCOPY, MODE_MEMVERBOSE | MODE_TYPE, true),
END_FIELD
};
static int sort_selected;
@@ -433,20 +418,20 @@ static void parse_args(int argc, char **argv)
/* Calculate average delay in milliseconds for overall memory */
static void set_mem_delay_total(struct task_info *t)
{
- t->mem_delay_total = t->swapin_delay_total +
- t->freepages_delay_total +
- t->thrashing_delay_total +
- t->compact_delay_total +
- t->wpcopy_delay_total;
+ t->delays[DELAY_MEM].delay_total = t->delays[DELAY_SWAPIN].delay_total +
+ t->delays[DELAY_FREEPAGES].delay_total +
+ t->delays[DELAY_THRASHING].delay_total +
+ t->delays[DELAY_COMPACT].delay_total +
+ t->delays[DELAY_WPCOPY].delay_total;
}
static void set_mem_count(struct task_info *t)
{
- t->mem_count = t->swapin_count +
- t->freepages_count +
- t->thrashing_count +
- t->compact_count +
- t->wpcopy_count;
+ t->delays[DELAY_MEM].count = t->delays[DELAY_SWAPIN].count +
+ t->delays[DELAY_FREEPAGES].count +
+ t->delays[DELAY_THRASHING].count +
+ t->delays[DELAY_COMPACT].count +
+ t->delays[DELAY_WPCOPY].count;
}
/* Create a raw netlink socket and bind */
@@ -758,38 +743,14 @@ static void fetch_and_fill_task_info(int pid, const char *comm)
strncpy(tasks[task_count].command, comm,
TASK_COMM_LEN - 1);
tasks[task_count].command[TASK_COMM_LEN - 1] = '\0';
- SET_TASK_STAT(task_count, cpu_count);
- SET_TASK_STAT(task_count, cpu_delay_total);
- SET_TASK_STAT(task_count, cpu_delay_max);
- SET_TASK_STAT(task_count, cpu_delay_max_ts);
- SET_TASK_STAT(task_count, blkio_count);
- SET_TASK_STAT(task_count, blkio_delay_total);
- SET_TASK_STAT(task_count, blkio_delay_max);
- SET_TASK_STAT(task_count, blkio_delay_max_ts);
- SET_TASK_STAT(task_count, swapin_count);
- SET_TASK_STAT(task_count, swapin_delay_total);
- SET_TASK_STAT(task_count, swapin_delay_max);
- SET_TASK_STAT(task_count, swapin_delay_max_ts);
- SET_TASK_STAT(task_count, freepages_count);
- SET_TASK_STAT(task_count, freepages_delay_total);
- SET_TASK_STAT(task_count, freepages_delay_max);
- SET_TASK_STAT(task_count, freepages_delay_max_ts);
- SET_TASK_STAT(task_count, thrashing_count);
- SET_TASK_STAT(task_count, thrashing_delay_total);
- SET_TASK_STAT(task_count, thrashing_delay_max);
- SET_TASK_STAT(task_count, thrashing_delay_max_ts);
- SET_TASK_STAT(task_count, compact_count);
- SET_TASK_STAT(task_count, compact_delay_total);
- SET_TASK_STAT(task_count, compact_delay_max);
- SET_TASK_STAT(task_count, compact_delay_max_ts);
- SET_TASK_STAT(task_count, wpcopy_count);
- SET_TASK_STAT(task_count, wpcopy_delay_total);
- SET_TASK_STAT(task_count, wpcopy_delay_max);
- SET_TASK_STAT(task_count, wpcopy_delay_max_ts);
- SET_TASK_STAT(task_count, irq_count);
- SET_TASK_STAT(task_count, irq_delay_total);
- SET_TASK_STAT(task_count, irq_delay_max);
- SET_TASK_STAT(task_count, irq_delay_max_ts);
+ COPY_DELAY(task_count, CPU, cpu);
+ COPY_DELAY(task_count, BLKIO, blkio);
+ COPY_DELAY(task_count, SWAPIN, swapin);
+ COPY_DELAY(task_count, FREEPAGES, freepages);
+ COPY_DELAY(task_count, THRASHING, thrashing);
+ COPY_DELAY(task_count, COMPACT, compact);
+ COPY_DELAY(task_count, WPCOPY, wpcopy);
+ COPY_DELAY(task_count, IRQ, irq);
set_mem_count(&tasks[task_count]);
set_mem_delay_total(&tasks[task_count]);
task_count++;
@@ -912,10 +873,10 @@ static int compare_tasks(const void *a, const void *b)
return 0;
}
- total1 = *(unsigned long long *)((char *)t1 + cfg.sort_field->total_offset);
- total2 = *(unsigned long long *)((char *)t2 + cfg.sort_field->total_offset);
- count1 = *(unsigned long long *)((char *)t1 + cfg.sort_field->count_offset);
- count2 = *(unsigned long long *)((char *)t2 + cfg.sort_field->count_offset);
+ total1 = t1->delays[cfg.sort_field->type].delay_total;
+ total2 = t2->delays[cfg.sort_field->type].delay_total;
+ count1 = t1->delays[cfg.sort_field->type].count;
+ count2 = t2->delays[cfg.sort_field->type].count;
avg1 = average_ms(total1, count1);
avg2 = average_ms(total2, count2);
@@ -929,22 +890,17 @@ static int compare_tasks(const void *a, const void *b)
static void field_delay_max_and_ts(const struct task_info *task, const struct field_desc *field,
unsigned long long *max_ns, struct __kernel_timespec *max_ts)
{
- if (!field || !field->max_offset) {
+ if (!field || !field->has_max) {
*max_ns = 0;
if (max_ts)
memset(max_ts, 0, sizeof(*max_ts));
return;
}
- *max_ns = *(unsigned long long *)((char *)task + field->max_offset);
+ *max_ns = task->delays[field->type].delay_max;
- if (max_ts) {
- if (field->max_ts_offset)
- *max_ts = *(struct __kernel_timespec *)((char *)task +
- field->max_ts_offset);
- else
- memset(max_ts, 0, sizeof(*max_ts));
- }
+ if (max_ts)
+ *max_ts = task->delays[field->type].delay_max_ts;
}
/* Get delay values for a specific field */
@@ -954,15 +910,15 @@ static void get_field_delay_values(const struct task_info *task, const struct fi
{
unsigned long long total, count, max;
- if (!field || !field->max_offset) {
+ if (!field) {
*avg_ms = 0;
*max_ms = 0;
memset(max_ts, 0, sizeof(*max_ts));
return;
}
- total = *(unsigned long long *)((char *)task + field->total_offset);
- count = *(unsigned long long *)((char *)task + field->count_offset);
+ total = task->delays[field->type].delay_total;
+ count = task->delays[field->type].count;
*avg_ms = average_ms(total, count);
field_delay_max_and_ts(task, field, &max, max_ts);
@@ -1180,18 +1136,18 @@ static void display_results(int psi_ret)
avg_ms, max_ms, format_kernel_timespec(&max_ts));
} else if (cfg.display_mode == MODE_MEMVERBOSE) {
suc &= BOOL_FPRINT(out, DELAY_FMT_MEMVERBOSE,
- TASK_AVG(tasks[i], mem),
- TASK_AVG(tasks[i], swapin),
- TASK_AVG(tasks[i], freepages),
- TASK_AVG(tasks[i], thrashing),
- TASK_AVG(tasks[i], compact),
- TASK_AVG(tasks[i], wpcopy));
+ TASK_AVG(tasks[i], MEM),
+ TASK_AVG(tasks[i], SWAPIN),
+ TASK_AVG(tasks[i], FREEPAGES),
+ TASK_AVG(tasks[i], THRASHING),
+ TASK_AVG(tasks[i], COMPACT),
+ TASK_AVG(tasks[i], WPCOPY));
} else {
suc &= BOOL_FPRINT(out, DELAY_FMT_DEFAULT,
- TASK_AVG(tasks[i], cpu),
- TASK_AVG(tasks[i], blkio),
- TASK_AVG(tasks[i], irq),
- TASK_AVG(tasks[i], mem));
+ TASK_AVG(tasks[i], CPU),
+ TASK_AVG(tasks[i], BLKIO),
+ TASK_AVG(tasks[i], IRQ),
+ TASK_AVG(tasks[i], MEM));
}
}
--
2.27.0
^ permalink raw reply related
* [PATCH 0/3] tools/accounting: refactor delay fields and share format_timespec()
From: wang.yaxin @ 2026-07-11 9:31 UTC (permalink / raw)
To: akpm, fan.yu9, yang.yang29
Cc: corbet, linux-kernel, linux-doc, xu.xin16, wang.yaxin
From: Wang Yaxin <wang.yaxin@zte.com.cn>
- Convert per-field delay members in struct task_info to an array indexed
by enum delay_type, eliminating offsetof() pointer arithmetic.
- Factor out a common format_timespec() implementation shared by getdelays
and delaytop, using strftime for cleaner timestamp formatting.
- Replace the complex sizeof/ULL/shift Y2038 guard with a direct narrowing
truncation check ((long long)time_sec != ts->tv_sec).
Wang Yaxin (3):
delaytop: refactor repetitive delay fields into array with enum
tools/accounting: factor out shared format_timespec() implementation
tools/accounting: simplify 32-bit time_t overflow check in
format_timespec()
tools/accounting/Makefile | 12 +-
tools/accounting/delaytop.c | 261 +++++++++-----------------
tools/accounting/format_timespec.c | 37 ++++
tools/accounting/format_timespec.h | 9 +
tools/accounting/getdelays.c | 32 +---
tools/include/uapi/linux/time_types.h | 18 ++
6 files changed, 169 insertions(+), 200 deletions(-)
create mode 100644 tools/accounting/format_timespec.c
create mode 100644 tools/accounting/format_timespec.h
create mode 100644 tools/include/uapi/linux/time_types.h
--
2.27.0
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: hwmon: (pmbus/max20830): add enable-gpios property and complete examples
From: Krzysztof Kozlowski @ 2026-07-11 8:46 UTC (permalink / raw)
To: Alexis Czezar Torreno, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260706-dev-max20830c-v2-1-37761e89bb5f@analog.com>
On 06/07/2026 04:08, Alexis Czezar Torreno wrote:
> Adding an entry for the MAX20830 EN (enable) pin. This pin exist but
> was not included before. Also edited examples entry to be more complete.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> ---
> .../devicetree/bindings/hwmon/pmbus/adi,max20830.yaml | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] docs: custom.css: don't limit randering to old 800px monitors
From: Mauro Carvalho Chehab @ 2026-07-11 7:48 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Linux Doc Mailing List, linux-kernel, Clinton Phillips,
Daniel Lundberg Pedersen, Hans Verkuil, Mauro Carvalho Chehab,
Petr Vorel, Randy Dunlap, Rito Rhymes, Shuah Khan, linux-media
In-Reply-To: <20260711001015.3cf5d166@foz.lan>
On Sat, 11 Jul 2026 00:10:15 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> On Fri, 10 Jul 2026 13:52:55 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
>
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> >
> > > On Fri, 10 Jul 2026 09:27:23 -0600
> > > Jonathan Corbet <corbet@lwn.net> wrote:
> > >
> > >> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> > >>
> > >> > Right now, base.css style imposes a maximum limit of 800 horizontal
> > >> > pixels to be compatible with very old SVGA monitors.
> > >> >
> > >> > Remove such artificial limit, letting the output to be adjusted to
> > >> > the browser windows size.
> > >> >
> > >> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > >> > ---
> > >> > Documentation/sphinx-static/custom.css | 2 ++
> > >> > 1 file changed, 2 insertions(+)
> > >> >
> > >> > diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
> > >> > index 5aa0a1ed9864..1055db7dc1dd 100644
> > >> > --- a/Documentation/sphinx-static/custom.css
> > >> > +++ b/Documentation/sphinx-static/custom.css
> > >> > @@ -3,6 +3,8 @@
> > >> > * CSS tweaks for the Alabaster theme
> > >> > */
> > >> >
> > >> > +div.body { max-width: none; }
> > >> > +
> > >>
> > >> 800px is clearly a dumb limit, I have no problem changing that. Going
> > >> to arbitrary width doesn't seem good for readability, though. What do
> > >> you think about, instead, setting a limit in a resolution-independent
> > >> say, to (say) 60em?
> > >
> > > 60em also seems too small, considering the size of tables we have on
> > > media. Some tables have one column for each bit, plus one or two other
> > > columns, so the table would easily have up to 34 columns. After adding
> > > long fourcc codes there and V4L macro names, it can easily be very big,
> > > in terms of "em" measures.
> >
> > I did say "say" :) I don't feel the need to argue too much about the
> > exact value. I do believe, though, that excessively wide columns are
> > not good human factors in general.
>
> If one gets a big enough "em" to fit the largest tables and ascii artwork,
> I'm ok using "em" but one would need to double check what's the bigger
> one, which would require some time and someone would need to periodically
> review it.
>
> My feeling is that, on media, the bigger tables are the pixformat ones,
> but maybe the biggest one is somewhere else.
>
> Most (if not all) artwork fits on 80 columns, but I vaguely remember
> some that were bigger (can't remember if they were changed to fit on
> 80 cols).
>
> Probably a way to define a limit that covers artwork would be to run a script
> to get the max column size for .rst files. Not perfect because of indentation,
> on codeblocks, but it could work as a hint. Unfortunately, this won't work
> for tables using flat-table (which is used on ~235 files - most on media,
> but ~20 files elsewhere).
After sleeping on it, I think that we need something bigger than 100em,
as this is is the checkpatch.pl max columns warning limit. To align with
most pixfmt tables on media, 120em sounds a reasonable limit.
Patch enclosed.
Thanks,
Mauro
[PATCH] docs: custom.css: don't limit randering to old 800px monitors
Right now, base.css style imposes a maximum limit of 800 horizontal
pixels to be compatible with very old SVGA monitors.
This is not enough to display some tables like pixformat ones on
media. Instead, use a more realistic maximum limit.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
index 2e019c8f8a56..be33d9ed1280 100644
--- a/Documentation/sphinx-static/custom.css
+++ b/Documentation/sphinx-static/custom.css
@@ -3,6 +3,8 @@
* CSS tweaks for the Alabaster theme
*/
+div.body { max-width: 120em; }
+
/* Shrink the headers a bit */
div.body h1 { font-size: 180%; }
div.body h2 { font-size: 150%; }
^ permalink raw reply related
* Re: [PATCH] arm64: errata: Mitigate AmpereOne erratum AC03_CPU_57 and AC04_CPU_29
From: Marc Zyngier @ 2026-07-11 7:37 UTC (permalink / raw)
To: D Scott Phillips
Cc: Oliver Upton, Catalin Marinas, Will Deacon, Jonathan Corbet,
Shuah Khan, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Mark Rutland, Zeng Heng, Wei Xu, Vladimir Murzin,
Lucas Wei, Kuninori Morimoto, Sascha Bischoff, Yicong Yang,
Yeoreum Yun, linux-arm-kernel, linux-doc, linux-kernel, kvmarm
In-Reply-To: <20260710222128.416581-1-scott@os.amperecomputing.com>
Hi Scott,
On Fri, 10 Jul 2026 23:21:28 +0100,
D Scott Phillips <scott@os.amperecomputing.com> wrote:
>
> On AmpereOne, deactivating a physical interrupt through ICC_DIR_EL1 or
> ICC_EOIRx_EL1 (depending on EOImode) which is not active, but is the
> highest priority pending interrupt causes the cpu to lose the interrupt
> pending state and also prevents the delivery of future interrupts.
>
> Work around this in the vgic, avoiding the cpu issue.
Thanks for getting to the bottom of this.
>
> Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com>
> ---
>
> Hi Marc, we've tracked down the nested virt hang reported
> previously[1] to a cpu erratum in AmpereOne[2].
>
> Here I'm just sort of parroting the change you had posted for
> debugging. I'm not familiar with the vgic logic well enough to know if
> this change is sufficient and doesn't have some unintended
> consequences. I guess read this more are as "I've tested this and I'm
> not seeing it hang now."
>
> Sorry for sending this half-baked, I didn't want to further delay the
> errata details on my ongoing vgic education. I'm happy to take any
> advice you can give, otherwise I'll continue familiarizing myself and
> will hopefully later have a patch which I can actually claim I think is
> correct.
No worries.
To be perfectly clear, what I posted at [1] *is* a bug-fix. A very
minor one. Nothing wrong should come as a result, except when it does,
such as in your case.
The core reason why this happens is that the L2 will have EOI'd its
timer, and that the HW bit set in the LR will have propagated the
deactivation all the way to the HW redistributor. Then L1 takes over,
and needs to reconcile the LR state with its own, namely its view of
the active state.
The issue here is that when dealing with a nested vgic (the state
contained in the LRs is for L2, not L1), the deactivation process
doesn't need to involve the HW again -- this has already be dealt
with, and results in the double deactivation I mentioned in my email.
>
> [1]: https://lore.kernel.org/linux-arm-kernel/87ecjybz30.wl-maz@kernel.org/
>
> [2]: https://amperecomputing.com/products/developer-errata
>
> The updates with AC03_CPU_57 and AC04_CPU_29 have not yet been
> published at the time I'm writing this. They should be coming
> soon. I've reproduced the full entries from those two coming documents
> collapsed together below:
>
> | {AC03_CPU_57, AC04_CPU_29}: Deactivation of the non-active, highest
> | priority pending interrupt prevents further interrupt delivery.
> |
> | Functional Unit: CPU
> |
> | Category: 4
> |
> | Affected Version(s): AmpereOne AC03 A0, AmpereOne AC03 B0
> | Affected Version(s): AmpereOne AC04 A0, AmpereOne AC04_1 A0
> |
> | Fixed Version(s): Open
> |
> | Overview:
> |
> | If software directly deactivates a physical interrupt which is not
> | in the active state, and the interrupt is also currently the highest
> | priority pending interrupt, then interrupt delivery will cease on
> | that PE. Deactivation can happen either through ICC_EOIRx_EL1 if
> | ICC_CTLR_EL1.EOIMode==0, or through ICC_DIR_EL1 if
> | ICC_CTLR_EL1.EOIMode==1. Deactivation of virtual interrupts that are
> | redirected through ICV_ registers will not cause this issue, even
> | when the virtual interrupt deactivation triggers a physical
> | interrupt deactivation through ICH_LR<n>_EL2.HW=1.
OK, that's pretty good news. Can I safely assume that your HW doesn't
support VLPIs/VSGIs in any form (no GICv4+)?
> |
> | This has been observed with Nested Virtualization starting with
> | Linux-KVM v6.19.
> |
> | Impact:
> |
> | Physical interrupts will not be delivered after the deactivation of
> | the non-active, highest priority pending interrupt. A core may
> | appear to be hung.
> |
> | Workaround:
> |
> | Software must only deactivate interrupts which are currently active
>
>
> Documentation/arch/arm64/silicon-errata.rst | 4 ++++
> arch/arm64/Kconfig | 17 +++++++++++++++++
> arch/arm64/kernel/cpu_errata.c | 15 +++++++++++++++
> arch/arm64/kvm/vgic/vgic-v3.c | 4 +++-
> arch/arm64/tools/cpucaps | 1 +
> 5 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 014aa1c215a16..89130404ce572 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -55,10 +55,14 @@ stable kernels.
> +----------------+-----------------+-----------------+-----------------------------+
> | Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 |
> +----------------+-----------------+-----------------+-----------------------------+
> +| Ampere | AmpereOne | AC03_CPU_57 | AMPERE_ERRATUM_AC03_CPU_57 |
> ++----------------+-----------------+-----------------+-----------------------------+
> | Ampere | AmpereOne AC04 | AC04_CPU_10 | AMPERE_ERRATUM_AC03_CPU_38 |
> +----------------+-----------------+-----------------+-----------------------------+
> | Ampere | AmpereOne AC04 | AC04_CPU_23 | AMPERE_ERRATUM_AC04_CPU_23 |
> +----------------+-----------------+-----------------+-----------------------------+
> +| Ampere | AmpereOne AC04 | AC04_CPU_29 | AMPERE_ERRATUM_AC03_CPU_57 |
> ++----------------+-----------------+-----------------+-----------------------------+
> +----------------+-----------------+-----------------+-----------------------------+
> | ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
> +----------------+-----------------+-----------------+-----------------------------+
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b3afe0688919b..ee5421283d8df 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -436,6 +436,23 @@ config AMPERE_ERRATUM_AC03_CPU_38
>
> If unsure, say Y.
>
> +config AMPERE_ERRATUM_AC03_CPU_57
> + bool "AmpereOne: AC03_CPU_57: Deactivation of the non-active, highest priority pending interrupt prevents further interrupt delivery."
> + default y
> + help
> + This option adds an alternative code sequence to work around Ampere
> + errata AC03_CPU_57 and AC04_CPU_29 on AmpereOne.
> +
> + Deactivating a physical interrupt through ICC_DIR_EL1 or
> + ICC_EOIR1_EL1 (depending on EOImode) which is not active, but is the
> + highest priority pending interrupt causes the cpu to lose the
> + interrupt pending state and also prevents the delivery of future
> + interrupts.
> +
> + The workaround is for KVM to not deactivate interrupts for nested vgics.
> +
> + If unsure, say Y.
> +
> config AMPERE_ERRATUM_AC04_CPU_23
> bool "AmpereOne: AC04_CPU_23: Failure to synchronize writes to HCR_EL2 may corrupt address translations."
> default y
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 1995e1198648e..9b03dccd55e09 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -631,6 +631,14 @@ static const struct midr_range erratum_ac03_cpu_38_list[] = {
> };
> #endif
>
> +#ifdef CONFIG_AMPERE_ERRATUM_AC03_CPU_57
> +static const struct midr_range erratum_ac03_cpu_57_list[] = {
> + MIDR_ALL_VERSIONS(MIDR_AMPERE1),
> + MIDR_ALL_VERSIONS(MIDR_AMPERE1A),
> + {},
> +};
> +#endif
> +
> #ifdef CONFIG_AMPERE_ERRATUM_AC04_CPU_23
> static const struct midr_range erratum_ac04_cpu_23_list[] = {
> MIDR_ALL_VERSIONS(MIDR_AMPERE1A),
> @@ -987,6 +995,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> ERRATA_MIDR_RANGE_LIST(erratum_ac03_cpu_38_list),
> },
> #endif
> +#ifdef CONFIG_AMPERE_ERRATUM_AC03_CPU_57
> + {
> + .desc = "AmpereOne erratum AC03_CPU_57",
> + .capability = ARM64_WORKAROUND_AMPERE_AC03_CPU_57,
> + ERRATA_MIDR_RANGE_LIST(erratum_ac03_cpu_57_list),
> + },
> +#endif
> #ifdef CONFIG_AMPERE_ERRATUM_AC04_CPU_23
> {
> .desc = "AmpereOne erratum AC04_CPU_23",
> diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
> index 9e841e7afd4a7..8f1d10872360c 100644
> --- a/arch/arm64/kvm/vgic/vgic-v3.c
> +++ b/arch/arm64/kvm/vgic/vgic-v3.c
> @@ -275,7 +275,9 @@ void vgic_v3_deactivate(struct kvm_vcpu *vcpu, u64 val)
> lr = vgic_v3_compute_lr(vcpu, irq) & ~ICH_LR_ACTIVE_BIT;
> }
>
> - if (lr & ICH_LR_HW)
> + if ((lr & ICH_LR_HW) &&
> + !(cpus_have_final_cap(ARM64_WORKAROUND_AMPERE_AC03_CPU_57) &&
> + vgic_state_is_nested(vcpu)))
> vgic_v3_deactivate_phys(FIELD_GET(ICH_LR_PHYS_ID_MASK, lr));
I think this is slightly overkill. The hack I posted should be enough,
and we can replace all the capability business with a simple comment
referencing the errata numbers and the entries in silicon-errata.rst.
Use the information provided above to beef up the commit message and
stick:
Cc: stable@vger.kernel.org
Fixes: 6dd333c8942b2 ("KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive")
so that we know how far this needs to be backported.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>
From: Yureka Lilian @ 2026-07-11 7:35 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
Anshuman Khandual
Cc: linux-doc, linux-kernel, linux-arm-kernel, Yureka Lilian
Overriding the idle mechanism might be useful for debugging and performance
testing. Add a cmdline parameter for it, similar to the existing idle=
parameter already present for the x86 and ppc architectures.
It is also useful on platforms where the WFI instruction misbehaves,
such as Apple Silicon SoCs. Generally, a misbehaving instruction should
be treated as an erratum and patched using the alternatives framework.
However, in the Apple Silicon case we need more flexibility because it is
difficult to detect whether the erratum applies. For example, Linux VMs
inside macOS have the same MIDR and may even seem like they're running
in EL2 in the case of NV, but should continue using WFI (it's trapped and
handled correctly by the hypervisor there). Thus, we prefer to
let the m1n1 bootloader add the idle=nop parameter[1].
Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
---
Changes in v2:
- Applied suggestions by Anshuman Khandual (Thanks!)
- Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
---
Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
arch/arm64/kernel/idle.c | 30 +++++++++++++++++++++++--
arch/arm64/kernel/idle.h | 13 +++++++++++
arch/arm64/lib/delay.c | 5 ++++-
4 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b2d7d3540ded..d7f5471edf8f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2239,6 +2239,29 @@ Kernel parameters
idle=nomwait: Disable mwait for CPU C-states
+ [ARM64,EARLY]
+ Format: idle=wfi, idle=yield, idle=nop
+
+ idle=wfi: Use the WFI (Wait For Interrupt) hint
+ instruction in the idle loop. This is the default and
+ allows the CPU to enter a low-power state until an
+ interrupt arrives.
+
+ idle=yield: Use the YIELD hint instruction instead of
+ WFI. CPUs supporting simultaneous multi-threading (SMT),
+ can continue executing another thread when the current
+ thread reaches the idle loop. This will make the CPUs
+ eat more power, but may be useful to get slightly better
+ performance in some applications, since the CPUs will
+ not enter a low-power state.
+
+ idle=nop: Do not execute any idle instruction in the
+ idle loop. This is useful on platforms where WFI
+ misbehaves, leading to system instability or loss of CPU
+ state. This will make the CPUs eat more power, but may
+ give slightly better performance in some applications,
+ since the CPUs will not enter a low-power state.
+
idxd.sva= [HW]
Format: <bool>
Allow force disabling of Shared Virtual Memory (SVA)
diff --git a/arch/arm64/kernel/idle.c b/arch/arm64/kernel/idle.c
index 05cfb347ec26..f161711a9954 100644
--- a/arch/arm64/kernel/idle.c
+++ b/arch/arm64/kernel/idle.c
@@ -11,6 +11,27 @@
#include <asm/cpufeature.h>
#include <asm/sysreg.h>
+#include "idle.h"
+
+enum arm64_idle_mode idle = ARM64_IDLE_WFI;
+
+static int __init setup_idle(char *arg)
+{
+ if (!arg)
+ return -1;
+ else if (!strcmp(arg, "wfi"))
+ idle = ARM64_IDLE_WFI;
+ else if (!strcmp(arg, "yield"))
+ idle = ARM64_IDLE_YIELD;
+ else if (!strcmp(arg, "nop"))
+ idle = ARM64_IDLE_NOP;
+ else
+ return -1;
+
+ return 0;
+}
+early_param("idle", setup_idle);
+
/*
* cpu_do_idle()
*
@@ -26,8 +47,13 @@ void __cpuidle cpu_do_idle(void)
arm_cpuidle_save_irq_context(&context);
- dsb(sy);
- wfi();
+ if (likely(idle == ARM64_IDLE_WFI)) {
+ dsb(sy);
+ wfi();
+ } else if (idle == ARM64_IDLE_YIELD) {
+ dsb(sy);
+ asm volatile("yield" ::: "memory");
+ }
arm_cpuidle_restore_irq_context(&context);
}
diff --git a/arch/arm64/kernel/idle.h b/arch/arm64/kernel/idle.h
new file mode 100644
index 000000000000..693f981c9a91
--- /dev/null
+++ b/arch/arm64/kernel/idle.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ARM64_KERNEL_IDLE_H
+#define __ARM64_KERNEL_IDLE_H
+
+extern enum arm64_idle_mode idle;
+
+enum arm64_idle_mode {
+ ARM64_IDLE_WFI,
+ ARM64_IDLE_YIELD,
+ ARM64_IDLE_NOP,
+};
+
+#endif
diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
index e278e060e78a..2452990ed37a 100644
--- a/arch/arm64/lib/delay.c
+++ b/arch/arm64/lib/delay.c
@@ -15,6 +15,8 @@
#include <clocksource/arm_arch_timer.h>
+#include "../kernel/idle.h"
+
#define USECS_TO_CYCLES(time_usecs) \
xloops_to_cycles((time_usecs) * 0x10C7UL)
@@ -49,7 +51,8 @@ void __delay(unsigned long cycles)
* Start with WFIT. If an interrupt makes us resume
* early, use a WFET loop to complete the delay.
*/
- wfit(end);
+ if (likely(idle == ARM64_IDLE_WFI))
+ wfit(end);
while ((__delay_cycles() - start) < cycles)
wfet(end);
} else if (arch_timer_evtstrm_available()) {
---
base-commit: bee763d5f341b99cf472afeb508d4988f62a6ca1
change-id: 20260705-arm64-idle-param-c27fc0e7ea05
Best regards,
--
Yureka Lilian <yureka@cyberchaos.dev>
^ permalink raw reply related
* Re: [PATCH v8 1/7] KVM: arm64: Disallow vPMU when pPMUs do not cover all CPUs
From: Akihiko Odaki @ 2026-07-11 6:18 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, Shuah Khan,
linux-arm-kernel, kvmarm, linux-kernel, linux-hardening, devel,
kvm, linux-doc, linux-kselftest
In-Reply-To: <7bf6c440-5f14-4326-9800-9821adc4e2e4@rsg.ci.i.u-tokyo.ac.jp>
On 2026/07/08 17:32, Akihiko Odaki wrote:
> On 2026/07/08 3:20, Oliver Upton wrote:
>> On Tue, Jul 07, 2026 at 08:08:03PM +0900, Akihiko Odaki wrote:
>>> On 2026/07/07 2:04, Oliver Upton wrote:
>>>> Hi,
>>>>
>>>> On Mon, Jul 06, 2026 at 07:03:24PM +0900, Akihiko Odaki wrote:
>>>>> Commit ec3eb9ed6081 ("KVM: arm64: PMU: Disallow vPMU on non-uniform
>>>>> PMUVer") made KVM reject vPMU unless the system-wide PMUVer is usable.
>>>>> That covers systems where PMUv3 is absent or non-uniform, as well as
>>>>> systems where IMPDEF PMUv3 sysreg traps are unavailable.
>>>>>
>>>>> However, KVM can still accept vPMU when all CPUs uniformly trap PMUv3
>>>>> sysregs, but the pPMUs registered with KVM only cover a subset of
>>>>> possible CPUs.
>>>>>
>>>>> Reject vPMU unless the registered pPMUs cover every possible CPU.
>>>>> This avoids carrying support for partial pPMU coverage into the
>>>>> fixed-counters-only UAPI introduced later in the series.
>>>>
>>>> Doesn't CPU hotplug screw this up? I could online a CPU that doesn't
>>>> have a PMU after creating the VM.>
>>>> I'd rather just change ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS to become a
>>>> system feature. That way any CPU which breaks the system-wide
>>>> assumption
>>>> cannot be onlined.
>>>
>>> ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS only says that IMPDEF PMUv3
>>> sysregs are
>>> trapped. It does not say that KVM has a driver-backed PMU usable for
>>> PMUv3
>>> emulation. This patch checks that extra requirement.
>>>
>>> I re-checked CPU hotplug. Onlining a CPU without a PMU later does not
>>> make
>>> an accepted VM unsafe, since the check is against cpu_possible_mask.
>>
>> Sorry, I missed that this was against the possible mask.
>>
>>> The problem is the reverse case on ACPI: this check can disable vPMU
>>> when a
>>> possible CPU is offline. DT populates supported_cpus at boot, while ACPI
>>> initially populates it only from online CPUs and grows it as matching
>>> CPUs
>>> come online.
>>>
>>> That makes this patch too conservative. In practice, I do not expect
>>> systems
>>> to mix CPUs with and without a usable PMU. A better approach is
>>> probably to
>>> treat such a host as out of spec and add TAINT_CPU_OUT_OF_SPEC. We
>>> already
>>> do that for architectural PMUv3 by detecting mismatches in
>>> ID_AA64DFR0_EL1.PMUVer; we can do the same for
>>> ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS with non-standard PMUs.
>>
>> The presence of the workaround is, by definition, out of spec. I just
>> never bothered tainting the kernel because these machines are already
>> TAINT_CPU_OUT_OF_SPEC by way of the broken VGIC.
>>
>> Ok, so how about you keep the check that you're doing here and promote
>> IMPDEF_TRAPS to a system-wide feature? That would satisfy the two
>> preconditions we have for PMU emulation, which is system register traps
>> and a backing arm_pmu that understands PMUv3 events.
>
> This check turned out to be faulty: it can disable PMU emulation on ACPI
> systems when a possible CPU is offline, because ACPI grows
> arm_pmu::supported_cpus as matching CPUs come online.
>
> My current plan is:
>
> - drop the possible-mask coverage check, to avoid breaking ACPI;
> - promote ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS to
> ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE, so the system will have the
> feature only if all online CPUs implement it;
> - explicitly taint hosts with ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS,
> matching what KVM already does for non-architectural VGICs. The
> comment will make it clear that this is out of spec because KVM cannot
> make the usual architectural assumptions about PMUv3 sysreg traps and
> uniform driver-backed PMU availability.
I sent a new revision implementing these changes, but due to a rebase
mistake it was also sent as v8.
However, it still does not cover every case of non-uniform driver-backed
PMU availability. With ACPI, if a CPU is brought online whose MIDR was
not represented by any CPU online during PMU probing, the PMU code
cannot associate it with an existing arm_pmu or register a new one.
This can happen even when PMUVer is uniform across CPUs.
I therefore plan to take a simpler approach: when KVM cannot find a
registered pPMU for the vCPU's current CPU, emit a one-time warning and
set TAINT_CPU_OUT_OF_SPEC, matching the treatment of mismatched CPU
features.
Regards,
Akihiko Odaki
>
> That lets the code keep assuming uniform PMU availability without adding
> an ACPI-hostile possible-CPU check, and makes that assumption explicit
> for humans like me and tools such as Sashiko [1].
>
> [1] https://sashiko.dev/#/patchset/20260706-hybrid-v8-0-
> de459617b59d@rsg.ci.i.u-tokyo.ac.jp?part=6
>
> Regards,
> Akihiko Odaki
>
^ permalink raw reply
* Re: [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
From: Andrew Morton @ 2026-07-11 5:49 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alG2-RSitzPWClAX@skinsburskii>
On Fri, 10 Jul 2026 20:22:33 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> On Fri, Jul 10, 2026 at 03:11:51PM -0700, Andrew Morton wrote:
> > On Fri, 10 Jul 2026 14:26:20 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> >
> > > This series extends the HMM framework to support userfaultfd-backed memory
> > > by allowing the mmap read lock to be dropped during hmm_range_fault().
> >
> > Thanks. This seems fairly mature and mostly-reviewed so I'll give it a
> > spin in mm.git's mm-new branch.
> >
> > Unfortunately Sashiko wasn't able to apply this or v7. I'm not sure
> > what base you were using. Hopefully there's a reason for a v9 so we
> > can retry this.
> >
>
> I rebased this series on top of mm-new right before sending it out.
> Should I have used a different branch?
mm-new is good - Sashiko attempts that. But it's changing rapidly at
this point in the development cycle.
^ permalink raw reply
* Re: [PATCH v8 5/8] drm/nouveau: Use hmm_range_fault_unlocked_timeout() for SVM faults
From: Andrew Morton @ 2026-07-11 5:48 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alG1k3JsoywE2CBM@skinsburskii>
On Fri, 10 Jul 2026 20:16:35 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> On Fri, Jul 10, 2026 at 03:12:22PM -0700, Andrew Morton wrote:
> > On Fri, 10 Jul 2026 14:26:58 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> >
> > > @@ -683,15 +683,11 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
> > > goto out;
> > > }
> > >
> > > - range.notifier_seq = mmu_interval_read_begin(range.notifier);
> > > - mmap_read_lock(mm);
> > > - ret = hmm_range_fault(&range);
> > > - mmap_read_unlock(mm);
> > > - if (ret) {
> > > - if (ret == -EBUSY)
> > > - continue;
> > > + ret = hmm_range_fault_unlocked_timeout(&range,
> > > + max(timeout - jiffies,
> > > + 1L));
> >
> > "1UL" here? I'd have expected min() to warn, as it likes to do.
>
> I'm not sure... The "timeout - jiffies" can become negative.
> Won't 1UL convert both of them to "UL" and thus make the comparison
> overflow?
`timeout' and `jiffies' are both unsigned long.
^ permalink raw reply
* Re: [PATCH v8 4/8] mshv: Use hmm_range_fault_unlocked_timeout() for region faults
From: Andrew Morton @ 2026-07-11 5:46 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alG1JwgUK44dCiN4@skinsburskii>
On Fri, 10 Jul 2026 20:14:47 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > > + mutex_lock(®ion->mreg_mutex);
> > > +
> > > + if (mmu_interval_read_retry(range.notifier, range.notifier_seq)) {
> > > + mutex_unlock(®ion->mreg_mutex);
> > > + cond_resched();
> > > + goto again;
> > > + }
> > > +
> >
> > If the calling process has realtime scheduling policy and either a)
> > we're uniprocessor or b) this process and the holder of
> > interval_sub->invalidate_seq are both pinned to the same CPU then
> > cond_resched() won't do anything, and this might be an infinite loop?
>
> Yes, looks like it might.
> What can be done to prevent this?
Well the best way is remove the polling loop and use a proper sleep/wakeup
mechanism - mutex_lock()/prepare_to_wait()/etc.
If the polling loop is to be retained then maybe msleep(1) or
usleep_range()?
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Weijie Yuan @ 2026-07-11 5:21 UTC (permalink / raw)
To: Dongliang Mu
Cc: 葉宸佑, Hu Haowen, Alex Shi, Jonathan Corbet,
Shuah Khan, Dongliang Mu, linux-doc, linux-kernel
In-Reply-To: <06fcda8b-b507-409e-9ded-299baa6ddd09@hust.edu.cn>
On Fri, Jul 10, 2026 at 09:05:47PM +0800, Dongliang Mu wrote:
>
> On 7/10/26 4:49 PM, 葉宸佑 wrote:
> > Gentle ping.
> >
> > This v2 addressed the review comments from Alex and Dongliang.
> > Is there anything else I should improve, or is it queued somewhere
> > I might have missed?
>
> It seems like Alex is not on the cc list. None can pick up this patch.
>
> Add Alex into this thread.
>
> Dongliang Mu
I suspect that some contributors would run the get_maintainers.pl script
or b4 prep --auto-to-cc, so they did not cc Alex, as they didn't know
the current situation. Because I noticed that for both two versions,
Chen-yu didn't cc Alex or Dongliang or Yanteng. Am I right, @Chen-yu? ;-)
Therefore, how about adding zh_CN team temporarily to zh_TW in
MAINTAINERS file? So that it won't confuse newcomers in the near future.
Thanks,
Weijie
^ permalink raw reply
* Re: [PATCH 1/4] Docs/ABI/damon: fix typo in intervals_goal sysfs path
From: Song Hu @ 2026-07-11 5:04 UTC (permalink / raw)
To: SJ Park; +Cc: damon, linux-mm, linux-kernel, linux-doc, stable
In-Reply-To: <20260711002127.32005-1-sj@kernel.org>
于 2026年7月11日 GMT+08:00 08:21:25，SJ Park <sj@kernel.org> 写道：
>On Fri, 10 Jul 2026 07:17:37 -0700 SJ Park <sj@kernel.org> wrote:
>
>> On Fri, 10 Jul 2026 12:47:34 +0800 Song Hu <husong@kylinos.cn> wrote:
>>
>> > The ABI document spells the DAMON sysfs directory as "intrvals_goal"
>> > (missing 'e') in four What: entries, but the kernel creates it as
>> > "intervals_goal" (mm/damon/sysfs.c). Following the documented path
>> > therefore yields a non-existent directory.
>>
>> Nice catch!
>>
>> >
>> > Fixes: e2b23dc62369 ("Docs/ABI/damon: document intervals auto-tuning ABI")
>> > Cc: stable@vger.kernel.org
>
Hi SJ,
Thanks a lot for your thorough reviews and ongoing support.
I will strictly check the complete recipient list generated by get_maintainer.pl for all future patch submissions.
>By the way, hotfixes and non-hotfixes usually take different trains to the
>mainline. Having those in single series therefore makes maintainer works
>difficult. I understand this is not a hotfix but just somewhat worthy to
>eventually be backported to stable kernels. So no problem for this.
>
>But, from the next time, please clarify or use different series for Cc: stable@
>patches.
>
As I’m still figuring out the correct timing for Cc: stable@ , I will consult with you prior to adding this tag next time and separate stable-bound patches into an independent series.
Thanks,
Song
>
>Thanks,
>SJ
>
>[...]
^ permalink raw reply
* Re: [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
From: Stanislav Kinsburskii @ 2026-07-11 3:22 UTC (permalink / raw)
To: Andrew Morton
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <20260710151151.1e193eedd0cf2591ae392f76@linux-foundation.org>
On Fri, Jul 10, 2026 at 03:11:51PM -0700, Andrew Morton wrote:
> On Fri, 10 Jul 2026 14:26:20 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
>
> > This series extends the HMM framework to support userfaultfd-backed memory
> > by allowing the mmap read lock to be dropped during hmm_range_fault().
>
> Thanks. This seems fairly mature and mostly-reviewed so I'll give it a
> spin in mm.git's mm-new branch.
>
> Unfortunately Sashiko wasn't able to apply this or v7. I'm not sure
> what base you were using. Hopefully there's a reason for a v9 so we
> can retry this.
>
I rebased this series on top of mm-new right before sending it out.
Should I have used a different branch?
Thanks,
Stanislav
> I have a few niggles, nothing major...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox