* Re: [PATCH v3 00/12] [PATCH v3 00/12] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Moger, Babu @ 2026-06-12 15:37 UTC (permalink / raw)
To: Reinette Chatre, Babu Moger, corbet, tony.luck, Dave.Martin,
james.morse, tglx, bp, dave.hansen
Cc: skhan, x86, mingo, hpa, akpm, rdunlap, pawan.kumar.gupta,
feng.tang, dapeng1.mi, kees, elver, lirongqing, paulmck, bhelgaas,
seanjc, alexandre.chartre, yazen.ghannam, peterz, chang.seok.bae,
kim.phillips, xin, naveen, thomas.lendacky, linux-doc,
linux-kernel, eranian, peternewman
In-Reply-To: <a1dbbb1a-ef78-468a-a80c-572a85220bbe@intel.com>
On 6/11/2026 4:53 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 4/30/26 4:24 PM, Babu Moger wrote:
>> Design
>> ======
>>
>> A new sysfs file, info/kernel_mode, holds a single global policy that
>> selects what kernel work is steered and which rdtgroup it is steered
>
> How should "selects *what* kernel work is steered" be interpreted? Do these
> modes not all apply to *all* kernel work?
How about?
A new sysfs file, info/kernel_mode, holds a single global policy for
kernel contexts and the rdtgroup associated with the policy.
>
>> to. Reads describe the supported modes and the currently-active
>> binding; writes change the policy or rebind to a different group.
>> Look at the thread below for design discussion.
>> https://lore.kernel.org/lkml/14a8ad0a-e842-4268-871a-0762f1169e03@intel.com/
>>
>
> ...
>
>> Examples
>> ========
>>
>> (See Documentation/filesystems/resctrl.rst, "kernel_mode" and
>> "kmode_cpus" sections, for the full UAPI.)
>>
>> # Mount resctrl
>> # mount -t resctrl resctrl /sys/fs/resctrl
>> # cd /sys/fs/resctrl
>>
>> # Read the supported modes. The active mode is bracketed and reports
>> # the bound "<ctrl>/<mon>/" group; other supported modes report
>> # ":group=none" because nothing is bound to them.
>> # cat info/kernel_mode
>> [inherit_ctrl_and_mon:group=//]
>
> This is unexpected since associating a group to this mode implies that this
> group is used to manage allocations and monitoring of kernel work but this
> is not true, right? From what I understand there should be no group associated with
> this default "inherit_ctrl_and_mon" mode.
The default mode is "inherit_ctrl_and_mon", where both user mode and
kernel mode share the same CLOSID and RMID. This is current mode
(without this series).
I thought we are going to set the default mode with the default group
when system boots up. No?
>
>> global_assign_ctrl_inherit_mon_per_cpu:group=none
>> global_assign_ctrl_assign_mon_per_cpu:group=none
>
> nit: "none" does not reflect state as clearly as "unset"/"uninitialized"/"NA"
Lets go with "uninitialized".
>
>>
>> # Create a CTRL_MON group plus a MON child and bind both the kernel
>> # CLOSID and RMID to them.
>> # mkdir ctrl1
>> # mkdir ctrl1/mon_groups/mon1
>> # echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/" \
>> > info/kernel_mode
>> # cat info/kernel_mode
>> inherit_ctrl_and_mon:group=none
>> global_assign_ctrl_inherit_mon_per_cpu:group=none
>> [global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]
>>
>> # kmode_cpus and kmode_cpus_list are visible only on the bound group.
>> # ls ctrl1/kmode_cpus*
>> ctrl1/kmode_cpus ctrl1/kmode_cpus_list
>
> Since it is ctrl1/mon1 that was bound, should these CPU files not appear
> in ctrl1/mon_groups/mon1 ?
Correct. Will fix it.
>>
>> # Restrict the binding to a CPU subset; the write is incremental.
>
> Does "incremental" mean that if the file contains CPUs 0-3 then writing
> "4" would set the CPUs to 0-4? This does not sound right since it is
> expected that user space can remove CPUs also?
Will remove incremental. Writing "4" will remove 0-3 and keep only 4.
>
>> # echo 0-3 > ctrl1/kmode_cpus_list
>> # cat ctrl1/kmode_cpus
>> f
>> # cat ctrl1/kmode_cpus_list
>> 0-3
>>
>> # Empty masks are rejected; use info/kernel_mode to reset to
>> # "every online CPU".
>> # echo "" > ctrl1/kmode_cpus_list
>> bash: echo: write error: Invalid argument
>> # cat info/last_cmd_status
>> Empty mask not allowed; use info/kernel_mode to unbind
>
> Why are empty masks rejected/not allowed?
No specific reason.
When the mode is switched, we discussed earlier to globally apply the
mode to all the online CPUs.
At this point reading "kmode_cpus_list" will still report empty.
Users can change it to selectively apply the mode by writing to
"kmode_cpus_list".
I was not sure what was the action when empty masks are written.
Should the empty mask apply the mode to all the online CPUs?
>
>>
>> # Disable kernel-mode steering (back to inherit, default group).
>
> This sounds like kernel work is steered to default group which I
> do not think is accurate for the "inherit_ctrl_and_mon" mode.
How about ?
Drop the kernel-mode binding and restore inherit_ctrl_and_mon on the
default group.
thanks
Babu
^ permalink raw reply
* Re: [mic:next 15/15] htmldocs: Documentation/userspace-api/landlock.rst:768: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
From: Randy Dunlap @ 2026-06-12 15:35 UTC (permalink / raw)
To: kernel test robot, Matthieu Buffet
Cc: oe-kbuild-all, Mickaël Salaün, linux-doc
In-Reply-To: <202606120923.1nYYlfdb-lkp@intel.com>
On 6/12/26 12:52 AM, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git next
> head: a6f0a6f5377fae42a8028f63c89d544c68f24b60
> commit: a6f0a6f5377fae42a8028f63c89d544c68f24b60 [15/15] landlock: Add documentation for UDP support
> compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
> docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
> reproduce: (https://download.01.org/0day-ci/archive/20260612/202606120923.1nYYlfdb-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202606120923.1nYYlfdb-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> Scope flags
> ~~~~~~~~~~~ [docutils]
>>> Documentation/userspace-api/landlock.rst:768: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
>>> Documentation/userspace-api/landlock.rst:768: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
> Documentation/userspace-api/landlock:596: ./include/uapi/linux/landlock.h:40: ERROR: Unknown target name: "filesystem flags". [docutils]
> Documentation/userspace-api/landlock:596: ./include/uapi/linux/landlock.h:45: ERROR: Unknown target name: "network flags". [docutils]
> Documentation/userspace-api/landlock:596: ./include/uapi/linux/landlock.h:50: ERROR: Unknown target name: "scope flags". [docutils]
> Documentation/userspace-api/landlock:596: ./include/uapi/linux/landlock.h:24: ERROR: Unknown target name: "filesystem flags". [docutils]
> Documentation/userspace-api/landlock:605: ./include/uapi/linux/landlock.h:168: ERROR: Unknown target name: "filesystem flags". [docutils]
>
>
In case it's not obvious:
> vim +768 Documentation/userspace-api/landlock.rst
>
> 767
> > 768 Starting with the Landlock ABI version 10, it is possible to restrict
> 769 setting the local port of UDP sockets with the
> 770 ``LANDLOCK_ACCESS_NET_BIND_UDP`` right. This includes restricting the
> 771 ability to trigger autobind of an ephemeral port by the kernel by e.g.
> 772 sending a first datagram or setting the remote peer of a socket.
> 773 The ``LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP`` right controls setting the
> 774 remote port of UDP sockets (via :manpage:`connect(2)), and sending
missing ending `
> 775 datagrams to an explicit remote port (ignoring any destination set on
> 776 UDP sockets, via e.g. :manpage:`sendto(2)).
same here
> 777
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
--
~Randy
^ permalink raw reply
* Re: [PATCH v5 09/10] dt-bindings: firmware: add arm,ras-cper
From: Rob Herring @ 2026-06-12 14:49 UTC (permalink / raw)
To: Ahmed Tiba
Cc: Jonathan Cameron, will, xueshuai, saket.dumbre, mchehab, dave,
djbw, bp, tony.luck, guohanjun, lenb, skhan, vishal.l.verma,
rafael, corbet, ira.weiny, dave.jiang, krzk+dt, catalin.marinas,
alison.schofield, conor+dt, linux-arm-kernel, Michael.Zhao2,
linux-doc, linux-kernel, linux-cxl, Dmitry.Lamerov, devicetree,
linux-acpi, linux-edac, acpica-devel
In-Reply-To: <ceb19cb6-7083-44ad-a262-a8198f489257@arm.com>
On Thu, Jun 11, 2026 at 03:22:21PM +0100, Ahmed Tiba wrote:
> On 29/05/2026 17:44, Jonathan Cameron wrote:
> > On Fri, 29 May 2026 10:50:49 +0100
> > Ahmed Tiba<ahmed.tiba@arm.com> wrote:
> > > .../devicetree/bindings/firmware/arm,ras-cper.yaml | 54 ++++++++++++++++++++++
> > > MAINTAINERS | 5 ++
> > > 2 files changed, 59 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
> > > new file mode 100644
> > > index 000000000000..3d4de096093f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
> > > @@ -0,0 +1,54 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id:http://devicetree.org/schemas/firmware/arm,ras-cper.yaml#
> > > +$schema:http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Arm RAS CPER provider
> > > +
> > > +maintainers:
> > > + - Ahmed Tiba<ahmed.tiba@arm.com>
> > > +
> > > +description:
> > > + Arm Reliability, Availability and Serviceability (RAS) firmware can expose
> > > + a firmware-first CPER error source directly via DeviceTree. Firmware
> > > + provides the CPER Generic Error Status block and notifies the OS through
> > > + an interrupt.
> > I'd like some spec references in here if possible.
> I can add a reference to the UEFI CPER specification for the Generic
> Error Status record format.
>
> For the firmware-first DT description itself I do not have a more specific
> public reference to cite.
Is there a platform actually using this with DT (FVP doesn't really
count)?
Rob
^ permalink raw reply
* Re: configurable block error injection v5
From: Haris Iqbal @ 2026-06-12 14:10 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe
Cc: Jonathan Corbet, Damien Le Moal, Hannes Reinecke, Keith Busch,
linux-block, linux-doc
In-Reply-To: <20260611140703.2401204-1-hch@lst.de>
On 6/11/26 16:06, Christoph Hellwig wrote:
> Hi all,
>
> this series adds a new configurable block error injection facility.
> We already have a few to inject block errors, but unfortunately most
> of them are either not very useful or hard to use, or both:
>
> - The fail_make_request failure injection point can't distinguish
> different commands, different ranges in the file and can only injection
> plain I/O errors.
> - the should_fail_bio 'dynamic' failure injection has all the same issues
> as fail_make_request
> - dm-error can only fail all command in the table using BLK_STS_IOERR
> and requires setting up a new block device
> - dm-flakey and dm-dust allow all kinds of configurability, but still
> don't have good error selection, no good support for non-read/write
> commands and are limited to the dm table alignment requirements,
> which for zoned devices enforces setting them up for an entire zone.
> They also once again require setting up a stacked block device,
> which is really annoying in harnesses like xfstests
>
> This series adds a new debugfs-based block layer error injection
> that allows to configure what operations and ranges the injection
> applied to, and what status to return. It also allows to configure a
> failure ratio similar to the xfs errortag injection.
>
> Changes since v4:
> - don't unlock in removeall to avoid a race between removeall and setup
> - document why we can't match 0-sized bios
>
> Changes since v3:
> - use a static branch to guard the new condition
> - split out a new header so that jump_label.h doesn't get pulled into
> blk.h
> - more checking for impossible conditions in blk_status_to_tag
> - more spelling fixes
>
> Changes since v2:
> - improve the documentation a bit
> - fix a spelling mistake in a comment
>
> Changes since v1:
> - drop the should_fail_bio removal and cleanup depending on it, as it's
> used by eBPF programs and thus a hidden UABI.
> - as a result split the code out to it's own Kconfig symbol
> - various error handling fixed pointed out by Keith
> - documentation spelling fixes pointed out by Randy
>
> Diffstat:
> Documentation/block/error-injection.rst | 59 +++++
> Documentation/block/index.rst | 1
> block/Kconfig | 8
> block/Makefile | 1
> block/blk-core.c | 87 ++++++--
> block/blk-sysfs.c | 5
> block/blk.h | 3
> block/error-injection.c | 315 ++++++++++++++++++++++++++++++++
> block/error-injection.h | 21 ++
> block/genhd.c | 4
> include/linux/blkdev.h | 6
> 11 files changed, 490 insertions(+), 20 deletions(-)
Thank you for this series. It is a nice addition.
Reviewed-by: Md Haris Iqbal <haris.iqbal@linux.dev>
(for the whole series)
>
^ permalink raw reply
* Re: [PATCH v4 05/16] riscv: Add Zicclsm to cpufeature and hwprobe
From: Jesse Taube @ 2026-06-12 13:51 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt,
Jesse Taube, Conor Dooley, Charlie Jenkins, Andrew Jones,
Andy Chiu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-5-3f01a2449488@gmail.com>
On Thu, Jun 11, 2026 at 4:14 PM Guodong Xu <docular.xu@gmail.com> wrote:
>
> From: Jesse Taube <jesse@rivosinc.com>
>
> Zicclsm requires misaligned support for all regular load and store
> instructions, both scalar and vector, but not AMOs or other
> specialized forms of memory access, to main memory regions with both
> the cacheability and coherence PMAs, as defined in the profiles spec.
> Even though mandated, misaligned loads and stores might execute
> extremely slowly. Standard software distributions should assume their
> existence only for correctness, not for performance.
>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Andy Chiu <andy.chiu@sifive.com>
> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
> Tested-by: Charlie Jenkins <charlie@rivosinc.com>
> Signed-off-by: Jesse Taube <jesse@rivosinc.com>
Thanks for the update! Just an fyi email has changed to
jtaubepe@redhat.com though.
No need to change the signoff though.
Thanks,
Jesse Taube
> [Rebased, rewrote doc text, minor commit message revisions]
> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
>
> ---
> v4: No change.
> v3:
> - Move the hwprobe.rst entry to the IMA_EXT_1 section so its
> documentation matches the IMA_EXT_1 bit it was allocated in v2
> (Sashiko, agreed by Andrew).
> v2:
> - Rebased onto v7.1-rc2; moved ZICCLSM to IMA_EXT_1 and
> allocated a new bit for it
> ---
> Documentation/arch/riscv/hwprobe.rst | 4 ++++
> arch/riscv/include/asm/hwcap.h | 1 +
> arch/riscv/include/uapi/asm/hwprobe.h | 1 +
> arch/riscv/kernel/cpufeature.c | 1 +
> arch/riscv/kernel/sys_hwprobe.c | 1 +
> 5 files changed, 8 insertions(+)
>
> diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> index d9928641deb99..49d9fb68632d0 100644
> --- a/Documentation/arch/riscv/hwprobe.rst
> +++ b/Documentation/arch/riscv/hwprobe.rst
> @@ -401,3 +401,7 @@ The following keys are defined:
> as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
> extensions specification, ratified in commit 302a2d45c243
> ("Update build-pdf.yml") of riscv-cfi.
> +
> + * :c:macro:`RISCV_HWPROBE_EXT_ZICCLSM`: The Zicclsm extension is supported,
> + as defined in the RISC-V Profiles specification starting from commit
> + b1d80660 ("Updated to ratified state.")
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index 44bf8c7d8acc5..e8f4a7dd96a93 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -112,6 +112,7 @@
> #define RISCV_ISA_EXT_ZCLSD 103
> #define RISCV_ISA_EXT_ZICFILP 104
> #define RISCV_ISA_EXT_ZICFISS 105
> +#define RISCV_ISA_EXT_ZICCLSM 106
>
> #define RISCV_ISA_EXT_XLINUXENVCFG 127
>
> diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> index 9139edba0aecb..6819df159c51e 100644
> --- a/arch/riscv/include/uapi/asm/hwprobe.h
> +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> @@ -116,6 +116,7 @@ struct riscv_hwprobe {
> #define RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE 15
> #define RISCV_HWPROBE_KEY_IMA_EXT_1 16
> #define RISCV_HWPROBE_EXT_ZICFISS (1ULL << 0)
> +#define RISCV_HWPROBE_EXT_ZICCLSM (1ULL << 1)
>
> /* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
>
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 686dde3ce3b98..1fb595581adcf 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -502,6 +502,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> __RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
> __RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
> __RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
> + __RISCV_ISA_EXT_DATA(zicclsm, RISCV_ISA_EXT_ZICCLSM),
> __RISCV_ISA_EXT_DATA(ziccrse, RISCV_ISA_EXT_ZICCRSE),
> __RISCV_ISA_EXT_SUPERSET_VALIDATE(zicfilp, RISCV_ISA_EXT_ZICFILP, riscv_xlinuxenvcfg_exts,
> riscv_cfilp_validate),
> diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
> index f8f68ba781b45..9cf62266f1890 100644
> --- a/arch/riscv/kernel/sys_hwprobe.c
> +++ b/arch/riscv/kernel/sys_hwprobe.c
> @@ -205,6 +205,7 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
> * in the hart_isa bitmap, are made.
> */
> EXT_KEY(isainfo->isa, ZICFISS, pair->value, missing);
> + EXT_KEY(isainfo->isa, ZICCLSM, pair->value, missing);
> }
>
> /* Now turn off reporting features if any CPU is missing it. */
>
> --
> 2.43.0
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
^ permalink raw reply
* Re: [RFC PATCH v2 02/14] kcov: fix INIT_TRACK race in kcov_dataflow
From: Yunseong Kim @ 2026-06-12 13:11 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, sashiko-bot
In-Reply-To: <CAG_fn=XB7_zbjGzpgwEzm5dqcwehqvB+=SpJhHvw9QdETberAg@mail.gmail.com>
Hi Alexander,
> On Fri, Jun 12, 2026 at 9:25 AM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>
>> Hi Alexander,
>>
>>> On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>>>
>>>> [snip...]
>>
>> Thank you for your guide. I'll remove it in the next patch set.
> Also please make sure to update the patch version. It's really hard to
> distinguish between "[RFC PATCH v2 n/6]" and "[RFC PATCH v2 m/14]"
> when both series pop up in the inbox.
My apologies for the noise in the v1 (Mistakenly sent v2).
I will ensure the v3 patch is thoroughly cleaned up before submitting.
Thank you again, for the review.
Best regards,
Yunseong
^ permalink raw reply
* Re: [PATCH v2 0/2] vsprintf: add upper case to %p[mM] et alia
From: Petr Mladek @ 2026-06-12 13:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jiri Kosina, Daniel J. Ogorchock, Tamir Duberstein, linux-doc,
linux-kernel, linux-input, Steven Rostedt, Rasmus Villemoes,
Sergey Senozhatsky, Jonathan Corbet, Shuah Khan,
Benjamin Tissoires, Andrew Morton
In-Reply-To: <20260603104351.152085-1-andriy.shevchenko@linux.intel.com>
On Wed 2026-06-03 12:34:01, Andy Shevchenko wrote:
> The first patch induced by Sashiko rightfully rises a concern on
> potential ABI breakage. To avoid that and allow the user (patch 2)
> to be converted to use unified output introduce %p[mM][...]U for
> printing in upper case. Tests are included and passed.
>
> Changelog v2:
> - added first patch (Sashiko)
>
> Andy Shevchenko (2):
> vsprintf: Add upper case flavour to %p[mM]
> HID: nintendo: Use %pM format specifier for MAC addresses
JFYI, the patchset has been committed into printk/linux.git,
branch for-7.2-vsprintf-pmM-uppercase.
Best Regards,
Petr
^ permalink raw reply
* Re: [RFC PATCH v2 03/14] kcov: add barriers to recursion guard in kcov_df_write
From: Yunseong Kim @ 2026-06-12 12:55 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, Yunseong Kim, Yunseong Kim
In-Reply-To: <CAG_fn=XRzSuFrxtFbz2t9jjY8HPUUhhnU3iWJiSV-X4+hg66cw@mail.gmail.com>
Hi Alexander,
> On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>
>> The recursion guard (bit-31 of kcov_df_seq) prevents reentry when
>> copy_from_kernel_nofault() or other called functions are instrumented
>> with INSTRUMENT_ALL. Without compiler barriers, the guard set/clear
>> can be reordered relative to the function body, making the protection
>> ineffective under optimization.
>>
>> Add barrier() after setting the guard and before clearing it, ensuring
>> the compiler does not move instrumented operations outside the guarded
>> region.
>>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
>> ---
>> kernel/kcov_dataflow.c | 2 ++
>
> Please merge this patch into the one introducing kcov_dataflow.c
>
Understood. I'll merge them in v3.
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/kernel/kcov_dataflow.c b/kernel/kcov_dataflow.c
>> index df7e8bf70bfa..5248293280d5 100644
>> --- a/kernel/kcov_dataflow.c
>> +++ b/kernel/kcov_dataflow.c
>> @@ -86,6 +86,7 @@ kcov_df_write(u64 type_marker, u64 pc, u64 meta, void *ptr,
>> if (t->kcov_df_seq & (1U << 31))
>> return;
>> t->kcov_df_seq |= (1U << 31);
>> + barrier();
>
> Please make sure barriers have comments explaining which barriers they
> pair with (see kernel/kcov.c)
Thanks for the pointer. I see the existing implementation now and will align
my changes with it.
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 01/14] kcov: add per-task dataflow tracking for function arguments/return values
From: Yunseong Kim @ 2026-06-12 12:51 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, Yunseong Kim, Yunseong Kim
In-Reply-To: <CAG_fn=WYdnX_09RNs3sTQWn+KZZaw+X9a=s1Uk1bqd3gW04h6Q@mail.gmail.com>
Hi Alexander,
> On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>
>> [snip...]
>> ---
>> include/linux/sched.h | 10 ++
>> kernel/Makefile | 3 +
>> kernel/kcov.c | 2 +
>> kernel/kcov_dataflow.c | 324 +++++++++++++++++++++++++++++++++++++++++++++++++
>
> I think the total size of kcov_dataflow.c doesn't justify splitting it
> in multiple patches.
Thanks for the feedback. I'll combine the changes into a single patch for the
next version.
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 01/14] kcov: add per-task dataflow tracking for function arguments/return values
From: Yunseong Kim @ 2026-06-12 12:48 UTC (permalink / raw)
To: Julian Braha, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Alexander Potapenko, Dmitry Vyukov, Andrew Morton, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Nathan Chancellor, Nicolas Schier, Nick Desaulniers,
Bill Wendling, Justin Stitt, Kees Cook, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Jonathan Corbet,
Shuah Khan
Cc: linux-kernel, kasan-dev, rust-for-linux, linux-kbuild, llvm,
linux-mm, linux-kselftest, workflows, linux-doc, Yeoreum Yun,
Yunseong Kim, Yunseong Kim
In-Reply-To: <2e528372-aba4-4621-a9a3-7ce23571ef37@gmail.com>
Hi Julian,
> On 6/11/26 17:21, Yunseong Kim wrote:
>> +config KCOV_DATAFLOW_RET
>> + bool "Enable KCOV dataflow: return value capture"
>> + depends on KCOV
>> + depends on DEBUG_INFO
>> + depends on $(cc-option,-fsanitize-coverage=trace-ret)
>> + help
>> + Captures function return values via /sys/kernel/debug/kcov_dataflow.
>> + Struct pointer returns are auto-expanded using compiler DebugInfo
>> + metadata, recording individual field values at runtime.
>> + Enable per-module with: KCOV_DATAFLOW_file.o := y in the Makefile.
>> + Requires clang with -fsanitize-coverage=trace-ret support.
>> +
>> +config KCOV_DATAFLOW_NO_INLINE
>> + bool "Disable inlining for dataflow-instrumented files"
>> + default n
> In Kconfig, when you don't specify any default explicitly, it's
> implicitly 'default n'.
>
> I think either style (implicit or explicit) is fine and both are used
> throughout the kernel, but is there any reason to make it explicit only
> for KCOV_DATAFLOW_NO_INLINE, and implicit for the others?
Thank you for pointing out.
You're right, there's no reason to make it explicit only for this one.
I'll drop the "default n" line to be consistent with the other options
in the same block.
> - Julian Braha
Best regards,
Yunseong
^ permalink raw reply
* Re: [PATCH v3] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
From: Jason Gunthorpe @ 2026-06-12 12:48 UTC (permalink / raw)
To: Shanker Donthineni
Cc: Will Deacon, Catalin Marinas, Vladimir Murzin,
linux-arm-kernel@lists.infradead.org, Mark Rutland,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Vikram Sethi, Jason Sequeira
In-Reply-To: <851c4107-3f6d-46f3-b659-212ce4f69e6e@nvidia.com>
On Thu, Jun 11, 2026 at 08:13:48PM -0500, Shanker Donthineni wrote:
> For the scalar MMIO helpers, the workaround promotes the raw writes to
> store-release on affected CPUs as v1/v2 shown below. For the memcpy-toIO
> helpers, could you please clarify the specific reason for adding a dmb despite
> the documented no-ordering contract? Is the concern that some drivers may
> be relying on ordering across memcpy_toio_*() today even though the API
> does not guarantee it, and that we should cover those cases defensively?
I think given how arm implements them today the iocopy's are actually
the _relaxed variations.. I wonder if this matters to any user?
Jason
^ permalink raw reply
* Re: [RFC PATCH v2 0/6] kcov: per-task dataflow extraction at kernel function boundaries
From: Yunseong Kim @ 2026-06-12 12:45 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, Dmitry Vyukov, Andrey Konovalov, Andrew Morton,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Nicolas Schier, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Jonathan Corbet, Shuah Khan,
linux-kernel, kasan-dev, llvm, linux-kbuild, rust-for-linux,
workflows, linux-doc, Yunseong Kim, Yeoreum Yun
In-Reply-To: <20260612073858.GS187714@noisy.programming.kicks-ass.net>
Hi Peter,
> On Fri, Jun 12, 2026 at 09:37:40AM +0200, Yunseong Kim wrote:
>> Hi Peter,
>>
>>> On Wed, Jun 03, 2026 at 07:43:27PM +0200, Yunseong Kim wrote:
>>>> CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL instruments every function in the
>>>> kernel.
>>>
>>> Well, I would hope it would very much not instrument noinstr functions.
>>
>> Thank you for your guidance. I updated the default
>> CONFIG_KCOV_DATAFLOW_NO_INLINE to n.
>
> That's not really the point. The compiler extension *must* respect
> noinstr. If there it no function attribute to suppress this kcov stuff,
> then its an absolute non-starter.
Thank you again, for pointing that out.
I've been using the same mechanism that KCOV (trace-pc) already relies on.
trace-args/ret shares the identical code path and attribute check.
LLVM side:
noinstr functions are never instrumented because the existing
NoSanitizeCoverage attribute check at the top of the function-level pass
covers all SanCov instrumentation types including trace-args/ret.
1. Marked functions as noinstr expands to __no_sanitize_coverage, emits
__attribute__((no_sanitize("coverage")))
2. Clang translates that to Attribute::NoSanitizeCoverage
3. llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
if (F.hasFnAttribute(Attribute::NoSanitizeCoverage))
https://github.com/llvm/llvm-project/commit/280333021e95#diff-1b024748b036cfd10a7c3dfc7e9c53b0f752b27d7ea193939c59b2de60f69a70R445
4. skips ALL instrumentation including trace-args/trace-ret
Dobule check with objtool:
Even KCOV_DATAFLOW_NO_INLINE enabled kernel:
$ for fn in ct_nmi_enter ct_nmi_exit exc_nmi syscall_enter_from_user_mode; do
count=$(objdump -d vmlinux --disassemble=$fn | grep -c sanitizer_cov)
echo "$fn: $count sanitizer calls"
done
ct_nmi_enter: 0 sanitizer calls
ct_nmi_exit: 0 sanitizer calls
exc_nmi: 0 sanitizer calls
syscall_enter_from_user_mode: 0 sanitizer calls
If Rust noinstr functions are added in the future, they would use
#[no_sanitize(coverage)]. This maps to the same Attribute::NoSanitizeCoverage
LLVM attribute, yielding the exact same check and result.
Best regards,
Yunseong
^ permalink raw reply
* Re: [PATCH 0/2] module: restrict module auto-loading to privileged users
From: Michal Gorlas @ 2026-06-12 12:41 UTC (permalink / raw)
To: Kees Cook, Sami Tolvanen
Cc: Michal Gorlas, Jonathan Corbet, Shuah Khan, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Aaron Tomlin, linux-doc, linux-kernel,
linux-modules
In-Reply-To: <202606101317.D23383F465@keescook>
On Wed Jun 10, 2026 at 10:23 PM CEST, Kees Cook wrote:
> On Fri, Jun 05, 2026 at 06:36:46PM +0000, Sami Tolvanen wrote:
>> On Fri, May 15, 2026 at 07:20:18PM +0200, Michal Gorlas wrote:
>> > Add option to restrict the module auto-loading to CAP_SYS_ADMIN.
>> > This is heavily inspired by CONFIG_GRKERNSEC_MODHARDEN of the latest
>> > available Grsecurity patches [1]. Instead of checking whether the
>> > callers' UID is 0, check whether the calling process has CAP_SYS_ADMIN.
>> > The reasoning here is that many modules are autoloaded by systemd
>> > services which are running as privileged users, but do not have UID 0.
>> > While systemd-udevd runs as root, systemd-network (which often
>> > auto-loads a module) for example runs as system user (UID range 6 to
>> > 999).
>> >
>> > When enabled, reduces attack surface where unprivileged users can trigger
>> > vulnerable module to be auto-loaded, to then exploit it. Recent LPEs
>> > (CopyFail [3], DirtyFrag [4]) for example, would have been mitigated
>> > with this option enabled as long as the vulnerable modules are not built-in
>> > (or already loaded at the point of running the exploit).
>>
>> This sounds potentially useful as an optional feature. Kees, you've
>> looked at grsec features in the past, do you have any thoughts about
>> this?
>
> This doesn't really look like GRKERNSEC_MODHARDEN to me? In that
> feature, the credentials of the usermode helper are passed down so that
> udev or whatever can examine them and make choices (instead of seeing
> the uid-0 usermode helper credentials).
It is based on a part of GRKERNSEC_MODHARDEN policy check in
____request_module in [1]. By no means it reasembles the full
feature. Very similar check was proposed for linux-hardened
tree few years back (with the difference of checking for
CAP_SYS_MODULE) [2].
>
> This looks like it is just doing a request-time policy check, but that's
> already covered by the security_kernel_module_request() call immediately
> before the proposed module_autoload_restrict check.
>
> Also note that module loading is _already_ controlled by CAP_SYS_MODULE,
> not uid 0 nor CAP_SYS_ADMIN.
>
> Sashiko has similar feedback, and some other notes too:
> https://sashiko.dev/#/patchset/20260515-autoload_restrict-v1-0-40b7c03ddd04%409elements.com
My understanding is that CAP_SYS_MODULE is for processes that are
using load/unload directly (i.e. by doing init_module/delete_module
syscall), and the kmod's__request_module, is a user mode call
(at least that's what the comment in __request_module suggests),
so CAP_SYS_MODULE does not have to be set for processes that are
just using __request_module. One example of this is systemd-networkd
(there are probably more but that's one that I tested), i.e. it will
trigger the module autoload even though its not given CAP_SYS_MODULE.
Please correct me if I am wrong here.
>
> I'm not clear what problem this patch is trying to solve?
To have an option to completely disable module auto-loading for
non-root in general. By root here I also think of system users so
UID 1-999 [3] (had typo in cover for the patch, sorry for that).
Not sure if this is a best approach, it could be also implemented
as small LSM hook on security_kernel_module_request() (just a thought
after you mentioned it). Either way, the idea is to limit the
auto-loading, not direct loading.
[1] - https://github.com/minipli/linux-grsec/blob/v4.9.24-grsec/kernel/kmod.c#L153
[2] - https://github.com/anthraxx/linux-hardened/pull/23
[3] - https://systemd.io/UIDS-GIDS/
Best,
Michal
^ permalink raw reply
* Re: [Question] 5.posting.rst use To: or Cc:
From: Jonathan Corbet @ 2026-06-12 12:41 UTC (permalink / raw)
To: Manuel Ebner, Shuah Khan, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
In-Reply-To: <f55eb34b92a01159e0224611296fc51fcfb5ec5d.camel@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> so every time I send a mail to lists or maintainers I have to choose: To:
> or Cc:. I did look for an answer in the Documentation but couldn't find
> one.
> I think if there is an answer then it could be added to 5.posting.rst .
Normally you would To: the maintainers, CC: the rest, but the end result
is the same either way - it really doesn't matter.
jon
^ permalink raw reply
* Re: [PATCH v6 02/12] PCI: liveupdate: Track outgoing preserved PCI devices
From: Pasha Tatashin @ 2026-06-12 11:38 UTC (permalink / raw)
To: David Matlack
Cc: kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Leon Romanovsky,
Lukas Wunner, Mike Rapoport, Parav Pandit, Pasha Tatashin,
Pranjal Shrivastava, Pratyush Yadav, Saeed Mahameed,
Samiullah Khawaja, Shuah Khan, Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <20260522202410.3104264-3-dmatlack@google.com>
On Fri, 22 May 2026 20:24:00 +0000, David Matlack <dmatlack@google.com> wrote:
> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> index 737e7b9366db..065d5af822f7 100644
> --- a/drivers/pci/liveupdate.c
> +++ b/drivers/pci/liveupdate.c
> @@ -115,6 +150,138 @@ static struct liveupdate_flb pci_liveupdate_flb = {
> [ ... skip 59 lines ... ]
> + dev_ser->bdf = pci_dev_id(dev);
> + dev_ser->refcount = 1;
> +
> + dev->liveupdate.outgoing = dev_ser;
> + return 0;
> + }
This loop is compatible with KHO block iterators, as mentioned in the
previous email. It should be straightforward to convert to them.
>
> diff --git a/include/linux/kho/abi/pci.h b/include/linux/kho/abi/pci.h
> index 6ebcf817fff4..85def616703d 100644
> --- a/include/linux/kho/abi/pci.h
> +++ b/include/linux/kho/abi/pci.h
> @@ -23,19 +23,22 @@
> [ ... skip 16 lines ... ]
> */
> struct pci_dev_ser {
> u32 domain;
> u16 bdf;
> - u16 padding;
> + u16 refcount;
Just add refcount to the previous patch, to reduce changes to your own
code.
Otherwise looks good
--
Pasha Tatashin <pasha.tatashin@soleen.com>
^ permalink raw reply
* Re: [RFC PATCH v2 01/14] kcov: add per-task dataflow tracking for function arguments/return values
From: Julian Braha @ 2026-06-12 11:37 UTC (permalink / raw)
To: Yunseong Kim, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Alexander Potapenko, Dmitry Vyukov, Andrew Morton, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Nathan Chancellor, Nicolas Schier, Nick Desaulniers,
Bill Wendling, Justin Stitt, Kees Cook, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Jonathan Corbet,
Shuah Khan
Cc: linux-kernel, kasan-dev, rust-for-linux, linux-kbuild, llvm,
linux-mm, linux-kselftest, workflows, linux-doc, Yeoreum Yun
In-Reply-To: <20260611-b4-kcov-dataflow-v2-v2-1-0a261da3987c@est.tech>
On 6/11/26 17:21, Yunseong Kim wrote:
> +config KCOV_DATAFLOW_RET
> + bool "Enable KCOV dataflow: return value capture"
> + depends on KCOV
> + depends on DEBUG_INFO
> + depends on $(cc-option,-fsanitize-coverage=trace-ret)
> + help
> + Captures function return values via /sys/kernel/debug/kcov_dataflow.
> + Struct pointer returns are auto-expanded using compiler DebugInfo
> + metadata, recording individual field values at runtime.
> + Enable per-module with: KCOV_DATAFLOW_file.o := y in the Makefile.
> + Requires clang with -fsanitize-coverage=trace-ret support.
> +
> +config KCOV_DATAFLOW_NO_INLINE
> + bool "Disable inlining for dataflow-instrumented files"
> + default n
In Kconfig, when you don't specify any default explicitly, it's
implicitly 'default n'.
I think either style (implicit or explicit) is fine and both are used
throughout the kernel, but is there any reason to make it explicit only
for KCOV_DATAFLOW_NO_INLINE, and implicit for the others?
- Julian Braha
^ permalink raw reply
* Re: [RFC V2 0/3] lib/vsprintf: Add support for pgtable entries
From: David Hildenbrand (Arm) @ 2026-06-12 11:14 UTC (permalink / raw)
To: Matthew Wilcox, Andy Shevchenko
Cc: Anshuman Khandual, linux-mm, Rasmus Villemoes, Sergey Senozhatsky,
Petr Mladek, Steven Rostedt, Jonathan Corbet, Andrew Morton,
linux-kernel, linux-doc
In-Reply-To: <aisOi1B0o5KYyaQo@casper.infradead.org>
On 6/11/26 21:37, Matthew Wilcox wrote:
> On Thu, Jun 11, 2026 at 10:33:35PM +0300, Andy Shevchenko wrote:
>> On Thu, Jun 11, 2026 at 08:15:57PM +0100, Matthew Wilcox wrote:
>>>
>>> You didn't address my objection here:
>>>
>>> https://lore.kernel.org/linux-mm/aFQP8LzVMctf6XH5@casper.infradead.org/
>>>
>>> ie there is now no typechecking possible. So you've made it more
>>> dangerous. I reiterate my NACK to the concept, not to the implementation.
>>
>> But this is more of a global question, how do we check the validity of
>> the parameters of pointer extensions in the kernel? Does anybody go to
>> commit into GCC plugin or so for this job?
>
> I agree that it's a global question that it would be great for somebody
> to answer. But it's specifically a problem for this patchset because:
>
> - It's really easy to get confused about which page table level you're
> working on. And hugetlbfs deliberately increases that confusion.
Yeah ... so far I was assuming that for hugetlb, all relevant entries (what we
call a PTE although it isn't ....) would have to be the same size. I mean, at
least in the callers they are the same size (pte_t)
> - Different levels of the page tables actually do have different sizes
> on some architectures, so if you think you're looking at a pointer to a
> 64-bit quantity when it's really a pointer to a 32-bit quantity, things
> Will Go Wrong (or vice-versa. And some architctures are big-endian)
I see your point with the pass-by-pointer.
> - But on x86-64, Everything Is Fine because all levels of the page table
> are basically identical, so you'll never notice there's a problem.
I assume on most architectures.
Let's see if we can stop printing that information completely, so we can avoid
messing with this at all.
--
Cheers,
David
^ permalink raw reply
* Re: [RFC V2 3/3] mm: Replace pgtable entry prints with new format
From: David Hildenbrand (Arm) @ 2026-06-12 11:08 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Andy Shevchenko, Rasmus Villemoes, Sergey Senozhatsky,
Petr Mladek, Steven Rostedt, Jonathan Corbet, Andrew Morton,
linux-kernel, linux-doc, Lorenzo Stoakes
In-Reply-To: <20260610043545.3725735-4-anshuman.khandual@arm.com>
On 6/10/26 06:35, Anshuman Khandual wrote:
> Replace all existing pgtable entry prints with recently added new format in
> __print_bad_page_map_pgtable().
>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Lorenzo Stoakes <ljs@kernel.org>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
>
> mm/memory.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 86a973119bd4..8a25790f7c24 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -521,7 +521,6 @@ static bool is_bad_page_map_ratelimited(void)
>
> static void __print_bad_page_map_pgtable(struct mm_struct *mm, unsigned long addr)
> {
> - unsigned long long pgdv, p4dv, pudv, pmdv;
> p4d_t p4d, *p4dp;
> pud_t pud, *pudp;
> pmd_t pmd, *pmdp;
> @@ -532,34 +531,30 @@ static void __print_bad_page_map_pgtable(struct mm_struct *mm, unsigned long add
> * see locking requirements for print_bad_page_map().
> */
> pgdp = pgd_offset(mm, addr);
> - pgdv = pgd_val(*pgdp);
>
> if (!pgd_present(*pgdp) || pgd_leaf(*pgdp)) {
> - pr_alert("pgd:%08llx\n", pgdv);
> + pr_alert("pgd:%ppgd\n", pgdp);
> return;
> }
>
> p4dp = p4d_offset(pgdp, addr);
> p4d = p4dp_get(p4dp);
> - p4dv = p4d_val(p4d);
>
> if (!p4d_present(p4d) || p4d_leaf(p4d)) {
> - pr_alert("pgd:%08llx p4d:%08llx\n", pgdv, p4dv);
> + pr_alert("pgd:%ppgd p4d:%pp4d\n", pgdp, p4dp);
> return;
> }
>
> pudp = pud_offset(p4dp, addr);
> pud = pudp_get(pudp);
> - pudv = pud_val(pud);
>
> if (!pud_present(pud) || pud_leaf(pud)) {
> - pr_alert("pgd:%08llx p4d:%08llx pud:%08llx\n", pgdv, p4dv, pudv);
> + pr_alert("pgd:%ppgd p4d:%pp4d pud:%ppud\n", pgdp, p4dp, pudp);
> return;
> }
>
> pmdp = pmd_offset(pudp, addr);
> pmd = pmdp_get(pmdp);
> - pmdv = pmd_val(pmd);
>
> /*
> * Dumping the PTE would be nice, but it's tricky with CONFIG_HIGHPTE,
> @@ -567,8 +562,8 @@ static void __print_bad_page_map_pgtable(struct mm_struct *mm, unsigned long add
> * doing another map would be bad. print_bad_page_map() should
> * already take care of printing the PTE.
> */
> - pr_alert("pgd:%08llx p4d:%08llx pud:%08llx pmd:%08llx\n", pgdv,
> - p4dv, pudv, pmdv);
> + pr_alert("pgd:%ppgd p4d:%pp4d pud:%ppud pmd:%ppmd\n", pgdp,
> + p4dp, pudp, pmdp);
> }
>
> /*
After some off-list discussion, I wonder if we can make our life easier.
I think, even with your patch, there is still the case:
pr_alert("BUG: Bad page map in process %s %s:%08llx", current->comm,
pgtable_level_to_str(level), entry);
Where we cast all entries to an "unsigned long" in the callers. We'd have to rework all
that for 128bit entries either way (passing them in some struct instead).
I really just extended what we used to do here in print_bad_pte() before commit ec63a44011d.
Maybe we should just drop the "print the involved page table entries" thing?
I mean, we do have the actual page, and we do have the address in the address space, which
we all print.
Not sure if the actual page table entries are that relevant? Would clean up nicely:
From a1673198f9687b307496903b3f516a3c00f76199 Mon Sep 17 00:00:00 2001
From: "David Hildenbrand (Arm)" <david@kernel.org>
Date: Fri, 12 Jun 2026 13:06:00 +0200
Subject: [PATCH] tmp
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
mm/memory.c | 80 +++++++++--------------------------------------------
1 file changed, 13 insertions(+), 67 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index d4b3540ae659..989f7d6b280d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -519,58 +519,6 @@ static bool is_bad_page_map_ratelimited(void)
return false;
}
-static void __print_bad_page_map_pgtable(struct mm_struct *mm, unsigned long addr)
-{
- unsigned long long pgdv, p4dv, pudv, pmdv;
- p4d_t p4d, *p4dp;
- pud_t pud, *pudp;
- pmd_t pmd, *pmdp;
- pgd_t *pgdp;
-
- /*
- * Although this looks like a fully lockless pgtable walk, it is not:
- * see locking requirements for print_bad_page_map().
- */
- pgdp = pgd_offset(mm, addr);
- pgdv = pgd_val(*pgdp);
-
- if (!pgd_present(*pgdp) || pgd_leaf(*pgdp)) {
- pr_alert("pgd:%08llx\n", pgdv);
- return;
- }
-
- p4dp = p4d_offset(pgdp, addr);
- p4d = p4dp_get(p4dp);
- p4dv = p4d_val(p4d);
-
- if (!p4d_present(p4d) || p4d_leaf(p4d)) {
- pr_alert("pgd:%08llx p4d:%08llx\n", pgdv, p4dv);
- return;
- }
-
- pudp = pud_offset(p4dp, addr);
- pud = pudp_get(pudp);
- pudv = pud_val(pud);
-
- if (!pud_present(pud) || pud_leaf(pud)) {
- pr_alert("pgd:%08llx p4d:%08llx pud:%08llx\n", pgdv, p4dv, pudv);
- return;
- }
-
- pmdp = pmd_offset(pudp, addr);
- pmd = pmdp_get(pmdp);
- pmdv = pmd_val(pmd);
-
- /*
- * Dumping the PTE would be nice, but it's tricky with CONFIG_HIGHPTE,
- * because the table should already be mapped by the caller and
- * doing another map would be bad. print_bad_page_map() should
- * already take care of printing the PTE.
- */
- pr_alert("pgd:%08llx p4d:%08llx pud:%08llx pmd:%08llx\n", pgdv,
- p4dv, pudv, pmdv);
-}
-
/*
* This function is called to print an error when a bad page table entry (e.g.,
* corrupted page table entry) is found. For example, we might have a
@@ -584,8 +532,7 @@ static void __print_bad_page_map_pgtable(struct mm_struct *mm, unsigned long add
* page table lock.
*/
static void print_bad_page_map(struct vm_area_struct *vma,
- unsigned long addr, unsigned long long entry, struct page *page,
- enum pgtable_level level)
+ unsigned long addr, struct page *page, enum pgtable_level level)
{
struct address_space *mapping;
pgoff_t index;
@@ -596,9 +543,8 @@ static void print_bad_page_map(struct vm_area_struct *vma,
mapping = vma->vm_file ? vma->vm_file->f_mapping : NULL;
index = linear_page_index(vma, addr);
- pr_alert("BUG: Bad page map in process %s %s:%08llx", current->comm,
- pgtable_level_to_str(level), entry);
- __print_bad_page_map_pgtable(vma->vm_mm, addr);
+ pr_alert("BUG: Bad page map in process %s on %s level", current->comm,
+ pgtable_level_to_str(level));
if (page)
dump_page(page, "bad page map");
pr_alert("addr:%px vm_flags:%08lx anon_vma:%px mapping:%px index:%lx\n",
@@ -627,8 +573,8 @@ static inline bool pgtable_level_has_pxx_special(enum pgtable_level level)
}
}
-#define print_bad_pte(vma, addr, pte, page) \
- print_bad_page_map(vma, addr, pte_val(pte), page, PGTABLE_LEVEL_PTE)
+#define print_bad_pte(vma, addr, page) \
+ print_bad_page_map(vma, addr, page, PGTABLE_LEVEL_PTE)
/**
* __vm_normal_page() - Get the "struct page" associated with a page table entry.
@@ -697,7 +643,7 @@ static inline bool pgtable_level_has_pxx_special(enum pgtable_level level)
*/
static inline struct page *__vm_normal_page(struct vm_area_struct *vma,
unsigned long addr, unsigned long pfn, bool special,
- unsigned long long entry, enum pgtable_level level)
+ enum pgtable_level level)
{
if (pgtable_level_has_pxx_special(level)) {
if (unlikely(special)) {
@@ -710,7 +656,7 @@ static inline struct page *__vm_normal_page(struct vm_area_struct *vma,
if (is_zero_pfn(pfn) || is_huge_zero_pfn(pfn))
return NULL;
- print_bad_page_map(vma, addr, entry, NULL, level);
+ print_bad_page_map(vma, addr, NULL, level);
return NULL;
}
/*
@@ -741,7 +687,7 @@ static inline struct page *__vm_normal_page(struct vm_area_struct *vma,
if (unlikely(pfn > highest_memmap_pfn)) {
/* Corrupted page table entry. */
- print_bad_page_map(vma, addr, entry, NULL, level);
+ print_bad_page_map(vma, addr, NULL, level);
return NULL;
}
/*
@@ -768,7 +714,7 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
pte_t pte)
{
return __vm_normal_page(vma, addr, pte_pfn(pte), pte_special(pte),
- pte_val(pte), PGTABLE_LEVEL_PTE);
+ PGTABLE_LEVEL_PTE);
}
/**
@@ -810,7 +756,7 @@ struct page *vm_normal_page_pmd(struct vm_area_struct *vma, unsigned long addr,
pmd_t pmd)
{
return __vm_normal_page(vma, addr, pmd_pfn(pmd), pmd_special(pmd),
- pmd_val(pmd), PGTABLE_LEVEL_PMD);
+ PGTABLE_LEVEL_PMD);
}
/**
@@ -851,7 +797,7 @@ struct page *vm_normal_page_pud(struct vm_area_struct *vma,
unsigned long addr, pud_t pud)
{
return __vm_normal_page(vma, addr, pud_pfn(pud), pud_special(pud),
- pud_val(pud), PGTABLE_LEVEL_PUD);
+ PGTABLE_LEVEL_PUD);
}
#endif
@@ -1672,7 +1618,7 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb,
folio_remove_rmap_ptes(folio, page, nr, vma);
if (unlikely(folio_mapcount(folio) < 0))
- print_bad_pte(vma, addr, ptent, page);
+ print_bad_pte(vma, addr, page);
}
if (unlikely(__tlb_remove_folio_pages(tlb, page, nr, delay_rmap))) {
*force_flush = true;
@@ -4812,7 +4758,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
} else if (softleaf_is_marker(entry)) {
ret = handle_pte_marker(vmf);
} else {
- print_bad_pte(vma, vmf->address, vmf->orig_pte, NULL);
+ print_bad_pte(vma, vmf->address, NULL);
ret = VM_FAULT_SIGBUS;
}
goto out;
--
2.43.0
--
Cheers,
David
^ permalink raw reply related
* Re: [PATCH v6 01/12] PCI: liveupdate: Set up FLB handler for the PCI core
From: Pasha Tatashin @ 2026-06-12 10:47 UTC (permalink / raw)
To: Mike Rapoport
Cc: Pasha Tatashin, David Matlack, kexec, linux-doc, linux-kernel,
linux-mm, linux-pci, Adithya Jayachandran, Alexander Graf,
Alex Williamson, Bjorn Helgaas, Chris Li, David Rientjes,
Jacob Pan, Jason Gunthorpe, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Parav Pandit, Pranjal Shrivastava,
Pratyush Yadav, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <aiutNINqxhtlm2Dt@kernel.org>
On 2026-06-12 09:54:44+03:00, Mike Rapoport wrote:
> On Fri, Jun 12, 2026 at 05:15:02AM +0000, Pasha Tatashin wrote:
>
> > On Fri, 22 May 2026 20:23:59 +0000, David Matlack <dmatlack@google.com> wrote:
> >
> > Please add Pratyush, Mike, and myself so we are notified directly of
> > incoming patches, the same as with other areas where the liveupdate/
> > tree is specified.
>
> Or we can add PCI liveupdate files to LIVEUPDATE entry.
That will not work, as we cannot serve as maintainers for
PCI/VFIO/IOMMU/KVM, etc. David Matlack will be the maintainer for the
PCI components, and we will accept patches once they have been approved
by him.
The simplification we could do is to create an email alias
for the live-update tree maintainers. This would allow us to use a
single entry instead of listing all three of us individually.
^ permalink raw reply
* Re: 答复: [PATCH v3] mm/mempool: Untangle CONFIG_SLUB_DEBUG_ON abuse and switch to static key
From: Vlastimil Babka (SUSE) @ 2026-06-12 10:43 UTC (permalink / raw)
To: Li,Rongqing, Jonathan Corbet, Shuah Khan, Harry Yoo,
Andrew Morton, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: Matthew Wilcox, Usama Arif
In-Reply-To: <d06d13c4aebe44a2abca4aee0083644f@baidu.com>
On 6/12/26 12:12, Li,Rongqing wrote:
>> 主题: [PATCH v3] mm/mempool: Untangle CONFIG_SLUB_DEBUG_ON abuse
>> and switch to static key
>>
>> From: Li RongQing <lirongqing@baidu.com>
>>
>> The mempool subsystem historically wrapped its debugging logic inside an
>> merely defines compile-time defaults for SLUB and caused two flaws:
>>
>> 1. On production kernels where CONFIG_SLUB_DEBUG=y but
>> CONFIG_SLUB_DEBUG_ON=n, mempool debugging was completely
>> compiled out
>> at compile time.
>> 2. On kernels with CONFIG_SLUB_DEBUG_ON=y, mempool debugging stayed
>> active
>> even if a user explicitly disabled slub debugging at boot time.
>>
>> Clean up this mess by removing the #ifdef and switching to a runtime static
>> key (mempool_debug_enabled), allowing mempool debugging to be toggled
>> cleanly via its own boot parameter.
>>
> Ping
>
> Thanks
Sorry, missed this. Since it's just before merge window and it's not
critical, will queue it after merge window for 7.3. Thanks!
> [Li,Rongqing]
>
>
>
>> Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
>> Signed-off-by: Li RongQing <lirongqing@baidu.com>
>> Cc: Vlastimil Babka <vbabka@kernel.org>
>> Cc: Harry Yoo <harry@kernel.org>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Hao Li <hao.li@linux.dev>
>> Cc: Christoph Lameter <cl@gentwo.org>
>> Cc: David Rientjes <rientjes@google.com>
>> Cc: Roman Gushchin <roman.gushchin@linux.dev>
>> Cc: Matthew Wilcox <willy@infradead.org>
>> Cc: Usama Arif <usama.arif@linux.dev>
>> ---
>> Diff with v2: Move the check out of check_element/poison_element Diff with
>> v1: Rewrite commit message, change early_param to __setup
>>
>> Documentation/admin-guide/kernel-parameters.txt | 5 ++++
>> mm/mempool.c | 35
>> +++++++++++++++++--------
>> 2 files changed, 29 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index 642659b..89b5994 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -3980,6 +3980,11 @@ Kernel parameters
>> Note that even when enabled, there are a few cases where
>> the feature is not effective.
>>
>> + mempool_debug [MM]
>> + Enable mempool debugging. This enables element
>> + poison checking when freeing elements back to the
>> + pool. Useful for debugging mempool corruption.
>> +
>> memtest= [KNL,X86,ARM,M68K,PPC,RISCV,EARLY] Enable memtest
>> Format: <integer>
>> default : 0 <disable>
>> diff --git a/mm/mempool.c b/mm/mempool.c index db23e0e..dabe05c
>> 100644
>> --- a/mm/mempool.c
>> +++ b/mm/mempool.c
>> @@ -16,11 +16,28 @@
>> #include <linux/export.h>
>> #include <linux/mempool.h>
>> #include <linux/writeback.h>
>> +#include <linux/static_key.h>
>> +#include <linux/init.h>
>> #include "slab.h"
>>
>> static DECLARE_FAULT_ATTR(fail_mempool_alloc);
>> static DECLARE_FAULT_ATTR(fail_mempool_alloc_bulk);
>>
>> +/*
>> + * Debugging support for mempool using static key.
>> + *
>> + * This allows enabling mempool debug at boot time via:
>> + * mempool_debug
>> + */
>> +static DEFINE_STATIC_KEY_FALSE(mempool_debug_enabled);
>> +
>> +static int __init mempool_debug_setup(char *str) {
>> + static_branch_enable(&mempool_debug_enabled);
>> + return 1;
>> +}
>> +__setup("mempool_debug", mempool_debug_setup);
>> +
>> static int __init mempool_faul_inject_init(void) {
>> int error;
>> @@ -37,7 +54,6 @@ static int __init mempool_faul_inject_init(void) }
>> late_initcall(mempool_faul_inject_init);
>>
>> -#ifdef CONFIG_SLUB_DEBUG_ON
>> static void poison_error(struct mempool *pool, void *element, size_t size,
>> size_t byte)
>> {
>> @@ -140,14 +156,6 @@ static void poison_element(struct mempool *pool,
>> void *element) #endif
>> }
>> }
>> -#else /* CONFIG_SLUB_DEBUG_ON */
>> -static inline void check_element(struct mempool *pool, void *element) -{ -}
>> -static inline void poison_element(struct mempool *pool, void *element) -{ -}
>> -#endif /* CONFIG_SLUB_DEBUG_ON */
>>
>> static __always_inline bool kasan_poison_element(struct mempool *pool,
>> void *element)
>> @@ -175,7 +183,10 @@ static void kasan_unpoison_element(struct
>> mempool *pool, void *element) static __always_inline void
>> add_element(struct mempool *pool, void *element) {
>> BUG_ON(pool->min_nr != 0 && pool->curr_nr >= pool->min_nr);
>> - poison_element(pool, element);
>> +
>> + if (static_branch_unlikely(&mempool_debug_enabled))
>> + poison_element(pool, element);
>> +
>> if (kasan_poison_element(pool, element))
>> pool->elements[pool->curr_nr++] = element; } @@ -186,7 +197,9
>> @@ static void *remove_element(struct mempool *pool)
>>
>> BUG_ON(pool->curr_nr < 0);
>> kasan_unpoison_element(pool, element);
>> - check_element(pool, element);
>> +
>> + if (static_branch_unlikely(&mempool_debug_enabled))
>> + check_element(pool, element);
>> return element;
>> }
>>
>> --
>> 2.9.4
>
^ permalink raw reply
* Re: [PATCH v3 02/24] firmware: arm_scmi: Reduce the scope of protocols mutex
From: Usama Arif @ 2026-06-12 10:15 UTC (permalink / raw)
To: Cristian Marussi
Cc: Usama Arif, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
dan.carpenter, d-gole, jonathan.cameron, elif.topuz, lukasz.luba,
philip.radford, brauner, souvik.chakravarty
In-Reply-To: <20260329163337.637393-3-cristian.marussi@arm.com>
On Sun, 29 Mar 2026 17:33:13 +0100 Cristian Marussi <cristian.marussi@arm.com> wrote:
> Currently the mutex dedicated to the protection of the list of registered
> protocols is held during all the protocol initialization phase.
>
> Such a wide locking region is not needed and causes problem when trying to
> initialize notifications from within a protocol initialization routine.
>
> Reduce the scope of the protocol mutex.
I think this changes more than the mutex scope. scmi_get_protocol_instance()
can now drop protocols_mtx after idr_find() while scmi_protocol_release()
can concurrently drop the final reference, remove the IDR entry, and release
the devres group. Does that leaves a use-after-free window around the returned
pi?
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> v1-->v2
> - Fixed improper mixed usage of cleanup and goto constructs
> ---
> drivers/firmware/arm_scmi/driver.c | 50 ++++++++++++++----------------
> 1 file changed, 24 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 3e76a3204ba4..26f192b8d7a9 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -17,6 +17,7 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include <linux/bitmap.h>
> +#include <linux/cleanup.h>
> #include <linux/debugfs.h>
> #include <linux/device.h>
> #include <linux/export.h>
> @@ -2190,7 +2191,6 @@ static void scmi_protocol_version_initialize(struct device *dev,
> * all resources management is handled via a dedicated per-protocol devres
> * group.
> *
> - * Context: Assumes to be called with @protocols_mtx already acquired.
> * Return: A reference to a freshly allocated and initialized protocol instance
> * or ERR_PTR on failure. On failure the @proto reference is at first
> * put using @scmi_protocol_put() before releasing all the devres group.
> @@ -2236,8 +2236,10 @@ scmi_alloc_init_protocol_instance(struct scmi_info *info,
> if (ret)
> goto clean;
>
> - ret = idr_alloc(&info->protocols, pi, proto->id, proto->id + 1,
> - GFP_KERNEL);
> + /* Finally register the initialized protocol */
> + mutex_lock(&info->protocols_mtx);
> + ret = idr_alloc(&info->protocols, pi, proto->id, proto->id + 1, GFP_KERNEL);
> + mutex_unlock(&info->protocols_mtx);
> if (ret != proto->id)
> goto clean;
>
> @@ -2284,27 +2286,25 @@ scmi_alloc_init_protocol_instance(struct scmi_info *info,
> static struct scmi_protocol_instance * __must_check
> scmi_get_protocol_instance(const struct scmi_handle *handle, u8 protocol_id)
> {
> - struct scmi_protocol_instance *pi;
> struct scmi_info *info = handle_to_scmi_info(handle);
> + const struct scmi_protocol *proto;
>
> - mutex_lock(&info->protocols_mtx);
> - pi = idr_find(&info->protocols, protocol_id);
> -
> - if (pi) {
> - refcount_inc(&pi->users);
> - } else {
> - const struct scmi_protocol *proto;
> + scoped_guard(mutex, &info->protocols_mtx) {
> + struct scmi_protocol_instance *pi;
>
> - /* Fails if protocol not registered on bus */
> - proto = scmi_protocol_get(protocol_id, &info->version);
> - if (proto)
> - pi = scmi_alloc_init_protocol_instance(info, proto);
> - else
> - pi = ERR_PTR(-EPROBE_DEFER);
> + pi = idr_find(&info->protocols, protocol_id);
> + if (pi) {
> + refcount_inc(&pi->users);
> + return pi;
> + }
> }
> - mutex_unlock(&info->protocols_mtx);
>
> - return pi;
> + /* Fails if protocol not registered on bus */
> + proto = scmi_protocol_get(protocol_id, &info->version);
> + if (!proto)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + return scmi_alloc_init_protocol_instance(info, proto);
> }
>
> /**
> @@ -2335,10 +2335,11 @@ void scmi_protocol_release(const struct scmi_handle *handle, u8 protocol_id)
> struct scmi_info *info = handle_to_scmi_info(handle);
> struct scmi_protocol_instance *pi;
>
> - mutex_lock(&info->protocols_mtx);
> - pi = idr_find(&info->protocols, protocol_id);
> - if (WARN_ON(!pi))
> - goto out;
> + scoped_guard(mutex, &info->protocols_mtx) {
> + pi = idr_find(&info->protocols, protocol_id);
> + if (WARN_ON(!pi))
> + return;
> + }
>
> if (refcount_dec_and_test(&pi->users)) {
> void *gid = pi->gid;
> @@ -2357,9 +2358,6 @@ void scmi_protocol_release(const struct scmi_handle *handle, u8 protocol_id)
> dev_dbg(handle->dev, "De-Initialized protocol: 0x%X\n",
> protocol_id);
> }
> -
> -out:
> - mutex_unlock(&info->protocols_mtx);
> }
>
> void scmi_setup_protocol_implemented(const struct scmi_protocol_handle *ph,
> --
> 2.53.0
>
>
^ permalink raw reply
* 答复: [PATCH v3] mm/mempool: Untangle CONFIG_SLUB_DEBUG_ON abuse and switch to static key
From: Li,Rongqing @ 2026-06-12 10:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Vlastimil Babka, Harry Yoo,
Andrew Morton, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: Matthew Wilcox, Usama Arif
In-Reply-To: <20260604110318.2089-1-lirongqing@baidu.com>
> 主题: [PATCH v3] mm/mempool: Untangle CONFIG_SLUB_DEBUG_ON abuse
> and switch to static key
>
> From: Li RongQing <lirongqing@baidu.com>
>
> The mempool subsystem historically wrapped its debugging logic inside an
> merely defines compile-time defaults for SLUB and caused two flaws:
>
> 1. On production kernels where CONFIG_SLUB_DEBUG=y but
> CONFIG_SLUB_DEBUG_ON=n, mempool debugging was completely
> compiled out
> at compile time.
> 2. On kernels with CONFIG_SLUB_DEBUG_ON=y, mempool debugging stayed
> active
> even if a user explicitly disabled slub debugging at boot time.
>
> Clean up this mess by removing the #ifdef and switching to a runtime static
> key (mempool_debug_enabled), allowing mempool debugging to be toggled
> cleanly via its own boot parameter.
>
Ping
Thanks
[Li,Rongqing]
> Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Harry Yoo <harry@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Hao Li <hao.li@linux.dev>
> Cc: Christoph Lameter <cl@gentwo.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Usama Arif <usama.arif@linux.dev>
> ---
> Diff with v2: Move the check out of check_element/poison_element Diff with
> v1: Rewrite commit message, change early_param to __setup
>
> Documentation/admin-guide/kernel-parameters.txt | 5 ++++
> mm/mempool.c | 35
> +++++++++++++++++--------
> 2 files changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 642659b..89b5994 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3980,6 +3980,11 @@ Kernel parameters
> Note that even when enabled, there are a few cases where
> the feature is not effective.
>
> + mempool_debug [MM]
> + Enable mempool debugging. This enables element
> + poison checking when freeing elements back to the
> + pool. Useful for debugging mempool corruption.
> +
> memtest= [KNL,X86,ARM,M68K,PPC,RISCV,EARLY] Enable memtest
> Format: <integer>
> default : 0 <disable>
> diff --git a/mm/mempool.c b/mm/mempool.c index db23e0e..dabe05c
> 100644
> --- a/mm/mempool.c
> +++ b/mm/mempool.c
> @@ -16,11 +16,28 @@
> #include <linux/export.h>
> #include <linux/mempool.h>
> #include <linux/writeback.h>
> +#include <linux/static_key.h>
> +#include <linux/init.h>
> #include "slab.h"
>
> static DECLARE_FAULT_ATTR(fail_mempool_alloc);
> static DECLARE_FAULT_ATTR(fail_mempool_alloc_bulk);
>
> +/*
> + * Debugging support for mempool using static key.
> + *
> + * This allows enabling mempool debug at boot time via:
> + * mempool_debug
> + */
> +static DEFINE_STATIC_KEY_FALSE(mempool_debug_enabled);
> +
> +static int __init mempool_debug_setup(char *str) {
> + static_branch_enable(&mempool_debug_enabled);
> + return 1;
> +}
> +__setup("mempool_debug", mempool_debug_setup);
> +
> static int __init mempool_faul_inject_init(void) {
> int error;
> @@ -37,7 +54,6 @@ static int __init mempool_faul_inject_init(void) }
> late_initcall(mempool_faul_inject_init);
>
> -#ifdef CONFIG_SLUB_DEBUG_ON
> static void poison_error(struct mempool *pool, void *element, size_t size,
> size_t byte)
> {
> @@ -140,14 +156,6 @@ static void poison_element(struct mempool *pool,
> void *element) #endif
> }
> }
> -#else /* CONFIG_SLUB_DEBUG_ON */
> -static inline void check_element(struct mempool *pool, void *element) -{ -}
> -static inline void poison_element(struct mempool *pool, void *element) -{ -}
> -#endif /* CONFIG_SLUB_DEBUG_ON */
>
> static __always_inline bool kasan_poison_element(struct mempool *pool,
> void *element)
> @@ -175,7 +183,10 @@ static void kasan_unpoison_element(struct
> mempool *pool, void *element) static __always_inline void
> add_element(struct mempool *pool, void *element) {
> BUG_ON(pool->min_nr != 0 && pool->curr_nr >= pool->min_nr);
> - poison_element(pool, element);
> +
> + if (static_branch_unlikely(&mempool_debug_enabled))
> + poison_element(pool, element);
> +
> if (kasan_poison_element(pool, element))
> pool->elements[pool->curr_nr++] = element; } @@ -186,7 +197,9
> @@ static void *remove_element(struct mempool *pool)
>
> BUG_ON(pool->curr_nr < 0);
> kasan_unpoison_element(pool, element);
> - check_element(pool, element);
> +
> + if (static_branch_unlikely(&mempool_debug_enabled))
> + check_element(pool, element);
> return element;
> }
>
> --
> 2.9.4
^ permalink raw reply
* Re: [PATCH v3 01/24] firmware: arm_scmi: Add new SCMIv4.0 error codes definitions
From: Usama Arif @ 2026-06-12 10:10 UTC (permalink / raw)
To: Cristian Marussi
Cc: Usama Arif, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
dan.carpenter, d-gole, jonathan.cameron, elif.topuz, lukasz.luba,
philip.radford, brauner, souvik.chakravarty
In-Reply-To: <20260329163337.637393-2-cristian.marussi@arm.com>
On Sun, 29 Mar 2026 17:33:12 +0100 Cristian Marussi <cristian.marussi@arm.com> wrote:
> SCMIv4.0 introduces a couple of new possible protocol error codes: add
> the needed definitions and mappings to Linux error values.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> drivers/firmware/arm_scmi/common.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> index 7c35c95fddba..44af2018e21d 100644
> --- a/drivers/firmware/arm_scmi/common.h
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -45,6 +45,8 @@ enum scmi_error_codes {
> SCMI_ERR_GENERIC = -8, /* Generic Error */
> SCMI_ERR_HARDWARE = -9, /* Hardware Error */
> SCMI_ERR_PROTOCOL = -10,/* Protocol Error */
> + SCMI_ERR_IN_USE = -11, /* In Use Error */
> + SCMI_ERR_PARTIAL = -12, /* Partial Error */
> };
>
> static const int scmi_linux_errmap[] = {
> @@ -60,6 +62,8 @@ static const int scmi_linux_errmap[] = {
> -EIO, /* SCMI_ERR_GENERIC */
> -EREMOTEIO, /* SCMI_ERR_HARDWARE */
> -EPROTO, /* SCMI_ERR_PROTOCOL */
> + -EPERM, /* SCMI_ERR_IN_USE */
"In use" reads like a resource-state failure, where -EBUSY would normally be expected.
-EPERM suggests an authorization failure, which is already represented by SCMI_ERR_ACCESS.
> + -EINVAL, /* SCMI_ERR_PARTIAL */
> };
>
> static inline int scmi_to_linux_errno(int errno)
> --
> 2.53.0
>
>
^ permalink raw reply
* [PATCH] v2 Documentation: arch: fix brackets
From: Manuel Ebner @ 2026-06-12 9:54 UTC (permalink / raw)
To: Vineet Gupta, Jonathan Corbet, Shuah Khan, Krzysztof Kozlowski,
Peter Griffin, Alim Akhtar, Catalin Marinas, Will Deacon,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, open list:SYNOPSYS ARC ARCHITECTURE,
open list:DOCUMENTATION, open list,
moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES,
open list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)
Cc: Manuel Ebner, Randy Dunlap
Add missing and remove needless parentheses, brackets and curly braces.
Fix typos.
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
---
[v1] -> [v2]
"(i.e cache geometries)" -> "(e.g., cache geometries)"
"Excer[t" -> "Excerpt"
add Reviewed-by: Randy Dunlap
fixed my own typos.
---
Documentation/arch/arc/arc.rst | 2 +-
.../arm/samsung/clksrc-change-registers.awk | 2 +-
Documentation/arch/arm/vlocks.rst | 4 ++--
.../arch/arm64/memory-tagging-extension.rst | 2 +-
Documentation/arch/powerpc/vas-api.rst | 2 +-
Documentation/arch/sparc/oradax/dax-hv-api.txt | 18 +++++++++---------
Documentation/arch/sparc/oradax/oracle-dax.rst | 2 +-
Documentation/arch/x86/x86_64/fsgs.rst | 4 ++--
8 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/Documentation/arch/arc/arc.rst b/Documentation/arch/arc/arc.rst
index 6c4d978f3f4e..5923dee37a98 100644
--- a/Documentation/arch/arc/arc.rst
+++ b/Documentation/arch/arc/arc.rst
@@ -36,7 +36,7 @@ Important note on ARC processors configurability
ARC processors are highly configurable and several configurable options
are supported in Linux. Some options are transparent to software
-(i.e cache geometries, some can be detected at runtime and configured
+(e.g., cache geometries), some can be detected at runtime and configured
and used accordingly, while some need to be explicitly selected or configured
in the kernel's configuration utility (AKA "make menuconfig").
diff --git a/Documentation/arch/arm/samsung/clksrc-change-registers.awk b/Documentation/arch/arm/samsung/clksrc-change-registers.awk
index 7be1b8aa7cd9..48464397088c 100755
--- a/Documentation/arch/arm/samsung/clksrc-change-registers.awk
+++ b/Documentation/arch/arm/samsung/clksrc-change-registers.awk
@@ -163,4 +163,4 @@ BEGIN {
}
}
-// && ! /clksrc_clk.*=.*{/ { print $0 }
+// && ! /clksrc_clk.*=.*{/ { print $0 }}
diff --git a/Documentation/arch/arm/vlocks.rst b/Documentation/arch/arm/vlocks.rst
index 737aa8661a21..b0ac33263086 100644
--- a/Documentation/arch/arm/vlocks.rst
+++ b/Documentation/arch/arm/vlocks.rst
@@ -102,10 +102,10 @@ Features and limitations
if (I_won) {
/* we won the town election, let's go for the state */
my_state = states[(this_cpu >> 8) & 0xf];
- I_won = vlock_lock(my_state, this_cpu & 0xf));
+ I_won = vlock_lock(my_state, this_cpu & 0xf);
if (I_won) {
/* and so on */
- I_won = vlock_lock(the_whole_country, this_cpu & 0xf];
+ I_won = vlock_lock(the_whole_country, this_cpu & 0xf);
if (I_won) {
/* ... */
}
diff --git a/Documentation/arch/arm64/memory-tagging-extension.rst b/Documentation/arch/arm64/memory-tagging-extension.rst
index 679725030731..e6fe428f0e2a 100644
--- a/Documentation/arch/arm64/memory-tagging-extension.rst
+++ b/Documentation/arch/arm64/memory-tagging-extension.rst
@@ -222,7 +222,7 @@ programs should not retry in case of a non-zero system call return.
address ABI control and MTE configuration of a process as per the
``prctl()`` options described in
Documentation/arch/arm64/tagged-address-abi.rst and above. The corresponding
-``regset`` is 1 element of 8 bytes (``sizeof(long))``).
+``regset`` is 1 element of 8 bytes (``sizeof(long)``).
Core dump support
-----------------
diff --git a/Documentation/arch/powerpc/vas-api.rst b/Documentation/arch/powerpc/vas-api.rst
index a9625a2fa0c6..1d0d055356e3 100644
--- a/Documentation/arch/powerpc/vas-api.rst
+++ b/Documentation/arch/powerpc/vas-api.rst
@@ -293,7 +293,7 @@ Simple example
//Format CRB request with compression or
//uncompression
// Refer tests for vas_copy/vas_paste
- vas_copy((&crb, 0, 1);
+ vas_copy(&crb, 0, 1);
vas_paste(addr, 0, 1);
// Poll on csb.flags with timeout
// csb address is listed in CRB
diff --git a/Documentation/arch/sparc/oradax/dax-hv-api.txt b/Documentation/arch/sparc/oradax/dax-hv-api.txt
index ef1a4c2bf08b..49be62a9ce86 100644
--- a/Documentation/arch/sparc/oradax/dax-hv-api.txt
+++ b/Documentation/arch/sparc/oradax/dax-hv-api.txt
@@ -457,7 +457,7 @@ bits set, and terminate at a CCB that has the Conditional bit set, but not the P
Offset Size Field Description
Bits Field Description
[15:14] Secondary Input Element Size (see Section 36.2.1.1.4,
- “Secondary Input Element Size”
+ “Secondary Input Element Size”)
[13:10] Output Format (see Section 36.2.1.1.6, “Output Format”)
[9] Padding Direction selector: A value of 1 causes padding bytes
to be added to the left side of output elements. A value of 0
@@ -656,7 +656,7 @@ Offset Size Field Description
[18:16] Secondary Input Starting Offset (see Section 36.2.1.1.5, “Input
Element Offsets”)
[15:14] Secondary Input Element Size (see Section 36.2.1.1.4,
- “Secondary Input Element Size”
+ “Secondary Input Element Size”)
[13:10] Output Format (see Section 36.2.1.1.6, “Output Format”)
[9:5] Operand size for first scan criteria value. In a scan value
operation, this is one of two potential exact match values.
@@ -793,13 +793,13 @@ Offset Size Field Description
[18:16] Secondary Input Starting Offset (see Section 36.2.1.1.5, “Input
Element Offsets”)
[15:14] Secondary Input Element Size (see Section 36.2.1.1.4,
- “Secondary Input Element Size”
+ “Secondary Input Element Size”)
[13:10] Output Format (see Section 36.2.1.1.6, “Output Format”)
[9] Reserved
[8:0] Test value used for comparison against the most significant bits
in the input values, when using 2 or 3 byte input elements.
-8 8 Completion (same fields as Section 36.2.1.2, “Extract command”
-16 8 Primary Input (same fields as Section 36.2.1.2, “Extract command”
+8 8 Completion (same fields as Section 36.2.1.2, “Extract command”)
+16 8 Primary Input (same fields as Section 36.2.1.2, “Extract command”)
24 8 Data Access Control (same fields as Section 36.2.1.2, “Extract command”,
except Primary Input Length Format may not use the 0x0 value)
32 8 Secondary Input, if used by Primary Input Format. Same fields as Primary
@@ -880,7 +880,7 @@ Offset Size Field Description
[18:16] Secondary Input Starting Offset (see Section 36.2.1.1.5, “Input
Element Offsets”)
[15:14] Secondary Input Element Size (see Section 36.2.1.1.4,
- “Secondary Input Element Size”
+ “Secondary Input Element Size”)
524
@@ -895,8 +895,8 @@ Offset Size Field Description
causes padding bytes to be added to the right side of output
elements.
[8:0] Reserved
- 8 8 Completion (same fields as Section 36.2.1.2, “Extract command”
- 16 8 Primary Input (same fields as Section 36.2.1.2, “Extract command”
+ 8 8 Completion (same fields as Section 36.2.1.2, “Extract command”)
+ 16 8 Primary Input (same fields as Section 36.2.1.2, “Extract command”)
24 8 Data Access Control (same fields as Section 36.2.1.2, “Extract command”)
32 8 Secondary Bit Vector Input. Same fields as Primary Input.
40 8 Reserved
@@ -949,7 +949,7 @@ Offset Size Field Description
[31] If set, this CCB functions as a Sync command. If clear, this
CCB functions as a No-op command.
[30:0] Reserved
- 8 8 Completion (same fields as Section 36.2.1.2, “Extract command”
+ 8 8 Completion (same fields as Section 36.2.1.2, “Extract command”)
16 46 Reserved
36.2.2. CCB Completion Area
diff --git a/Documentation/arch/sparc/oradax/oracle-dax.rst b/Documentation/arch/sparc/oradax/oracle-dax.rst
index d1e14d572918..a5d53f240dc8 100644
--- a/Documentation/arch/sparc/oradax/oracle-dax.rst
+++ b/Documentation/arch/sparc/oradax/oracle-dax.rst
@@ -438,7 +438,7 @@ that in user land::
The output bitmap is ready for consumption immediately after the
completion status indicates success.
-Excer[t from UltraSPARC Virtual Machine Specification
+Excerpt from UltraSPARC Virtual Machine Specification
=====================================================
.. include:: dax-hv-api.txt
diff --git a/Documentation/arch/x86/x86_64/fsgs.rst b/Documentation/arch/x86/x86_64/fsgs.rst
index 6bda4d16d3f7..f8d483a7fb06 100644
--- a/Documentation/arch/x86/x86_64/fsgs.rst
+++ b/Documentation/arch/x86/x86_64/fsgs.rst
@@ -182,8 +182,8 @@ address spaces via an attribute based mechanism in Clang 2.6 and newer
versions:
==================================== =====================================
- __attribute__((address_space(256)) Variable is addressed relative to GS
- __attribute__((address_space(257)) Variable is addressed relative to FS
+ __attribute__(address_space(256)) Variable is addressed relative to GS
+ __attribute__(address_space(257)) Variable is addressed relative to FS
==================================== =====================================
FS/GS based addressing with inline assembly
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 0/2] vsprintf: add upper case to %p[mM] et alia
From: Petr Mladek @ 2026-06-12 9:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jiri Kosina, Daniel J. Ogorchock, Tamir Duberstein, linux-doc,
linux-kernel, linux-input, Steven Rostedt, Rasmus Villemoes,
Sergey Senozhatsky, Jonathan Corbet, Shuah Khan,
Benjamin Tissoires, Andrew Morton
In-Reply-To: <20260603104351.152085-1-andriy.shevchenko@linux.intel.com>
On Wed 2026-06-03 12:34:01, Andy Shevchenko wrote:
> The first patch induced by Sashiko rightfully rises a concern on
> potential ABI breakage. To avoid that and allow the user (patch 2)
> to be converted to use unified output introduce %p[mM][...]U for
> printing in upper case. Tests are included and passed.
>
> Changelog v2:
> - added first patch (Sashiko)
>
> Andy Shevchenko (2):
> vsprintf: Add upper case flavour to %p[mM]
> HID: nintendo: Use %pM format specifier for MAC addresses
For the whole series:
Reviewed-by: Petr Mladek <pmladek@suse.com>
I am going to queue it via printk tree.
Best Regards,
Petr
PS: I am sorry for "late" review. My queue is quite long
at the moment...
^ 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