* Re: [PATCH v2 3/3] powerpc/numa: Support coregroup on PowerNV
From: Ritesh Harjani @ 2026-07-10 5:48 UTC (permalink / raw)
To: Srikar Dronamraju, linuxppc-dev, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy, Naveen N Rao
Cc: skiboot, arbab, mahesh, chleroy, Srikar Dronamraju, linux-kernel
In-Reply-To: <20260605055242.1757485-8-srikar@linux.ibm.com>
Srikar Dronamraju <srikar@linux.ibm.com> writes:
> Coregroup support on powerpc has so far been limited to PowerVM LPARs.
> However, PowerNV can also support coregroups when firmware exposes the
> required coregroup information through the associativity hierarchy.
>
> Detect coregroup support by checking whether primary_domain_index is the
> penultimate domain in the CPU node's ibm,associativity property. On
> PowerNV, a non-penultimate primary_domain_index indicates that firmware
> provides an additional level for coregroup information.
>
> This keeps the logic compatible with PowerVM systems, where
> primary_domain_index is likewise not the penultimate associativity
> domain.
>
> Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
> ---
> Changelog from v1: https://lkml.kernel.org/r/20260524010017.140408-1-srikar@linux.ibm.com
> - Handle comments from Christophe Leroy; make code more flat
>
> arch/powerpc/mm/numa.c | 56 ++++++++++++++++++++++++++++++++++--------
> 1 file changed, 46 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 9aa71eb7e96b..e97b624203ea 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -889,12 +889,32 @@ static int __init numa_setup_drmem_lmb(struct drmem_lmb *lmb,
> return 0;
> }
>
> +/*
> + * If hierarchy extends beyond primary_domain_index + 1, then next
> + * level corresponds to coregroup.
> + */
> +static int detect_and_enable_coregroup(const __be32 *associativity, int index)
Do we care about it's return value? We are not reading that in the
patch.
this function is mainly only needed in __init, can we mark it so.
> +{
> + if (!associativity || index == -1)
> + goto out;
> +
> + index = of_read_number(associativity, 1);
> +
> + if (index > primary_domain_index + 1) {
> + coregroup_enabled = 1;
> + return index;
> + }
> +out:
> + coregroup_enabled = 0;
> + return -1;
> +}
For PowerVM, we now have two places which will enable coregroup_enabled
during mem_topology_setup(). Is there some way we can unify that?
This also means we enable coregroup in case of PowerVM with SPLPAR when
per-cpu VPHN associativity index > primary_domain_index+1. But this
isn't reflected in your commit msg. The commit msg only says this
affects PowerNV.
setup_arch
mem_topology_setup
parse_numa_properties
detect_and_enable_coregroup() {...
// coregroup_enabled = 0/1
index = of_read_number(associativity, 1);
if (index > primary_domain_index + 1) {
coregroup_enabled = 1;
return index;
}
}
<...>
find_possible_nodes() {...
prop_length /= sizeof(int);
if (prop_length > primary_domain_index + 2)
coregroup_enabled = 1;
}
> +
> static int __init parse_numa_properties(void)
> {
> struct device_node *memory, *pci;
> - int default_nid = 0;
> - unsigned long i;
> + int default_nid = 0, index = 0;
> const __be32 *associativity;
> + unsigned long i;
>
> if (numa_enabled == 0) {
> pr_warn("disabled by user\n");
> @@ -927,7 +947,6 @@ static int __init parse_numa_properties(void)
> */
> for_each_present_cpu(i) {
> __be32 vphn_assoc[VPHN_ASSOC_BUFSIZE];
> - struct device_node *cpu;
> int nid = NUMA_NO_NODE;
>
> memset(vphn_assoc, 0, VPHN_ASSOC_BUFSIZE * sizeof(__be32));
> @@ -935,7 +954,9 @@ static int __init parse_numa_properties(void)
> if (__vphn_get_associativity(i, vphn_assoc) == 0) {
> nid = associativity_to_nid(vphn_assoc);
> initialize_form1_numa_distance(vphn_assoc);
> + index = detect_and_enable_coregroup(vphn_assoc, index);
> } else {
> + struct device_node *cpu;
>
> /*
> * Don't fall back to default_nid yet -- we will plug
> @@ -948,6 +969,7 @@ static int __init parse_numa_properties(void)
> associativity = of_get_associativity(cpu);
> if (associativity) {
> nid = associativity_to_nid(associativity);
> + index = detect_and_enable_coregroup(associativity, index);
> initialize_form1_numa_distance(associativity);
> }
> of_node_put(cpu);
> @@ -1445,7 +1467,9 @@ static long vphn_get_associativity(unsigned long cpu,
>
> int cpu_to_coregroup_id(int cpu)
> {
> - __be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
> + int coregroup_id = cpu_to_core_id(cpu);
> + struct device_node *cpunode = NULL;
> + const __be32 *associativity;
> int index;
>
> if (cpu < 0 || cpu > nr_cpu_ids)
> @@ -1454,19 +1478,31 @@ int cpu_to_coregroup_id(int cpu)
> if (!coregroup_enabled)
> goto out;
>
> - if (!firmware_has_feature(FW_FEATURE_VPHN))
> - goto out;
> + if (firmware_has_feature(FW_FEATURE_VPHN)) {
> + __be32 tmp[VPHN_ASSOC_BUFSIZE] = {0};
>
> - if (vphn_get_associativity(cpu, associativity))
> + if (vphn_get_associativity(cpu, tmp))
> + goto out;
> +
> + associativity = tmp;
> +
> + } else {
> + cpunode = of_get_cpu_node(cpu, NULL);
> + if (!cpunode)
> + goto out;
> +
> + associativity = of_get_associativity(cpunode);
> + }
> + if (!associativity)
> goto out;
>
> index = of_read_number(associativity, 1);
> if (index > primary_domain_index + 1)
> - return of_read_number(&associativity[index - 1], 1);
> + coregroup_id = of_read_number(&associativity[index - 1], 1);
>
> out:
> - return cpu_to_core_id(cpu);
> -}
Looks like leftover removed from previous patch. This change should be
fixed in patch-2 itself.
> + if (cpunode)
> + of_node_put(cpunode);
>
> return coregroup_id;
> }
> --
> 2.43.0
-ritesh
^ permalink raw reply
* Re: ld.lld: error: relocation R_PPC_ADDR16_LO cannot be used against symbol 'init_task'; recompile with -fPIC
From: Feng Tang @ 2026-07-10 9:44 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), lkp
Cc: kernel test robot, linuxppc-dev, Nathan Chancellor,
Nick Desaulniers, clang-built-linux, oe-kbuild-all, linux-kernel,
Marek Szyprowski
In-Reply-To: <37fe4a15-e51b-411e-9667-a1c670f413e1@kernel.org>
On Fri, Jul 10, 2026 at 06:33:49AM +0200, Christophe Leroy (CS GROUP) wrote:
> + Clang
>
> Le 10/07/2026 à 04:51, Feng Tang a écrit :
> > Thanks for the report!
> >
> > Add Powerpc list.
>
> This is a Clang build with Clang linker, did you reproduce the problem with
> a normal GCC build ?
I tried the 'reproduce' provided by 0day bot, but it failed early:
/workspace/feng/ws2/projects/linux-2.6/Makefile:1244: C=1 specified, but sparse is not available or not up to date
Documentation/.renames.txt: warning: ignored by one of the .gitignore files
../arch/powerpc/lib/sstep.c:1346:31: error: variable 'rc' set but not used [-Werror,-Wunused-but-set-variable]
1346 | unsigned int opcode, ra, rb, rc, rd, spr, u;
| ^
../arch/powerpc/lib/sstep.c:1350:21: error: variable 'suffix' set but not used [-Werror,-Wunused-but-set-variable]
1350 | unsigned int word, suffix;
| ^
2 errors generated.
0day folks, could you help to check? thanks
> Thanks
> Christophe
>
> >
> > On Fri, Jul 10, 2026 at 06:18:50AM +0800, kernel test robot wrote:
> > > tree: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094863506%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fQm6QfsJ2ggaKoRJWCz4dsaquz7Wo3uhRnOexVUrTnQ%3D&reserved=0 master
> > > head: 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53
> > > commit: d5cae2261b86913e602452ce4a07e6aefc0f603b dma-contiguous: simplify numa cma area handling
> > > date: 6 weeks ago
> > > config: powerpc-randconfig-r133-20260709 (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdownload.01.org%2F0day-ci%2Farchive%2F20260710%2F202607100652.WPUlEAfx-lkp%40intel.com%2Fconfig&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094899182%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BkT0BYyJtniz6YPzGpYbO0jn2T7vBDBLaK2Tsh1LcnE%3D&reserved=0)
> > > compiler: clang version 21.1.8 (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094917538%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5%2BLVtRoojuNbhEMr3BhM2xF50PV%2FIYh%2FWw3ipDIWG%2FY%3D&reserved=0 2078da43e25a4623cab2d0d60decddf709aaea28)
> > > sparse: v0.6.5-rc1
> > > reproduce (this is a W=1 build): (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdownload.01.org%2F0day-ci%2Farchive%2F20260710%2F202607100652.WPUlEAfx-lkp%40intel.com%2Freproduce&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094935016%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BrpcCLuNecZIfyF6N5X%2FFcHhdG9YzLBAErvBGHyjjak%3D&reserved=0)
> >
> >
> > > All errors (new ones prefixed by >>):
> > >
> > > > > ld.lld: error: relocation R_PPC_ADDR16_LO cannot be used against symbol 'init_task'; recompile with -fPIC
> > > >>> defined in vmlinux.a(init/init_task.o)
> > > >>> referenced by head_44x.S:101 (arch/powerpc/kernel/head_44x.S:101)
> > > >>> arch/powerpc/kernel/head_44x.o:(.head.text+0x42) in archive vmlinux.a
> > > --
> > > > > ld.lld: error: relocation R_PPC_ADDR16_HI cannot be used against symbol 'init_thread_union'; recompile with -fPIC
> > > >>> defined in ./arch/powerpc/kernel/vmlinux.lds:133
> > > >>> referenced by head_44x.S:108 (arch/powerpc/kernel/head_44x.S:108)
> > > >>> arch/powerpc/kernel/head_44x.o:(.head.text+0x4e) in archive vmlinux.a
> >
> > I checked the patch and couldn't find obvious clue between the patch and
> > the error.
> >
> > commit d5cae2261b8691 only changes kernel/dma/contiguous.c, which is under
> > CONFIG_DMA_CMA per kernel/dma/Makefile. In your config above, CONFIG_DMA_CMA
> > is not even set, so the contigous.c should not be compiled. Could you help
> > to double check? thanks!
> >
> > - Feng
> >
> > > Kconfig warnings: (for reference only)
> > > WARNING: unmet direct dependencies detected for HOTPLUG_CPU
> > > Depends on [n]: SMP [=y] && (PPC_PSERIES [=n] || PPC_PMAC [=n] || PPC_POWERNV [=n] || FSL_SOC_BOOKE [=n])
> > > Selected by [y]:
> > > - PM_SLEEP_SMP [=y] && SMP [=y] && (ARCH_SUSPEND_POSSIBLE [=y] || ARCH_HIBERNATION_POSSIBLE [=y]) && PM_SLEEP [=y]
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fintel%2Flkp-tests%2Fwiki&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094952205%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sqz%2BJ2dpT3ZZjlQyyvAhgPdP9jS0kJLpbRKTcV4rM50%3D&reserved=0
> >
^ permalink raw reply
* Re: [PATCH v8] mm: pgtable: free kernel page tables via RCU to fix ptdump UAF
From: David CARLIER @ 2026-07-10 9:33 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Dev Jain, David Hildenbrand, Liam R . Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Dave Hansen, Lu Baolu, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Ritesh Harjani,
syzbot+fd95a72470f5a44e464c, linux-mm, linux-kernel, linux-riscv,
linuxppc-dev
In-Reply-To: <alC3HqLVTBA92Prx@lucifer>
Hi Lorenzo,
On Fri, 10 Jul 2026 at 10:13, Lorenzo Stoakes <ljs@kernel.org> wrote:
>
> On Tue, Jul 07, 2026 at 06:08:49PM +0100, David CARLIER wrote:
> > Sure thing :)
> >
> > On Tue, 7 Jul 2026 at 16:19, Lorenzo Stoakes <ljs@kernel.org> wrote:
> > >
> > > Hi David C,
> > >
> > > This has been through a lot of revisions so I think for the sake of expediency
> > > the best solution here is for me to grab this and fiddle with it a bit then post
> > > it out myself.
> > >
> > > TO BE VERY CLEAR - I will keep your authorship and attribution :), and simply
> > > stick my name on a Co-developed-by tag.
> > >
> > > So this will remain your patch.
>
> Apologies, but the approach I'm taking is very significantly different so it
> would be problematic in terms of patch provenance to do this :(
>
> I will make sure to credit you directly in the commit message so there is proper
> attribution, this patch and follow up stuff has grown a lot (been working on it
> all of yesterday afternoon/evening + this morning) and need to ensure the stable
> stuff is backported etc.
>
> Thanks for your contributions here, very much appreciated, and sorry to have
> messed you about on this!
>
> Cheers, Lorenzo
No worries I understand.
Cheers !
^ permalink raw reply
* Re: [PATCH v8] mm: pgtable: free kernel page tables via RCU to fix ptdump UAF
From: Lorenzo Stoakes @ 2026-07-10 9:12 UTC (permalink / raw)
To: David CARLIER
Cc: Andrew Morton, Dev Jain, David Hildenbrand, Liam R . Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Dave Hansen, Lu Baolu, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Ritesh Harjani,
syzbot+fd95a72470f5a44e464c, linux-mm, linux-kernel, linux-riscv,
linuxppc-dev
In-Reply-To: <CA+XhMqzvFtLq1OT-qh207aJhSf+okdE8o8Joe8e_KBvdCjcQfQ@mail.gmail.com>
On Tue, Jul 07, 2026 at 06:08:49PM +0100, David CARLIER wrote:
> Sure thing :)
>
> On Tue, 7 Jul 2026 at 16:19, Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > Hi David C,
> >
> > This has been through a lot of revisions so I think for the sake of expediency
> > the best solution here is for me to grab this and fiddle with it a bit then post
> > it out myself.
> >
> > TO BE VERY CLEAR - I will keep your authorship and attribution :), and simply
> > stick my name on a Co-developed-by tag.
> >
> > So this will remain your patch.
Apologies, but the approach I'm taking is very significantly different so it
would be problematic in terms of patch provenance to do this :(
I will make sure to credit you directly in the commit message so there is proper
attribution, this patch and follow up stuff has grown a lot (been working on it
all of yesterday afternoon/evening + this morning) and need to ensure the stable
stuff is backported etc.
Thanks for your contributions here, very much appreciated, and sorry to have
messed you about on this!
Cheers, Lorenzo
^ permalink raw reply
* [PATCH v2] ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP
From: Chancel Liu @ 2026-07-10 7:08 UTC (permalink / raw)
To: shengjiu.wang, Xiubo.Lee, festevam, nicoleotsuka, lgirdwood,
broonie, perex, tiwai, linux-kernel, linuxppc-dev, linux-sound
From: Chancel Liu <chancel.liu@nxp.com>
When the BCLK divider ratio is 1:1, fsl_sai_set_bclk() enables bypass
mode by setting BYP, but never clears the bit. The BYP=1 value remains
in the regcache, and is restored by regcache_sync() on the next runtime
resume.
Since BYP=1 combined with BCD=1 immediately outputs the ungated MCLK
as BCLK without waiting for BCE/TE/RE to be enabled, the clock is
driven prematurely before the stream is fully configured, causing
noise on some codecs.
Fix this by clearing BYP and BCI in fsl_sai_hw_free() taking into
account sync mode and the opposite stream's state, so that the regcache
holds BYP=0 before runtime suspend and regcache_sync() on resume will
not restore bypass mode prematurely.
Fixes: a50b7926d015 ("ASoC: fsl_sai: implement 1:1 bclk:mclk ratio support")
Cc: stable@vger.kernel.org
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
Changes in v2:
- Move BYP/BCI clearing from fsl_sai_config_disable() (trigger path)
to fsl_sai_hw_free() to avoid breaking pause/suspend-resume cycles
where hw_params() is not called again on unpause/resume.
sound/soc/fsl/fsl_sai.c | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 9661602b53c5..d232c8f53061 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -808,6 +808,8 @@ static int fsl_sai_hw_free(struct snd_pcm_substream *substream,
struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
unsigned int ofs = sai->soc_data->reg_offset;
+ int adir = tx ? RX : TX;
+ int dir = tx ? TX : RX;
/* Clear xMR to avoid channel swap with mclk_with_tere enabled case */
regmap_write(sai->regmap, FSL_SAI_xMR(tx), 0);
@@ -815,10 +817,29 @@ static int fsl_sai_hw_free(struct snd_pcm_substream *substream,
regmap_update_bits(sai->regmap, FSL_SAI_xCR3(tx, ofs),
FSL_SAI_CR3_TRCE_MASK, 0);
- if (!sai->is_consumer_mode[tx] &&
- sai->mclk_streams & BIT(substream->stream)) {
- clk_disable_unprepare(sai->mclk_clk[sai->mclk_id[tx]]);
- sai->mclk_streams &= ~BIT(substream->stream);
+ if (!sai->is_consumer_mode[tx]) {
+ bool adir_active = !!(sai->mclk_streams & BIT(!substream->stream));
+ /*
+ * If opposite stream provides clocks for synchronous mode and
+ * it is inactive, Clear BYP and BCI
+ */
+ if (fsl_sai_dir_is_synced(sai, adir) && !adir_active)
+ regmap_update_bits(sai->regmap, FSL_SAI_xCR2(!tx, ofs),
+ FSL_SAI_CR2_BCI | FSL_SAI_CR2_BYP, 0);
+ /*
+ * Clear BYP and BCI of current stream if either of:
+ * 1. current stream doesn't provide clocks for synchronous mode
+ * 2. current stream provides clocks for synchronous mode but no
+ * more stream is active.
+ */
+ if (!fsl_sai_dir_is_synced(sai, dir) || !adir_active)
+ regmap_update_bits(sai->regmap, FSL_SAI_xCR2(tx, ofs),
+ FSL_SAI_CR2_BCI | FSL_SAI_CR2_BYP, 0);
+
+ if (sai->mclk_streams & BIT(substream->stream)) {
+ clk_disable_unprepare(sai->mclk_clk[sai->mclk_id[tx]]);
+ sai->mclk_streams &= ~BIT(substream->stream);
+ }
}
return 0;
--
2.50.1
^ permalink raw reply related
* Re: powerpc/kexec_file: print configured kernel command line
From: Mukesh Kumar Chaurasiya @ 2026-07-10 7:05 UTC (permalink / raw)
To: Sourabh Jain; +Cc: linuxppc-dev, Madhavan Srinivasan, Michael Ellerman
In-Reply-To: <20250725124438.327593-1-sourabhjain@linux.ibm.com>
On Fri, Jul 25, 2025 at 06:14:38PM +0530, Sourabh Jain wrote:
> Kexec with the -d option prints extra logs about the kexec/kdump kernel
> that help debug kexec and kdump. For example, it shows what kexec
> segments are loaded, their locations, and sizes.
>
> One key piece of information still missing is the kernel command line
> configured for the kexec/kdump kernel.
>
> With this patch included, the kernel will print the kernel command line
> configured for the kexec/kdump kernel as shown below:
>
> kexec --initrd=./initrd ./kernel -lspd --command-line="test1 test2"
>
> Loaded elf core header at 0x22e30000, bufsz=0x2000 memsz=0x80000
> kexec_elf: Command line: elfcorehdr=0x22e30000 test1 test2 <--- New
> kexec_elf: Loaded initrd at 0x22eb0000
>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
> arch/powerpc/kexec/elf_64.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
> index 5d6d616404cf..db0af790c784 100644
> --- a/arch/powerpc/kexec/elf_64.c
> +++ b/arch/powerpc/kexec/elf_64.c
> @@ -90,6 +90,8 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
> cmdline = modified_cmdline;
> }
>
> + kexec_dprintk("Command line: %s", cmdline ? cmdline : "");
> +
> if (initrd != NULL) {
> kbuf.buffer = initrd;
> kbuf.bufsz = kbuf.memsz = initrd_len;
> --
> 2.50.1
>
>
Tested this on P11 LPAR.
[ 485.755942] kexec_file: kernel: 00000000cb90aae7 kernel_size: 0x1d1531d0
[ 485.762870] kexec_elf: Loaded the kernel at 0x80000000
[ 485.762930] kexec_elf: Loaded purgatory at 0x9fff0000
[ 485.762944] Loaded the backup region at 0x84160000
[ 485.763088] crash_core: Crash PT_LOAD ELF header. phdr=00000000364832a7 vaddr=0xc000000000000000, paddr=0x0, sz=0x10000 e_phnum=178 p_offset=0x0
[ 485.763095] crash_core: Crash PT_LOAD ELF header. phdr=000000009122d5f0 vaddr=0xc000000000010000, paddr=0x10000, sz=0x7fff0000 e_phnum=179 p_offset=0x10000
[ 485.763099] crash_core: Crash PT_LOAD ELF header. phdr=000000007ead431b vaddr=0xc0000000a0000000, paddr=0xa0000000, sz=0xb10000000 e_phnum=180 p_offset=0xa0000000
[ 485.763103] crash_core: Crash PT_LOAD ELF header. phdr=0000000001ee8e6f vaddr=0xc000000bb0000000, paddr=0xbb0000000, sz=0x5d0000000 e_phnum=181 p_offset=0xbb0000000
[ 485.763108] crash_core: Crash PT_LOAD ELF header. phdr=000000004566b315 vaddr=0xc000001180000000, paddr=0x1180000000, sz=0x1d20000000 e_phnum=182 p_offset=0x1180000000
[ 485.763112] crash_core: Crash PT_LOAD ELF header. phdr=00000000a9df7c03 vaddr=0xc000002ea0000000, paddr=0x2ea0000000, sz=0x1d10000000 e_phnum=183 p_offset=0x2ea0000000
[ 485.763116] crash_core: Crash PT_LOAD ELF header. phdr=0000000077ee5d4c vaddr=0xc000004bb0000000, paddr=0x4bb0000000, sz=0x1d10000000 e_phnum=184 p_offset=0x4bb0000000
[ 485.763119] crash_core: Crash PT_LOAD ELF header. phdr=000000000ea82932 vaddr=0xc0000068c0000000, paddr=0x68c0000000, sz=0x1740000000 e_phnum=185 p_offset=0x68c0000000
[ 485.763124] Backup region offset updated to 0x84160000
[ 485.763130] Loaded elf core header at 0x84170000, bufsz=0x3000 memsz=0x80000
[ 485.763134] No dm-crypt keys
[ 485.763139] kexec_elf: Command line: elfcorehdr=0x84170000 BOOT_IMAGE=(ieee1275//vdevice/v-scsi@30000065/disk@8100000000000000,gpt2)/vmlinuz-6.19.7-200.fc43.ppc64le root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root crashkernel=512M@2G test1 test2
[ 485.763145] kexec_elf: Loaded initrd at 0x841f0000
[ 485.763678] Memory node path: /memory@0
[ 485.795492] kexec_elf: Loaded device tree at 0x9ffd0000
[ 486.417820] kexec_file: nr_segments = 6
[ 486.417839] kexec_file: segment[0]: buf=0x00000000ac04377b bufsz=0x3f74bc4 mem=0x80000000 memsz=0x4160000
[ 486.424367] kexec_file: segment[1]: buf=0x00000000b22938ec bufsz=0x310 mem=0x9fff0000 memsz=0x10000
[ 486.424403] kexec_file: segment[2]: buf=0x0000000043b34bd4 bufsz=0x10000 mem=0x84160000 memsz=0x10000
[ 486.424417] kexec_file: segment[3]: buf=0x00000000421e955d bufsz=0x3000 mem=0x84170000 memsz=0x80000
[ 486.424450] kexec_file: segment[4]: buf=0x000000009a7ce2c9 bufsz=0x4ed96f8 mem=0x841f0000 memsz=0x4ee0000
[ 486.432514] kexec_file: segment[5]: buf=0x0000000023a3b280 bufsz=0x1553b mem=0x9ffd0000 memsz=0x20000
[ 486.432558] kexec_file: kexec_file_load: type:1, start:0x9fff0000 head:0x4 flags:0xa
Tested-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
^ permalink raw reply
* [PATCH 1/2] powerpc/vdso: Add support for vDSO installation
From: Thomas Weißschuh @ 2026-07-10 6:14 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP)
Cc: linuxppc-dev, linux-kernel, Thomas Weißschuh
In-Reply-To: <20260710-powerpc-vdso-install-v1-0-3015af1aa354@linutronix.de>
From: Thomas Weißschuh <linux@weissschuh.net>
'make vdso_install' can install the unstripped vDSO files,
so that they can be shipped to the target system for debugging purposes.
Add the necessary variables so this also works on PowerPC.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
arch/powerpc/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a58b1029592c..78112e032c50 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -391,6 +391,9 @@ vdso_prepare: prepare0
$(build)=arch/powerpc/kernel/vdso include/generated/vdso64-offsets.h)
endif
+vdso-install-$(CONFIG_VDSO32) += arch/powerpc/kernel/vdso/vdso32.so.dbg
+vdso-install-$(CONFIG_PPC64) += arch/powerpc/kernel/vdso/vdso64.so.dbg
+
archprepare: checkbin
archheaders:
--
2.55.0
^ permalink raw reply related
* [PATCH 0/2] powerpc/vdso: Debugging improvements
From: Thomas Weißschuh @ 2026-07-10 6:14 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP)
Cc: linuxppc-dev, linux-kernel, Thomas Weißschuh,
Thomas Weißschuh
Make it possible to package the vDSO debug information and correlate it
with the vDSO mapped into processes.
Also see https://lore.kernel.org/lkml/20260708-vdso-sysfs-v1-1-fcd93385006d@linutronix.de/
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Thomas Weißschuh (2):
powerpc/vdso: Add support for vDSO installation
powerpc/vdso: Generate build IDs
arch/powerpc/Makefile | 3 +++
arch/powerpc/kernel/vdso/Makefile | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
---
base-commit: e891777067dc42e033906c23c0bd048b09202f49
change-id: 20260318-powerpc-vdso-install-847443f7712f
Best regards,
--
Thomas Weißschuh <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* [PATCH 2/2] powerpc/vdso: Generate build IDs
From: Thomas Weißschuh @ 2026-07-10 6:14 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP)
Cc: linuxppc-dev, linux-kernel, Thomas Weißschuh,
Thomas Weißschuh
In-Reply-To: <20260710-powerpc-vdso-install-v1-0-3015af1aa354@linutronix.de>
The build ID can be used to correlate a vDSO mapped into a process with
its debugging information.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
arch/powerpc/kernel/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile
index 368759f81708..18ef3057dfd0 100644
--- a/arch/powerpc/kernel/vdso/Makefile
+++ b/arch/powerpc/kernel/vdso/Makefile
@@ -45,7 +45,7 @@ ccflags-y += $(call cc-option, -fno-stack-protector)
ccflags-y += -DDISABLE_BRANCH_PROFILING
ccflags-y += -ffreestanding -fasynchronous-unwind-tables
ccflags-remove-y := $(CC_FLAGS_FTRACE)
-ldflags-y := -Wl,--hash-style=both -nostdlib -shared -z noexecstack $(CLANG_FLAGS)
+ldflags-y := -Wl,--hash-style=both -Wl,--build-id=sha1 -nostdlib -shared -z noexecstack $(CLANG_FLAGS)
ldflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
ldflags-$(CONFIG_LD_ORPHAN_WARN) += -Wl,--orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
--
2.55.0
^ permalink raw reply related
* Re: [PATCH 1/1] powerpc/crash: stop watchdogs before booting kdump kernel
From: Sourabh Jain @ 2026-07-10 6:08 UTC (permalink / raw)
To: Ritesh Harjani (IBM), linuxppc-dev, maddy, mpe
Cc: npiggin, chleroy, shivangu, hbathini, mahesh, adityag, venkat88,
stable, Mahesh Kumar G
In-Reply-To: <4ii8w2ex.ritesh.list@gmail.com>
On 09/07/26 22:01, Ritesh Harjani (IBM) wrote:
> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
>> On pseries LPAR systems, watchdog timers configured from userspace
>> can remain active after a kernel panic. During panic triggered crash
>> dump capture, the crashing kernel jumps directly to the kdump kernel
>> without shutting down userspace services. As a result, active
>> watchdogs are not stopped before entering the kdump kernel.
>>
>> If dump capture takes longer than the watchdog timeout, PHYP resets
>> the LPAR before dump collection completes, resulting in dump capture
>> failure.
>>
>> Fix this by issuing the H_WATCHDOG hcall on the crash shutdown path
>> to stop all active watchdogs before booting the kdump kernel.
>>
> Nice catch!
>
>> Fixes: 69472ffa6575 ("watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers")
>> Reported-by: Mahesh Kumar G <mahe657@linux.ibm.com>
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>> arch/powerpc/kexec/crash.c | 25 +++++++++++++++++++++++++
>> 1 file changed, 25 insertions(+)
>>
>> diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
>> index e6539f213b3d..5651523e3a70 100644
>> --- a/arch/powerpc/kexec/crash.c
>> +++ b/arch/powerpc/kexec/crash.c
>> @@ -28,6 +28,7 @@
>> #include <asm/interrupt.h>
>> #include <asm/kexec_ranges.h>
>> #include <asm/crashdump-ppc64.h>
>> +#include <asm/hvcall.h>
>>
> would be nice, if we could avoid papr specific header into common crash.c
>
>> /*
>> * The primary CPU waits a while for all secondary CPUs to enter. This is to
>> @@ -352,6 +353,28 @@ int crash_shutdown_unregister(crash_shutdown_t handler)
>> }
>> EXPORT_SYMBOL(crash_shutdown_unregister);
>>
>> +/**
>> + * stop_watchdogs - Stop active watchdogs before entering kdump kernel
>> + * On pseries LPAR systems, watchdogs configured from userspace remain
>> + * active after a kernel panic because userspace services are not shut
>> + * down on the kdump crash path. If a watchdog expires while the kdump
>> + * kernel is collecting the dump, PHYP resets the LPAR and dump capture
>> + * fails
>> + *
>> + * 0x200UL : watchdog stop operation
>> + * -1 : watchdog number, disable all watchdogs
>> + */
>> +static void stop_watchdogs(void)
>> +{
>> + if (firmware_has_feature(FW_FEATURE_LPAR)) {
>> + int rc;
> ditto.
> Also I guess this could be FW_FEATURE_WATCHDOG
>
>> +
>> + rc = plpar_hcall_norets_notrace(H_WATCHDOG, 0x200UL, -1);
> - 0x200 is hardcoded.
> - -1 is hardcoded.
> - I think it's return value is long.
>
>> + if (rc != H_SUCCESS && rc != H_NOOP)
>> + pr_warn("crash: failed to stop watchdogs\n");
> Let's print rc as well.
>
>> + }
>> +}
>> +
> Looking at the code, we already have a mechanism to register a crash
> shutdown handler which anyways is getting called from
> default_machine_crash_shutdown(). So, I think we could use this generic
> crash handler register mechanism and keep the wdt specific calls within
> pseries/setup.c file...
That's a good idea. I wasn't aware of this crash handler.
The main reason I wanted to stop the watchdog as soon as the kernel
enters the architecture-specific crash code is that, on PowerPC, the
crash path sends IPIs to all other CPUs and waits for their response
before continuing. Because of this, I thought it would be better to
stop the watchdog as early as possible.
I knew there was an IPI timeout, but I just checked and it's set to
10 seconds. See crash_kexec_prepare_cpus() in crash.c.
The crash handler is called after the IPI wait. So, in theory, the watchdog
timeout could occur before the IPI timeout. But I think that's a very
unlikely
scenario, though. So I think disabling the watchdog from the crash handler
is a reasonable approach.
Please share your thoughts.
>
> ...How about something like this?
>
> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
> index 50b26ed8432d..4e557694d724 100644
> --- a/arch/powerpc/platforms/pseries/setup.c
> +++ b/arch/powerpc/platforms/pseries/setup.c
> @@ -59,6 +59,7 @@
> #include <asm/xics.h>
> #include <asm/xive.h>
> #include <asm/papr-sysparm.h>
> +#include <asm/papr-watchdog.h>
> #include <asm/ppc-pci.h>
> #include <asm/i8259.h>
> #include <asm/udbg.h>
> @@ -185,14 +186,42 @@ static void __init fwnmi_init(void)
> #endif
> }
>
> <...>
>
> +static void pseries_crash_stop_watchdogs(void)
> +{
> + long rc;
> +
> + rc = plpar_hcall_norets_notrace(H_WATCHDOG, PSERIES_WDTF_OP_STOP,
> + PSERIES_WDT_NUM_ALL);
> + if (rc != H_SUCCESS && rc != H_NOOP)
> + pr_warn("Could not stop watchdogs before kdump rc=%ld\n", rc);
> +}
> +
> /*
> * Affix a device for the first timer to the platform bus if
> * we have firmware support for the H_WATCHDOG hypercall.
> */
> static __init int pseries_wdt_init(void)
> {
> - if (firmware_has_feature(FW_FEATURE_WATCHDOG))
> - platform_device_register_simple("pseries-wdt", 0, NULL, 0);
> + if (!firmware_has_feature(FW_FEATURE_WATCHDOG))
> + return 0;
> +
> + platform_device_register_simple("pseries-wdt", 0, NULL, 0);
> +
> + if (crash_shutdown_register(pseries_crash_stop_watchdogs))
> + pr_warn("Could not register watchdog crash shutdown handler\n");
> +
> return 0;
> }
> machine_subsys_initcall(pseries, pseries_wdt_init);
>
>
> Note that I added papr-watchdog.h header file in above. I am guessing we
> can move some definitions from drivers/watchdog/pseries-wdt.c to
> arch/powerpc/include/asm/papr-watchdog.h in a separate patch before this
> change.
Yes, it is better to keep the watchdog definitions in a common header
instead
of duplicating them in multiple places.
> I think you get the idea. Can you try this way and let me know if this works?
Sure. Thanks for the review.
- Sourabh Jain
>
> -ritesh
>
>> void default_machine_crash_shutdown(struct pt_regs *regs)
>> {
>> volatile unsigned int i;
>> @@ -360,6 +383,8 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
>> if (TRAP(regs) == INTERRUPT_SYSTEM_RESET)
>> is_via_system_reset = 1;
>>
>> + stop_watchdogs();
>> +
>> if (IS_ENABLED(CONFIG_SMP))
>> crash_smp_send_stop();
>> else
>> --
>> 2.52.0
^ permalink raw reply
* Re: [PATCH v7 16/22] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
From: Aneesh Kumar K.V @ 2026-07-10 5:22 UTC (permalink / raw)
To: Jason Gunthorpe, Catalin Marinas
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Jiri Pirko, Mostafa Saleh, Petr Tesarik,
Alexey Kardashevskiy, Dan Williams, Xu Yilun, linuxppc-dev,
linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley
In-Reply-To: <20260709181336.GM118978@ziepe.ca>
Jason Gunthorpe <jgg@ziepe.ca> writes:
> On Thu, Jul 09, 2026 at 12:13:19PM +0100, Catalin Marinas wrote:
>> > > For AMD/SME, on host with memory encryption we now end up setting the C
>> > > bit for DMA_ATTR_MMIO. This is fine for RAM but not sure whether
>> > > some other MMIO bus understands this attribute. Maybe we should stick to
>> > > something like __phys_to_dma() for the !CC_SHARED && MMIO path. Or,
>> > > since this is not universally defined, just use the old dma_addr = phys
>> > > if MMIO and ignore any unlikely DMA offsets.
>> > >
>> >
>> > Considering for AMD/SME system an unencrypted dma addr is one without C
>> > bit, will this be good?
>> >
>> > /*
>> > * For host memory encryption and device requiring unencrypted DMA,
>> > * MMIO memory is treated as shared by default.
>> > */
>> > if (attrs & DMA_ATTR_MMIO) {
>> > if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) || force_dma_unencrypted(dev))
>> > attrs |= DMA_ATTR_CC_SHARED;
>> > }
>>
>> Yes, I think it does the trick, preserves the current semantics for AMD.
>> I guess you could use a single 'if' for all checks (up to you).
>
> Please don't change it, MMIO P2P is broken on CC systems today and it
> should stay broken. Passing DMA_ATTR_MMIO with DMA_ATTR_CC_SHARED is
> an error that we need to correct in the drivers not make work in the
> core code.
>
But the above changes are intended to handle HOST_MEM_ENCRYPT. In v7, we
had the following diff:
@@ -88,37 +88,40 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
{
dma_addr_t dma_addr;
+ /*
+ * For a device requiring unencrypted DMA, MMIO memory is treated
+ * as shared by default.
+ */
+ if (force_dma_unencrypted(dev) && (attrs & DMA_ATTR_MMIO))
+ attrs |= DMA_ATTR_CC_SHARED;
+
This is now getting updated to
@@ -624,37 +626,44 @@ dma_addr_t dma_direct_map_phys(struct device *dev, phys_addr_t phys,
{
dma_addr_t dma_addr;
+ if (attrs & DMA_ATTR_MMIO) {
+ /*
+ * For host memory encryption and device requiring
+ * unencrypted DMA, MMIO memory is treated as shared by
+ * default.
+ */
+ if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) ||
+ force_dma_unencrypted(dev))
+ attrs |= DMA_ATTR_CC_SHARED;
+ }
+
I agree that we need to move that DMA_ATTR_CC_SHARED setting to
modified drivers/pci/p2pdma.c
@@ -285,6 +285,11 @@ int pcim_p2pdma_init(struct pci_dev *pdev)
continue;
p2p->mem[i].owner = &pdev->dev;
+
+ p2p->mem[i].dma_mapping_flags = DMA_ATTR_MMIO;
+ if (force_dma_unencrypted(dev))
+ p2p->mem[i].dma_mapping_flags |= DMA_ATTR_CC_SHARED;
+
As we discussed [1], that can come in a later patch. In the meantime, adding
the HOST_MEM_ENCRYPT check preserves the previous behavior for SME.
[1] https://lore.kernel.org/all/20260522132240.GD7702@ziepe.ca/
-aneesh
^ permalink raw reply
* Re: [RFC PATCH 0/6] selftests/vfio: Add sPAPR TCE v2 coverage
From: Narayana Murty N @ 2026-07-10 5:11 UTC (permalink / raw)
To: David Matlack
Cc: alex, shuah, amastro, rananta, kvm, linux-kselftest, linux-kernel,
vaibhav, sbhat, harshpb, linuxppc-dev
In-Reply-To: <CALzav=eB5NwrHNq4bm2ooSFmTtGk3sfUk7_k+iE+Kwm+Jc9LFA@mail.gmail.com>
On 09/07/26 9:21 PM, David Matlack wrote:
> On Thu, Jul 9, 2026 at 1:49 AM Narayana Murty N <nnmlinux@linux.ibm.com> wrote:
>
>>>> Feedback is requested from the VFIO and PowerPC communities on:
>>>> 1. whether the sPAPR TCE v2 helpers should remain in the common VFIO
>>>> selftest library or move into a sPAPR-specific test helper?
>>> Responded in the patch. Let's move to their own file.
>> Will do. v2 will have:
>>
>> lib/iommu_spapr.c — all sPAPR logic, compiled only on powerpc
>> lib/iommu_spapr_stub.c — empty stubs returning -EOPNOTSUPP,
>> compiled on all other architectures
>> lib/include/libvfio/iommu_spapr.h — declarations
> Just one small thing here: You can put all the stubs in iommu_spapr.h
> as static inlines, then you don't need the extra C file. e.g.
>
> #ifdef __powerpc__
>
> ... prototypes ...
>
> #else
>
> ... static inline stubs ...
>
> #endif
Sure, will follow the same.
regards,
Narayana
^ permalink raw reply
* Re: ld.lld: error: relocation R_PPC_ADDR16_LO cannot be used against symbol 'init_task'; recompile with -fPIC
From: Christophe Leroy (CS GROUP) @ 2026-07-10 4:33 UTC (permalink / raw)
To: Feng Tang, kernel test robot, linuxppc-dev, Nathan Chancellor,
Nick Desaulniers, clang-built-linux
Cc: oe-kbuild-all, linux-kernel, Marek Szyprowski
In-Reply-To: <alBeJUafPKhx8RMS@U-2FWC9VHC-2323.local>
+ Clang
Le 10/07/2026 à 04:51, Feng Tang a écrit :
> Thanks for the report!
>
> Add Powerpc list.
This is a Clang build with Clang linker, did you reproduce the problem
with a normal GCC build ?
Thanks
Christophe
>
> On Fri, Jul 10, 2026 at 06:18:50AM +0800, kernel test robot wrote:
>> tree: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094863506%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fQm6QfsJ2ggaKoRJWCz4dsaquz7Wo3uhRnOexVUrTnQ%3D&reserved=0 master
>> head: 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53
>> commit: d5cae2261b86913e602452ce4a07e6aefc0f603b dma-contiguous: simplify numa cma area handling
>> date: 6 weeks ago
>> config: powerpc-randconfig-r133-20260709 (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdownload.01.org%2F0day-ci%2Farchive%2F20260710%2F202607100652.WPUlEAfx-lkp%40intel.com%2Fconfig&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094899182%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BkT0BYyJtniz6YPzGpYbO0jn2T7vBDBLaK2Tsh1LcnE%3D&reserved=0)
>> compiler: clang version 21.1.8 (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094917538%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5%2BLVtRoojuNbhEMr3BhM2xF50PV%2FIYh%2FWw3ipDIWG%2FY%3D&reserved=0 2078da43e25a4623cab2d0d60decddf709aaea28)
>> sparse: v0.6.5-rc1
>> reproduce (this is a W=1 build): (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdownload.01.org%2F0day-ci%2Farchive%2F20260710%2F202607100652.WPUlEAfx-lkp%40intel.com%2Freproduce&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094935016%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BrpcCLuNecZIfyF6N5X%2FFcHhdG9YzLBAErvBGHyjjak%3D&reserved=0)
>
>
>> All errors (new ones prefixed by >>):
>>
>>>> ld.lld: error: relocation R_PPC_ADDR16_LO cannot be used against symbol 'init_task'; recompile with -fPIC
>> >>> defined in vmlinux.a(init/init_task.o)
>> >>> referenced by head_44x.S:101 (arch/powerpc/kernel/head_44x.S:101)
>> >>> arch/powerpc/kernel/head_44x.o:(.head.text+0x42) in archive vmlinux.a
>> --
>>>> ld.lld: error: relocation R_PPC_ADDR16_HI cannot be used against symbol 'init_thread_union'; recompile with -fPIC
>> >>> defined in ./arch/powerpc/kernel/vmlinux.lds:133
>> >>> referenced by head_44x.S:108 (arch/powerpc/kernel/head_44x.S:108)
>> >>> arch/powerpc/kernel/head_44x.o:(.head.text+0x4e) in archive vmlinux.a
>
> I checked the patch and couldn't find obvious clue between the patch and
> the error.
>
> commit d5cae2261b8691 only changes kernel/dma/contiguous.c, which is under
> CONFIG_DMA_CMA per kernel/dma/Makefile. In your config above, CONFIG_DMA_CMA
> is not even set, so the contigous.c should not be compiled. Could you help
> to double check? thanks!
>
> - Feng
>
>> Kconfig warnings: (for reference only)
>> WARNING: unmet direct dependencies detected for HOTPLUG_CPU
>> Depends on [n]: SMP [=y] && (PPC_PSERIES [=n] || PPC_PMAC [=n] || PPC_POWERNV [=n] || FSL_SOC_BOOKE [=n])
>> Selected by [y]:
>> - PM_SLEEP_SMP [=y] && SMP [=y] && (ARCH_SUSPEND_POSSIBLE [=y] || ARCH_HIBERNATION_POSSIBLE [=y]) && PM_SLEEP [=y]
>>
>> --
>> 0-DAY CI Kernel Test Service
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fintel%2Flkp-tests%2Fwiki&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C016c05b801ba48f2593f08dede2e29c2%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639192487094952205%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sqz%2BJ2dpT3ZZjlQyyvAhgPdP9jS0kJLpbRKTcV4rM50%3D&reserved=0
>
^ permalink raw reply
* Re: [PATCH v2 2/3] powerpc/numa: Allow cpu_to_coregroup_id without PPC_SPLPAR
From: Ritesh Harjani @ 2026-07-10 4:04 UTC (permalink / raw)
To: Srikar Dronamraju, linuxppc-dev, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy, Naveen N Rao
Cc: skiboot, arbab, mahesh, chleroy, Srikar Dronamraju, linux-kernel
In-Reply-To: <20260605055242.1757485-7-srikar@linux.ibm.com>
Srikar Dronamraju <srikar@linux.ibm.com> writes:
> Make cpu_to_coregroup_id() available outside PPC_SPLPAR so it can be
> used by platforms that do not rely on the SPLPAR-specific VPHN path.
>
> Keep the existing fallback behavior by returning the core ID when
> coregroup information is unavailable.
>
Looks like this mainly brings the cpu_to_coregroup_id() outside of
CONFIG_PPC_SPLPAR gate.
> Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
> ---
> Changelog from v1:
> - Handle comments from Christophe Leroy; Remove extern key word in
> declaration
>
> arch/powerpc/include/asm/topology.h | 15 +++++++--------
> arch/powerpc/mm/numa.c | 22 ++++++++++++++++------
> 2 files changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
> index 66ed5fe1b718..385715f1ad56 100644
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -71,6 +71,7 @@ extern void map_cpu_to_node(int cpu, int node);
> extern void unmap_cpu_from_node(unsigned long cpu);
> #endif /* CONFIG_HOTPLUG_CPU */
>
> +int cpu_to_coregroup_id(int cpu);
> #else
>
> static inline int early_cpu_to_node(int cpu) { return 0; }
> @@ -107,14 +108,6 @@ static inline void map_cpu_to_node(int cpu, int node) {}
> static inline void unmap_cpu_from_node(unsigned long cpu) {}
> #endif /* CONFIG_HOTPLUG_CPU */
> #endif /* CONFIG_SMP */
> -
> -#endif /* CONFIG_NUMA */
> -
> -#if defined(CONFIG_NUMA) && defined(CONFIG_PPC_SPLPAR)
> -void find_and_update_cpu_nid(int cpu);
> -extern int cpu_to_coregroup_id(int cpu);
> -#else
> -static inline void find_and_update_cpu_nid(int cpu) {}
> static inline int cpu_to_coregroup_id(int cpu)
> {
> #ifdef CONFIG_SMP
> @@ -124,6 +117,12 @@ static inline int cpu_to_coregroup_id(int cpu)
> #endif
> }
>
> +#endif /* CONFIG_NUMA */
> +
> +#if defined(CONFIG_NUMA) && defined(CONFIG_PPC_SPLPAR)
> +void find_and_update_cpu_nid(int cpu);
> +#else
> +static inline void find_and_update_cpu_nid(int cpu) {}
> #endif /* CONFIG_NUMA && CONFIG_PPC_SPLPAR */
>
> #include <asm-generic/topology.h>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index c44a80d8fc11..9aa71eb7e96b 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1428,6 +1428,21 @@ void find_and_update_cpu_nid(int cpu)
> pr_debug("%s:%d cpu %d nid %d\n", __func__, __LINE__, cpu, new_nid);
> }
>
> +static int topology_update_init(void)
> +{
> + topology_inited = 1;
> + return 0;
> +}
> +device_initcall(topology_update_init);
> +
> +#else
> +static long vphn_get_associativity(unsigned long cpu,
> + __be32 *associativity)
> +{
> + return -1;
> +}
> +#endif /* CONFIG_PPC_SPLPAR */
> +
> int cpu_to_coregroup_id(int cpu)
> {
> __be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
> @@ -1453,10 +1468,5 @@ int cpu_to_coregroup_id(int cpu)
> return cpu_to_core_id(cpu);
> }
>
> -static int topology_update_init(void)
> -{
> - topology_inited = 1;
> - return 0;
> + return coregroup_id;
> }
These above two lines seems to be out of any function scope. So applying
only patch-1 & patch-2 will give a compile error. This needs fixing.
-ritesh
> -device_initcall(topology_update_init);
> -#endif /* CONFIG_PPC_SPLPAR */
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc/numa: Simplify find_primary_domain_index
From: Ritesh Harjani @ 2026-07-10 4:03 UTC (permalink / raw)
To: Srikar Dronamraju, linuxppc-dev, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy, Naveen N Rao
Cc: skiboot, arbab, mahesh, chleroy, Srikar Dronamraju, linux-kernel
In-Reply-To: <20260605055242.1757485-6-srikar@linux.ibm.com>
Srikar Dronamraju <srikar@linux.ibm.com> writes:
> Initialize the return value once and use a single exit path in
> find_primary_domain_index().
>
> This is a small cleanup that keeps the existing behavior unchanged while
> making the control flow easier to follow.
>
> Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
Cleanup LGTM. Feel free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
^ permalink raw reply
* Re: powerpc/kexec_file: print configured kernel command line
From: Ritesh Harjani @ 2026-07-10 3:40 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev
Cc: Sourabh Jain, Madhavan Srinivasan, Michael Ellerman
In-Reply-To: <20250725124438.327593-1-sourabhjain@linux.ibm.com>
Sourabh Jain <sourabhjain@linux.ibm.com> writes:
> Kexec with the -d option prints extra logs about the kexec/kdump kernel
> that help debug kexec and kdump. For example, it shows what kexec
> segments are loaded, their locations, and sizes.
>
> One key piece of information still missing is the kernel command line
> configured for the kexec/kdump kernel.
>
> With this patch included, the kernel will print the kernel command line
> configured for the kexec/kdump kernel as shown below:
>
> kexec --initrd=./initrd ./kernel -lspd --command-line="test1 test2"
>
> Loaded elf core header at 0x22e30000, bufsz=0x2000 memsz=0x80000
> kexec_elf: Command line: elfcorehdr=0x22e30000 test1 test2 <--- New
> kexec_elf: Loaded initrd at 0x22eb0000
>
Looks like this slipped through the cracks. agreed that this is good to
have info. LGTM. So please feel free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
(this was still cleanly applicable on my latest dev tree)
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
-ritesh
^ permalink raw reply
* [PATCH] ASoC: fsl: imx-card: Skip sysclk reset for active DAIs in shutdown
From: Chancel Liu @ 2026-07-10 3:13 UTC (permalink / raw)
To: shengjiu.wang, Xiubo.Lee, festevam, nicoleotsuka, lgirdwood,
broonie, perex, tiwai, Frank.Li
Cc: kernel, linuxppc-dev, linux-sound, imx, linux-arm-kernel,
linux-kernel, stable
From: Chancel Liu <chancel.liu@nxp.com>
In a full-duplex setup, when one direction (playback or capture) is
closed while the other is still running, imx_aif_shutdown() was
unconditionally calling snd_soc_dai_set_sysclk() with rate=0 for all
cpu/codec DAIs, which would disable the clock still needed by the
active stream.
Add snd_soc_dai_active() checks before clearing sysclk so that only
truly inactive DAIs have their clocks reset.
Fixes: 2260bc6ea8bd ("ASoC: imx-card: Add WM8524 support")
Cc: stable@vger.kernel.org
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
sound/soc/fsl/imx-card.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/imx-card.c b/sound/soc/fsl/imx-card.c
index a4518fefad69..43438af1e1c6 100644
--- a/sound/soc/fsl/imx-card.c
+++ b/sound/soc/fsl/imx-card.c
@@ -496,11 +496,15 @@ static void imx_aif_shutdown(struct snd_pcm_substream *substream)
struct snd_soc_dai *codec_dai;
int i;
- for_each_rtd_cpu_dais(rtd, i, cpu_dai)
- snd_soc_dai_set_sysclk(cpu_dai, 0, 0, SND_SOC_CLOCK_OUT);
+ for_each_rtd_cpu_dais(rtd, i, cpu_dai) {
+ if (!snd_soc_dai_active(cpu_dai))
+ snd_soc_dai_set_sysclk(cpu_dai, 0, 0, SND_SOC_CLOCK_OUT);
+ }
- for_each_rtd_codec_dais(rtd, i, codec_dai)
- snd_soc_dai_set_sysclk(codec_dai, 0, 0, SND_SOC_CLOCK_IN);
+ for_each_rtd_codec_dais(rtd, i, codec_dai) {
+ if (!snd_soc_dai_active(codec_dai))
+ snd_soc_dai_set_sysclk(codec_dai, 0, 0, SND_SOC_CLOCK_IN);
+ }
}
static const struct snd_soc_ops imx_aif_ops = {
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v2 1/4] powerpc/mmu: do MMU type discovery before crashkernel reservation
From: Ritesh Harjani @ 2026-07-10 2:44 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev, maddy, mpe
Cc: npiggin, chleroy, shivangu, hbathini, mahesh, adityag, venkat88,
Sourabh Jain
In-Reply-To: <20260708143357.673251-2-sourabhjain@linux.ibm.com>
Minor nits
Sourabh Jain <sourabhjain@linux.ibm.com> writes:
> Crashkernel reservation on high memory depends on the MMU type, so
> finalize the MMU type before calling arch_reserve_crashkernel().
>
> With the changes introduced here, early_radix_enabled() becomes usable
> and will be used in arch_reserve_crashkernel() in the upcoming patch.
>
> early_radix_enabled() depends on cur_cpu_spec->mmu_features to find
> out if the radix MMU is enabled. The radix MMU bit in mmu_features is
> discovered from the FDT and kernel configs. To make sure the MMU type is
> finalized before arch_reserve_crashkernel() is called, the function that
> scans the FDT and sets mmu_features, along with some bits from
> mmu_early_type_finalize(), has been moved above
> arch_reserve_crashkernel().
>
Can you also add a short description of why can't we move
arch_reserve_crashkernel() to a later point instead of breaking
mmu_early_init_devtree() and moving the xx_type_finalize() part above?
If I am not wrong, it is since move_device_tree() checks whether the FDT
overlaps the crash kernel reservation. So arch_reserve_crashkernel()
must be called before move_device_tree().
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/mmu.h | 1 +
> arch/powerpc/include/asm/mmu.h | 1 +
> arch/powerpc/kernel/prom.c | 28 +++++++++++++-----------
> arch/powerpc/mm/init_64.c | 27 ++++++++++++++---------
> 4 files changed, 34 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
> index 48631365b48c..7a3b2ff02041 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -208,6 +208,7 @@ extern int mmu_vmemmap_psize;
>
> /* MMU initialization */
> void mmu_early_init_devtree(void);
> +void mmu_early_type_finalize(void);
can you rename this as mmu_early_init_type().
Otherwise the change looks good to me. With the above 2 addressed, feel
free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
^ permalink raw reply
* Re: ld.lld: error: relocation R_PPC_ADDR16_LO cannot be used against symbol 'init_task'; recompile with -fPIC
From: Feng Tang @ 2026-07-10 2:51 UTC (permalink / raw)
To: kernel test robot, linuxppc-dev
Cc: oe-kbuild-all, linux-kernel, Marek Szyprowski
In-Reply-To: <202607100652.WPUlEAfx-lkp@intel.com>
Thanks for the report!
Add Powerpc list.
On Fri, Jul 10, 2026 at 06:18:50AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53
> commit: d5cae2261b86913e602452ce4a07e6aefc0f603b dma-contiguous: simplify numa cma area handling
> date: 6 weeks ago
> config: powerpc-randconfig-r133-20260709 (https://download.01.org/0day-ci/archive/20260710/202607100652.WPUlEAfx-lkp@intel.com/config)
> compiler: clang version 21.1.8 (https://github.com/llvm/llvm-project 2078da43e25a4623cab2d0d60decddf709aaea28)
> sparse: v0.6.5-rc1
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260710/202607100652.WPUlEAfx-lkp@intel.com/reproduce)
> All errors (new ones prefixed by >>):
>
> >> ld.lld: error: relocation R_PPC_ADDR16_LO cannot be used against symbol 'init_task'; recompile with -fPIC
> >>> defined in vmlinux.a(init/init_task.o)
> >>> referenced by head_44x.S:101 (arch/powerpc/kernel/head_44x.S:101)
> >>> arch/powerpc/kernel/head_44x.o:(.head.text+0x42) in archive vmlinux.a
> --
> >> ld.lld: error: relocation R_PPC_ADDR16_HI cannot be used against symbol 'init_thread_union'; recompile with -fPIC
> >>> defined in ./arch/powerpc/kernel/vmlinux.lds:133
> >>> referenced by head_44x.S:108 (arch/powerpc/kernel/head_44x.S:108)
> >>> arch/powerpc/kernel/head_44x.o:(.head.text+0x4e) in archive vmlinux.a
I checked the patch and couldn't find obvious clue between the patch and
the error.
commit d5cae2261b8691 only changes kernel/dma/contiguous.c, which is under
CONFIG_DMA_CMA per kernel/dma/Makefile. In your config above, CONFIG_DMA_CMA
is not even set, so the contigous.c should not be compiled. Could you help
to double check? thanks!
- Feng
> Kconfig warnings: (for reference only)
> WARNING: unmet direct dependencies detected for HOTPLUG_CPU
> Depends on [n]: SMP [=y] && (PPC_PSERIES [=n] || PPC_PMAC [=n] || PPC_POWERNV [=n] || FSL_SOC_BOOKE [=n])
> Selected by [y]:
> - PM_SLEEP_SMP [=y] && SMP [=y] && (ARCH_SUSPEND_POSSIBLE [=y] || ARCH_HIBERNATION_POSSIBLE [=y]) && PM_SLEEP [=y]
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 0/3] selftests/mm: avoid false failures in hugetlb and KSM tests
From: Andrew Morton @ 2026-07-10 1:53 UTC (permalink / raw)
To: Sayali Patil
Cc: Shuah Khan, linux-mm, linux-kernel, linux-kselftest,
Ritesh Harjani, David Hildenbrand, Zi Yan, Michal Hocko,
Oscar Salvador, Lorenzo Stoakes, Dev Jain, Liam.Howlett,
linuxppc-dev, Miaohe Lin, Venkat Rao Bagalkote
In-Reply-To: <cover.1783446924.git.sayalip@linux.ibm.com>
On Wed, 8 Jul 2026 12:29:04 +0530 Sayali Patil <sayalip@linux.ibm.com> wrote:
> This series fixes issues in the hugetlb and KSM MM selftest categories
> that can report failures when the prerequisites for the tests are not
> satisfied.
Thanks. AI review asked one question:
https://sashiko.dev/#/patchset/cover.1783446924.git.sayalip@linux.ibm.com
^ permalink raw reply
* Re: [PATCH v4] perf dso: Fix kallsyms DSO detection with fallback logic
From: Namhyung Kim @ 2026-07-10 0:41 UTC (permalink / raw)
To: acme, jolsa, adrian.hunter, vmolnaro, mpetlan, tmricht, maddy,
irogers, Tanushree Shah
Cc: linux-perf-users, linuxppc-dev, atrajeev, hbathini, Tejas.Manhas1,
Tanushree.Shah, Shivani.Nittor
In-Reply-To: <20260708112607.548304-2-tshah@linux.ibm.com>
On Wed, 08 Jul 2026 16:56:08 +0530, Tanushree Shah wrote:
> The current kallsyms detection in dso__is_kallsyms() uses the
> dso_binary_type enum which fixes the issue of kallsyms being cached in
> the build-id cache for out-of-tree modules.
>
> However, during build-id injection in perf record/inject, dso_binary_type
> has not been explicitly set yet,so dso__binary_type() returns
> DSO_BINARY_TYPE__NOT_FOUND instead of DSO_BINARY_TYPE__KALLSYMS for the
> kernel DSO. The current check then fails to identify it as kallsyms,
> causing build-id symlinks to not be created in ~/.debug/.build-id/ and
> perf archive to fail with "Cannot stat" errors.
>
> [...]
Applied to perf-tools-next, thanks!
Best regards,
Namhyung
^ permalink raw reply
* [PATCH] selftests/powerpc: Check mmap return value in inject-ra-err
From: longlong yan @ 2026-07-09 12:49 UTC (permalink / raw)
To: maddy, mpe
Cc: npiggin, chleroy, ganeshgr, linuxppc-dev, linux-kselftest,
longlong yan
mmap() in test_ra_error() is not checked for MAP_FAILED. On failure,
the subsequent write *paste_addr = 1 dereferences an invalid pointer
and segfaults. Add a FAIL_IF() check, consistent with the rest of the
function.
Fixes: 0f4ef8a3bf78 ("selftests/powerpc: Add test for real address error handling")
Signed-off-by: longlong yan <yanlonglong@kylinos.cn>
---
tools/testing/selftests/powerpc/mce/inject-ra-err.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/powerpc/mce/inject-ra-err.c b/tools/testing/selftests/powerpc/mce/inject-ra-err.c
index 94323c34d9a6..0622fd814114 100644
--- a/tools/testing/selftests/powerpc/mce/inject-ra-err.c
+++ b/tools/testing/selftests/powerpc/mce/inject-ra-err.c
@@ -47,6 +47,7 @@ static int test_ra_error(void)
FAIL_IF(sigaction(SIGBUS, &act, NULL) != 0);
paste_addr = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0ULL);
+ FAIL_IF(paste_addr == MAP_FAILED);
/* The following assignment triggers exception */
mb();
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 7.1.y 1/6] bpf: Support for hardening against JIT spraying
From: bot+bpf-ci @ 2026-07-09 22:52 UTC (permalink / raw)
To: pawan.kumar.gupta, stable, gregkh, sashal
Cc: bpf, linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv, x86,
ast, daniel, ast, andrii, daniel, martin.lau, eddyz87,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260709-cbpf-jit-spray-hardening-7-1-y-v1-1-5ac5a2d6797f@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]
> commit 96cce16e26dd02a8678f1e87f88a4b5cdb63b995 upstream.
> The BPF JIT allocator packs many small programs into larger executable
> allocations and reuses space within those allocations as programs are
> loaded and freed. When fresh code is written into space that a previous
> program occupied, an indirect jump into the new program can reuse a branch
> prediction left behind by the old one.
> Flush the indirect branch predictors before reusing JIT memory so that
> indirect jumps into a newly written program don't reuse predictions from an
> old program that occupied the same space.
> Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush
> static call for flushing the branch predictors on JIT memory reuse.
> Architectures that need a flush, can update it to a predictor flush
> function. By default, its a NOP and does not emit any CALL.
> Allocations larger than a pack are not covered by this flush. That is safe
> because cBPF programs (the unprivileged attack surface) are bounded well
> below a pack size. Issue a warning if this assumption is ever violated
> while the flush is active.
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
The reuse path this patch hardens (bpf_prog_pack_alloc() finding a free
area within a pack, and the size > BPF_PROG_PACK_SIZE branch) comes from
the pack allocator that first packed many programs into shared executable
allocations and reused freed space within a pack.
Should this carry a Fixes: tag pointing at that commit?
Fixes: 57631054fae6 ("bpf: Introduce bpf_prog_pack allocator")
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/29054648899
^ permalink raw reply
* Re: [PATCH v2 0/2] PCI: Add boot options to disable DPC and AER recovery
From: Bjorn Helgaas @ 2026-07-09 22:42 UTC (permalink / raw)
To: Yury Murashka
Cc: bhelgaas, corbet, skhan, mahesh, oohall, linux-pci, linux-doc,
linux-kernel, linuxppc-dev
In-Reply-To: <20260709185429.627968-1-yurypm@arista.com>
On Thu, Jul 09, 2026 at 06:54:27PM +0000, Yury Murashka wrote:
> On large modular systems with a complex PCIe tree, the default kernel
> AER recovery and DPC behavior could cause unexpected side effects.
I can't tell what the actual issues are, but if there are kernel
defects in this area, we should fix them. If this is to work around
platform defects, maybe we need quirks to work around them
automatically?
^ permalink raw reply
* [PATCH 7.1.y 6/6] bpf: Prefer dirty packs for eBPF allocations
From: Pawan Gupta @ 2026-07-09 22:24 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, Sasha Levin
Cc: bpf, linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv, x86,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20260709-cbpf-jit-spray-hardening-7-1-y-v1-0-5ac5a2d6797f@linux.intel.com>
commit b72e29e0f7ee329d89f86db8700c8ea99b4a370a upstream.
The pack allocator only flushes predictors when reusing a dirty pack for
cBPF, eBPF allocations never trigger a flush. Currently, eBPF picks the
first free pack, which could be a clean pack. As an optimization, leaving
a clean pack for cBPF can avoid flushes.
Prefer dirty packs for eBPF and keep clean packs free for cBPF. This
mirrors the existing cBPF preference for clean packs: each program kind
prefers the pack that avoids an extra flush, and falls back to the other
kind only when no preferred pack has room. eBPF reuse of a dirty pack is
harmless since eBPF being privileged does not flush.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
kernel/bpf/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index bba4acd61d41..de61e1894452 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -988,10 +988,10 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool
goto found_free_area;
/*
* cBPF reuse of a dirty pack triggers a flush, so prefer a
- * clean pack for cBPF. eBPF never flushes, so pick the first
- * free pack, dirty or clean.
+ * clean pack for cBPF. eBPF never flushes, so steer it to a
+ * dirty pack and keep clean packs free for cBPF.
*/
- if (!was_classic || !pack->arch_flush_needed)
+ if (was_classic ^ pack->arch_flush_needed)
goto found_free_area;
if (!fallback_pack) {
fallback_pack = pack;
--
2.43.0
^ 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