* Re: [PATCH v2 10/69] mm/mm_init: Remove set_pageblock_order() call from sparse_init()
From: Oscar Salvador (SUSE) @ 2026-05-25 17:10 UTC (permalink / raw)
To: Muchun Song
Cc: Andrew Morton, David Hildenbrand, Muchun Song, Oscar Salvador,
Michael Ellerman, Madhavan Srinivasan, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Nicholas Piggin,
Christophe Leroy, Ackerley Tng, Frank van der Linden,
aneesh.kumar, joao.m.martins, linux-mm, linuxppc-dev,
linux-kernel
In-Reply-To: <20260513130542.35604-11-songmuchun@bytedance.com>
On Wed, May 13, 2026 at 09:04:38PM +0800, Muchun Song wrote:
> free_area_init() already sets pageblock_order before sparse_init() runs
> for CONFIG_HUGETLB_PAGE_SIZE_VARIABLE, so sparse_init() does not need to
> call set_pageblock_order() again.
>
> With that call removed, set_pageblock_order() is only used in mm/mm_init.c.
> Make it static.
>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Oscar Salvador (SUSE) <osalvador@suse.de>
--
Oscar Salvador
SUSE Labs
^ permalink raw reply
* Re: [PATCH 08/11] params: Convert generic kernel_param_ops .get helpers to seq_buf
From: Petr Pavlu @ 2026-05-25 17:10 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-8-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Convert the generic struct kernel_param_ops .get helpers in
> kernel/params.c directly to the seq_buf signature, drop their legacy
> "char *" form, and refresh prototypes in <linux/moduleparam.h>:
>
> param_get_byte/short/ushort/int/uint/long/ulong/ullong/hexint
> param_get_charp/bool/invbool/string
> param_array_get
>
> The STANDARD_PARAM_DEF() macro expands to a seq_buf body for every
> numeric helper. param_array_get() now writes element output directly
> into the parent seq_buf when the element ops provide .get; it only
> allocates the per-call PAGE_SIZE bounce buffer when the element ops
> still use the legacy .get_str path. The common "rewrite the prior
> element's trailing newline as a comma" step lives outside both
> branches so the two paths share it.
>
> The non-core changes in this commit (arch/x86/kvm, mm/kfence,
> drivers/dma/dmatest, security/apparmor) are the small set of callers that
> directly invoke one of the converted generic helpers from their own .get
> callback (e.g. an apparmor wrapper that adds a capability check and then
> delegates to param_get_bool()). Because the helpers' signature changes
> here, these wrappers must move in lockstep. Each of them is updated
> to take "struct seq_buf *" and pass it through; param_get_debug() in
> apparmor also pulls aa_print_debug_params() (and its val_mask_to_str()
> helper, in security/apparmor/lib.c) over to seq_buf, since that is the
> only consumer. No other behavioural change is intended.
>
> Custom .get callbacks that do not delegate to a generic helper (and
> therefore still match the .get_str signature) are routed automatically
> to the .get_str field by the DEFINE_KERNEL_PARAM_OPS _Generic dispatcher
> and are deliberately left alone here, to be changed separately within
> their respective subsystems.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> [...]
> @@ -453,36 +457,46 @@ static int param_array_set(const char *val, const struct kernel_param *kp)
> arr->num ?: &temp_num);
> }
>
> -static int param_array_get(char *buffer, const struct kernel_param *kp)
> +static int param_array_get(struct seq_buf *s, const struct kernel_param *kp)
> {
> - int i, off, ret;
> - char *elem_buf;
> const struct kparam_array *arr = kp->arr;
> struct kernel_param p = *kp;
> + char *elem_buf = NULL;
> + int i, ret = 0;
>
> - elem_buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
> - if (!elem_buf)
> - return -ENOMEM;
> + for (i = 0; i < (arr->num ? *arr->num : arr->max); i++) {
> + size_t before = s->len;
>
> - for (i = off = 0; i < (arr->num ? *arr->num : arr->max); i++) {
> p.arg = arr->elem + arr->elemsize * i;
> check_kparam_locked(p.mod);
> - ret = arr->ops->get_str(elem_buf, &p);
> - if (ret < 0)
> - goto out;
> - ret = min(ret, (int)(PAGE_SIZE - 1 - off));
> - if (!ret)
> +
> + if (arr->ops->get) {
> + ret = arr->ops->get(s, &p);
> + if (ret < 0)
> + goto out;
> + } else {
> + if (!elem_buf) {
> + elem_buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!elem_buf) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + }
> + ret = arr->ops->get_str(elem_buf, &p);
> + if (ret < 0)
> + goto out;
> + seq_buf_putmem(s, elem_buf, ret);
> + }
> +
> + /* Nothing got written (e.g. overflow) — stop. */
> + if (s->len == before)
> break;
> +
> /* Replace the previous element's trailing newline with a comma. */
> - if (i)
> - buffer[off - 1] = ',';
> - memcpy(buffer + off, elem_buf, ret);
> - off += ret;
> - if (off == PAGE_SIZE - 1)
> - break;
> + if (i && s->buffer[before - 1] == '\n')
> + s->buffer[before - 1] = ',';
> }
> - buffer[off] = '\0';
> - ret = off;
> + ret = 0;
> out:
> kfree(elem_buf);
> return ret;
Since you're almost completely rewriting the logic in param_array_get(),
I suggest tightening it up a bit. The function could warn or return an
error when a kernel_param_ops::get/get_str() call adds a string that
doesn't terminate with '\n', specifically, when the call adds either
a zero-length string or a non-zero-length string that ends with
a different character (unless an overflow occurred).
The updated code silently stops the loop when a get call returns
a zero-length string. Similarly, handling of a string not terminated by
'\n' is halfway there because of the added check
"s->buffer[before - 1] == '\n'".
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v2 09/69] mm/mm_init: Defer hugetlb reservation until after zone initialization
From: Oscar Salvador (SUSE) @ 2026-05-25 17:08 UTC (permalink / raw)
To: Muchun Song
Cc: Andrew Morton, David Hildenbrand, Muchun Song, Oscar Salvador,
Michael Ellerman, Madhavan Srinivasan, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Nicholas Piggin,
Christophe Leroy, Ackerley Tng, Frank van der Linden,
aneesh.kumar, joao.m.martins, linux-mm, linuxppc-dev,
linux-kernel
In-Reply-To: <20260513130542.35604-10-songmuchun@bytedance.com>
On Wed, May 13, 2026 at 09:04:37PM +0800, Muchun Song wrote:
> hugetlb_cma_reserve() and hugetlb_bootmem_alloc() currently run before
> free_area_init(), so HugeTLB reservation happens before zone state is
> initialized.
>
> Move the reservation step after free_area_init() so the relevant zone
> information is available before HugeTLB reserves memory. This is needed
> for later hugetlb changes that validate boot-time HugeTLB reservations
> against zone boundaries.
>
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Oscar Salvador (SUSE) <osalvador@kernel.org>
--
Oscar Salvador
SUSE Labs
^ permalink raw reply
* Re: [PATCH 07/11] moduleparam: Route DEFINE_KERNEL_PARAM_OPS get pointer via _Generic
From: Petr Pavlu @ 2026-05-25 16:24 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-7-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Make the DEFINE_KERNEL_PARAM_OPS family route their _get argument to
> either .get (struct seq_buf *) or .get_str (char *) at compile time
> based on the pointer's actual function signature. Two helper macros
> do the routing:
>
> _KERNEL_PARAM_OPS_GET - return the pointer if it has the seq_buf
> signature, otherwise NULL of that type
> _KERNEL_PARAM_OPS_GET_STR - mirror image for the char * signature
>
> Both use _Generic; only the two valid function-pointer types are
> listed, so any third-party type is a compile error rather than
> silently falling through.
>
> Now a callback whose body has been migrated from char * to struct
> seq_buf * needs no change at its kernel_param_ops initialization site,
> because the macro picks up the new type automatically and assigns to
> the correct field.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> include/linux/moduleparam.h | 33 ++++++++++++++++++++++++++-------
> 1 file changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index c52120f6ac28..795bc7c654ef 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -85,15 +85,32 @@ struct kernel_param_ops {
> *
> * static DEFINE_KERNEL_PARAM_OPS(my_ops, my_set, my_get);
> *
> - * Routing the @_set and @_get function pointers through the macro
> - * (rather than naming the struct fields at every call site) lets the
> - * field layout change in one place when callbacks are migrated to a
> - * new signature.
> + * @_get may be either of:
> + * int (*)(struct seq_buf *, const struct kernel_param *) (seq_buf)
> + * int (*)(char *, const struct kernel_param *) (legacy)
> + *
> + * The macro uses _Generic to route the function pointer to the
> + * matching field (.get or .get_str) at compile time, leaving the
> + * other field NULL. Each helper matches the wrong prototype signature
> + * and returns NULL, falling through to the default branch otherwise;
> + * if @_get has neither expected signature the assignment to the
> + * fields gets a normal compile-time type-mismatch error.
> */
> +#define _KERNEL_PARAM_OPS_GET(_get) \
> + _Generic((_get), \
> + int (*)(char *, const struct kernel_param *): NULL, \
> + default: (_get))
> +
> +#define _KERNEL_PARAM_OPS_GET_STR(_get) \
> + _Generic((_get), \
> + int (*)(struct seq_buf *, const struct kernel_param *): NULL, \
> + default: (_get))
> +
> #define DEFINE_KERNEL_PARAM_OPS(_name, _set, _get) \
> const struct kernel_param_ops _name = { \
> .set = (_set), \
> - .get_str = (_get), \
> + .get = _KERNEL_PARAM_OPS_GET(_get), \
> + .get_str = _KERNEL_PARAM_OPS_GET_STR(_get), \
> }
>
> /* As DEFINE_KERNEL_PARAM_OPS, with KERNEL_PARAM_OPS_FL_NOARG set. */
> @@ -101,14 +118,16 @@ struct kernel_param_ops {
> const struct kernel_param_ops _name = { \
> .flags = KERNEL_PARAM_OPS_FL_NOARG, \
> .set = (_set), \
> - .get_str = (_get), \
> + .get = _KERNEL_PARAM_OPS_GET(_get), \
> + .get_str = _KERNEL_PARAM_OPS_GET_STR(_get), \
> }
>
> /* As DEFINE_KERNEL_PARAM_OPS, with an additional .free callback. */
> #define DEFINE_KERNEL_PARAM_OPS_FREE(_name, _set, _get, _free) \
> const struct kernel_param_ops _name = { \
> .set = (_set), \
> - .get_str = (_get), \
> + .get = _KERNEL_PARAM_OPS_GET(_get), \
> + .get_str = _KERNEL_PARAM_OPS_GET_STR(_get), \
> .free = (_free), \
> }
>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
-- Petr
^ permalink raw reply
* Re: [PATCH 06/11] moduleparam: Add seq_buf-based .get callback alongside .get_str
From: Petr Pavlu @ 2026-05-25 16:19 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-6-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Add a new struct kernel_param_ops::get callback whose signature
> takes a struct seq_buf instead of a raw char buffer:
>
> int (*get)(struct seq_buf *sb, const struct kernel_param *kp);
>
> The previously-legacy .get field is now .get_str (char *buffer);
> .get is the new seq_buf-aware form. param_attr_show() prefers .get
> when set, otherwise falls back to .get_str. WARN_ON_ONCE() if both
> are set. Return contract for .get:
>
> < 0 : errno propagated to userspace; seq_buf contents discarded
> = 0 : success; length derived from seq_buf_used()
> > 0 : forbidden; the dispatcher WARN_ON_ONCE()s and treats as 0
>
> The default policy on seq_buf_has_overflowed() is silent truncation,
> matching scnprintf()/sysfs_emit() behaviour. Callbacks that want a
> specific overflow errno can check seq_buf_has_overflowed() and
> return their preferred error.
>
> No callbacks use .get yet; the legacy path is still the only one in use
> after this commit. A subsequent commit teaches DEFINE_KERNEL_PARAM_OPS
> to route initializers by type.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
-- Petr
^ permalink raw reply
* Re: [BUG] sched/cache: "Make LLC id continuous" causes NULL cpumask dereference in build_sched_domains on POWER9
From: K Prateek Nayak @ 2026-05-25 16:16 UTC (permalink / raw)
To: Chen, Yu C, Venkat Rao Bagalkote
Cc: Madhavan Srinivasan, Shrikanth Hegde, Ritesh Harjani,
Christophe Leroy (CS GROUP), LKML, linuxppc-dev, linux-sched,
tim.c.chen, Peter Zijlstra
In-Reply-To: <bca40921-d351-4439-ae6a-9e5294f23e2e@intel.com>
Hello Chenyu, Venkat,
On 5/25/2026 9:05 PM, Chen, Yu C wrote:
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 3467f86fd78f..cf6c2e4190ab 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1042,11 +1042,6 @@ static const struct cpumask *tl_smallcore_smt_mask(struct sched_domain_topology_
> }
> #endif
>
> -struct cpumask *cpu_coregroup_mask(int cpu)
> -{
> - return per_cpu(cpu_coregroup_map, cpu);
> -}
> -
> static bool has_coregroup_support(void)
> {
> /* Coregroup identification not available on shared systems */
> @@ -1056,6 +1051,14 @@ static bool has_coregroup_support(void)
> return coregroup_enabled;
> }
>
> +struct cpumask *cpu_coregroup_mask(int cpu)
> +{
> + if (!has_coregroup_support())
> + return cpu_l2_cache_mask(cpu);
> +> + return per_cpu(cpu_coregroup_map, cpu);
Interestingly, on powerpc, the MC domain doesn't have SD_SHARE_LLC flag
set but I believe there is still some benefit of keeping the tasks on
the same hemisphere?
If we are actually aiming for LLC, I think cpu_l2_cache_mask() is the
right cpumask for all cases since tl_cache_mask() also returns that
and the l2_cache_mask is set in all cases covered by update_mask_by_l2()
in the same file.
If consolidation on hemisphere is beneficial, then the above diff
looks correct.
Note: For has_coregroup_support(), with the above fix, the scheduler
side llc_id will now be based on MC domain's span which seems wrong
since it doesn't have SD_SHARE_LLC flag and might lead to other
behavioral changes now.
> +}
> +
> static int __init init_big_cores(void)
> {
> int cpu;
--
Thanks and Regards,
Prateek
^ permalink raw reply
* [PATCH] powerpc/boot: Allow text relocations for pseries wrapper with binutils 2.46+
From: Amit Machhiwal @ 2026-05-25 16:16 UTC (permalink / raw)
To: Madhavan Srinivasan, linuxppc-dev
Cc: Amit Machhiwal, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Antonio Alvarez Feijoo, Vaibhav Jain,
Harsh Prateek Bora, Anushree Mathur, linux-kernel
Binutils 2.46 changed the default linker behavior from '-z notext' to
'-z text', which treats dynamic relocations in read-only segments as
errors rather than warnings. This causes the pseries boot wrapper build
to fail with:
/usr/bin/ld.bfd: arch/powerpc/boot/wrapper.a(crt0.o): warning:
relocation against `_platform_stack_top' in read-only section `.text'
/usr/bin/ld.bfd: error: read-only segment has dynamic relocations
The pseries wrapper uses '-pie' to create position-independent code.
However, crt0.S contains a pointer to '_platform_stack_top' in the .text
section, which requires a dynamic relocation at runtime. This creates
DT_TEXTREL (text relocations), which were allowed by default in binutils
2.45 and earlier (via implicit '-z notext') but are now rejected by
binutils 2.46+.
Add '-z notext' linker flag to explicitly allow text relocations for
the pseries platform, similar to what is already done for the epapr
platform. This restores the previous behavior and allows the boot
wrapper to build successfully with binutils 2.46+.
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
---
arch/powerpc/boot/wrapper | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 1efd1206fcab..25321ce262e8 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -262,6 +262,7 @@ pseries)
if [ "$format" != "elf32ppc" ]; then
link_address=
pie=-pie
+ notext='-z notext'
fi
make_space=n
;;
base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v4 0/3] ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
From: Mark Brown @ 2026-05-25 12:38 UTC (permalink / raw)
To: lgirdwood, perex, tiwai, shengjiu.wang, Xiubo.Lee, festevam,
nicoleotsuka, Frank.Li, s.hauer, Chancel Liu
Cc: kernel, shumingf, pierre-louis.bossart, linux-sound, linux-kernel,
linuxppc-dev, imx, linux-arm-kernel
In-Reply-To: <20260507013654.2945915-1-chancel.liu@nxp.com>
On Thu, 07 May 2026 10:36:51 +0900, Chancel Liu wrote:
> ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
>
> Some audio systems require specific DAPM widgets to remain powered
> during system suspend. Introduce a generic and reusable mechanism in
> the ASoC core to mark selected DAPM widgets as ignore_suspend.
>
> The unified mechanism consists of two parts:
> 1. Parse and store the name list of widgets to ignore suspend in
> struct snd_soc_card
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/3] ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts
https://git.kernel.org/broonie/sound/c/8468c8aafe8b
[2/3] ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
https://git.kernel.org/broonie/sound/c/51271184a06d
[3/3] ASoC: fsl: imx-rpmsg: Switch to core ignore-suspend-widgets support
https://git.kernel.org/broonie/sound/c/68bb9a7f557a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [BUG] sched/cache: "Make LLC id continuous" causes NULL cpumask dereference in build_sched_domains on POWER9
From: Chen, Yu C @ 2026-05-25 15:35 UTC (permalink / raw)
To: Venkat Rao Bagalkote
Cc: Madhavan Srinivasan, Shrikanth Hegde, Ritesh Harjani,
Christophe Leroy (CS GROUP), LKML, linuxppc-dev, linux-sched,
tim.c.chen, K Prateek Nayak, Peter Zijlstra
In-Reply-To: <51154de7-3700-4cb4-82f2-1b3a8fa427f7@linux.ibm.com>
Hi Venkat,
On 5/25/2026 10:07 PM, Venkat Rao Bagalkote wrote:
> Greetings!!!
>
> I am seeing an early boot kernel panic due to NULL pointer dereference
> on a POWER9 (pSeries) system when testing linux-next (next-20260522).
>
Thanks for the test.
>
> Traces:
>
> [ 0.038567] Big cores detected but using small core scheduling
> [ 0.038796] BUG: Kernel NULL pointer dereference at 0x00000000
> [ 0.038804] Faulting instruction address: 0xc000000000e58504
> [ 0.038812] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 0.038819] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=8192 NUMA pSeries
> [ 0.038830] Modules linked in:
> [ 0.038840] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-
> rc6+ #14 PREEMPTLAZY
> [ 0.038851] Hardware name: IBM,8375-42A POWER9 (architected) 0x4e0202
> 0xf000005 of:IBM,FW950.80 (VL950_131) hv:phyp pSeries
> [ 0.039029] NIP [c000000000e58504] _find_first_bit+0x44/0x130
> [ 0.039043] LR [c000000000e58500] _find_first_bit+0x40/0x130
> [ 0.039076] [c0000000090e7bc0] [c00000000038b3b8]
> build_sched_domains+0xad8/0xe50
It seems that cpumask_first(llc_mask(i)) is accessing
NULL cpu_coregroup_mask():
has_coregroup_support() is false, thus cpu_coregroup_map
is never allocated in smp_prepare_cpus().
This machine is a "shared system" VM. We should probably
let the LLC id generation fall back to using L2 id if
cpu_coregroup_mask is unavailable (which restores the
behavior before this patch). I'm wondering if the following
change would help(need IBM friends' help on this):
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 3467f86fd78f..cf6c2e4190ab 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1042,11 +1042,6 @@ static const struct cpumask
*tl_smallcore_smt_mask(struct sched_domain_topology_
}
#endif
-struct cpumask *cpu_coregroup_mask(int cpu)
-{
- return per_cpu(cpu_coregroup_map, cpu);
-}
-
static bool has_coregroup_support(void)
{
/* Coregroup identification not available on shared systems */
@@ -1056,6 +1051,14 @@ static bool has_coregroup_support(void)
return coregroup_enabled;
}
+struct cpumask *cpu_coregroup_mask(int cpu)
+{
+ if (!has_coregroup_support())
+ return cpu_l2_cache_mask(cpu);
+
+ return per_cpu(cpu_coregroup_map, cpu);
+}
+
static int __init init_big_cores(void)
{
int cpu;
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: powerpc: update VMX AES entries
From: Breno Leitao @ 2026-05-25 15:30 UTC (permalink / raw)
To: Thorsten Blum
Cc: Herbert Xu, David S. Miller, Nayna Jain, Paulo Flabiano Smorigo,
Eric Biggers, Ard Biesheuvel, linux-crypto, linuxppc-dev,
linux-kernel
In-Reply-To: <20260524212943.799757-3-thorsten.blum@linux.dev>
On Sun, May 24, 2026 at 11:29:45PM +0000, Thorsten Blum wrote:
> Commit 7cf2082e74ce ("lib/crypto: powerpc/aes: Migrate POWER8 optimized
> code into library") removed arch/powerpc/crypto/aes.c and moved
> arch/powerpc/crypto/aesp8-ppc.pl to lib/crypto/powerpc/.
>
> However, the "IBM Power VMX Cryptographic instructions" entry still
> references the removed file and no longer covers the moved aesp8-ppc.pl.
>
> Remove the stale entry, add lib/crypto/powerpc/aesp8-ppc.pl, and tighten
> the arch/powerpc/crypto/aesp8-ppc.* pattern to match the remaining
> header only.
>
> Fixes: 7cf2082e74ce ("lib/crypto: powerpc/aes: Migrate POWER8 optimized code into library")
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Acked-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* [BUG] sched/cache: "Make LLC id continuous" causes NULL cpumask dereference in build_sched_domains on POWER9
From: Venkat Rao Bagalkote @ 2026-05-25 14:07 UTC (permalink / raw)
To: Peter Zijlstra, K Prateek Nayak, Chen, Yu C, tim.c.chen
Cc: Madhavan Srinivasan, Shrikanth Hegde, Ritesh Harjani,
Christophe Leroy (CS GROUP), LKML, linuxppc-dev, linux-sched
Greetings!!!
I am seeing an early boot kernel panic due to NULL pointer dereference
on a POWER9 (pSeries) system when testing linux-next (next-20260522).
Traces:
[ 0.038567] Big cores detected but using small core scheduling
[ 0.038796] BUG: Kernel NULL pointer dereference at 0x00000000
[ 0.038804] Faulting instruction address: 0xc000000000e58504
[ 0.038812] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.038819] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=8192 NUMA pSeries
[ 0.038830] Modules linked in:
[ 0.038840] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted
7.0.0-rc6+ #14 PREEMPTLAZY
[ 0.038851] Hardware name: IBM,8375-42A POWER9 (architected) 0x4e0202
0xf000005 of:IBM,FW950.80 (VL950_131) hv:phyp pSeries
[ 0.038860] NIP: c000000000e58504 LR: c000000000e58500 CTR:
0000000000000000
[ 0.038869] REGS: c0000000090e78e0 TRAP: 0380 Not tainted (7.0.0-rc6+)
[ 0.038878] MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR:
44002242 XER: 20040003
[ 0.038907] CFAR: c00000000093f3f0 IRQMASK: 0
[ 0.038907] GPR00: c00000000038b3b8 c0000000090e7b80 c00000000259a800
0000000000000000
[ 0.038907] GPR04: 0000000000000038 0000000000000038 c00000000c6e2560
0000000000000000
[ 0.038907] GPR08: 0000000000000000 0000000000000037 0000ffffffffffff
0000000000000000
[ 0.038907] GPR12: c000000000072730 c0000000051b0000 c00000000c6ee560
00000000ffffffff
[ 0.038907] GPR16: 0000000000000000 0000000000000038 c0000000032c6b08
fffffffffffffff6
[ 0.038907] GPR20: 0000000000000000 c000000004d1a6e0 0000000000000000
0000000000000000
[ 0.038907] GPR24: 0000000000000000 0000000000000000 00000000ffffffff
c00000000a3bf940
[ 0.038907] GPR28: 0000000000000038 0000000000000000 0000000000000000
0000000000000000
[ 0.039029] NIP [c000000000e58504] _find_first_bit+0x44/0x130
[ 0.039043] LR [c000000000e58500] _find_first_bit+0x40/0x130
[ 0.039054] Call Trace:
[ 0.039060] [c0000000090e7b80] [c00000000416af20]
schedutil_gov+0x0/0xa0 (unreliable)
[ 0.039076] [c0000000090e7bc0] [c00000000038b3b8]
build_sched_domains+0xad8/0xe50
[ 0.039089] [c0000000090e7ce0] [c000000003045d78]
sched_init_smp+0xa8/0x164
[ 0.039102] [c0000000090e7d30] [c00000000300f374]
kernel_init_freeable+0x250/0x370
[ 0.039117] [c0000000090e7de0] [c000000000011f90] kernel_init+0x34/0x1e4
[ 0.039129] [c0000000090e7e50] [c00000000000debc]
ret_from_kernel_user_thread+0x14/0x1c
[ 0.039142] ---- interrupt: 0 at 0x0
[ 0.039150] Code: 41820090 7c0802a6 393cffff fbe10038 7c7f1b78
fba10028 fbc10030 3bc00000 793dd7e2 f8010050 4bae6e9d 60000000
<e93f0000> 2c290000 408200bc 283c0040
[ 0.039196] ---[ end trace 0000000000000000 ]---
Git bisect is pointing to b5ea300a17e3 sched/cache: Make LLC id
continuous as first bad commit.
Git Bisect Logs:
# git bisect log
git bisect start
# status: waiting for both good and bad commits
# bad: [c1ecb239fa3456529a32255359fc78b69eb9d847] Add linux-next
specific files for 20260522
git bisect bad c1ecb239fa3456529a32255359fc78b69eb9d847
# status: waiting for good commit(s), bad commit known
# good: [5200f5f493f79f14bbdc349e402a40dfb32f23c8] Linux 7.1-rc4
git bisect good 5200f5f493f79f14bbdc349e402a40dfb32f23c8
# good: [7cd27a0d57b8539366c98bb04fe48d1aff779ea9] Merge branch 'main'
of https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git bisect good 7cd27a0d57b8539366c98bb04fe48d1aff779ea9
# good: [efb3dd6031ec9858c7285fd673970320c86c01f3] Merge branch 'next'
of https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
git bisect good efb3dd6031ec9858c7285fd673970320c86c01f3
# bad: [1a6066d1c1243fdc5ed464032bbdf12e6710c027] Merge branch
'driver-core-next' of
https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
git bisect bad 1a6066d1c1243fdc5ed464032bbdf12e6710c027
# good: [409a99cbc316d912c999fd75b9df042b25900e50] Merge branch
'for-next' of
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
git bisect good 409a99cbc316d912c999fd75b9df042b25900e50
# bad: [af73f6b022c8c09a3234176892a18216be4cd984] Merge branch 'next' of
git://git.kernel.org/pub/scm/virt/kvm/kvm.git
git bisect bad af73f6b022c8c09a3234176892a18216be4cd984
# bad: [6a459eb254e4bff61546587eccd3091955123d24] Merge branch into
tip/master: 'sched/core'
git bisect bad 6a459eb254e4bff61546587eccd3091955123d24
# good: [71ba4bb66c3a9287245d0f5fcfb27d4b951ba402] Merge branch into
tip/master: 'locking/core'
git bisect good 71ba4bb66c3a9287245d0f5fcfb27d4b951ba402
# good: [f3b45696a160a2230d846de8f706e835984ae65b] Merge branch into
tip/master: 'objtool/core'
git bisect good f3b45696a160a2230d846de8f706e835984ae65b
# bad: [c99b8593b060931c5a0a4b701689f8d6a2c00dbf] sched/cache: Fix stale
preferred_llc for a new task
git bisect bad c99b8593b060931c5a0a4b701689f8d6a2c00dbf
# bad: [5b1d5e6db20a6c64ffb95d04578db8c4b0228eea] sched/cache: Respect
LLC preference in task migration and detach
git bisect bad 5b1d5e6db20a6c64ffb95d04578db8c4b0228eea
# bad: [46afe3af7ead57190b6d362e214814ec804e3b7b] sched/cache: Track
LLC-preferred tasks per runqueue
git bisect bad 46afe3af7ead57190b6d362e214814ec804e3b7b
# good: [f025ef275388742643a2c33f00a0d9c0af3112ee] sched/cache: Record
per LLC utilization to guide cache aware scheduling decisions
git bisect good f025ef275388742643a2c33f00a0d9c0af3112ee
# bad: [b5ea300a17e37eada7a98561fbd34a3054578713] sched/cache: Make LLC
id continuous
git bisect bad b5ea300a17e37eada7a98561fbd34a3054578713
# good: [23b2b5ccc45ce2a38b9336a916088fffdc4cdfb1] sched/cache:
Introduce helper functions to enforce LLC migration policy
git bisect good 23b2b5ccc45ce2a38b9336a916088fffdc4cdfb1
# first bad commit: [b5ea300a17e37eada7a98561fbd34a3054578713]
sched/cache: Make LLC id continuous
b5ea300a17e37eada7a98561fbd34a3054578713 is the first bad commit
commit b5ea300a17e37eada7a98561fbd34a3054578713
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date: Wed Apr 1 14:52:17 2026 -0700
sched/cache: Make LLC id continuous
Introduce an index mapping between CPUs and their LLCs. This provides
a roughly continuous per LLC index needed for cache-aware load
balancing in
later patches.
The existing per_cpu llc_id usually points to the first CPU of the
LLC domain, which is sparse and unsuitable as an array index. Using
llc_id directly would waste memory.
With the new mapping, CPUs in the same LLC share an approximate
continuous id:
per_cpu(llc_id, CPU=0...15) = 0
per_cpu(llc_id, CPU=16...31) = 1
per_cpu(llc_id, CPU=32...47) = 2
...
Note that the LLC IDs are allocated via bitmask, so the IDs may be
reused during CPU offline->online transitions.
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Originally-by: K Prateek Nayak <kprateek.nayak@amd.com>
Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link:
https://patch.msgid.link/047ef46339e4db497b54a89940a7ebedf27fcf28.1775065312.git.tim.c.chen@linux.intel.com
kernel/sched/core.c | 2 ++
kernel/sched/sched.h | 3 ++
kernel/sched/topology.c | 90
+++++++++++++++++++++++++++++++++++++++++++++++--
3 files changed, 93 insertions(+), 2 deletions(-)
If you happen to fix this, please add below tag.
Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Regards,
Venkat.
^ permalink raw reply
* Re: [PATCH 04/11] treewide: Convert struct kernel_param_ops initializers to DEFINE_KERNEL_PARAM_OPS
From: Petr Pavlu @ 2026-05-25 13:35 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-4-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Using Coccinelle, rewrite every struct kernel_param_ops initializer that
> sets .get into a DEFINE_KERNEL_PARAM_OPS-family macro invocation,
> for example:
>
> @@
> declarer name DEFINE_KERNEL_PARAM_OPS;
> identifier OPS;
> expression SET, GET;
> @@
> - const struct kernel_param_ops OPS = {
> - .set = SET,
> - .get = GET,
> - };
> + DEFINE_KERNEL_PARAM_OPS(OPS, SET, GET);
>
> Using the macro for initialization means future changes can manipulate
> the struct layout and callback prototypes without having to change every
> initializer.
Nit: For consistency, I suggest also converting the few remaining
kernel_param_ops instances that specify only .set and no .get, such as
simdisk_param_ops_filename.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH 03/11] moduleparam: Add DEFINE_KERNEL_PARAM_OPS macro family
From: Petr Pavlu @ 2026-05-25 13:27 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-3-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Add macros that define a struct kernel_param_ops initializer through a
> macro so the underlying field layout can evolve without touching every
> call site. Three variants cover the three cases:
>
> DEFINE_KERNEL_PARAM_OPS(name, set, get) // basic
> DEFINE_KERNEL_PARAM_OPS_NOARG(name, set, get) // set KERNEL_PARAM_OPS_FL_NOARG
> DEFINE_KERNEL_PARAM_OPS_FREE(name, set, get, free) // also set .free
>
> Callers prefix their own visibility qualifiers, e.g.:
>
> static DEFINE_KERNEL_PARAM_OPS(my_ops, my_set, my_get);
>
> Also update module_param_call() and STANDARD_PARAM_DEF() to use
> DEFINE_KERNEL_PARAM_OPS internally so the generated ops table will go
> through the same macro as everything else.
>
> Subsequent commits convert all open-coded struct kernel_param_ops
> definitions to use these macros, in preparation for migrating to a
> seq_buf .get API.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> include/linux/moduleparam.h | 36 ++++++++++++++++++++++++++++++++++--
> kernel/params.c | 6 ++----
> 2 files changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index 075f28585074..26bf45b36d02 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -68,6 +68,39 @@ struct kernel_param_ops {
> void (*free)(void *arg);
> };
>
> +/*
> + * Define a const struct kernel_param_ops initializer. Callers prefix with
> + * any required visibility qualifiers (typically "static"):
> + *
> + * static DEFINE_KERNEL_PARAM_OPS(my_ops, my_set, my_get);
> + *
> + * Routing the @_set and @_get function pointers through the macro
> + * (rather than naming the struct fields at every call site) lets the
> + * field layout change in one place when callbacks are migrated to a
> + * new signature.
> + */
Nit: The newly introduced DEFINE_KERNEL_PARAM_OPS*() macros remain in
place at the end of the series after the migration is complete and this
comment is removed in patch 7. It would be helpful to describe in the
commit message why these macros are generally preferable to defining
kernel_param_ops instances directly.
I assume the motivation is that the structure is simple enough and using
macros then makes defining kernel_param_ops instances a bit more
concise. A minor disadvantage is that some analysis tools, such as
ctags, may no longer see the generated definition, but that is also the
case for DEFINE_MUTEX() and other similar macros.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v14 00/17] arm64/riscv: Add support for crashkernel CMA reservation
From: Huacai Chen @ 2026-05-25 13:17 UTC (permalink / raw)
To: Mike Rapoport
Cc: Jinjie Ruan, corbet, skhan, catalin.marinas, will, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, pasha.tatashin,
pratyush, ruirui.yang, rdunlap, pmladek, feng.tang, dapeng1.mi,
kees, elver, kuba, lirongqing, ebiggers, paulmck, thuth, ardb,
masahiroy, mark.rutland, maz, james.morse, leitao, sourabhjain,
yeoreum.yun, coxu, jbohac, ryan.roberts, cfsworks, tangyouling,
ritesh.list, songshuaishuai, junhui.liu, vishal.moola, kas, debug,
namcao, liaoyuanhong, fuqiang.wang, seanjc, guoren, chenjiahao16,
hbathini, bgwin, takahiro.akashi, lizhengyu3, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <ahQ0WRiMsB011tym@kernel.org>
On Mon, May 25, 2026 at 7:37 PM Mike Rapoport <rppt@kernel.org> wrote:
>
> Hi Huacai,
>
> On Mon, May 25, 2026 at 06:14:52PM +0800, Huacai Chen wrote:
> > On Mon, May 25, 2026 at 4:50 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> > >
> > > Jinjie Ruan (16):
> > > riscv: kexec_file: Fix crashk_low_res not exclude bug
> > > powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
> > > arm64: kexec: Fix image->elf_headers memory leak during retry loop
> > > x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
> > > arm64: kexec_file: Fix potential buffer overflow in
> > > prepare_elf_headers()
> > > riscv: kexec_file: Fix potential buffer overflow in
> > > prepare_elf_headers()
> > > LoongArch: kexec: Fix potential buffer overflow in
> > > prepare_elf_headers()
> > > crash: Add crash_prepare_headers() to exclude crash kernel memory
> > > arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
> > > x86/kexec: Use crash_prepare_headers() helper to simplify code
> > > riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
> > > LoongArch: kexec: Use crash_prepare_headers() helper to simplify code
> > > crash: Use crash_exclude_core_ranges() on powerpc
> > > arm64: kexec: Add support for crashkernel CMA reservation
> > > riscv: kexec: Add support for crashkernel CMA reservation
> > > arm64/crash: Add crash hotplug support
> > I have some bikesheedings about the subjects. Can we unify the prefix formats?
> > x86/kexec, arm64: kexec_file, riscv: kexec_file, LoongArch: kexec .....
>
> It might look weird in the series, but powerpc and x86 use '/' and arm64 and
> riscv use ':' so in the logs in arch/ this would be actually fine.
OK, but at least we can unify kexec and kexec_file.
Huacai
>
> With the only exception of arm64/crash that should have been arm64: crash:
>
> > Huacai
>
> --
> Sincerely yours,
> Mike.
^ permalink raw reply
* [PATCH] ppc/pnv: Fix null pointer deref in pci hotplug
From: Aditya Gupta @ 2026-05-25 12:16 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, Madhavan Srinivasan, Timothy Pearson,
Bjorn Helgaas, Shawn Anastasio
Cc: linux-pci, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), stable
With upstream kernel booted on a PowerNV system with OpenCAPI device,
below crash is observed:
[ 1.568588] PowerPC PowerNV PCI Hotplug Driver version: 0.1
[ 1.569722] BUG: Kernel NULL pointer dereference at 0x00000074
[ 1.569811] Faulting instruction address: 0xc000000000b75fd0
[ 1.569890] Oops: Kernel access of bad area, sig: 11 [#1]
[ 1.569963] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
[ 1.570037] Modules linked in:
[ 1.570099] CPU: 250 UID: 0 PID: 1 Comm: swapper/248 Not tainted 7.1.0-rc4+ #1 PREEMPTLAZY
[ 1.570207] Hardware name: 9105-22A Power11 (raw) 0x820200 opal:v7.1-142-gbbc276524497 PowerNV
[ 1.570325] NIP: c000000000b75fd0 LR: c000000000b75fbc CTR: 000000003008a65c
[ 1.570411] REGS: c000c0000688f6f0 TRAP: 0380 Not tainted (7.1.0-rc4+)
[ 1.570494] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 28000284 XER: 20040000
[ 1.570636] CFAR: c00000000019f9e8 IRQMASK: 0
...
[ 1.571492] NIP [c000000000b75fd0] pnv_php_get_adapter_state+0x60/0x154
[ 1.571604] LR [c000000000b75fbc] pnv_php_get_adapter_state+0x4c/0x154
[ 1.571690] Call Trace:
[ 1.571725] [c000c0000688f990] [c000000000b75fbc] pnv_php_get_adapter_state+0x4c/0x154 (unreliable)
[ 1.571783] [c000c0000688fa20] [c000000000b78bd0] pnv_php_enable+0x94/0x378
[ 1.571951] [c000c0000688fac0] [c000000000b7912c] pnv_php_register_one.isra.0+0x11c/0x1e0
[ 1.572077] [c000c0000688fb00] [c000000002091318] pnv_php_init+0x168/0x1b0
[ 1.572111] [c000c0000688fb80] [c00000000001103c] do_one_initcall+0x5c/0x450
[ 1.572162] [c000c0000688fc70] [c000000002006abc] do_initcalls+0x15c/0x29c
[ 1.572283] [c000c0000688fd30] [c000000002006ec4] kernel_init_freeable+0x224/0x3e0
[ 1.572484] [c000c0000688fde0] [c000000000011578] kernel_init+0x30/0x268
[ 1.572562] [c000c0000688fe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c
[ 1.572667] ---- interrupt: 0 at 0x0
[ 1.572720] Code: 38810065 e90d0c78 f9010068 39000000 99210065 e8630020 4b6299c9 60000000 2c030000 418000ac e87f0058 89410065 <a1230074> 55290636 2c090060 41820044
This NULL pointer dereference happens due to the call to
'pci_pcie_type(php_slot->pdev)' without checking if php_slot->pdev is
NULL.
This occurs for hotplug slots on root buses where bus->self == NULL,
such as OpenCAPI PHB direct slots. An added debug print (not part of
this patch) confirmed it was opencapi:
[ 1.617227] pnv_php: slot 'OPENCAPI-0009' has NULL pdev (bus 0009:00, parent=NO (root bus))
[ 1.617308] pnv_php: slot 'OPENCAPI-0009' dn->full_name='pciex@603a000000000', compatible='ibm,power10-pau-opencapi-pciex'
Add a NULL check for this.
Cc: stable@vger.kernel.org
Fixes: 80f9fc236279 ("PCI: pnv_php: Work around switches with broken presence detection")
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
---
drivers/pci/hotplug/pnv_php.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
index ff92a5c301b8..21ce7ead9e19 100644
--- a/drivers/pci/hotplug/pnv_php.c
+++ b/drivers/pci/hotplug/pnv_php.c
@@ -414,7 +414,8 @@ static int pnv_php_get_adapter_state(struct hotplug_slot *slot, u8 *state)
*/
ret = pnv_pci_get_presence_state(php_slot->id, &presence);
if (ret >= 0) {
- if (pci_pcie_type(php_slot->pdev) == PCI_EXP_TYPE_DOWNSTREAM &&
+ if (php_slot->pdev &&
+ pci_pcie_type(php_slot->pdev) == PCI_EXP_TYPE_DOWNSTREAM &&
presence == OPAL_PCI_SLOT_EMPTY) {
/*
* Similar to pciehp_hpc, check whether the Link Active
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v14 00/17] arm64/riscv: Add support for crashkernel CMA reservation
From: Mike Rapoport @ 2026-05-25 11:36 UTC (permalink / raw)
To: Huacai Chen
Cc: Jinjie Ruan, corbet, skhan, catalin.marinas, will, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, pasha.tatashin,
pratyush, ruirui.yang, rdunlap, pmladek, feng.tang, dapeng1.mi,
kees, elver, kuba, lirongqing, ebiggers, paulmck, thuth, ardb,
masahiroy, mark.rutland, maz, james.morse, leitao, sourabhjain,
yeoreum.yun, coxu, jbohac, ryan.roberts, cfsworks, tangyouling,
ritesh.list, songshuaishuai, junhui.liu, vishal.moola, kas, debug,
namcao, liaoyuanhong, fuqiang.wang, seanjc, guoren, chenjiahao16,
hbathini, bgwin, takahiro.akashi, lizhengyu3, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <CAAhV-H4NA7vgyxKnK+N_3C6pWBnwXc2URUyLh_h1m-MO=MnsGQ@mail.gmail.com>
Hi Huacai,
On Mon, May 25, 2026 at 06:14:52PM +0800, Huacai Chen wrote:
> On Mon, May 25, 2026 at 4:50 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> >
> > Jinjie Ruan (16):
> > riscv: kexec_file: Fix crashk_low_res not exclude bug
> > powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
> > arm64: kexec: Fix image->elf_headers memory leak during retry loop
> > x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
> > arm64: kexec_file: Fix potential buffer overflow in
> > prepare_elf_headers()
> > riscv: kexec_file: Fix potential buffer overflow in
> > prepare_elf_headers()
> > LoongArch: kexec: Fix potential buffer overflow in
> > prepare_elf_headers()
> > crash: Add crash_prepare_headers() to exclude crash kernel memory
> > arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
> > x86/kexec: Use crash_prepare_headers() helper to simplify code
> > riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
> > LoongArch: kexec: Use crash_prepare_headers() helper to simplify code
> > crash: Use crash_exclude_core_ranges() on powerpc
> > arm64: kexec: Add support for crashkernel CMA reservation
> > riscv: kexec: Add support for crashkernel CMA reservation
> > arm64/crash: Add crash hotplug support
> I have some bikesheedings about the subjects. Can we unify the prefix formats?
> x86/kexec, arm64: kexec_file, riscv: kexec_file, LoongArch: kexec .....
It might look weird in the series, but powerpc and x86 use '/' and arm64 and
riscv use ':' so in the logs in arch/ this would be actually fine.
With the only exception of arm64/crash that should have been arm64: crash:
> Huacai
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH] KVM: Validate irqchip index for LoongArch and PowerPC
From: Yanfei Xu @ 2026-05-25 7:01 UTC (permalink / raw)
To: zhaotianrui, maobibo, chenhuacai, maddy, npiggin, sashiko-reviews,
seanjc, pbonzini
Cc: kvm, loongarch, linuxppc-dev, caixiangfeng, fangying.tommy,
yanfei.xu, isyanfei.xu, Sashiko
Sashiko reported that irqchip index is not validated for LoongArch and
PowerPC. Add validation and reject out-of-range irqchip indexes to avoid
indexing past the routing table's chip array.
Fixes: de9ba2f36368 ("KVM: PPC: Support irq routing and irqfd for in-kernel MPIC")
Fixes: 1928254c5ccb ("LoongArch: KVM: Add irqfd support")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/kvm/20260525051714.485D51F000E9@smtp.kernel.org/
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
---
arch/loongarch/kvm/irqfd.c | 3 ++-
arch/powerpc/kvm/mpic.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/loongarch/kvm/irqfd.c b/arch/loongarch/kvm/irqfd.c
index f4f953b22419..40ed1081c4b6 100644
--- a/arch/loongarch/kvm/irqfd.c
+++ b/arch/loongarch/kvm/irqfd.c
@@ -51,7 +51,8 @@ int kvm_set_routing_entry(struct kvm *kvm,
e->irqchip.irqchip = ue->u.irqchip.irqchip;
e->irqchip.pin = ue->u.irqchip.pin;
- if (e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS)
+ if (e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS ||
+ e->irqchip.irqchip >= KVM_NR_IRQCHIPS)
return -EINVAL;
return 0;
diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c
index 3070f36d9fb8..fb5f9e65e02e 100644
--- a/arch/powerpc/kvm/mpic.c
+++ b/arch/powerpc/kvm/mpic.c
@@ -1833,7 +1833,8 @@ int kvm_set_routing_entry(struct kvm *kvm,
e->set = mpic_set_irq;
e->irqchip.irqchip = ue->u.irqchip.irqchip;
e->irqchip.pin = ue->u.irqchip.pin;
- if (e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS)
+ if (e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS ||
+ e->irqchip.irqchip >= KVM_NR_IRQCHIPS)
goto out;
break;
case KVM_IRQ_ROUTING_MSI:
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] misc: eeprom: at24: Make VCC supply description requirement optional
From: Mark Brown @ 2026-05-25 10:32 UTC (permalink / raw)
To: Paul Menzel
Cc: Bartosz Golaszewski, Arnd Bergmann, Greg Kroah-Hartman,
Liam Girdwood, Madhavan Srinivasan, Michael Ellerman,
linuxppc-dev, linux-i2c, linux-kernel
In-Reply-To: <84448a84-1c96-45a9-9ba8-1e058d0bf8a5@molgen.mpg.de>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
On Mon, May 25, 2026 at 09:07:42AM +0200, Paul Menzel wrote:
> Am 25.05.26 um 00:07 schrieb Mark Brown:
> > This is not appropriate unless the device can actually operate without
> > power, any driver could be used in a system where the firmware does not
> > describe the regultors and it'd obviously be pointless and error prone
> > to scatter bodges like this on every single call to a regulator API
> > function.
> How should the warning on the POWER server be addressed then?
They should fix their DT, or you should arrange some way of identifying
that for some reason their DT is like this and dummy regulators are the
expected case.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v14 00/17] arm64/riscv: Add support for crashkernel CMA reservation
From: Huacai Chen @ 2026-05-25 10:14 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, kernel, maddy, mpe, npiggin,
chleroy, pjw, palmer, aou, alex, tglx, mingo, bp, dave.hansen,
hpa, robh, saravanak, akpm, bhe, rppt, pasha.tatashin, pratyush,
ruirui.yang, rdunlap, pmladek, feng.tang, dapeng1.mi, kees, elver,
kuba, lirongqing, ebiggers, paulmck, thuth, ardb, masahiroy,
mark.rutland, maz, james.morse, leitao, sourabhjain, yeoreum.yun,
coxu, jbohac, ryan.roberts, cfsworks, tangyouling, ritesh.list,
songshuaishuai, junhui.liu, vishal.moola, kas, debug, namcao,
liaoyuanhong, fuqiang.wang, seanjc, guoren, chenjiahao16,
hbathini, bgwin, takahiro.akashi, lizhengyu3, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <20260525084932.934910-1-ruanjinjie@huawei.com>
Hi, Jinjie,
On Mon, May 25, 2026 at 4:50 PM 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.
>
> Also add support for arm64 crash hotplug.
>
> This patch set is rebased on v7.1-rc1.
>
> Basic second kernel boot test were performed on QEMU platforms for x86,
> ARM64 and RISC-V architectures with the following parameters:
>
> "cma=256M crashkernel=4G crashkernel=64M,cma"
>
> For first kernel, there will be such log:
>
> # dmesg | grep crash
> [ 0.000000] crashkernel low memory reserved: 0xe8000000 - 0xf0000000 (128 MB)
> [ 0.000000] crashkernel reserved: 0x000000023e600000 - 0x000000033e600000 (4096 MB)
> [ 0.000000] crashkernel CMA reserved: 64 MB in 1 ranges
>
> # dmesg | grep cma
> [ 0.000000] cma: Reserved 256 MiB at 0x00000000f0000000
> [ 0.000000] cma: Reserved 64 MiB at 0x0000000100000000
>
> For second kernel, there will be such log:
>
> [ 0.000000] OF: fdt: Looking for usable-memory-range property...
> [ 0.000000] OF: fdt: cap_mem_regions[0]: base=0x000000023e600000, size=0x0000000100000000
> [ 0.000000] OF: fdt: cap_mem_regions[1]: base=0x00000000e8000000, size=0x0000000008000000
> [ 0.000000] OF: fdt: cap_mem_regions[2]: base=0x0000000100000000, size=0x0000000004000000
>
> Changes in v14:
> - Fix image->elf_headers memory leak during retry loop for arm64 as Sashiko
> AI code review pointed out.
> - Solve the hotplug notifier arch_crash_handle_hotplug_event() AA
> self-deadlock problem as Sashiko AI code review pointed out.
> - Fix the TOCTOU issue in prepare_elf_headers() by get_online_mems().
> - -ENOMEM -> -EAGAIN as Breno suggested.
> - Add support for arm64 crash hotplug.
> - Link to v13: https://lore.kernel.org/all/20260511030454.1730881-1-ruanjinjie@huawei.com/
>
> Changes in v13:
> - Rebased on v7.1-rc1.
> - Update the commit message.
> - Add Reviewed-by.
> - Link to v12: https://lore.kernel.org/all/20260402072701.628293-1-ruanjinjie@huawei.com/
>
> Changes in v12:
> - Remove the unused "nr_mem_ranges" for x86.
> - Add "Fix crashk_low_res not exclude bug" test log.
> - Provide a separate patch for each architecture for using
> crash_prepare_headers(), which will make the review more convenient.
> - Add Reviewed-by and Tested-by.
> - Link to v11: https://lore.kernel.org/all/20260328074013.3589544-1-ruanjinjie@huawei.com/
>
> Changes in v11:
> - Avoid silently drop crash memory if the crash kernel is built without
> CONFIG_CMA.
> - Remove unnecessary "cmem->nr_ranges = 0" for arch_crash_populate_cmem()
> as we use kvzalloc().
> - Provide a separate patch for each architecture to fix the existing
> buffer overflow issue.
> - Add Acked-bys for arm64.
>
> Changes in v10:
> - Fix crashk_low_res not excluded bug in the existing
> RISC-V code.
> - Fix an existing memory leak issue in the existing PowerPC code.
> - Fix the ordering issue of adding CMA ranges to
> "linux,usable-memory-range".
> - Fix 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.
> - Link to v9: https://lore.kernel.org/all/20260323072745.2481719-1-ruanjinjie@huawei.com/
>
> Changes in v9:
> - Collect Reviewed-by and Acked-by, and prepare for Sashiko AI review.
> - Link to v8: https://lore.kernel.org/all/20260302035315.3892241-1-ruanjinjie@huawei.com/
>
> Changes in v8:
> - Fix the build issues reported by kernel test robot and Sourabh.
> - Link to v7: https://lore.kernel.org/all/20260226130437.1867658-1-ruanjinjie@huawei.com/
>
> Changes in v7:
> - Correct the inclusion of CMA-reserved ranges for kdump kernel in of/kexec
> for arm64 and riscv.
> - Add Acked-by.
> - Link to v6: https://lore.kernel.org/all/20260224085342.387996-1-ruanjinjie@huawei.com/
>
> Changes in v6:
> - Update the crash core exclude code as Mike suggested.
> - Rebased on v7.0-rc1.
> - Add acked-by.
> - Link to v5: https://lore.kernel.org/all/20260212101001.343158-1-ruanjinjie@huawei.com/
>
> Jinjie Ruan (16):
> riscv: kexec_file: Fix crashk_low_res not exclude bug
> powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
> arm64: kexec: Fix image->elf_headers memory leak during retry loop
> x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
> arm64: kexec_file: Fix potential buffer overflow in
> prepare_elf_headers()
> riscv: kexec_file: Fix potential buffer overflow in
> prepare_elf_headers()
> LoongArch: kexec: Fix potential buffer overflow in
> prepare_elf_headers()
> crash: Add crash_prepare_headers() to exclude crash kernel memory
> arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
> x86/kexec: Use crash_prepare_headers() helper to simplify code
> riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
> LoongArch: kexec: Use crash_prepare_headers() helper to simplify code
> crash: Use crash_exclude_core_ranges() on powerpc
> arm64: kexec: Add support for crashkernel CMA reservation
> riscv: kexec: Add support for crashkernel CMA reservation
> arm64/crash: Add crash hotplug support
I have some bikesheedings about the subjects. Can we unify the prefix formats?
x86/kexec, arm64: kexec_file, riscv: kexec_file, LoongArch: kexec .....
Huacai
>
> Sourabh Jain (1):
> powerpc/crash: sort crash memory ranges before preparing elfcorehdr
>
> .../admin-guide/kernel-parameters.txt | 16 +--
> arch/arm64/Kconfig | 3 +
> arch/arm64/include/asm/kexec.h | 14 +-
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/crash.c | 125 ++++++++++++++++++
> arch/arm64/kernel/kexec_image.c | 22 ++-
> arch/arm64/kernel/machine_kexec_file.c | 78 ++++++-----
> arch/arm64/mm/init.c | 5 +-
> arch/loongarch/kernel/machine_kexec_file.c | 43 +++---
> arch/powerpc/include/asm/kexec_ranges.h | 1 -
> arch/powerpc/kexec/crash.c | 7 +-
> arch/powerpc/kexec/ranges.c | 101 +-------------
> arch/riscv/kernel/machine_kexec_file.c | 42 +++---
> arch/riscv/mm/init.c | 5 +-
> arch/x86/kernel/crash.c | 92 ++-----------
> drivers/of/fdt.c | 9 +-
> drivers/of/kexec.c | 9 ++
> include/linux/crash_core.h | 11 ++
> include/linux/crash_reserve.h | 4 +-
> kernel/crash_core.c | 102 +++++++++++++-
> 20 files changed, 392 insertions(+), 298 deletions(-)
> create mode 100644 arch/arm64/kernel/crash.c
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 3/4] fbdev: Wrap fbcon updates from vga-switcheroo in helper
From: Geert Uytterhoeven @ 2026-05-25 9:31 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: deller, simona, airlied, lukas, maddy, mpe, npiggin, chleroy,
dri-devel, linux-fbdev, linuxppc-dev
In-Reply-To: <20260522123019.211059-4-tzimmermann@suse.de>
Hi Thomas,
On Fri, 22 May 2026 at 15:11, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Handle console remapping in fbcon in fb_switch_output(). Vga-switcheroo
> invokes this functionality before switching physical outputs to a new
> graphics device. Open-coding fbcon state in vga-switcheroo exposed fbdev
> implementation details.
>
> Vga-switcheroo is used for switching physical outputs among graphics
> hardware. This functionality is only supported by DRM drivers. A later
> update will further move fb_switch_output() into DRM's fbdev emulation;
> thus fully decoupling vga-switcheroo from fbdev.
>
> v2:
> - use '#if defined' (Helge)
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Thanks for your patch, which is now commit 91458b3f2a84bc7b ("fbdev:
Wrap fbcon updates from vga-switcheroo in helper") in fbdev/for-next.
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -31,11 +31,9 @@
> #define pr_fmt(fmt) "vga_switcheroo: " fmt
>
> #include <linux/apple-gmux.h>
> -#include <linux/console.h>
> #include <linux/debugfs.h>
> #include <linux/fb.h>
> #include <linux/fs.h>
> -#include <linux/fbcon.h>
> #include <linux/module.h>
> #include <linux/pci.h>
> #include <linux/pm_domain.h>
> @@ -735,8 +733,10 @@ static int vga_switchto_stage2(struct vga_switcheroo_client *new_client)
> if (!active->driver_power_control)
> set_audio_state(active->id, VGA_SWITCHEROO_OFF);
>
> +#if defined(CONFIG_FB)
> if (new_client->fb_info)
> - fbcon_remap_all(new_client->fb_info);
> + fb_switch_outputs(new_client->fb_info);
> +#endif
What if CONFIG_FB is modular?
CONFIG_VGA_SWITCHEROO is bool.
>
> mutex_lock(&vgasr_priv.mux_hw_lock);
> ret = vgasr_priv.handler->switchto(new_client->id);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] powerpc/boot: remove unused min_t/max_t macros
From: Thorsten Blum @ 2026-05-25 9:18 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP)
Cc: Thorsten Blum, linuxppc-dev, linux-kernel
The min_t() and max_t() macros are no longer used by the boot wrapper,
remove them.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/powerpc/boot/types.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/boot/types.h b/arch/powerpc/boot/types.h
index 8a4c418b7260..c5085c2632bf 100644
--- a/arch/powerpc/boot/types.h
+++ b/arch/powerpc/boot/types.h
@@ -37,9 +37,6 @@ typedef s64 int64_t;
(void) (&_x == &_y); \
_x > _y ? _x : _y; })
-#define min_t(type, a, b) min(((type) a), ((type) b))
-#define max_t(type, a, b) max(((type) a), ((type) b))
-
typedef int bool;
#ifndef true
^ permalink raw reply related
* [PATCH v14 17/17] arm64/crash: Add crash hotplug support
From: Jinjie Ruan @ 2026-05-25 8:49 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
feng.tang, dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers,
paulmck, thuth, ardb, masahiroy, mark.rutland, maz, james.morse,
leitao, sourabhjain, yeoreum.yun, coxu, jbohac, ryan.roberts,
cfsworks, tangyouling, ritesh.list, songshuaishuai, junhui.liu,
vishal.moola, kas, debug, namcao, liaoyuanhong, fuqiang.wang,
seanjc, guoren, chenjiahao16, hbathini, bgwin, takahiro.akashi,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260525084932.934910-1-ruanjinjie@huawei.com>
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) of kdump
image becomes outdated. Consequently, attempting dump collection with
an outdated elfcorehdr can lead to inaccurate dump collection.
The current solution to address the above issue involves monitoring
the CPU/Memory add/remove events in userspace using udev rules and
whenever there are changes in CPU and memory resources, the entire
kdump image is loaded again. The kdump image includes kernel, initrd,
elfcorehdr, FDT, purgatory. Given that only elfcorehdr gets outdated
due to CPU/Memory add/remove events, reloading the entire kdump image
is inefficient. More importantly, kdump remains inactive for a
substantial amount of time until the kdump reload completes.
To address the aforementioned issue, commit 247262756121 ("crash: add
generic infrastructure for crash hotplug support") added a generic
infrastructure that allows architectures to selectively update the
kdump image component during CPU or memory add/remove events within
the kernel itself.
In the event of a CPU or memory add/remove events, the generic crash
hotplug event handler, crash_handle_hotplug_event(), is triggered. It
then acquires the necessary locks to update the kdump image and invokes
the architecture-specific crash hotplug handler,
arch_crash_handle_hotplug_event(), to update the required kdump image
components.
[1] has supported virtual CPU hotplug in virtual machines for ARM64,
allowing vCPUs to be added or removed at runtime to meet Kubernetes
demands.
On ARM64, only memory add/remove events are handled. Here's why:
1. Physical CPU hotplug: Not supported on ARM64 hardware.
2. ACPI vCPU hotplug (KVM virtual machine):
- vCPU hotplug is implemented as a static firmware policy where all
possible vCPUs are pre-described in the MADT table at boot.
- The vCPU status will be automatically updated after vCPU hotplug.
- No FDT or elfcorehdr update needed.
3. Device tree booted Virtual Machine vCPU hotplug:
- The elfcorehdr is built using for_each_possible_cpu(), so it
already includes all possible CPUs and doesn't need updates.
For memory add/remove events, the elfcorehdr is updated to reflect
the current memory layout.
This patch adds the ARCH_SUPPORTS_CRASH_HOTPLUG config option and
implements:
- arch_crash_hotplug_support(): Check if hotplug update is supported
- arch_crash_get_elfcorehdr_size(): Return elfcorehdr buffer size
- arch_crash_handle_hotplug_event(): Handle memory hotplug events
This follows the same approach as x86 commit
ea53ad9cf73b ("x86/crash: add x86 crash hotplug support") and powerpc
commit b741092d5976 ("powerpc/crash: add crash CPU hotplug support")
and commit 849599b702ef ("powerpc/crash: add crash memory hotplug
support").
The test is based on the following QEMU version:
https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v2
Replace your '-smp' argument with something like:
| -smp cpus=1,maxcpus=3,cores=3,threads=1,sockets=1
then feed the following to the Qemu montior to hotplug vCPU;
| (qemu) device_add driver=host-arm-cpu,core-id=1,id=cpu1
| (qemu) device_del cpu1
feed the following to the Qemu montior to hotplug memory;
| (qemu) object_add memory-backend-ram,id=mem1,size=256M
| (qemu) device_add pc-dimm,id=dimm1,memdev=mem1
| (qemu) device_del dimm1
The qemu startup configuration is as follows:
qemu-system-aarch64 \
-M virt,gic-version=3,acpi=on,highmem=on \
-enable-kvm \
-cpu host \
-kernel Image \
-smp cpus=1,maxcpus=3,cores=3,threads=1,sockets=1 \
-bios /usr/share/edk2/aarch64/QEMU_EFI.fd \
-m 2G,slots=64,maxmem=16G \
-nographic \
-no-reboot \
-device virtio-rng-pci \
-append "root=/dev/vda rw console=ttyAMA0 kgdboc=ttyAMA0,115200 \
earlycon acpi=on crashkernel=512M" \
-drive if=none,file=images/rootfs.ext4,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. Only kexec_file_load syscall way is tested now.
This patch is based on following rework:
https://lore.kernel.org/all/20260328074013.3589544-1-ruanjinjie@huawei.com/
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Breno Leitao <leitao@debian.org>
Cc: Kees Cook <kees@kernel.org>
[1]: https://lore.kernel.org/all/20240529133446.28446-1-Jonathan.Cameron@huawei.com/
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/kexec.h | 11 +++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/crash.c | 125 +++++++++++++++++++++++++
arch/arm64/kernel/machine_kexec_file.c | 23 ++++-
5 files changed, 161 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/kernel/crash.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fe60738e5943..9091c67e1cc2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1609,6 +1609,9 @@ config ARCH_DEFAULT_CRASH_DUMP
config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
def_bool CRASH_RESERVE
+config ARCH_SUPPORTS_CRASH_HOTPLUG
+ def_bool y
+
config TRANS_TABLE
def_bool y
depends on HIBERNATION || KEXEC_CORE
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index cc2f36b1b0d4..f338d162dec1 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -131,6 +131,17 @@ extern int load_other_segments(struct kimage *image,
extern int prepare_elf_headers(void **addr, unsigned long *sz);
#endif
+#ifdef CONFIG_CRASH_HOTPLUG
+void arch_crash_handle_hotplug_event(struct kimage *image, void *arg);
+#define arch_crash_handle_hotplug_event arch_crash_handle_hotplug_event
+
+int arch_crash_hotplug_support(struct kimage *image, unsigned long kexec_flags);
+#define arch_crash_hotplug_support arch_crash_hotplug_support
+
+unsigned int arch_crash_get_elfcorehdr_size(void);
+#define crash_get_elfcorehdr_size arch_crash_get_elfcorehdr_size
+#endif
+
#endif /* __ASSEMBLER__ */
#endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 74b76bb70452..629e962813ab 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_image.o
obj-$(CONFIG_ARM64_RELOC_TEST) += arm64-reloc-test.o
arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
+obj-$(CONFIG_CRASH_HOTPLUG) += crash.o
obj-$(CONFIG_VMCORE_INFO) += vmcore_info.o
obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
obj-$(CONFIG_ARM64_PTR_AUTH) += pointer_auth.o
diff --git a/arch/arm64/kernel/crash.c b/arch/arm64/kernel/crash.c
new file mode 100644
index 000000000000..2114375820da
--- /dev/null
+++ b/arch/arm64/kernel/crash.c
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Architecture specific functions for kexec based crash dumps.
+ */
+
+#define pr_fmt(fmt) "crash hp: " fmt
+
+#include <linux/kexec.h>
+#include <linux/elf.h>
+#include <linux/vmalloc.h>
+#include <linux/crash_core.h>
+
+#include <asm/kexec.h>
+
+#ifdef CONFIG_CRASH_HOTPLUG
+
+int arch_crash_hotplug_support(struct kimage *image, unsigned long kexec_flags)
+{
+#ifdef CONFIG_KEXEC_FILE
+ if (image->file_mode)
+ return 1;
+#endif
+ /*
+ * For kexec_load syscall, crash hotplug support requires
+ * KEXEC_CRASH_HOTPLUG_SUPPORT flag to be passed by userspace.
+ */
+ return kexec_flags & KEXEC_CRASH_HOTPLUG_SUPPORT;
+}
+
+unsigned int arch_crash_get_elfcorehdr_size(void)
+{
+ unsigned int phdr_cnt;
+
+ /* A program header for possible CPUs, vmcoreinfo and kernel_map */
+ phdr_cnt = 2 + num_possible_cpus();
+ if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
+ phdr_cnt += CONFIG_CRASH_MAX_MEMORY_RANGES;
+
+ return sizeof(Elf64_Ehdr) + phdr_cnt * sizeof(Elf64_Phdr);
+}
+
+/**
+ * update_crash_elfcorehdr() - Recreate the elfcorehdr and replace it with old
+ * elfcorehdr in the kexec segment array.
+ * @image: the active struct kimage
+ */
+static void update_crash_elfcorehdr(struct kimage *image)
+{
+ void *elfbuf = NULL, *old_elfcorehdr;
+ unsigned long mem, memsz;
+ unsigned long elfsz = 0;
+
+ /*
+ * Create the new elfcorehdr reflecting the changes to CPU and/or
+ * memory resources.
+ */
+ if (crash_prepare_headers(true, &elfbuf, &elfsz, NULL)) {
+ pr_err("unable to create new elfcorehdr");
+ goto out;
+ }
+
+ /*
+ * Obtain address and size of the elfcorehdr segment, and
+ * check it against the new elfcorehdr buffer.
+ */
+ mem = image->segment[image->elfcorehdr_index].mem;
+ memsz = image->segment[image->elfcorehdr_index].memsz;
+ if (elfsz > memsz) {
+ pr_err("update elfcorehdr elfsz %lu > memsz %lu",
+ elfsz, memsz);
+ goto out;
+ }
+
+ /*
+ * Copy new elfcorehdr over the old elfcorehdr at destination.
+ */
+ old_elfcorehdr = (void *)__va(mem);
+ if (!old_elfcorehdr) {
+ pr_err("mapping elfcorehdr segment failed\n");
+ goto out;
+ }
+
+ /*
+ * Temporarily invalidate the crash image while the
+ * elfcorehdr is updated.
+ */
+ xchg(&kexec_crash_image, NULL);
+ memcpy_flushcache(old_elfcorehdr, elfbuf, elfsz);
+ xchg(&kexec_crash_image, image);
+ pr_debug("updated elfcorehdr\n");
+
+out:
+ vfree(elfbuf);
+}
+
+/**
+ * arch_crash_handle_hotplug_event() - Handle hotplug elfcorehdr changes
+ * @image: a pointer to kexec_crash_image
+ * @arg: struct memory_notify handler for memory hotplug case and
+ * NULL for CPU hotplug case.
+ *
+ * Update the kdump image based on the type of hotplug event:
+ * - CPU add and remove: No action is needed.
+ * - Memory add/remove: Update the elfcorehdr to reflect the current memory layout.
+ *
+ * Prepare the new elfcorehdr and replace the existing elfcorehdr.
+ */
+void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
+{
+ switch (image->hp_action) {
+ case KEXEC_CRASH_HP_ADD_CPU:
+ fallthrough;
+ case KEXEC_CRASH_HP_REMOVE_CPU:
+ if (image->file_mode || image->elfcorehdr_updated)
+ return;
+ fallthrough;
+ case KEXEC_CRASH_HP_ADD_MEMORY:
+ case KEXEC_CRASH_HP_REMOVE_MEMORY:
+ update_crash_elfcorehdr(image);
+ return;
+ default:
+ pr_warn_once("Unknown hotplug action\n");
+ }
+}
+#endif /* CONFIG_CRASH_HOTPLUG */
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index d2985ce62306..781febd0f6db 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -82,10 +82,11 @@ int load_other_segments(struct kimage *image,
char *cmdline, void *headers,
unsigned long headers_sz)
{
- struct kexec_buf kbuf = {};
- void *dtb = NULL;
unsigned long initrd_load_addr = 0, dtb_len,
orig_segments = image->nr_segments;
+ struct kexec_buf kbuf = {};
+ unsigned long pnum = 0;
+ void *dtb = NULL;
int ret = 0;
kbuf.image = image;
@@ -98,6 +99,23 @@ int load_other_segments(struct kimage *image,
kbuf.bufsz = headers_sz;
kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
kbuf.memsz = headers_sz;
+
+#ifdef CONFIG_CRASH_HOTPLUG
+ /*
+ * The elfcorehdr segment size accounts for VMCOREINFO, kernel_map
+ * maximum CPUs and maximum memory ranges.
+ */
+ if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
+ pnum = 2 + num_possible_cpus() + CONFIG_CRASH_MAX_MEMORY_RANGES;
+ else
+ pnum += 2 + num_possible_cpus();
+
+ if (pnum < (unsigned long)PN_XNUM)
+ kbuf.memsz = pnum * sizeof(Elf64_Phdr) + sizeof(Elf64_Ehdr);
+ else
+ pr_err("number of Phdrs %lu exceeds max\n", pnum);
+#endif
+
kbuf.buf_align = SZ_64K; /* largest supported page size */
kbuf.buf_max = ULONG_MAX;
kbuf.top_down = true;
@@ -108,6 +126,7 @@ int load_other_segments(struct kimage *image,
goto out_err;
}
image->elf_load_addr = kbuf.mem;
+ image->elf_headers_sz = kbuf.memsz;
kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
--
2.34.1
^ permalink raw reply related
* [PATCH v14 16/17] riscv: kexec: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-05-25 8:49 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
feng.tang, dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers,
paulmck, thuth, ardb, masahiroy, mark.rutland, maz, james.morse,
leitao, sourabhjain, yeoreum.yun, coxu, jbohac, ryan.roberts,
cfsworks, tangyouling, ritesh.list, songshuaishuai, junhui.liu,
vishal.moola, kas, debug, namcao, liaoyuanhong, fuqiang.wang,
seanjc, guoren, chenjiahao16, hbathini, bgwin, takahiro.akashi,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260525084932.934910-1-ruanjinjie@huawei.com>
Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the
crashkernel= command line option") and commit ab475510e042 ("kdump:
implement reserve_crashkernel_cma") added CMA support for kdump
crashkernel reservation. This allows the kernel to dynamically allocate
contiguous memory for crash dumping when needed, rather than permanently
reserving a fixed region at boot time.
So extend crashkernel CMA reservation support to riscv. The following
changes are made to enable CMA reservation:
- Parse and obtain the CMA reservation size along with other crashkernel
parameters.
- Call reserve_crashkernel_cma() to allocate the CMA region for kdump.
- Include the CMA-reserved ranges for kdump kernel to use, which was
already done in of_kexec_alloc_and_setup_fdt().
- Exclude the CMA-reserved ranges from the crash kernel memory to
prevent them from being exported through /proc/vmcore, which was
already done in the crash core.
Update kernel-parameters.txt to document CMA support for crashkernel on
riscv architecture.
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: Paul Walmsley <pjw@kernel.org> # arch/riscv
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++--------
arch/riscv/kernel/machine_kexec_file.c | 2 +-
arch/riscv/mm/init.c | 5 +++--
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 52742fab49a9..3ff3ddd516cf 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1119,14 +1119,14 @@ Kernel parameters
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
crashkernel=size[KMG],cma
- [KNL, X86, ARM64, PPC] Reserve additional crash kernel memory from
- CMA. This reservation is usable by the first system's
- userspace memory and kernel movable allocations (memory
- balloon, zswap). Pages allocated from this memory range
- will not be included in the vmcore so this should not
- be used if dumping of userspace memory is intended and
- it has to be expected that some movable kernel pages
- may be missing from the dump.
+ [KNL, X86, ARM64, RISCV, PPC] Reserve additional crash
+ kernel memory from CMA. This reservation is usable by
+ the first system's userspace memory and kernel movable
+ allocations (memory balloon, zswap). Pages allocated
+ from this memory range will not be included in the vmcore
+ so this should not be used if dumping of userspace memory
+ is intended and it has to be expected that some movable
+ kernel pages may be missing from the dump.
A standard crashkernel reservation, as described above,
is still needed to hold the crash kernel and initrd.
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index d2bb61a8b6b6..075acf222fc0 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -46,7 +46,7 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
unsigned int arch_get_system_nr_ranges(void)
{
- unsigned int nr_ranges = 2; /* For exclusion of crashkernel region */
+ unsigned int nr_ranges = 2 + crashk_cma_cnt; /* For exclusion of crashkernel region */
walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index decd7df40fa4..c848454b8349 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -1295,7 +1295,7 @@ static inline void setup_vm_final(void)
*/
static void __init arch_reserve_crashkernel(void)
{
- unsigned long long low_size = 0;
+ unsigned long long low_size = 0, cma_size = 0;
unsigned long long crash_base, crash_size;
bool high = false;
int ret;
@@ -1305,11 +1305,12 @@ static void __init arch_reserve_crashkernel(void)
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
&crash_size, &crash_base,
- &low_size, NULL, &high);
+ &low_size, &cma_size, &high);
if (ret)
return;
reserve_crashkernel_generic(crash_size, crash_base, low_size, high);
+ reserve_crashkernel_cma(cma_size);
}
void __init paging_init(void)
--
2.34.1
^ permalink raw reply related
* [PATCH v14 15/17] arm64: kexec: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-05-25 8:49 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
feng.tang, dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers,
paulmck, thuth, ardb, masahiroy, mark.rutland, maz, james.morse,
leitao, sourabhjain, yeoreum.yun, coxu, jbohac, ryan.roberts,
cfsworks, tangyouling, ritesh.list, songshuaishuai, junhui.liu,
vishal.moola, kas, debug, namcao, liaoyuanhong, fuqiang.wang,
seanjc, guoren, chenjiahao16, hbathini, bgwin, takahiro.akashi,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260525084932.934910-1-ruanjinjie@huawei.com>
Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the
crashkernel= command line option") and commit ab475510e042 ("kdump:
implement reserve_crashkernel_cma") added CMA support for kdump
crashkernel reservation.
Crash kernel memory reservation wastes production resources if too
large, risks kdump failure if too small, and faces allocation difficulties
on fragmented systems due to contiguous block constraints. The new
CMA-based crashkernel reservation scheme splits the "large fixed
reservation" into a "small fixed region + large CMA dynamic region": the
CMA memory is available to userspace during normal operation to avoid
waste, and is reclaimed for kdump upon crash—saving memory while
improving reliability.
So extend crashkernel CMA reservation support to arm64. The following
changes are made to enable CMA reservation:
- Parse and obtain the CMA reservation size along with other crashkernel
parameters.
- Call reserve_crashkernel_cma() to allocate the CMA region for kdump.
- Include the CMA-reserved ranges for kdump kernel to use.
- Exclude the CMA-reserved ranges from the crash kernel memory to
prevent them from being exported through /proc/vmcore, which is already
done in the crash core.
Update kernel-parameters.txt to document CMA support for crashkernel on
arm64 architecture.
Tested-by: Breno Leitao <leitao@debian.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
v7:
- Correct the inclusion of CMA-reserved ranges for kdump
kernel in of/kexec.
v3:
- Add Acked-by.
v2:
- Free cmem in prepare_elf_headers()
- Add the mtivation.
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/arm64/kernel/machine_kexec_file.c | 2 +-
arch/arm64/mm/init.c | 5 +++--
drivers/of/fdt.c | 9 +++++----
drivers/of/kexec.c | 9 +++++++++
include/linux/crash_reserve.h | 4 +++-
6 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 4d0f545fb3ec..52742fab49a9 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1119,7 +1119,7 @@ Kernel parameters
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
crashkernel=size[KMG],cma
- [KNL, X86, ppc] Reserve additional crash kernel memory from
+ [KNL, X86, ARM64, PPC] Reserve additional crash kernel memory from
CMA. This reservation is usable by the first system's
userspace memory and kernel movable allocations (memory
balloon, zswap). Pages allocated from this memory range
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 66fbfbaec1c6..d2985ce62306 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -42,7 +42,7 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
#ifdef CONFIG_CRASH_DUMP
unsigned int arch_get_system_nr_ranges(void)
{
- unsigned int nr_ranges = 2; /* for exclusion of crashkernel region */
+ unsigned int nr_ranges = 2 + crashk_cma_cnt; /* for exclusion of crashkernel region */
phys_addr_t start, end;
u64 i;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 97987f850a33..227f58522dad 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -96,8 +96,8 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit;
static void __init arch_reserve_crashkernel(void)
{
+ unsigned long long crash_base, crash_size, cma_size = 0;
unsigned long long low_size = 0;
- unsigned long long crash_base, crash_size;
bool high = false;
int ret;
@@ -106,11 +106,12 @@ static void __init arch_reserve_crashkernel(void)
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
&crash_size, &crash_base,
- &low_size, NULL, &high);
+ &low_size, &cma_size, &high);
if (ret)
return;
reserve_crashkernel_generic(crash_size, crash_base, low_size, high);
+ reserve_crashkernel_cma(cma_size);
}
static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 82f7327c59ea..0470acbd1fcf 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -880,11 +880,12 @@ static unsigned long chosen_node_offset = -FDT_ERR_NOTFOUND;
/*
* The main usage of linux,usable-memory-range is for crash dump kernel.
* Originally, the number of usable-memory regions is one. Now there may
- * be two regions, low region and high region.
- * To make compatibility with existing user-space and older kdump, the low
- * region is always the last range of linux,usable-memory-range if exist.
+ * be 2 + CRASHK_CMA_RANGES_MAX regions, low region, high region and cma
+ * regions. To make compatibility with existing user-space and older kdump,
+ * the high and low region are always the first two ranges of
+ * linux,usable-memory-range if exist.
*/
-#define MAX_USABLE_RANGES 2
+#define MAX_USABLE_RANGES (2 + CRASHK_CMA_RANGES_MAX)
/**
* early_init_dt_check_for_usable_mem_range - Decode usable memory range
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index b6837e299e7f..029903b986cb 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -458,6 +458,15 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
if (ret)
goto out;
}
+
+ for (int i = 0; i < crashk_cma_cnt; i++) {
+ ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
+ "linux,usable-memory-range",
+ crashk_cma_ranges[i].start,
+ crashk_cma_ranges[i].end - crashk_cma_ranges[i].start + 1);
+ if (ret)
+ goto out;
+ }
#endif
}
diff --git a/include/linux/crash_reserve.h b/include/linux/crash_reserve.h
index f0dc03d94ca2..30864d90d7f5 100644
--- a/include/linux/crash_reserve.h
+++ b/include/linux/crash_reserve.h
@@ -14,9 +14,11 @@
extern struct resource crashk_res;
extern struct resource crashk_low_res;
extern struct range crashk_cma_ranges[];
+
+#define CRASHK_CMA_RANGES_MAX 4
#if defined(CONFIG_CMA) && defined(CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION)
#define CRASHKERNEL_CMA
-#define CRASHKERNEL_CMA_RANGES_MAX 4
+#define CRASHKERNEL_CMA_RANGES_MAX (CRASHK_CMA_RANGES_MAX)
extern int crashk_cma_cnt;
#else
#define crashk_cma_cnt 0
--
2.34.1
^ permalink raw reply related
* [PATCH v14 14/17] crash: Use crash_exclude_core_ranges() on powerpc
From: Jinjie Ruan @ 2026-05-25 8:49 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
feng.tang, dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers,
paulmck, thuth, ardb, masahiroy, mark.rutland, maz, james.morse,
leitao, sourabhjain, yeoreum.yun, coxu, jbohac, ryan.roberts,
cfsworks, tangyouling, ritesh.list, songshuaishuai, junhui.liu,
vishal.moola, kas, debug, namcao, liaoyuanhong, fuqiang.wang,
seanjc, guoren, chenjiahao16, hbathini, bgwin, takahiro.akashi,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260525084932.934910-1-ruanjinjie@huawei.com>
The crash memory exclude of crashk_res and crashk_cma memory on powerpc
are almost identical to the generic crash_exclude_core_ranges().
By introducing the architecture-specific arch_crash_exclude_mem_range()
function with a default implementation of crash_exclude_mem_range(),
and using crash_exclude_mem_range_guarded as powerpc's separate
implementation, the generic crash_exclude_core_ranges() helper function
can be reused.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/include/asm/kexec_ranges.h | 3 ---
arch/powerpc/kexec/crash.c | 2 +-
arch/powerpc/kexec/ranges.c | 16 ++++------------
include/linux/crash_core.h | 4 ++++
kernel/crash_core.c | 19 +++++++++++++------
5 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec_ranges.h b/arch/powerpc/include/asm/kexec_ranges.h
index ad95e3792d10..8489e844b447 100644
--- a/arch/powerpc/include/asm/kexec_ranges.h
+++ b/arch/powerpc/include/asm/kexec_ranges.h
@@ -7,9 +7,6 @@
void sort_memory_ranges(struct crash_mem *mrngs, bool merge);
struct crash_mem *realloc_mem_ranges(struct crash_mem **mem_ranges);
int add_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
-int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
- unsigned long long mstart,
- unsigned long long mend);
int get_exclude_memory_ranges(struct crash_mem **mem_ranges);
int get_reserved_memory_ranges(struct crash_mem **mem_ranges);
int get_crash_memory_ranges(struct crash_mem **mem_ranges);
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index d634db67becc..775895f31037 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -513,7 +513,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
base_addr = PFN_PHYS(mn->start_pfn);
size = mn->nr_pages * PAGE_SIZE;
end = base_addr + size - 1;
- ret = crash_exclude_mem_range_guarded(&cmem, base_addr, end);
+ ret = arch_crash_exclude_mem_range(&cmem, base_addr, end);
if (ret) {
pr_err("Failed to remove hot-unplugged memory from crash memory ranges\n");
goto out;
diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c
index 6c58bcc3e130..e5fea23b191b 100644
--- a/arch/powerpc/kexec/ranges.c
+++ b/arch/powerpc/kexec/ranges.c
@@ -553,9 +553,9 @@ int get_usable_memory_ranges(struct crash_mem **mem_ranges)
#endif /* CONFIG_KEXEC_FILE */
#ifdef CONFIG_CRASH_DUMP
-int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
- unsigned long long mstart,
- unsigned long long mend)
+int arch_crash_exclude_mem_range(struct crash_mem **mem_ranges,
+ unsigned long long mstart,
+ unsigned long long mend)
{
struct crash_mem *tmem = *mem_ranges;
@@ -604,18 +604,10 @@ int get_crash_memory_ranges(struct crash_mem **mem_ranges)
sort_memory_ranges(*mem_ranges, true);
}
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range_guarded(mem_ranges, crashk_res.start, crashk_res.end);
+ ret = crash_exclude_core_ranges(mem_ranges);
if (ret)
goto out;
- for (i = 0; i < crashk_cma_cnt; ++i) {
- ret = crash_exclude_mem_range_guarded(mem_ranges, crashk_cma_ranges[i].start,
- crashk_cma_ranges[i].end);
- if (ret)
- goto out;
- }
-
/*
* FIXME: For now, stay in parity with kexec-tools but if RTAS/OPAL
* regions are exported to save their context at the time of
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index d69c4c7c1f5e..0f4ea7ffd066 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -63,6 +63,7 @@ extern int crash_prepare_headers(int need_kernel_map, void **addr,
unsigned long *sz, unsigned long *nr_mem_ranges);
extern int crash_prepare_headers_locked(int need_kernel_map, void **addr,
unsigned long *sz, unsigned long *nr_mem_ranges);
+extern int crash_exclude_core_ranges(struct crash_mem **cmem);
struct kimage;
struct kexec_segment;
@@ -83,6 +84,9 @@ extern int kimage_crash_copy_vmcoreinfo(struct kimage *image);
extern unsigned int arch_get_system_nr_ranges(void);
extern int arch_crash_populate_cmem(struct crash_mem *cmem);
extern int arch_crash_exclude_ranges(struct crash_mem *cmem);
+extern int arch_crash_exclude_mem_range(struct crash_mem **mem,
+ unsigned long long mstart,
+ unsigned long long mend);
#else /* !CONFIG_CRASH_DUMP*/
struct pt_regs;
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index e84f3b63e79d..33e945da6776 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -286,24 +286,31 @@ unsigned int __weak arch_get_system_nr_ranges(void) { return 0; }
int __weak arch_crash_populate_cmem(struct crash_mem *cmem) { return -1; }
int __weak arch_crash_exclude_ranges(struct crash_mem *cmem) { return 0; }
-static int crash_exclude_core_ranges(struct crash_mem *cmem)
+int __weak arch_crash_exclude_mem_range(struct crash_mem **mem,
+ unsigned long long mstart,
+ unsigned long long mend)
+{
+ return crash_exclude_mem_range(*mem, mstart, mend);
+}
+
+int crash_exclude_core_ranges(struct crash_mem **cmem)
{
int ret, i;
/* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
+ ret = arch_crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
if (ret)
return ret;
if (crashk_low_res.end) {
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
+ ret = arch_crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
if (ret)
return ret;
}
for (i = 0; i < crashk_cma_cnt; ++i) {
- ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
- crashk_cma_ranges[i].end);
+ ret = arch_crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
+ crashk_cma_ranges[i].end);
if (ret)
return ret;
}
@@ -330,7 +337,7 @@ int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
if (ret)
goto out;
- ret = crash_exclude_core_ranges(cmem);
+ ret = crash_exclude_core_ranges(&cmem);
if (ret)
goto out;
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox