* Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Askar Safin @ 2026-03-24 6:15 UTC (permalink / raw)
To: babu.moger; +Cc: kvm, linux-coco, linux-doc, linux-kernel, x86
In-Reply-To: <cover.1773347820.git.babu.moger@amd.com>
Please, remove me from CC list in future versions of this patchset
--
Askar Safin
^ permalink raw reply
* Re: [PATCH v9 0/5] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-03-24 6:14 UTC (permalink / raw)
To: Sourabh Jain, Andrew Morton
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, bhe, vgoyal, dyoung, rdunlap,
peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees, elver,
paulmck, lirongqing, safinaskar, rppt, ardb, leitao, jbohac,
cfsworks, osandov, tangyouling, ritesh.list, eajames,
songshuaishuai, kevin.brodsky, samuel.holland, vishal.moola,
junhui.liu, coxu, liaoyuanhong, fuqiang.wang, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <595e793d-adc3-4acb-af18-f0a3cf2d5e73@linux.ibm.com>
On 2026/3/24 12:29, Sourabh Jain wrote:
>
>
> On 24/03/26 09:32, Jinjie Ruan wrote:
>>
>> On 2026/3/24 0:55, Andrew Morton wrote:
>>> On Mon, 23 Mar 2026 15:27:40 +0800 Jinjie Ruan
>>> <ruanjinjie@huawei.com> wrote:
>>>
>>>> The crash memory allocation, and the exclude of crashk_res,
>>>> crashk_low_res
>>>> and crashk_cma memory are almost identical across different
>>>> architectures,
>>>> This patch set handle them in crash core in a general way, which
>>>> eliminate
>>>> a lot of duplication code.
>>>>
>>>> And add support for crashkernel CMA reservation for arm64 and riscv.
>>> Thanks. AI review has completed and it asks questions:
>>> https://sashiko.dev/#/patchset/20260323072745.2481719-1-ruanjinjie@huawei.com
>> I believe it identified 4 valid issues:
>>
>> - The already discovered crashk_low_res not excluded bug in the existing
>> RISC-V code.
>>
>> - An existing memory leak issue in the existing PowerPC code.
>
> Yes and suggested approach to fix the issue looks good.
> Which is basically replace return with goto out.
>
> diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
> index 898742a5205c..1426d2099bad 100644
> --- a/arch/powerpc/kexec/crash.c
> +++ b/arch/powerpc/kexec/crash.c
> @@ -440,7 +440,7 @@ static void update_crash_elfcorehdr(struct kimage
> *image, struct memory_notify *
> ret = get_crash_memory_ranges(&cmem);
> if (ret) {
> pr_err("Failed to get crash mem range\n");
> - return;
> + goto out;
> }
>
> /*
>
> Are you planning to handle this in this patch series? Or do you want me
> to send a separate fix patch?
Yes, will fix it in v10, thanks for the clarification.
Best regards,
Jinjie
>
>
>>
>> - The ordering issue of adding CMA ranges to "linux,usable-memory-range".
>>
>> - An existing concurrency issue. A Concurrent memory hotplug may occur
>> between reading memblock and attempting to fill cmem during kexec_load()
>> for almost all existing architectures，I'm not sure if this is a
>> practical issue in reality..
What are your thoughts on this concurrency issue?
>>
>> Race Condition Scenario
>>
>> Timeline:
>> ---------------------------------------------------------------------
>> T1: kexec_load() syscall starts
>> T2: kexec_trylock() acquires kexec_lock
>> T3: crash_prepare_headers() is called
>> T4: arch_get_system_nr_ranges() queries memblock → finds 100 memory
>> ranges
>> T5: cmem = alloc_cmem(100) allocates buffer for 100 ranges
>> T6: [RACE WINDOW] Another process triggers memory hotplug
>> T7: add_memory() → lock_device_hotplug() → memblock_add_node()
>> T8: New memory region added to memblock
>> T9: arch_crash_populate_cmem() iterates: now finds 102 ranges
>> T10: cmem->ranges[100] → OUT OF BOUNDS WRITE!
>> T11: cmem->ranges[101] → OUT OF BOUNDS WRITE!
>> T12: Kernel crash or memory corruption
>>
>> Why This Happens
>>
>> 1. Different locks used:
>> - kexec_load() uses kexec_trylock (atomic_t)
>> - Memory hotplug uses device_hotplug_lock (mutex)
>> 2. No synchronization between these two operations
>> 3. Time-of-check to time-of-use (TOCTOU) issue:
>> - Step T4-T5: We query the number of ranges and allocate buffer
>> - Step T6-T9: Memory hotplug adds new ranges between query and
>> population
>>
>>
>>
>> Any comments or suggestions on the following approach?
>>
>>
>> int crash_prepare_headers(...)
>> {
>> unsigned int max_nr_ranges;
>> struct crash_mem *cmem;
>> int ret;
>>
>> lock_device_hotplug();
>>
>> max_nr_ranges = arch_get_system_nr_ranges();
>> // ...
>> ret = arch_crash_populate_cmem(cmem);
>> // ...
>>
>> unlock_device_hotplug();
>> return ret;
>> }
>>
>>
>
^ permalink raw reply
* Re: [PATCH v6 40/40] arm64: mpam: Add initial MPAM documentation
From: Gavin Shan @ 2026-03-24 6:04 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-41-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> MPAM (Memory Partitioning and Monitoring) is now exposed to user-space via
> resctrl. Add some documentation so the user knows what features to expect.
>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes by Ben:
> Some tidying, update for current heuristics
>
> Changes from v4:
> Fix unusual indentation
>
> Changes from v5:
> Drop cdp (under CONFIG_EXPERT) and mbwu (back with abmc)
> ---
> Documentation/arch/arm64/index.rst | 1 +
> Documentation/arch/arm64/mpam.rst | 72 ++++++++++++++++++++++++++++++
> 2 files changed, 73 insertions(+)
> create mode 100644 Documentation/arch/arm64/mpam.rst
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH] Documentation: PCI: Document decoding of TLP Header in AER messages
From: mx2pg @ 2026-03-24 5:53 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Lukas Wunner, Jonathan Corbet, linux-pci, linux-doc,
Mika Westerberg, Ilpo Jarvinen, Kai-Heng Feng
In-Reply-To: <20260323165038.GA830530@bhelgaas>
One thing worth calling out: starting with PCIe 6.0, Flit Mode is
mandatory at 64.0 GT/s and supported at all PCIe link speeds, so a
Flit-capable PCIe 6.x link may operate below 64.0 GT/s and still be
in Flit Mode. The raw TLP Header bytes do not encode the framing —
the same four bytes decode to entirely different packet types in
non-Flit vs Flit framing. The negotiated mode can be read from the
Flit Mode Status bit in Link Status 2, or via lspci -vv on a recent
pciutils build.
tlp-tool defaults to non-Flit, which is correct for the vast majority
of hardware deployed today. That will change: as PCIe 6.x adoption
grows, a significant share of TLP debugging will involve Flit Mode
links, and this is already a concern among switch and device vendors
working through the transition. Users on Flit Mode links must pass
--flit:
# non-Flit link (default, most common today)
curl -L https://git.kernel.org/linus/2ca1c94ce0b6 | rtlp-tool --aer
# Flit Mode link
curl -L https://git.kernel.org/linus/2ca1c94ce0b6 | rtlp-tool --aer --flit
It may be worth a one-liner in the Documentation patch:
For PCIe 6.x links with Flit Mode negotiated (check Flit Mode Status
in Link Status 2, or lspci -vv), pass --flit to rtlp-tool.
Maciej
On Monday, March 23rd, 2026 at 9:50 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Mon, Mar 23, 2026 at 07:52:39AM +0100, Lukas Wunner wrote:
> > The prefix/header of the TLP that caused an error is recorded by the Root
> > Complex and emitted to the kernel log in raw hex format. Document the
> > existence and usage of tlp-tool, which allows decoding the TLP Header
> > into human-readable form.
> >
> > The TLP Header hints at the root cause of an error, yet is often ignored
> > because of its seeming opaqueness. Instead, PCIe errors are frequently
> > worked around by a change in the kernel without fully understanding the
> > actual source of the problem. With more documentation on available tools
> > we'll hopefully come up with better solutions.
> >
> > There are also wireshark dissectors for TLPs, but it seems they expect a
> > complete TLP, not just the header, and they cannot grok the hex format
> > emitted by the kernel directly. tlp-tool appears to be the most cut and
> > dried solution out there.
> >
> > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> > Cc: Maciej Grochowski <mx2pg@pm.me>
>
> Applied to pci/for-linus for v7.0, thanks!
>
> I tweaked the commit log to note that the Header Log is in the AER
> Capability, which may be in any PCIe function.
>
> > ---
> > We could also go one step further and point users to this tool
> > in a printk_once() message when the first error occurs.
> > For now, just amending the documentation is probably sufficient.
> >
> > Documentation/PCI/pcieaer-howto.rst | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/PCI/pcieaer-howto.rst b/Documentation/PCI/pcieaer-howto.rst
> > index 3210c47..90fdfdd 100644
> > --- a/Documentation/PCI/pcieaer-howto.rst
> > +++ b/Documentation/PCI/pcieaer-howto.rst
> > @@ -85,6 +85,16 @@ In the example, 'Requester ID' means the ID of the device that sent
> > the error message to the Root Port. Please refer to PCIe specs for other
> > fields.
> >
> > +The 'TLP Header' is the prefix/header of the TLP that caused the error
> > +in raw hex format. To decode the TLP Header into human-readable form
> > +one may use tlp-tool:
> > +
> > +https://github.com/mmpg-x86/tlp-tool
> > +
> > +Example usage::
> > +
> > + curl -L https://git.kernel.org/linus/2ca1c94ce0b6 | rtlp-tool --aer
> > +
> > AER Ratelimits
> > --------------
> >
> > --
> > 2.51.0
> >
>
^ permalink raw reply
* [PATCH net-next v2] docs/mlx5: Fix typo subfuction
From: Ryohei Kinugawa @ 2026-03-24 5:34 UTC (permalink / raw)
To: rrameshbabu, saeedm, leon, tariqt, mbloch, davem, edumazet, kuba,
pabeni, horms, corbet, skhan
Cc: Ryohei Kinugawa, netdev, linux-rdma, linux-doc, joe
Fix two typos:
- 'Subfunctons' -> 'Subfunctions'
- 'subfuction' -> 'subfunction'
Reviewed-by: Joe Damato <joe@dama.to>
Signed-off-by: Ryohei Kinugawa <ryohei.kinugawa@gmail.com>
---
.../device_drivers/ethernet/mellanox/mlx5/kconfig.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
index 34e911480108..b45d6871492c 100644
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
+++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
@@ -114,13 +114,13 @@ Enabling the driver and kconfig options
**CONFIG_MLX5_SF=(y/n)**
| Build support for subfunction.
-| Subfunctons are more light weight than PCI SRIOV VFs. Choosing this option
+| Subfunctions are more light weight than PCI SRIOV VFs. Choosing this option
| will enable support for creating subfunction devices.
**CONFIG_MLX5_SF_MANAGER=(y/n)**
-| Build support for subfuction port in the NIC. A Mellanox subfunction
+| Build support for subfunction port in the NIC. A Mellanox subfunction
| port is managed through devlink. A subfunction supports RDMA, netdevice
| and vdpa device. It is similar to a SRIOV VF but it doesn't require
| SRIOV support.
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: hwmon: isl68137: Add compatible strings for RAA228942 and RAA228943
From: Dawei Liu @ 2026-03-24 5:08 UTC (permalink / raw)
To: krzk
Cc: linux, linux-hwmon, linux-kernel, linux-doc, devicetree,
linux-renesas-soc, robh, krzk+dt, conor+dt, corbet, skhan,
geert+renesas, magnus.damm, grant.peltier.jg, linda.xin.jg,
tabreztalks, Dawei Liu
> Please wrap commit message according to Linux coding style / submission process (neither too early nor over the limit):
I will fix the commit message wrapping in v4 to comply with the Linux
coding style guidelines (max 75 characters per line for commit message
body).
> Anyway, same feedback as last time. I responded to your answer but you
> did not give me chance anymore and sent v3.
I apologize for that. I should have waited for your feedback before
sending v3.
You are right about the fallback compatible approach. While the hardware
differs in some aspects, at the hwmon PMBus interface level currently
supported by this driver they are indeed compatible with RAA228244.
The binding change would be:
- items:
- enum:
- renesas,raa228942
- renesas,raa228943
- const: renesas,raa228244
And the driver only adds I2C device IDs without dedicated OF match
entries, relying on the fallback compatible for devicetree matching.
I will send v4 updated patch series shortly.
Thank you for your patience and detailed feedback.
Best regards,
Dawei
^ permalink raw reply
* Re: [PATCH v9 0/5] arm64/riscv: Add support for crashkernel CMA reservation
From: Sourabh Jain @ 2026-03-24 4:29 UTC (permalink / raw)
To: Jinjie Ruan, Andrew Morton
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, bhe, vgoyal, dyoung, rdunlap,
peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees, elver,
paulmck, lirongqing, safinaskar, rppt, ardb, leitao, jbohac,
cfsworks, osandov, tangyouling, ritesh.list, eajames,
songshuaishuai, kevin.brodsky, samuel.holland, vishal.moola,
junhui.liu, coxu, liaoyuanhong, fuqiang.wang, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <4cfde40c-673a-12b0-dfc5-703d582d6ea9@huawei.com>
On 24/03/26 09:32, Jinjie Ruan wrote:
>
> On 2026/3/24 0:55, Andrew Morton wrote:
>> On Mon, 23 Mar 2026 15:27:40 +0800 Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>>
>>> The crash memory allocation, and the exclude of crashk_res, crashk_low_res
>>> and crashk_cma memory are almost identical across different architectures,
>>> This patch set handle them in crash core in a general way, which eliminate
>>> a lot of duplication code.
>>>
>>> And add support for crashkernel CMA reservation for arm64 and riscv.
>> Thanks. AI review has completed and it asks questions:
>> https://sashiko.dev/#/patchset/20260323072745.2481719-1-ruanjinjie@huawei.com
> I believe it identified 4 valid issues:
>
> - The already discovered crashk_low_res not excluded bug in the existing
> RISC-V code.
>
> - An existing memory leak issue in the existing PowerPC code.
Yes and suggested approach to fix the issue looks good.
Which is basically replace return with goto out.
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index 898742a5205c..1426d2099bad 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -440,7 +440,7 @@ static void update_crash_elfcorehdr(struct kimage
*image, struct memory_notify *
ret = get_crash_memory_ranges(&cmem);
if (ret) {
pr_err("Failed to get crash mem range\n");
- return;
+ goto out;
}
/*
Are you planning to handle this in this patch series? Or do you want me
to send a separate fix patch?
>
> - The ordering issue of adding CMA ranges to "linux,usable-memory-range".
>
> - An existing concurrency issue. A Concurrent memory hotplug may occur
> between reading memblock and attempting to fill cmem during kexec_load()
> for almost all existing architectures，I'm not sure if this is a
> practical issue in reality..
>
> Race Condition Scenario
>
> Timeline:
> ---------------------------------------------------------------------
> T1: kexec_load() syscall starts
> T2: kexec_trylock() acquires kexec_lock
> T3: crash_prepare_headers() is called
> T4: arch_get_system_nr_ranges() queries memblock → finds 100 memory ranges
> T5: cmem = alloc_cmem(100) allocates buffer for 100 ranges
> T6: [RACE WINDOW] Another process triggers memory hotplug
> T7: add_memory() → lock_device_hotplug() → memblock_add_node()
> T8: New memory region added to memblock
> T9: arch_crash_populate_cmem() iterates: now finds 102 ranges
> T10: cmem->ranges[100] → OUT OF BOUNDS WRITE!
> T11: cmem->ranges[101] → OUT OF BOUNDS WRITE!
> T12: Kernel crash or memory corruption
>
> Why This Happens
>
> 1. Different locks used:
> - kexec_load() uses kexec_trylock (atomic_t)
> - Memory hotplug uses device_hotplug_lock (mutex)
> 2. No synchronization between these two operations
> 3. Time-of-check to time-of-use (TOCTOU) issue:
> - Step T4-T5: We query the number of ranges and allocate buffer
> - Step T6-T9: Memory hotplug adds new ranges between query and
> population
>
>
>
> Any comments or suggestions on the following approach?
>
>
> int crash_prepare_headers(...)
> {
> unsigned int max_nr_ranges;
> struct crash_mem *cmem;
> int ret;
>
> lock_device_hotplug();
>
> max_nr_ranges = arch_get_system_nr_ranges();
> // ...
> ret = arch_crash_populate_cmem(cmem);
> // ...
>
> unlock_device_hotplug();
> return ret;
> }
>
>
^ permalink raw reply related
* Re: [PATCH v6 39/40] arm_mpam: Quirk CMN-650's CSU NRDY behaviour
From: Gavin Shan @ 2026-03-24 4:21 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc
In-Reply-To: <20260313144617.3420416-40-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> CMN-650 is afflicted with an erratum where the CSU NRDY bit never clears.
> This tells us the monitor never finishes scanning the cache. The erratum
> document says to wait the maximum time, then ignore the field.
>
> Add a flag to indicate whether this is the final attempt to read the
> counter, and when this quirk is applied, ignore the NRDY field.
>
> This means accesses to this counter will always retry, even if the counter
> was previously programmed to the same values.
>
> The counter value is not expected to be stable, it drifts up and down with
> each allocation and eviction. The CSU register provides the value for a
> point in time.
>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since v3:
> parentheses in macro
> ---
> Documentation/arch/arm64/silicon-errata.rst | 3 +++
> drivers/resctrl/mpam_devices.c | 12 ++++++++++++
> drivers/resctrl/mpam_internal.h | 6 ++++++
> 3 files changed, 21 insertions(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 38/40] arm_mpam: Add workaround for T241-MPAM-6
From: Gavin Shan @ 2026-03-24 4:20 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-39-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: Shanker Donthineni <sdonthineni@nvidia.com>
>
> The registers MSMON_MBWU_L and MSMON_MBWU return the number of requests
> rather than the number of bytes transferred.
>
> Bandwidth resource monitoring is performed at the last level cache, where
> each request arrive in 64Byte granularity. The current implementation
> returns the number of transactions received at the last level cache but
> does not provide the value in bytes. Scaling by 64 gives an accurate byte
> count to match the MPAM specification for the MSMON_MBWU and MSMON_MBWU_L
> registers. This patch fixes the issue by reporting the actual number of
> bytes instead of the number of transactions from __ris_msmon_read().
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since rfc:
> MPAM_IIDR_NVIDIA_T421 -> MPAM_IIDR_NVIDIA_T241
> Don't apply workaround to MSMON_MBWU_LWD
> ---
> Documentation/arch/arm64/silicon-errata.rst | 2 ++
> drivers/resctrl/mpam_devices.c | 26 +++++++++++++++++++--
> drivers/resctrl/mpam_internal.h | 1 +
> 3 files changed, 27 insertions(+), 2 deletions(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 37/40] arm_mpam: Add workaround for T241-MPAM-4
From: Gavin Shan @ 2026-03-24 4:19 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-38-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: Shanker Donthineni <sdonthineni@nvidia.com>
>
> In the T241 implementation of memory-bandwidth partitioning, in the absence
> of contention for bandwidth, the minimum bandwidth setting can affect the
> amount of achieved bandwidth. Specifically, the achieved bandwidth in the
> absence of contention can settle to any value between the values of
> MPAMCFG_MBW_MIN and MPAMCFG_MBW_MAX. Also, if MPAMCFG_MBW_MIN is set
> zero (below 0.78125%), once a core enters a throttled state, it will never
> leave that state.
>
> The first issue is not a concern if the MPAM software allows to program
> MPAMCFG_MBW_MIN through the sysfs interface. This patch ensures program
> MBW_MIN=1 (0.78125%) whenever MPAMCFG_MBW_MIN=0 is programmed.
>
> In the scenario where the resctrl doesn't support the MBW_MIN interface via
> sysfs, to achieve bandwidth closer to MBW_MAX in the absence of contention,
> software should configure a relatively narrow gap between MBW_MIN and
> MBW_MAX. The recommendation is to use a 5% gap to mitigate the problem.
>
> Clear the feature MBW_MIN feature from the class to ensure we don't
> accidentally change behaviour when resctrl adds support for a MBW_MIN
> interface.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com>
> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> [ morse: Added as second quirk, adapted to use the new intermediate values
> in mpam_extend_config() ]
>
> Changes since rfc:
> MPAM_IIDR_NVIDIA_T421 -> MPAM_IIDR_NVIDIA_T241
> Handling when reset_mbw_min is set
>
> Changes since v3:
> Move the 5% gap policy back here
> Clear mbw_min feature in class
>
> Changes since v5:
> Calculate min from max when resetting
> ---
> Documentation/arch/arm64/silicon-errata.rst | 2 +
> drivers/resctrl/mpam_devices.c | 55 +++++++++++++++++++--
> drivers/resctrl/mpam_internal.h | 1 +
> 3 files changed, 55 insertions(+), 3 deletions(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 36/40] arm_mpam: Add workaround for T241-MPAM-1
From: Gavin Shan @ 2026-03-24 4:16 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-37-ben.horgan@arm.com>
Hi Ben,
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: Shanker Donthineni <sdonthineni@nvidia.com>
>
> The MPAM bandwidth partitioning controls will not be correctly configured,
> and hardware will retain default configuration register values, meaning
> generally that bandwidth will remain unprovisioned.
>
> To address the issue, follow the below steps after updating the MBW_MIN
> and/or MBW_MAX registers.
>
> - Perform 64b reads from all 12 bridge MPAM shadow registers at offsets
> (0x360048 + slice*0x10000 + partid*8). These registers are read-only.
> - Continue iterating until all 12 shadow register values match in a loop.
> pr_warn_once if the values fail to match within the loop count 1000.
> - Perform 64b writes with the value 0x0 to the two spare registers at
> offsets 0x1b0000 and 0x1c0000.
>
> In the hardware, writes to the MPAMCFG_MBW_MAX MPAMCFG_MBW_MIN registers
> are transformed into broadcast writes to the 12 shadow registers. The
> final two writes to the spare registers cause a final rank of downstream
> micro-architectural MPAM registers to be updated from the shadow copies.
> The intervening loop to read the 12 shadow registers helps avoid a race
> condition where writes to the spare registers occur before all shadow
> registers have been updated.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
>
> Changes from James:
> Merged the min/max update into a single
> mpam_quirk_post_config_change() helper. Stashed the t241_id in the msc
> instead of carrying the physical address around. Test the msc quirk bit
> instead of a static key.
>
> Changes since rfc:
> MPAM_IIDR_NVIDIA_T421 -> MPAM_IIDR_NVIDIA_T241
> return err from init
> Be specific about the errata in the init name,
> mpam_enable_quirk_nvidia_t241 -> mpam_enable_quirk_nvidia_t241_1
>
> Changes since v3:
> parentheses
> ---
> Documentation/arch/arm64/silicon-errata.rst | 2 +
> drivers/resctrl/mpam_devices.c | 88 +++++++++++++++++++++
> drivers/resctrl/mpam_internal.h | 9 +++
> 3 files changed, 99 insertions(+)
>
One question below.
Reviewed-by: Gavin Shan <gshan@redhat.com>
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 4c300caad901..a65620f98e3a 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -247,6 +247,8 @@ stable kernels.
> +----------------+-----------------+-----------------+-----------------------------+
> | NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
> +----------------+-----------------+-----------------+-----------------------------+
> +| NVIDIA | T241 MPAM | T241-MPAM-1 | N/A |
> ++----------------+-----------------+-----------------+-----------------------------+
> +----------------+-----------------+-----------------+-----------------------------+
> | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
> +----------------+-----------------+-----------------+-----------------------------+
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index e66631f3f732..b1753498f07f 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -29,6 +29,16 @@
>
> #include "mpam_internal.h"
>
> +/* Values for the T241 errata workaround */
> +#define T241_CHIPS_MAX 4
> +#define T241_CHIP_NSLICES 12
> +#define T241_SPARE_REG0_OFF 0x1b0000
> +#define T241_SPARE_REG1_OFF 0x1c0000
> +#define T241_CHIP_ID(phys) FIELD_GET(GENMASK_ULL(44, 43), phys)
> +#define T241_SHADOW_REG_OFF(sidx, pid) (0x360048 + (sidx) * 0x10000 + (pid) * 8)
> +#define SMCCC_SOC_ID_T241 0x036b0241
> +static void __iomem *t241_scratch_regs[T241_CHIPS_MAX];
> +
> /*
> * mpam_list_lock protects the SRCU lists when writing. Once the
> * mpam_enabled key is enabled these lists are read-only,
> @@ -630,7 +640,45 @@ static struct mpam_msc_ris *mpam_get_or_create_ris(struct mpam_msc *msc,
> return ERR_PTR(-ENOENT);
> }
>
> +static int mpam_enable_quirk_nvidia_t241_1(struct mpam_msc *msc,
> + const struct mpam_quirk *quirk)
> +{
> + s32 soc_id = arm_smccc_get_soc_id_version();
> + struct resource *r;
> + phys_addr_t phys;
> +
> + /*
> + * A mapping to a device other than the MSC is needed, check
> + * SOC_ID is NVIDIA T241 chip (036b:0241)
> + */
> + if (soc_id < 0 || soc_id != SMCCC_SOC_ID_T241)
> + return -EINVAL;
> +
> + r = platform_get_resource(msc->pdev, IORESOURCE_MEM, 0);
> + if (!r)
> + return -EINVAL;
> +
> + /* Find the internal registers base addr from the CHIP ID */
> + msc->t241_id = T241_CHIP_ID(r->start);
> + phys = FIELD_PREP(GENMASK_ULL(45, 44), msc->t241_id) | 0x19000000ULL;
> +
> + t241_scratch_regs[msc->t241_id] = ioremap(phys, SZ_8M);
> + if (WARN_ON_ONCE(!t241_scratch_regs[msc->t241_id]))
> + return -EINVAL;
Those IO regions aren't unmapped when the MSCs are removed. I guess it would be
something to be improved? :-)
> +
> + pr_info_once("Enabled workaround for NVIDIA T241 erratum T241-MPAM-1\n");
> +
> + return 0;
> +}
> +
> static const struct mpam_quirk mpam_quirks[] = {
> + {
> + /* NVIDIA t241 erratum T241-MPAM-1 */
> + .init = mpam_enable_quirk_nvidia_t241_1,
> + .iidr = MPAM_IIDR_NVIDIA_T241,
> + .iidr_mask = MPAM_IIDR_MATCH_ONE,
> + .workaround = T241_SCRUB_SHADOW_REGS,
Perhaps we need a more leading space for every line in the above block.
> + },
> { NULL } /* Sentinel */
> };
>
> @@ -1378,6 +1426,44 @@ static void mpam_reset_msc_bitmap(struct mpam_msc *msc, u16 reg, u16 wd)
> __mpam_write_reg(msc, reg, bm);
> }
>
> +static void mpam_apply_t241_erratum(struct mpam_msc_ris *ris, u16 partid)
> +{
> + int sidx, i, lcount = 1000;
> + void __iomem *regs;
> + u64 val0, val;
> +
> + regs = t241_scratch_regs[ris->vmsc->msc->t241_id];
> +
> + for (i = 0; i < lcount; i++) {
> + /* Read the shadow register at index 0 */
> + val0 = readq_relaxed(regs + T241_SHADOW_REG_OFF(0, partid));
> +
> + /* Check if all the shadow registers have the same value */
> + for (sidx = 1; sidx < T241_CHIP_NSLICES; sidx++) {
> + val = readq_relaxed(regs +
> + T241_SHADOW_REG_OFF(sidx, partid));
> + if (val != val0)
> + break;
> + }
> + if (sidx == T241_CHIP_NSLICES)
> + break;
> + }
> +
> + if (i == lcount)
> + pr_warn_once("t241: inconsistent values in shadow regs");
> +
> + /* Write a value zero to spare registers to take effect of MBW conf */
> + writeq_relaxed(0, regs + T241_SPARE_REG0_OFF);
> + writeq_relaxed(0, regs + T241_SPARE_REG1_OFF);
> +}
> +
> +static void mpam_quirk_post_config_change(struct mpam_msc_ris *ris, u16 partid,
> + struct mpam_config *cfg)
> +{
> + if (mpam_has_quirk(T241_SCRUB_SHADOW_REGS, ris->vmsc->msc))
> + mpam_apply_t241_erratum(ris, partid);
> +}
> +
> /* Called via IPI. Call while holding an SRCU reference */
> static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid,
> struct mpam_config *cfg)
> @@ -1457,6 +1543,8 @@ static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid,
> mpam_write_partsel_reg(msc, PRI, pri_val);
> }
>
> + mpam_quirk_post_config_change(ris, partid, cfg);
> +
> mutex_unlock(&msc->part_sel_lock);
> }
>
> diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h
> index e28a168419d4..e38954a735d8 100644
> --- a/drivers/resctrl/mpam_internal.h
> +++ b/drivers/resctrl/mpam_internal.h
> @@ -130,6 +130,9 @@ struct mpam_msc {
> void __iomem *mapped_hwpage;
> size_t mapped_hwpage_sz;
>
> + /* Values only used on some platforms for quirks */
> + u32 t241_id;
> +
> struct mpam_garbage garbage;
> };
>
> @@ -220,6 +223,7 @@ struct mpam_props {
>
> /* Workaround bits for msc->quirks */
> enum mpam_device_quirks {
> + T241_SCRUB_SHADOW_REGS,
> MPAM_QUIRK_LAST
> };
>
> @@ -240,6 +244,11 @@ struct mpam_quirk {
> FIELD_PREP_CONST(MPAMF_IIDR_REVISION, 0xf) | \
> FIELD_PREP_CONST(MPAMF_IIDR_IMPLEMENTER, 0xfff))
>
> +#define MPAM_IIDR_NVIDIA_T241 (FIELD_PREP_CONST(MPAMF_IIDR_PRODUCTID, 0x241) | \
> + FIELD_PREP_CONST(MPAMF_IIDR_VARIANT, 0) | \
> + FIELD_PREP_CONST(MPAMF_IIDR_REVISION, 0) | \
> + FIELD_PREP_CONST(MPAMF_IIDR_IMPLEMENTER, 0x36b))
> +
> /* The values for MSMON_CFG_MBWU_FLT.RWBW */
> enum mon_filter_options {
> COUNT_BOTH = 0,
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH v6 4/4] selftests/ftrace: Add accept cases for fprobe list syntax
From: Masami Hiramatsu @ 2026-03-24 4:12 UTC (permalink / raw)
To: Seokwoo Chung (Ryan)
Cc: rostedt, corbet, shuah, mathieu.desnoyers, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260205135842.20517-5-seokwoo.chung130@gmail.com>
On Thu, 5 Feb 2026 08:58:42 -0500
"Seokwoo Chung (Ryan)" <seokwoo.chung130@gmail.com> wrote:
> Add fprobe_list.tc to test the comma-separated symbol list syntax
> with :entry/:exit suffixes. Three scenarios are covered:
>
> 1. List with default (entry) behavior and ! exclusion
> 2. List with explicit :entry suffix
> 3. List with :exit suffix for return probes
Could you also add wildcard pattern test?
>
> Each test verifies that the correct functions appear in
> enabled_functions and that excluded (!) symbols are absent.
>
> Note: The existing tests add_remove_fprobe.tc, fprobe_syntax_errors.tc,
> and add_remove_fprobe_repeat.tc check their "requires" line against the
> tracefs README for the old "%return" syntax pattern. Since the README
> now documents ":entry|:exit" instead, these tests report UNSUPPORTED.
> Their "requires" lines need updating in a follow-up patch.
This means you'll break the selftest. please fix those test first.
(This fix must be done before "tracing/fprobe: Support comma-separated
symbols and :entry/:exit" so that we can safely bisect it.)
Thank you,
>
> Signed-off-by: Seokwoo Chung (Ryan) <seokwoo.chung130@gmail.com>
> ---
> .../ftrace/test.d/dynevent/fprobe_list.tc | 92 +++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/fprobe_list.tc
>
> diff --git a/tools/testing/selftests/ftrace/test.d/dynevent/fprobe_list.tc b/tools/testing/selftests/ftrace/test.d/dynevent/fprobe_list.tc
> new file mode 100644
> index 000000000000..45e57c6f487d
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/dynevent/fprobe_list.tc
> @@ -0,0 +1,92 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +# description: Fprobe event list syntax and :entry/:exit suffixes
> +# requires: dynamic_events "f[:[<group>/][<event>]] <func-name>[:entry|:exit] [<args>]":README
> +
> +# Setup symbols to test. These are common kernel functions.
> +PLACE=vfs_read
> +PLACE2=vfs_write
> +PLACE3=vfs_open
> +
> +echo 0 > events/enable
> +echo > dynamic_events
> +
> +# Get baseline count of enabled functions (should be 0 if clean, but be safe)
> +if [ -f enabled_functions ]; then
> + ocnt=`cat enabled_functions | wc -l`
> +else
> + ocnt=0
> +fi
> +
> +# Test 1: List default (entry) with exclusion
> +# Target: Trace vfs_read and vfs_open, but EXCLUDE vfs_write
> +echo "f:test/list_entry $PLACE,!$PLACE2,$PLACE3" >> dynamic_events
> +grep -q "test/list_entry" dynamic_events
> +test -d events/test/list_entry
> +
> +echo 1 > events/test/list_entry/enable
> +
> +grep -q "$PLACE" enabled_functions
> +grep -q "$PLACE3" enabled_functions
> +! grep -q "$PLACE2" enabled_functions
> +
> +# Check count (Baseline + 2 new functions)
> +cnt=`cat enabled_functions | wc -l`
> +if [ $cnt -ne $((ocnt + 2)) ]; then
> + exit_fail
> +fi
> +
> +# Cleanup Test 1
> +echo 0 > events/test/list_entry/enable
> +echo "-:test/list_entry" >> dynamic_events
> +! grep -q "test/list_entry" dynamic_events
> +
> +# Count should return to baseline
> +cnt=`cat enabled_functions | wc -l`
> +if [ $cnt -ne $ocnt ]; then
> + exit_fail
> +fi
> +
> +# Test 2: List with explicit :entry suffix
> +# (Should behave exactly like Test 1)
> +echo "f:test/list_entry_exp $PLACE,!$PLACE2,$PLACE3:entry" >> dynamic_events
> +grep -q "test/list_entry_exp" dynamic_events
> +test -d events/test/list_entry_exp
> +
> +echo 1 > events/test/list_entry_exp/enable
> +
> +grep -q "$PLACE" enabled_functions
> +grep -q "$PLACE3" enabled_functions
> +! grep -q "$PLACE2" enabled_functions
> +
> +cnt=`cat enabled_functions | wc -l`
> +if [ $cnt -ne $((ocnt + 2)) ]; then
> + exit_fail
> +fi
> +
> +# Cleanup Test 2
> +echo 0 > events/test/list_entry_exp/enable
> +echo "-:test/list_entry_exp" >> dynamic_events
> +
> +# Test 3: List with :exit suffix
> +echo "f:test/list_exit $PLACE,!$PLACE2,$PLACE3:exit" >> dynamic_events
> +grep -q "test/list_exit" dynamic_events
> +test -d events/test/list_exit
> +
> +echo 1 > events/test/list_exit/enable
> +
> +# Even for return probes, enabled_functions lists the attached symbols
> +grep -q "$PLACE" enabled_functions
> +grep -q "$PLACE3" enabled_functions
> +! grep -q "$PLACE2" enabled_functions
> +
> +cnt=`cat enabled_functions | wc -l`
> +if [ $cnt -ne $((ocnt + 2)) ]; then
> + exit_fail
> +fi
> +
> +# Cleanup Test 3
> +echo 0 > events/test/list_exit/enable
> +echo "-:test/list_exit" >> dynamic_events
> +
> +clear_trace
> --
> 2.43.0
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 3/4] docs: tracing/fprobe: Document list filters and :entry/:exit
From: Masami Hiramatsu @ 2026-03-24 4:07 UTC (permalink / raw)
To: Seokwoo Chung (Ryan)
Cc: rostedt, corbet, shuah, mathieu.desnoyers, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260205135842.20517-4-seokwoo.chung130@gmail.com>
On Thu, 5 Feb 2026 08:58:41 -0500
"Seokwoo Chung (Ryan)" <seokwoo.chung130@gmail.com> wrote:
> Update fprobe event documentation to describe comma-separated symbol lists,
> exclusions, and explicit suffixes.
>
> Signed-off-by: Seokwoo Chung (Ryan) <seokwoo.chung130@gmail.com>
> ---
> Documentation/trace/fprobetrace.rst | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/trace/fprobetrace.rst b/Documentation/trace/fprobetrace.rst
> index b4c2ca3d02c1..bbcfd57f0005 100644
> --- a/Documentation/trace/fprobetrace.rst
> +++ b/Documentation/trace/fprobetrace.rst
> @@ -25,14 +25,18 @@ Synopsis of fprobe-events
> -------------------------
> ::
>
> - f[:[GRP1/][EVENT1]] SYM [FETCHARGS] : Probe on function entry
> - f[MAXACTIVE][:[GRP1/][EVENT1]] SYM%return [FETCHARGS] : Probe on function exit
> + f[:[GRP1/][EVENT1]] SYM[%return] [FETCHARGS] : Single function
We also accept wildcard pattern instead of SYM.
f[:[GRP1/][EVENT1]] (SYM|PATTERN)[%return] [FETCHARGS] : Single target
> + f[:[GRP1/][EVENT1]] SYM[,[!]SYM[,...]][:entry|:exit] [FETCHARGS] :Multiple
Hmm if this is for multiple function, we can not omit event name, so
f:[GRP1/]EVNET1 SYM[,[!]SYM[,...]][:entry|:exit] [FETCHARGS] : Multiple function
> + function
Also, if you put this in the next line, please indent it.
> t[:[GRP2/][EVENT2]] TRACEPOINT [FETCHARGS] : Probe on tracepoint
>
> GRP1 : Group name for fprobe. If omitted, use "fprobes" for it.
> GRP2 : Group name for tprobe. If omitted, use "tracepoints" for it.
> EVENT1 : Event name for fprobe. If omitted, the event name is
> - "SYM__entry" or "SYM__exit".
> + - For a single literal symbol, the event name is
> + "SYM__entry" or "SYM__exit".
> + - For a *list or any wildcard*, an explicit [GRP1/][EVENT1] is
an explicit EVENT1 is required. (group name can be omitted)
> + required; otherwise the parser rejects it.
> EVENT2 : Event name for tprobe. If omitted, the event name is
> the same as "TRACEPOINT", but if the "TRACEPOINT" starts
> with a digit character, "_TRACEPOINT" is used.
> @@ -40,6 +44,13 @@ Synopsis of fprobe-events
> can be probed simultaneously, or 0 for the default value
> as defined in Documentation/trace/fprobe.rst
>
> + SYM : Function name or comma-separated list of symbols.
Doesn't SYM still be a function name? In above synopsis, SYM is an entry of
comma-separated list.
> + - SYM prefixed with "!" are exclusions.
> + - ":entry" suffix means it probes entry of given symbols
> + (default)
> + - ":exit" suffix means it probes exit of given symbols.
> + - "%return" suffix means it probes exit of SYM (single
> + symbol).
And we need PATTERN here.
PATTERN : Function name pattern with wildcards (You can use "*" or "?").
Thank you,
> FETCHARGS : Arguments. Each probe can have up to 128 args.
> ARG : Fetch "ARG" function argument using BTF (only for function
> entry or tracepoint.) (\*1)
> --
> 2.43.0
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 0/5] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-03-24 4:02 UTC (permalink / raw)
To: Andrew Morton
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, bhe, vgoyal, dyoung, rdunlap,
peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees, elver,
paulmck, lirongqing, safinaskar, rppt, ardb, leitao, jbohac,
cfsworks, osandov, tangyouling, sourabhjain, ritesh.list, eajames,
songshuaishuai, kevin.brodsky, samuel.holland, vishal.moola,
junhui.liu, coxu, liaoyuanhong, fuqiang.wang, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <20260323095548.fa4e13d6e8ae5005ae585e13@linux-foundation.org>
On 2026/3/24 0:55, Andrew Morton wrote:
> On Mon, 23 Mar 2026 15:27:40 +0800 Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
>> The crash memory allocation, and the exclude of crashk_res, crashk_low_res
>> and crashk_cma memory are almost identical across different architectures,
>> This patch set handle them in crash core in a general way, which eliminate
>> a lot of duplication code.
>>
>> And add support for crashkernel CMA reservation for arm64 and riscv.
>
> Thanks. AI review has completed and it asks questions:
> https://sashiko.dev/#/patchset/20260323072745.2481719-1-ruanjinjie@huawei.com
I believe it identified 4 valid issues:
- The already discovered crashk_low_res not excluded bug in the existing
RISC-V code.
- An existing memory leak issue in the existing PowerPC code.
- The ordering issue of adding CMA ranges to "linux,usable-memory-range".
- An existing concurrency issue. A Concurrent memory hotplug may occur
between reading memblock and attempting to fill cmem during kexec_load()
for almost all existing architectures，I'm not sure if this is a
practical issue in reality..
Race Condition Scenario
Timeline:
---------------------------------------------------------------------
T1: kexec_load() syscall starts
T2: kexec_trylock() acquires kexec_lock
T3: crash_prepare_headers() is called
T4: arch_get_system_nr_ranges() queries memblock → finds 100 memory ranges
T5: cmem = alloc_cmem(100) allocates buffer for 100 ranges
T6: [RACE WINDOW] Another process triggers memory hotplug
T7: add_memory() → lock_device_hotplug() → memblock_add_node()
T8: New memory region added to memblock
T9: arch_crash_populate_cmem() iterates: now finds 102 ranges
T10: cmem->ranges[100] → OUT OF BOUNDS WRITE!
T11: cmem->ranges[101] → OUT OF BOUNDS WRITE!
T12: Kernel crash or memory corruption
Why This Happens
1. Different locks used:
- kexec_load() uses kexec_trylock (atomic_t)
- Memory hotplug uses device_hotplug_lock (mutex)
2. No synchronization between these two operations
3. Time-of-check to time-of-use (TOCTOU) issue:
- Step T4-T5: We query the number of ranges and allocate buffer
- Step T6-T9: Memory hotplug adds new ranges between query and
population
Any comments or suggestions on the following approach?
int crash_prepare_headers(...)
{
unsigned int max_nr_ranges;
struct crash_mem *cmem;
int ret;
lock_device_hotplug();
max_nr_ranges = arch_get_system_nr_ranges();
// ...
ret = arch_crash_populate_cmem(cmem);
// ...
unlock_device_hotplug();
return ret;
}
>
^ permalink raw reply
* Re: [PATCH v6 35/40] arm_mpam: Add quirk framework
From: Gavin Shan @ 2026-03-24 3:56 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-36-ben.horgan@arm.com>
Hi Ben,
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: Shanker Donthineni <sdonthineni@nvidia.com>
>
> The MPAM specification includes the MPAMF_IIDR, which serves to uniquely
> identify the MSC implementation through a combination of implementer
> details, product ID, variant, and revision. Certain hardware issues/errata
> can be resolved using software workarounds.
>
> Introduce a quirk framework to allow workarounds to be enabled based on the
> MPAMF_IIDR value.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
> Co-developed-by: James Morse <james.morse@arm.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes by James:
> Stash the IIDR so this doesn't need an IPI, enable quirks only
> once, move the description to the callback so it can be pr_once()d, add an
> enum of workarounds for popular errata. Add macros for making lists of
> product/revision/vendor half readable
>
> Changes since rfc:
> remove trailing commas in last element of enums
> Make mpam_enable_quirks() in charge of mpam_set_quirk() even if there
> is an enable.
>
> Changes since v3:
> Brackets in macro
> ---
> drivers/resctrl/mpam_devices.c | 32 ++++++++++++++++++++++++++++++++
> drivers/resctrl/mpam_internal.h | 25 +++++++++++++++++++++++++
> 2 files changed, 57 insertions(+)
>
With the following nitpicks addressed if another respin is needed. This
looks good to me in either way.
Reviewed-by: Gavin Shan <gshan@redhat.com>
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 37b31a1cf376..e66631f3f732 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -630,6 +630,30 @@ static struct mpam_msc_ris *mpam_get_or_create_ris(struct mpam_msc *msc,
> return ERR_PTR(-ENOENT);
> }
>
> +static const struct mpam_quirk mpam_quirks[] = {
> + { NULL } /* Sentinel */
> +};
> +
> +static void mpam_enable_quirks(struct mpam_msc *msc)
> +{
> + const struct mpam_quirk *quirk;
> +
> + for (quirk = &mpam_quirks[0]; quirk->iidr_mask; quirk++) {
> + int err = 0;
The initialization on @err is unnecessary if it's checked only when it's
updated (see below). The variable can be avoided.
> +
> + if (quirk->iidr != (msc->iidr & quirk->iidr_mask))
> + continue;
> +
> + if (quirk->init)
> + err = quirk->init(msc, quirk);
> +
> + if (err)
> + continue;
Since @err is only updated by quirk->init(), the following check would be done
only when it's updated. Something like below, @err isn't needed.
if (quirk->init && quirk->init(msc, quirk)
continue;
> +
> + mpam_set_quirk(quirk->workaround, msc);
> + }
> +}
> +
> /*
> * IHI009A.a has this nugget: "If a monitor does not support automatic behaviour
> * of NRDY, software can use this bit for any purpose" - so hardware might not
> @@ -864,8 +888,11 @@ static int mpam_msc_hw_probe(struct mpam_msc *msc)
> /* Grab an IDR value to find out how many RIS there are */
> mutex_lock(&msc->part_sel_lock);
> idr = mpam_msc_read_idr(msc);
> + msc->iidr = mpam_read_partsel_reg(msc, IIDR);
> mutex_unlock(&msc->part_sel_lock);
>
> + mpam_enable_quirks(msc);
> +
> msc->ris_max = FIELD_GET(MPAMF_IDR_RIS_MAX, idr);
>
> /* Use these values so partid/pmg always starts with a valid value */
> @@ -1972,6 +1999,7 @@ static bool mpam_has_cmax_wd_feature(struct mpam_props *props)
> * resulting safe value must be compatible with both. When merging values in
> * the tree, all the aliasing resources must be handled first.
> * On mismatch, parent is modified.
> + * Quirks on an MSC will apply to all MSC in that class.
> */
> static void __props_mismatch(struct mpam_props *parent,
> struct mpam_props *child, bool alias)
> @@ -2091,6 +2119,7 @@ static void __props_mismatch(struct mpam_props *parent,
> * nobble the class feature, as we can't configure all the resources.
> * e.g. The L3 cache is composed of two resources with 13 and 17 portion
> * bitmaps respectively.
> + * Quirks on an MSC will apply to all MSC in that class.
> */
> static void
> __class_props_mismatch(struct mpam_class *class, struct mpam_vmsc *vmsc)
> @@ -2104,6 +2133,9 @@ __class_props_mismatch(struct mpam_class *class, struct mpam_vmsc *vmsc)
> dev_dbg(dev, "Merging features for class:0x%lx &= vmsc:0x%lx\n",
> (long)cprops->features, (long)vprops->features);
>
> + /* Merge quirks */
> + class->quirks |= vmsc->msc->quirks;
> +
> /* Take the safe value for any common features */
> __props_mismatch(cprops, vprops, false);
> }
> diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h
> index ce9e0e0483fb..e28a168419d4 100644
> --- a/drivers/resctrl/mpam_internal.h
> +++ b/drivers/resctrl/mpam_internal.h
> @@ -85,6 +85,8 @@ struct mpam_msc {
> u8 pmg_max;
> unsigned long ris_idxs;
> u32 ris_max;
> + u32 iidr;
> + u16 quirks;
>
It maybe reasonable to have 'u32 quirks' so that 32 instead of 16 quirks can be
supported to the maximal degree. It's known 16 quirks are enough at the moment,
but it's likely to be extended for more space.
> /*
> * error_irq_lock is taken when registering/unregistering the error
> @@ -216,6 +218,28 @@ struct mpam_props {
> #define mpam_set_feature(_feat, x) __set_bit(_feat, (x)->features)
> #define mpam_clear_feature(_feat, x) __clear_bit(_feat, (x)->features)
>
> +/* Workaround bits for msc->quirks */
> +enum mpam_device_quirks {
> + MPAM_QUIRK_LAST
> +};
> +
> +#define mpam_has_quirk(_quirk, x) ((1 << (_quirk) & (x)->quirks))
> +#define mpam_set_quirk(_quirk, x) ((x)->quirks |= (1 << (_quirk)))
> +
> +struct mpam_quirk {
> + int (*init)(struct mpam_msc *msc, const struct mpam_quirk *quirk);
> +
> + u32 iidr;
> + u32 iidr_mask;
> +
> + enum mpam_device_quirks workaround;
> +};
> +
> +#define MPAM_IIDR_MATCH_ONE (FIELD_PREP_CONST(MPAMF_IIDR_PRODUCTID, 0xfff) | \
> + FIELD_PREP_CONST(MPAMF_IIDR_VARIANT, 0xf) | \
> + FIELD_PREP_CONST(MPAMF_IIDR_REVISION, 0xf) | \
> + FIELD_PREP_CONST(MPAMF_IIDR_IMPLEMENTER, 0xfff))
> +
> /* The values for MSMON_CFG_MBWU_FLT.RWBW */
> enum mon_filter_options {
> COUNT_BOTH = 0,
> @@ -259,6 +283,7 @@ struct mpam_class {
>
> struct mpam_props props;
> u32 nrdy_usec;
> + u16 quirks;
As above, it would be "u32 quirks".
> u8 level;
> enum mpam_class_types type;
>
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH v6 34/40] arm_mpam: resctrl: Call resctrl_init() on platforms that can support resctrl
From: Gavin Shan @ 2026-03-24 3:43 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-35-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> Now that MPAM links against resctrl, call resctrl_init() to register the
> filesystem and setup resctrl's structures.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since v2:
> Use for_each_mpam...
> error path tidying
>
> Changes since v3:
> Don't consider abmc/mbwu in teardown
> ---
> drivers/resctrl/mpam_devices.c | 32 ++++++++++++++---
> drivers/resctrl/mpam_internal.h | 4 +++
> drivers/resctrl/mpam_resctrl.c | 63 ++++++++++++++++++++++++++++++++-
> 3 files changed, 94 insertions(+), 5 deletions(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 33/40] arm64: mpam: Select ARCH_HAS_CPU_RESCTRL
From: Gavin Shan @ 2026-03-24 3:42 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-34-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> Enough MPAM support is present to enable ARCH_HAS_CPU_RESCTRL. Let it
> rip^Wlink!
>
> ARCH_HAS_CPU_RESCTRL indicates resctrl can be enabled. It is enabled by the
> arch code simply because it has 'arch' in its name.
>
> This removes ARM_CPU_RESCTRL as a mimic of X86_CPU_RESCTRL. While here,
> move the ACPI dependency to the driver's Kconfig file.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> arch/arm64/Kconfig | 2 +-
> arch/arm64/include/asm/resctrl.h | 2 ++
> drivers/resctrl/Kconfig | 7 +++++++
> drivers/resctrl/Makefile | 2 +-
> 4 files changed, 11 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm64/include/asm/resctrl.h
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 32/40] arm_mpam: resctrl: Add empty definitions for assorted resctrl functions
From: Gavin Shan @ 2026-03-24 3:42 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-33-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> A few resctrl features and hooks need to be provided, but aren't needed or
> supported on MPAM platforms.
>
> resctrl has individual hooks to separately enable and disable the
> closid/partid and rmid/pmg context switching code. For MPAM this is all the
> same thing, as the value in struct task_struct is used to cache the value
> that should be written to hardware. arm64's context switching code is
> enabled once MPAM is usable, but doesn't touch the hardware unless the
> value has changed.
>
> For now event configuration is not supported, and can be turned off by
> returning 'false' from resctrl_arch_is_evt_configurable().
>
> The new io_alloc feature is not supported either, always return false from
> the enable helper to indicate and fail the enable.
>
> Add this, and empty definitions for the other hooks.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since v3:
> Add resctrl_arch_pre_mount() {}
> resctrl_arch_reset_rmid_all() signature update
> add stubs for abmc
> keep empty definitions together
>
> Changes since v5:
> Add resctrl_arch_reset_rmid() since mbwu will always use abmc
> ---
> drivers/resctrl/mpam_resctrl.c | 65 ++++++++++++++++++++++++++++++++++
> include/linux/arm_mpam.h | 9 +++++
> 2 files changed, 74 insertions(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 31/40] arm_mpam: resctrl: Update the rmid reallocation limit
From: Gavin Shan @ 2026-03-24 3:42 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-32-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> resctrl's limbo code needs to be told when the data left in a cache is
> small enough for the partid+pmg value to be re-allocated.
>
> x86 uses the cache size divided by the number of rmid users the cache may
> have. Do the same, but for the smallest cache, and with the number of
> partid-and-pmg users.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since v2:
> Move waiting for cache info into it's own patch
>
> Changes since v3:
> Move check class is csu higher (just kept to document intent)
> continue -> break
>
> to squash update rmid limits
> use raw_smp_processor_id()
> ---
> drivers/resctrl/mpam_resctrl.c | 39 ++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 30/40] arm_mpam: resctrl: Add resctrl_arch_rmid_read()
From: Gavin Shan @ 2026-03-24 3:41 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-31-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> resctrl uses resctrl_arch_rmid_read() to read counters. CDP emulation means
> the counter may need reading in three different ways.
>
> The helpers behind the resctrl_arch_ functions will be re-used for the ABMC
> equivalent functions.
>
> Add the rounding helper for checking monitor values while we're here.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since rfc:
> cfg initialisation style
> code flow at end of read_mon_cdp_safe()
>
> Changes since v2:
> Whitespace changes
>
> Changes since v3:
> Update function signatures
> Remove abmc check
>
> Changes since v5:
> don't read mbwu
> remove reset code as only needed for mbwu
> ---
> drivers/resctrl/mpam_resctrl.c | 82 ++++++++++++++++++++++++++++++++++
> include/linux/arm_mpam.h | 5 +++
> 2 files changed, 87 insertions(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 29/40] arm_mpam: resctrl: Allow resctrl to allocate monitors
From: Gavin Shan @ 2026-03-24 3:41 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-30-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> When resctrl wants to read a domain's 'QOS_L3_OCCUP', it needs to allocate
> a monitor on the corresponding resource. Monitors are allocated by class
> instead of component.
>
> Add helpers to allocate a CSU monitor. These helper return an out of range
> value for MBM counters.
>
> Allocating a montitor context is expected to block until hardware resources
> become available. This only makes sense for QOS_L3_OCCUP as unallocated MBM
> counters are losing data.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since rfc:
> USE_RMID_IDX -> USE_PRE_ALLOCATED in comment
> Remove unnecessary arch_mon_ctx = NULL
>
> Changes since v2:
> Add include of resctrl_types.h as dropped from earlier patch
>
> Changes since v3:
> Don't mention ABMC in commit message
>
> Changes since v5:
> Remove MBM free running sentence from commit message
> kmalloc -> kmalloc_obj
> ---
> drivers/resctrl/mpam_internal.h | 14 ++++++-
> drivers/resctrl/mpam_resctrl.c | 67 +++++++++++++++++++++++++++++++++
> include/linux/arm_mpam.h | 5 +++
> 3 files changed, 85 insertions(+), 1 deletion(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 28/40] arm_mpam: resctrl: Add support for csu counters
From: Gavin Shan @ 2026-03-24 3:40 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc, Shaopeng Tan
In-Reply-To: <20260313144617.3420416-29-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> resctrl exposes a counter via a file named llc_occupancy. This isn't really
> a counter as its value goes up and down, this is a snapshot of the cache
> storage usage monitor.
>
> Add some picking code which will only find an L3. The resctrl counter
> file is called llc_occupancy but we don't check it is the last one as
> it is already identified as L3.
>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Co-developed-by: Dave Martin <dave.martin@arm.com>
> Signed-off-by: Dave Martin <dave.martin@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since rfc:
> Allow csu counters however many partid or pmg there are
> else if -> if
> reduce scope of local variables
> drop has_csu
>
> Changes since v2:
> return -> break so works for mbwu in later patch
> add for_each_mpam_resctrl_mon
> return error from mpam_resctrl_monitor_init(). It may fail when is abmc
> allocation introduced in a later patch.
> Squashed in patch from Dave Martin:
> https://lore.kernel.org/lkml/20250820131621.54983-1-Dave.Martin@arm.com/
>
> Changes since v3:
> resctrl_enable_mon_event() signature update
> Restrict the events considered
> num-rmid update
> Use raw_smp_processor_id()
> Tighten heuristics:
> Make sure it is the L3
> Please shout if this means the counters aren't exposed on any platforms
> Drop tags due to change in policy/rework
>
> Changes since v4:
> Move generic monitor boilerplate to separate patch
> ---
> drivers/resctrl/mpam_resctrl.c | 83 ++++++++++++++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 27/40] arm_mpam: resctrl: Add monitor initialisation and domain boilerplate
From: Gavin Shan @ 2026-03-24 3:40 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc
In-Reply-To: <20260313144617.3420416-28-ben.horgan@arm.com>
On 3/14/26 12:46 AM, Ben Horgan wrote:
> Add the boilerplate that tells resctrl about the mpam monitors that are
> available. resctrl expects all (non-telemetry) monitors to be on the L3 and
> so advertise them there and invent an L3 resctrl resource if required. The
> L3 cache itself has to exist as the cache ids are used as the domain
> ids.
>
> Bring the resctrl monitor domains online and offline based on the cpus
> they contain.
>
> Support for specific monitor types is left to later.
>
> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
> Reviewed-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> New patch but mostly moved from the existing patches to
> separate the monitors from the controls and the boilerplate
> from the specific counters.
> Use l3->mon_capable in resctrl_arch_mon_capable() as
> resctrl_enable_mon_event() now returns a bool.
>
> Changes since v5:
> Use r->mon_capable instead of resctrl_arch_mon_capable() as specific
> to the resource
> Comment line wrap
> Include offline_ctrl_domain cleanup from controls boilerplate patch
> Include any_mon_comp finding and
> Halve num_rmid when cdp_enabled
> Move mpam_resctrl_get_mon_domain_from_cpu() from boilerplate patch
> ---
> drivers/resctrl/mpam_internal.h | 15 +++
> drivers/resctrl/mpam_resctrl.c | 231 ++++++++++++++++++++++++++++++--
> 2 files changed, 235 insertions(+), 11 deletions(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 2/4] fprobe: Support comma-separated filters in register_fprobe()
From: Masami Hiramatsu @ 2026-03-24 1:59 UTC (permalink / raw)
To: Seokwoo Chung (Ryan)
Cc: rostedt, corbet, shuah, mathieu.desnoyers, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260205135842.20517-3-seokwoo.chung130@gmail.com>
On Thu, 5 Feb 2026 08:58:40 -0500
"Seokwoo Chung (Ryan)" <seokwoo.chung130@gmail.com> wrote:
> register_fprobe() passes its filter and notfilter strings directly to
> glob_match(), which only understands shell-style globs (*, ?, [...]).
> Comma-separated symbol lists such as "vfs_read,vfs_open" never match
> any symbol because no kernel symbol contains a comma.
>
> Add glob_match_comma_list() that splits the filter on commas and
> checks each entry individually with glob_match(). The existing
> single-pattern fast path is preserved (no commas means the loop
> executes exactly once).
>
> This is required by the comma-separated fprobe list syntax introduced
> in the preceding patch; without it, enabling a list-mode fprobe event
> fails with "Could not enable event".
OK, in this case, you should reorder patch this as the first one.
Please make this [1/4] and remove this requirement explanation paragraph.
The patch itself looks good to me.
Thank you,
>
> Signed-off-by: Seokwoo Chung (Ryan) <seokwoo.chung130@gmail.com>
> ---
> kernel/trace/fprobe.c | 30 ++++++++++++++++++++++++++++--
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c
> index 1188eefef07c..2acd24b80d04 100644
> --- a/kernel/trace/fprobe.c
> +++ b/kernel/trace/fprobe.c
> @@ -672,12 +672,38 @@ struct filter_match_data {
> struct module **mods;
> };
>
> +/*
> + * Check if @name matches any comma-separated glob pattern in @list.
> + * If @list contains no commas, this is equivalent to glob_match().
> + */
> +static bool glob_match_comma_list(const char *list, const char *name)
> +{
> + const char *cur = list;
> +
> + while (*cur) {
> + const char *sep = strchr(cur, ',');
> + int len = sep ? sep - cur : strlen(cur);
> + char pat[KSYM_NAME_LEN];
> +
> + if (len > 0 && len < KSYM_NAME_LEN) {
> + memcpy(pat, cur, len);
> + pat[len] = '\0';
> + if (glob_match(pat, name))
> + return true;
> + }
> + if (!sep)
> + break;
> + cur = sep + 1;
> + }
> + return false;
> +}
> +
> static int filter_match_callback(void *data, const char *name, unsigned long addr)
> {
> struct filter_match_data *match = data;
>
> - if (!glob_match(match->filter, name) ||
> - (match->notfilter && glob_match(match->notfilter, name)))
> + if (!glob_match_comma_list(match->filter, name) ||
> + (match->notfilter && glob_match_comma_list(match->notfilter, name)))
> return 0;
>
> if (!ftrace_location(addr))
> --
> 2.43.0
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 0/4] tracing/fprobe: Support comma-separated symbol lists and :entry/:exit suffixes
From: Masami Hiramatsu @ 2026-03-24 1:51 UTC (permalink / raw)
To: Seokwoo Chung (Ryan)
Cc: rostedt, corbet, shuah, mathieu.desnoyers, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260205135842.20517-1-seokwoo.chung130@gmail.com>
Hi,
Sorry, I completely missed this series. Let me review it.
Thank you,
On Thu, 5 Feb 2026 08:58:38 -0500
"Seokwoo Chung (Ryan)" <seokwoo.chung130@gmail.com> wrote:
> Extend the fprobe event interface to accept comma-separated symbol lists
> with ! exclusion prefix, and :entry/:exit suffixes as an alternative to
> %return. Single-symbol probes retain full backward compatibility with
> %return.
>
> Example usage:
> f:mygroup/myevent vfs_read,!vfs_write,vfs_open:entry
> f:mygroup/myexit vfs_read,vfs_open:exit
>
> Changes since v5:
> - Fix missing closing brace in the empty-token check that caused a
> build error.
> - Remove redundant strchr/strstr checks for tracepoint validation;
> the character validation loop already rejects ',', ':', and '%'.
> - Add trace_probe_log_err() to the tracepoint character validation
> loop so users see what went wrong in tracefs/error_log (reviewer
> feedback from Masami Hiramatsu).
> - Remove unnecessary braces around single-statement if per kernel
> coding style (reviewer feedback).
> - Extract list parsing into parse_fprobe_list() to keep
> parse_fprobe_spec() focused (reviewer feedback).
> - New patch 2/4: add glob_match_comma_list() in kernel/trace/fprobe.c
> so register_fprobe() correctly handles comma-separated filter
> strings. Without this, enabling a list-mode fprobe event failed
> with "Could not enable event" because glob_match() does not
> understand commas.
> - Reorder: documentation patch now comes after all code changes.
> - Updated selftest commit message to note that existing tests
> (add_remove_fprobe.tc, fprobe_syntax_errors.tc,
> add_remove_fprobe_repeat.tc) report UNSUPPORTED because their
> "requires" lines still check for the old %return syntax in README.
> Their requires lines need updating in a follow-up patch.
>
> Tested in QEMU/KVM but I am not too confident if I configured correctly and
> would like to ask for further testing.
>
> Seokwoo Chung (Ryan) (4):
> tracing/fprobe: Support comma-separated symbols and :entry/:exit
> fprobe: Support comma-separated filters in register_fprobe()
> docs: tracing/fprobe: Document list filters and :entry/:exit
> selftests/ftrace: Add accept cases for fprobe list syntax
>
> Documentation/trace/fprobetrace.rst | 17 +-
> kernel/trace/fprobe.c | 30 ++-
> kernel/trace/trace.c | 3 +-
> kernel/trace/trace_fprobe.c | 219 ++++++++++++++----
> .../ftrace/test.d/dynevent/fprobe_list.tc | 92 ++++++++
> 5 files changed, 308 insertions(+), 53 deletions(-)
> create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/fprobe_list.tc
>
> --
> 2.43.0
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ 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