* Re: [PATCH] powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()
From: Florian Fuchs @ 2026-07-13 16:19 UTC (permalink / raw)
To: Thorsten Blum
Cc: Ritesh Harjani, Geoff Levand, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Geert Uytterhoeven, Paul Mackerras, MOKUNO Masakazu, stable,
Geoff Levand, linuxppc-dev, linux-kernel
In-Reply-To: <alT_fEu9AtQT9PxU@linux.dev>
On 13 Jul 17:08, Thorsten Blum wrote:
> On Mon, Jul 13, 2026 at 06:08:56PM +0530, Ritesh Harjani wrote:
> > Thorsten Blum <thorsten.blum@linux.dev> writes:
> >
> > > If lv1_put_iopte() fails in dma_ioc0_map_pages(), the error path
> > > decrements iopage but keeps using the failed mapping's offset. As a
> > > result, it repeatedly tries to invalidate the failed IOPTE slot and
> > > leaves the already installed IOPTEs valid.
> > >
> > > Recompute offset and invalidate the installed IOPTEs instead.
> > >
> >
> > Nice catch! I wonder how did you catch this?
> > Do you have ps3 console where you somehow ran into this ;)
> > Or was it a manual inspection?
>
> I do have a PS3 somewhere, but I stumbled upon this while reading and
> trying to understand the code.
>
> > I wonder whether PS3 consoles are still being used?
>
> Not sure.
>
Yes, indeed, they are :-) But I'm not sure on how to test or inject the
error path, so I can't add anything useful to that. Beside, thanks for
keeping an eye on the good stuff.
> > > Fixes: 6bb5cf102541 ("[POWERPC] PS3: System-bus rework")
> >
> > Looks like this was from 2007.
> >
> > However, the change looks good to me. So:
> > Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>
> Thanks,
> Thorsten
>
Regards,
Florian
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()
From: Thorsten Blum @ 2026-07-13 15:08 UTC (permalink / raw)
To: Ritesh Harjani
Cc: Geoff Levand, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Geert Uytterhoeven,
Paul Mackerras, MOKUNO Masakazu, stable, Geoff Levand,
linuxppc-dev, linux-kernel
In-Reply-To: <ik6jukrj.ritesh.list@gmail.com>
On Mon, Jul 13, 2026 at 06:08:56PM +0530, Ritesh Harjani wrote:
> Thorsten Blum <thorsten.blum@linux.dev> writes:
>
> > If lv1_put_iopte() fails in dma_ioc0_map_pages(), the error path
> > decrements iopage but keeps using the failed mapping's offset. As a
> > result, it repeatedly tries to invalidate the failed IOPTE slot and
> > leaves the already installed IOPTEs valid.
> >
> > Recompute offset and invalidate the installed IOPTEs instead.
> >
>
> Nice catch! I wonder how did you catch this?
> Do you have ps3 console where you somehow ran into this ;)
> Or was it a manual inspection?
I do have a PS3 somewhere, but I stumbled upon this while reading and
trying to understand the code.
> I wonder whether PS3 consoles are still being used?
Not sure.
> > Fixes: 6bb5cf102541 ("[POWERPC] PS3: System-bus rework")
>
> Looks like this was from 2007.
>
> However, the change looks good to me. So:
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH] drm/amd/display: Shorten KUnit exported symbol names
From: Alex Deucher @ 2026-07-13 14:20 UTC (permalink / raw)
To: Venkat Rao Bagalkote
Cc: alexander.deucher, chleroy, alex.hung, maddy, linuxppc-dev,
harry.wentland, sunpeng.li, christian.koenig, siqueira, amd-gfx,
dri-devel, linux-kernel
In-Reply-To: <20260711032956.87948-1-venkat88@linux.ibm.com>
Applied. Thanks!
On Sat, Jul 11, 2026 at 10:09 AM Venkat Rao Bagalkote
<venkat88@linux.ibm.com> wrote:
>
> The KUnit exported helpers
>
> amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers()
> amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers()
>
> exceed MODULE_NAME_LEN and cause modpost to fail with:
>
> ERROR: modpost: too long symbol
> "amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers"
>
> Shorten the helper names while preserving their functionality.
>
> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Link: https://lore.kernel.org/all/fde3656e-9e22-4e4c-937f-7e8cb918da6b@linux.ibm.com/
> Signed-off-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 12 ++++++------
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h | 4 ++--
> .../display/amdgpu_dm/tests/amdgpu_dm_plane_test.c | 8 ++++----
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> index 1b564cfe2120..b58225338bc4 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> @@ -328,7 +328,7 @@ STATIC_IFN_KUNIT int amdgpu_dm_plane_validate_dcc(struct amdgpu_device *adev,
> }
> EXPORT_IF_KUNIT(amdgpu_dm_plane_validate_dcc);
>
> -STATIC_IFN_KUNIT int amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers(struct amdgpu_device *adev,
> +STATIC_IFN_KUNIT int amdgpu_dm_plane_fill_gfx9_attrs_from_modifiers(struct amdgpu_device *adev,
> const struct amdgpu_framebuffer *afb,
> const enum surface_pixel_format format,
> const enum dc_rotation_angle rotation,
> @@ -378,9 +378,9 @@ STATIC_IFN_KUNIT int amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers(s
>
> return ret;
> }
> -EXPORT_IF_KUNIT(amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers);
> +EXPORT_IF_KUNIT(amdgpu_dm_plane_fill_gfx9_attrs_from_modifiers);
>
> -STATIC_IFN_KUNIT int amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers(struct amdgpu_device *adev,
> +STATIC_IFN_KUNIT int amdgpu_dm_plane_fill_gfx12_attrs_from_modifiers(struct amdgpu_device *adev,
> const struct amdgpu_framebuffer *afb,
> const enum surface_pixel_format format,
> const enum dc_rotation_angle rotation,
> @@ -419,7 +419,7 @@ STATIC_IFN_KUNIT int amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers(
>
> return ret;
> }
> -EXPORT_IF_KUNIT(amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers);
> +EXPORT_IF_KUNIT(amdgpu_dm_plane_fill_gfx12_attrs_from_modifiers);
>
> static void amdgpu_dm_plane_add_gfx10_1_modifiers(const struct amdgpu_device *adev,
> uint64_t **mods,
> @@ -927,14 +927,14 @@ int amdgpu_dm_plane_fill_plane_buffer_attributes(struct amdgpu_device *adev,
> }
>
> if (adev->family == AMDGPU_FAMILY_GC_12_0_0) {
> - ret = amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers(adev, afb, format,
> + ret = amdgpu_dm_plane_fill_gfx12_attrs_from_modifiers(adev, afb, format,
> rotation, plane_size,
> tiling_info, dcc,
> address);
> if (ret)
> return ret;
> } else if (adev->family >= AMDGPU_FAMILY_AI) {
> - ret = amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers(adev, afb, format,
> + ret = amdgpu_dm_plane_fill_gfx9_attrs_from_modifiers(adev, afb, format,
> rotation, plane_size,
> tiling_info, dcc,
> address);
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h
> index 911fb2d73e22..55c33e051aee 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h
> @@ -92,7 +92,7 @@ int amdgpu_dm_plane_get_plane_modifiers(struct amdgpu_device *adev,
> int amdgpu_dm_plane_get_plane_formats(const struct drm_plane *plane,
> const struct dc_plane_cap *plane_cap,
> uint32_t *formats, int max_formats);
> -int amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers(struct amdgpu_device *adev,
> +int amdgpu_dm_plane_fill_gfx9_attrs_from_modifiers(struct amdgpu_device *adev,
> const struct amdgpu_framebuffer *afb,
> const enum surface_pixel_format format,
> const enum dc_rotation_angle rotation,
> @@ -100,7 +100,7 @@ int amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers(struct amdgpu_devi
> struct dc_tiling_info *tiling_info,
> struct dc_plane_dcc_param *dcc,
> struct dc_plane_address *address);
> -int amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers(struct amdgpu_device *adev,
> +int amdgpu_dm_plane_fill_gfx12_attrs_from_modifiers(struct amdgpu_device *adev,
> const struct amdgpu_framebuffer *afb,
> const enum surface_pixel_format format,
> const enum dc_rotation_angle rotation,
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/tests/amdgpu_dm_plane_test.c b/drivers/gpu/drm/amd/display/amdgpu_dm/tests/amdgpu_dm_plane_test.c
> index 46c9af432e37..fc84f5a08596 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/tests/amdgpu_dm_plane_test.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/tests/amdgpu_dm_plane_test.c
> @@ -579,7 +579,7 @@ static void dm_test_fill_gfx12_plane_attributes_from_modifiers(struct kunit *tes
> plane_size.surface_size.height = 1080;
>
> KUNIT_EXPECT_EQ(test,
> - amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers(
> + amdgpu_dm_plane_fill_gfx12_attrs_from_modifiers(
> adev, afb, SURFACE_PIXEL_FORMAT_GRPH_ARGB8888,
> ROTATION_ANGLE_0, &plane_size, &tiling_info, &dcc, &address),
> 0);
> @@ -623,7 +623,7 @@ static void dm_test_fill_gfx9_plane_attributes_from_modifiers(struct kunit *test
> afb->base.modifier = DRM_FORMAT_MOD_LINEAR;
>
> KUNIT_EXPECT_EQ(test,
> - amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers(
> + amdgpu_dm_plane_fill_gfx9_attrs_from_modifiers(
> adev, afb, SURFACE_PIXEL_FORMAT_GRPH_ARGB8888,
> ROTATION_ANGLE_0, &plane_size, &tiling_info, &dcc, &address),
> 0);
> @@ -1187,9 +1187,9 @@ static struct kunit_case amdgpu_dm_plane_test_cases[] = {
> KUNIT_CASE(dm_test_get_cursor_position),
> /* amdgpu_dm_plane_format_mod_supported() */
> KUNIT_CASE(dm_test_format_mod_supported),
> - /* amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers() */
> + /* amdgpu_dm_plane_fill_gfx12_attrs_from_modifiers() */
> KUNIT_CASE(dm_test_fill_gfx12_plane_attributes_from_modifiers),
> - /* amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers() */
> + /* amdgpu_dm_plane_fill_gfx9_attrs_from_modifiers() */
> KUNIT_CASE(dm_test_fill_gfx9_plane_attributes_from_modifiers),
> /* amdgpu_dm_plane_helper_check_state() */
> KUNIT_CASE(dm_test_helper_check_state_viewport_reject),
> --
> 2.45.2
>
^ permalink raw reply
* Re: [PATCH v2] powerpc/ps3: Remove unused struct table in setup_areas()
From: Ritesh Harjani @ 2026-07-13 14:03 UTC (permalink / raw)
To: Thorsten Blum, Geoff Levand, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP)
Cc: Amit Machhiwal, Thorsten Blum, Geert Uytterhoeven, linuxppc-dev,
linux-kernel
In-Reply-To: <20260713091731.97212-3-thorsten.blum@linux.dev>
Thorsten Blum <thorsten.blum@linux.dev> writes:
> The local table structure is not used - remove it.
>
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
LGTM.
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
^ permalink raw reply
* Re: [PATCH v7 16/22] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-07-13 13:56 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Catalin Marinas, 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: <yq5atsq6hdaa.fsf@kernel.org>
On Sat, Jul 11, 2026 at 12:39:49AM +0530, Aneesh Kumar K.V wrote:
> > But if you really want to it should be
> > cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) *only* and get rid of the wrong
> > force_dma_unencrypted().
> >
>
> Ok, I will update the changes to so we preserve the previous behaviour
> for SME?
>
> if (attrs & DMA_ATTR_MMIO) {
> /*
> * For host memory encryption treat MMIO memory as shared
> */
> if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
> attrs |= DMA_ATTR_CC_SHARED;
> }
I'm OK with this, with the expectation we should aim to remove it when
fixing the callers.
> > But IMHO, I'd rather this series treat ATTR_MMIO as private MMIO and
> > ATTR_MMIO|CC_SHARED as shared MMIO and that's the right and correct
> > thing for the DMA API.
> >
>
> If you think the rest of the series is ready for upstream, could you
> please ack it so it can be picked up for the next merge window? I'll
> repost v8, rebased on top of the pKVM topic branch.
Yeah
Jason
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()
From: Ritesh Harjani @ 2026-07-13 12:38 UTC (permalink / raw)
To: Thorsten Blum, Geoff Levand, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Geert Uytterhoeven, Paul Mackerras, MOKUNO Masakazu
Cc: Thorsten Blum, stable, Geoff Levand, linuxppc-dev, linux-kernel
In-Reply-To: <20260711130931.740719-3-thorsten.blum@linux.dev>
Thorsten Blum <thorsten.blum@linux.dev> writes:
> If lv1_put_iopte() fails in dma_ioc0_map_pages(), the error path
> decrements iopage but keeps using the failed mapping's offset. As a
> result, it repeatedly tries to invalidate the failed IOPTE slot and
> leaves the already installed IOPTEs valid.
>
> Recompute offset and invalidate the installed IOPTEs instead.
>
Nice catch! I wonder how did you catch this?
Do you have ps3 console where you somehow ran into this ;)
Or was it a manual inspection?
I wonder whether PS3 consoles are still being used?
> Fixes: 6bb5cf102541 ("[POWERPC] PS3: System-bus rework")
Looks like this was from 2007.
However, the change looks good to me. So:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> arch/powerpc/platforms/ps3/mm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
> index 20fc5b68faee..315a32fd75b1 100644
> --- a/arch/powerpc/platforms/ps3/mm.c
> +++ b/arch/powerpc/platforms/ps3/mm.c
> @@ -615,6 +615,7 @@ static int dma_ioc0_map_pages(struct ps3_dma_region *r, unsigned long phys_addr,
>
> fail_map:
> for (iopage--; 0 <= iopage; iopage--) {
> + offset = (1 << r->page_size) * iopage;
> lv1_put_iopte(0,
> c->bus_addr + offset,
> c->lpar_addr + offset,
^ permalink raw reply
* Re: [PATCH v2 3/3] powerpc/crash: stop watchdogs before booting kdump kernel
From: Sourabh Jain @ 2026-07-13 13:37 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: <o6gbv5jl.ritesh.list@gmail.com>
On 13/07/26 10:40, 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. When a panic triggers kdump, the
>> crashing kernel jumps directly to the kdump kernel without stopping
>> active watchdogs. As a result, the watchdogs remain active after the
>> kdump kernel starts.
>>
>> If dump capture takes longer than the watchdog timeout, PHYP resets the
>> LPAR before the dump is fully captured, causing dump capture to fail.
>>
>> Fix this by issuing the `H_WATCHDOG` hcall during the crash shutdown
>> sequence to stop all active watchdogs before booting the kdump kernel.
>>
>> Fixes: 69472ffa6575 ("watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers")
>> Reported-by: Mahesh Kumar G <mahe657@linux.ibm.com>
>> Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>> arch/powerpc/include/asm/papr-watchdog.h | 2 ++
>> arch/powerpc/platforms/pseries/setup.c | 18 ++++++++++++++++++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/papr-watchdog.h b/arch/powerpc/include/asm/papr-watchdog.h
>> index fb3a511aa861..84bbe1ddd56f 100644
>> --- a/arch/powerpc/include/asm/papr-watchdog.h
>> +++ b/arch/powerpc/include/asm/papr-watchdog.h
>> @@ -55,4 +55,6 @@
>> #define PSERIES_WDTQ_MIN_TIMEOUT(cap) (((cap) >> 48) & 0xffff)
>> #define PSERIES_WDTQ_MAX_NUMBER(cap) (((cap) >> 32) & 0xffff)
>>
>> +#define PSERIES_WDT_NUM_ALL ((unsigned long)-1)
>> +
> minor nit:
>
> This should be defined at the end of the H_WATCHDOG Input section.
> /*
> * H_WATCHDOG Input
> *
>
> <...>
>
> Something like this maybe?
>
> /*
> * R5: "watchdogNumber":
Makes sense. Since this is the third argument to the hypercall,
R5 is the correct register to use in the comment.
> * PAPR says use -1 (all ones) to stop all watchdogs.
> */
> #define PSERIES_WDT_NUM_ALL ((unsigned long)-1)
>
> /*
> * H_WATCHDOG Output
> *
> * R3: Return code
> *
> <...>
>
>> #endif /* _ASM_POWERPC_CRASHDUMP_PPC64_H */
>> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
>> index bbb2813f8ede..2e40a9dba637 100644
>> --- a/arch/powerpc/platforms/pseries/setup.c
>> +++ b/arch/powerpc/platforms/pseries/setup.c
>> @@ -77,6 +77,7 @@
>> #include <asm/dtl.h>
>> #include <asm/hvconsole.h>
>> #include <asm/setup.h>
>> +#include <asm/papr-watchdog.h>
>>
>> #include "pseries.h"
>>
>> @@ -185,6 +186,18 @@ static void __init fwnmi_init(void)
>> #endif
>> }
>>
>> +#ifdef CONFIG_CRASH_DUMP
>> +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);
>> +}
>> +#endif /* CONFIG_CRASH_DUMP */
>> +
>> /*
>> * Affix a device for the first timer to the platform bus if
>> * we have firmware support for the H_WATCHDOG hypercall.
>> @@ -203,6 +216,11 @@ static __init int pseries_wdt_init(void)
>> return PTR_ERR(pseries_wdt_dev);
>> }
>>
>> +#ifdef CONFIG_CRASH_DUMP
>> + if (crash_shutdown_register(pseries_crash_stop_watchdogs))
>> + pr_warn("Could not register watchdog crash shutdown handler\n");
>> +#endif
>> +
> minor nit:
> I don't think we need any of the #ifdef. All definitions used inside
> pseries_crash_stop_watchdogs are already available and
> crash_shutdown_register() already exists for !CONFIG_CRASH_DUMP, so we
> may as well drop all of the ifdefs.
Yes, the #ifdef is not really needed because crash_shutdown_register() is
always available.
I removed the #ifdef blocks and built the kernel both with and without
CONFIG_CRASH_DUMP. The kernel built successfully in both cases.
>
>
> Otherwise LGTM, so feel free to add:
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Thanks for the review.
- Sourabh Jain
^ permalink raw reply
* Re: [PATCH v2 1/4] powerpc/mmu: do MMU type discovery before crashkernel reservation
From: Sourabh Jain @ 2026-07-13 13:12 UTC (permalink / raw)
To: Ritesh Harjani (IBM), linuxppc-dev, maddy, mpe
Cc: npiggin, chleroy, shivangu, hbathini, mahesh, adityag, venkat88
In-Reply-To: <1pdbwokc.ritesh.list@gmail.com>
On 10/07/26 08:14, Ritesh Harjani (IBM) wrote:
> 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?
The main reason is that the crashkernel requires one large contiguous memory
block to be reserved at a specific memory offset. To ensure this
allocation succeeds,
the crashkernel memory is reserved before any other components reserve
memory.
> 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().
I think the bootloader loads the device tree and may chose a location
that may falls
within the crashkernel region. The purpose of move_device_tree() is to
relocate
the device tree so that it no longer occupies the crashkernel memory.
Otherwise,
that memory region would also need to be excluded from the crashkernel
reserved area (and also need special APIs to access device tree present in
reserved memory regions), similar to the RTAS region.
- Sourabh Jain
>
>
>> 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: [PATCH 1/2] bus: fsl-mc: Remove redundant dev_err()
From: Ioana Ciornei @ 2026-07-13 12:48 UTC (permalink / raw)
To: Pan Chuang
Cc: open list:QORIQ DPAA2 FSL-MC BUS DRIVER,
open list:QORIQ DPAA2 FSL-MC BUS DRIVER
In-Reply-To: <20260710110930.462109-2-panchuang@vivo.com>
On Fri, Jul 10, 2026 at 07:09:26PM +0800, Pan Chuang wrote:
> Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
> devm_request_*_irq()"), devm_request_threaded_irq() automatically logs
> detailed error messages on failure. Remove the now-redundant
> driver-specific dev_err() calls.
>
> Signed-off-by: Pan Chuang <panchuang@vivo.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 0/3] powerpc/crash: protect kdump from active watchdogs
From: Ritesh Harjani @ 2026-07-13 11:39 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev, maddy, mpe
Cc: npiggin, chleroy, shivangu, hbathini, mahesh, adityag, venkat88,
stable
In-Reply-To: <a5f57d59-a246-4279-946f-2e41d1b438a7@linux.ibm.com>
Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
> Okay, for stable tree inclusion, CCing is enough.
yup, by ccing here means, adding a "Cc: stable@vger.kernel.org" tag to
the commit should do.
-ritesh
^ permalink raw reply
* Re: [PATCH v2 0/3] powerpc/crash: protect kdump from active watchdogs
From: Sourabh Jain @ 2026-07-13 11:30 UTC (permalink / raw)
To: Ritesh Harjani (IBM), linuxppc-dev, maddy, mpe
Cc: npiggin, chleroy, shivangu, hbathini, mahesh, adityag, venkat88,
stable
In-Reply-To: <ldbfv1dl.ritesh.list@gmail.com>
On 13/07/26 12:10, Ritesh Harjani (IBM) wrote:
> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
>> On 13/07/26 10:51, Ritesh Harjani (IBM) wrote:
>>> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>>>
>>>> Changelog:
>>>> ==========
>>>>
>>>> v2:
>>>> - Move H_WATCHDOG definitions to a common header for shared use
>>>> across pseries code. 1/3
>>>> - Added a new patch to handle pseries watchdog device registration
>>>> failure. 2/3
>>>> - Stop active watchdogs in crash hanlder. 3/3 Ritesh
>>>> - Add suggested-by tag 1/3 & 3/3
>>> Reviewed the changes and mostly looks good with some minor nits added to
>>> the individual patches.
>>>
>>> Small request -
>>> Could you please also update test results with v3 in your changelog
>>> (since you mentioned we are able to reproduce the issue easily with your
>>> test code).
>> I tested this fix with the program I shared in cover letter. The watchdog
>> was successfully stopped even when H_WATCHDOG is called form crash
>> handler. I will share my test details in v3 cover letter also.
>>
>>>
>>> aah one other thing I just noticed since you are ccing stable and you
>>> added a Fixes tag in patch-3.
>>> Patch-3 alone cannot be easily backported now due to patch-1 and
>>> patch-2. There must be a way to define the dependencies if you are
>>> looking for backporting the fix patch to stable tree, please check that
>>> and follow that accordingly in v3.
>> I thought about that as well, but since they are part of the same patch
>> series,
>> I assumed they would be picked together. However, I don't think that
>> will work
>> in all cases.
>>
>> I checked the older commits and noticed that a backport note was added.
>> I think
>> we can do the same for the fix patch. I'll add a note indicating that the
>> following patches should be backported first:
>>
>> powerpc/pseries: Move H_WATCHDOG definitions to a common header
>> powerpc/pseries: Handle and log pseries-wdt registration failures
>>
>> Since these patches are not upstream yet, I'll refer to them by their
>> commit titles.
>>
>> Does that look good to you?
>>
> Documentation/process/stable-kernel-rules.rst
> Note that for a patch series, you do not have to list as prerequisites the
> patches present in the series itself. For example, if you have the following
> patch series::
>
> patch1
> patch2
>
> where patch2 depends on patch1, you do not have to list patch1 as
> prerequisite of patch2 if you have already marked patch1 for stable
> inclusion.
>
>
> In that case, I think, we should mark all 3 patches for stable inclusion.
>
> patch 1/3 Cc: stable@vger.kernel.org
> patch 2/3 Cc: stable@vger.kernel.org
> patch 3/3 Cc: stable@vger.kernel.org
> Fixes: 69472ffa6575 ("watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers"
Okay, for stable tree inclusion, CCing is enough.
Thanks
Sourabh Jain
^ permalink raw reply
* Re: [PATCH next] drivers/bus/fsl-mc: Use strscpy() to copy strings into arrays
From: Ioana Ciornei @ 2026-07-13 11:08 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: david.laight.linux, Kees Cook, Arnd Bergmann, linux-kernel,
linux-hardening, linuxppc-dev
In-Reply-To: <dbd95f4c-cef3-4f7f-8619-375fe37c8852@kernel.org>
On Sat, Jul 04, 2026 at 11:10:18AM +0200, Christophe Leroy (CS GROUP) wrote:
>
>
> Le 08/06/2026 à 11:54, david.laight.linux@gmail.com a écrit :
> > From: David Laight <david.laight.linux@gmail.com>
> >
> > Replacing strcpy() with strscpy() ensures than overflow of the target
> > buffer cannot happen.
> >
> > Signed-off-by: David Laight <david.laight.linux@gmail.com>
> > ---
> > This is one of a group of patches that remove potentially unbounded
> > strcpy() calls.
> >
> > They are mostly replaced by strscpy() or, when strlen() has just been
> > called, with memcpy() (usually including the '\0').
> >
> > Calls with copy string literals into arrays are left unchanged.
> > They are safe and easily detected as such.
> >
> > The changes were made by getting the compiler to detect the calls and
> > then fixing the code by hand.
> >
> > Note that all the changes are only compile tested.
> >
> > Some Makefiles were changed to allow files to contain strcpy().
> > As well as 'difficult to fix' files, this included 'show' functions
> > as they really need to use sysfs_emit() or seq_printf().
> >
> > All the patches are being sent individually to avoid very long cc lists.
> > Apologies for the terse commit messages and likely unexpected tags.
> > (There are about 100 patches in total.)
> >
> > drivers/bus/fsl-mc/fsl-mc-bus.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Do you expect this patch to go via individual trees or will you apply them
> all together in a given tree ?
>
> Ioana, as usual I can take it via soc/fsl/ with your Ack.
Yes, you can take the patch through soc/fsl.
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
^ permalink raw reply
* Re: [PATCH v3 11/20] pmdomain: imx: use platform_device_set_of_node()
From: Ulf Hansson @ 2026-07-13 10:29 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Andy Shevchenko,
Joerg Roedel, Will Deacon, Robin Murphy, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Matthew Brost, Thomas Hellström, Rodrigo Vivi,
David Airlie, Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu,
Philipp Zabel, Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86,
mfd
In-Reply-To: <20260706-pdev-fwnode-ref-v3-11-1ff028e33779@oss.qualcomm.com>
On Mon, Jul 6, 2026 at 2:45 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
>
> Ahead of reworking the reference counting logic for platform devices,
> encapsulate the assignment of the OF node for dynamically allocated
> platform devices with the provided helper.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
If not too late, feel free to add:
Acked-by: Ulf Hansson <ulfh@kernel.org>
Kind regards
Uffe
> ---
> drivers/pmdomain/imx/gpc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c
> index 42e50c9b4fb9ffb96a20a462d4eb5168942a893c..abca5f449a226fbae4213926e1395c413160c950 100644
> --- a/drivers/pmdomain/imx/gpc.c
> +++ b/drivers/pmdomain/imx/gpc.c
> @@ -487,8 +487,7 @@ static int imx_gpc_probe(struct platform_device *pdev)
> domain->ipg_rate_mhz = ipg_rate_mhz;
>
> pd_pdev->dev.parent = &pdev->dev;
> - pd_pdev->dev.of_node = of_node_get(np);
> - pd_pdev->dev.fwnode = of_fwnode_handle(np);
> + platform_device_set_of_node(pd_pdev, np);
>
> ret = platform_device_add(pd_pdev);
> if (ret) {
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: powernv_rng_read: Oops: Kernel access of bad area, sig: 11 [#1]
From: Paul Menzel @ 2026-07-13 10:02 UTC (permalink / raw)
To: Madhavan Srinivasan, Olivia Mackall, Herbert Xu, Michael Ellerman,
Jason A. Donenfeld
Cc: linux-crypto, linuxppc-dev, LKML
In-Reply-To: <b507beef-3e1c-46d7-a434-d0235dace30b@molgen.mpg.de>
Dear Madhavan, dear Jason,
Am 11.05.26 um 10:03 schrieb Paul Menzel:
> Am 11.05.26 um 09:00 schrieb Paul Menzel:
>
>> Am 07.05.26 um 04:40 schrieb Madhavan Srinivasan:
>>>
>>> On 5/6/26 7:31 PM, Paul Menzel wrote:
>>
>>>> After a long while, on the 8335-GCA POWER8 (raw) 0x4d0200
>>>> opal:skiboot-5.4.8-5787ad3 PowerNV, I built Linux from Linus’ master
>>>> branch and rebooted via kexec.
>>>>
>>>> ```
>>>> [ 0.000000] Linux version 7.1.0-rc2+ (pmenzel@flughafenberlinbrandenburgwillybrandt.molgen.mpg.de) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #3 SMP PREEMPT Wed May 6 08:50:58 CEST 2026
>>>> […]
>>>> [ 17.901992] Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
>>>> [ 17.902011] BUG: Kernel NULL pointer dereference on read at 0x00000000
>>>> [ 17.902018] Faulting instruction address: 0xc0000000000e7138
>>>> [ 17.902027] Oops: Kernel access of bad area, sig: 11 [#1]
>>>> [ 17.902034] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>>>> [ 17.902045] Modules linked in: powernv_rng(+) bnx2x ofpart ibmpowernv bfq mdio cmdlinepart powernv_flash ipmi_powernv ipmi_devintf mtd ipmi_msghandler at24(+) vmx_crypto opal_prd sch_fq_codel nfsd parport_pc ppdev auth_rpcgss nfs_acl lp lockd grace parport sunrpc autofs4 btrfs xor libblake2b raid6_pq ast drm_shmem_helper drm_client_lib i2c_algo_bit drm_kms_helper drm ahci drm_panel_orientation_quirks libahci
>>>> [ 17.902185] CPU: 147 UID: 0 PID: 2626 Comm: hwrng Not tainted 7.1.0-rc2+ #3 PREEMPTLAZY
>>>> [ 17.902197] Hardware name: 8335-GCA POWER8 (raw) 0x4d0200 opal:skiboot-5.4.8-5787ad3 PowerNV
>>>> [ 17.902204] NIP: c0000000000e7138 LR: c00800001ec8013c CTR: c0000000000e70fc
>>>> [ 17.902212] REGS: c000000092913c50 TRAP: 0300 Not tainted (7.1.0-rc2+)
>>>> [ 17.902222] MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 44420220 XER: 20000000
>>>> [ 17.902269] CFAR: c00800001ec8026c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
>>>> GPR00: c00800001ec8013c c000000092913ef0 c000000001c18100 c00000002222d900
>>>> GPR04: c00000002222d900 0000000000000080 0000000000000001 0000000000000000
>>>> GPR08: 0000000000000000 c000000002212000 c0000000951e1780 c00800001ec80258
>>>> GPR12: c0000000000e70fc c00000ffff6fd700 c0000000001d11c0 c00000001b99b9c0
>>>> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>>> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>>> GPR24: 0000000000000000 c000000002fe6a58 0000000000000000 0000000000000000
>>>> GPR28: c000000002fe6a20 0000000000000010 000000000000000f c00000002222d900
>>>> [ 17.902406] NIP [c0000000000e7138] pnv_get_random_long+0x3c/0x114
>>>> [ 17.902426] LR [c00800001ec8013c] powernv_rng_read+0x78/0xc4 [powernv_rng]
>>>> [ 17.902444] Call Trace:
>>>> [ 17.902448] [c000000092913ef0] [c000000092913f30] 0xc000000092913f30 (unreliable)
>>>> [ 17.902463] [c000000092913f30] [c000000000decd58] hwrng_fillfn+0xd4/0x3dc
>>>> [ 17.902484] [c000000092913f90] [c0000000001d1328] kthread+0x170/0x1a4
>>>> [ 17.902498] [c000000092913fe0] [c00000000000d030] start_kernel_thread+0x14/0x18
>>>> [ 17.902513] Code: 60000000 7d2000a6 71290010 418200bc e94d0908 812a0000 39290001 912a0000 e90d0030 3d220060 39299f00 7d08482a <e9280000> 7c0004ac e8e90000 0c070000
>>>> [ 17.902569] ---[ end trace 0000000000000000 ]---
>>>> [ 18.008801] pstore: backend (nvram) writing error (-1)
>>>>
>>>> [ 18.015458] note: hwrng[2626] exited with irqs disabled
>>>> [ 18.015483] note: hwrng[2626] exited with preempt_count 1
>>>> ```
>>>>
>>>> Please find the output of `dmesg` attached.
>>>
>>> This is from my yesterday's boot test log in my P8, did not see this
>>> fail.
>>>
>>> root@ltcppm1:~# uname -a
>>> Linux ltcppm1.ltc.tadn.ibm.com 7.1.0-rc2-00021-gf583bd5f64d4 #1 SMP
>>> PREEMPT Wed May 6 00:55:45 EDT 2026 ppc64le GNU/Linux
>>> root@ltcppm1:~# dmesg
>>> [ 0.000000] [ T0] random: crng init done
>>> [ 0.000000] [ T0] hash-mmu: Page sizes from device-tree:
>>> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=0
>>> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=16, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=7
>>> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=24, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=56
>>> [ 0.000000] [ T0] hash-mmu: base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=1
>>> [ 0.000000] [ T0] hash-mmu: base_shift=16: shift=24, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=8
>>> [ 0.000000] [ T0] hash-mmu: base_shift=24: shift=24, sllp=0x0100, avpnm=0x00000001, tlbiel=0, penc=0
>>> [ 0.000000] [ T0] hash-mmu: base_shift=34: shift=34, sllp=0x0120, avpnm=0x000007ff, tlbiel=0, penc=3
>>> [ 0.000000] [ T0] Enabling pkeys with max key count 32
>>> [ 0.000000] [ T0] Activating Kernel Userspace Access Prevention
>>> [ 0.000000] [ T0] Activating Kernel Userspace Execution Prevention
>>> [ 0.000000] [ T0] hash-mmu: Page orders: linear mapping = 24, virtual = 16, io = 16, vmemmap = 24
>>> [ 0.000000] [ T0] hash-mmu: Using 1TB segments
>>> [ 0.000000] [ T0] hash-mmu: Initializing hash mmu with SLB
>>> [ 0.000000] [ T0] Linux version 7.1.0-rc2-00021-gf583bd5f64d4 (root@ltcppm1.ltc.tadn.ibm.com) (gcc (GCC) 16.1.1 20260501 (Red Hat 16.1.1-1), GNU ld version 2.46-1.fc44) #1 SMP PREEMPT Wed May 6 00:55:45 EDT 2026
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000039c00000..0x000000003b6801ff (27136 KiB) map non-reusable ibm,firmware-allocs-memory@39c00000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000800000000..0x0000000800e801ff (14848 KiB) map non-reusable ibm,firmware-allocs-memory@800000000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001000000000..0x0000001000dc01ff (14080 KiB) map non-reusable ibm,firmware-allocs-memory@1000000000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001800000000..0x0000001800e801ff (14848 KiB) map non-reusable ibm,firmware-allocs-memory@1800000000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000030000000..0x00000000302fffff (3072 KiB) map non-reusable ibm,firmware-code@30000000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000031000000..0x0000000031bfffff (12288 KiB) map non-reusable ibm,firmware-data@31000000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000030300000..0x0000000030ffffff (13312 KiB) map non-reusable ibm,firmware-heap@30300000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000031c00000..0x0000000033fdffff (36736 KiB) map non-reusable ibm,firmware-stacks@31c00000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd510000..0x0000001ffd69ffff (1600 KiB) map non-reusable ibm,hbrt-code-image@1ffd510000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd6a0000..0x0000001ffd6fffff (384 KiB) map non-reusable ibm,hbrt-target-image@1ffd6a0000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd700000..0x0000001ffd7fffff (1024 KiB) map non-reusable ibm,hbrt-vpd-image@1ffd700000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffda00000..0x0000001ffdafffff (1024 KiB) map non-reusable ibm,slw-image@1ffda00000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffde00000..0x0000001ffdefffff (1024 KiB) map non-reusable ibm,slw-image@1ffde00000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffe200000..0x0000001ffe2fffff (1024 KiB) map non-reusable ibm,slw-image@1ffe200000
>>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffe600000..0x0000001ffe6fffff (1024 KiB) map non-reusable ibm,slw-image@1ffe600000
>>> [ 0.000000] [ T0] Found initrd at 0xc000000006a40000:0xc00000000815ae9e
>>> [ 0.000000] [ T0] Hardware name: 8247-22L POWER8E (raw) 0x4b0201 opal:skiboot-v5.4.12 PowerNV
>>> [ 0.000000] [ T0] printk: legacy bootconsole [udbg0] enabled
>>> [ 0.000000] [ T0] CPU maps initialized for 8 threads per core
>>> [ 0.000000] [ T0] (thread shift is 3)
>>>>> But I my opal version 5.4.12.
>>>
>>> Thanks for reporting the issue, will have an look at it.
>>
>> I bisected it to a change between 5.19-rc3 and 5.19-rc4, and merge
>> commit 8100775d59a6 (Merge tag 'powerpc-5.19-3' of git://
>> git.kernel.org/ pub/scm/linux/kernel/git/powerpc/linux) [1] indeed has
>> rng related changes
>>
>>> - Three fixes to wire up our various RNGs earlier in boot so they're
>>> available for use in the initial seeding in random_init().
>
> I confirmed, that commit f3eac426657d (powerpc/powernv: wire up rng
> during setup_arch) [2] introduced the Oops.
>
>>> [ 0.000000] [ T0] Allocated 4608 bytes for 160 pacas
>>> [ 0.000000] [ T0]
>>> -----------------------------------------------------
>>>
>>> .......
>>>
>>> [ 37.407674] [ T900] audit: type=1130 audit(1778043621.931:10): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-monitor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
>>> [ 37.413015] [ T900] audit: type=1130 audit(1778043621.937:11): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-sysctl comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
>>> [ 38.448156] [ T2286] powernv_rng: Registered powernv hwrng.
>>> [ 38.575227] [ T2264] tg3 0005:09:00.1 enP5p9s0f1: renamed from eth1
>>> [ 38.582176] [ T2223] tg3 0005:09:00.2 enP5p9s0f2: renamed from eth2
>>> ........
>>>
>>> ////cpuinfo output
>>>
>>> processor : 159
>>>
>>> cpu : POWER8E (raw), altivec supported
>>> clock : 2061.000000MHz
>>> revision : 2.1 (pvr 004b 0201)
>>>
>>> timebase : 512000000
>>> platform : PowerNV
>>> model : 8247-22L
>>> machine : PowerNV 8247-22L
>>> firmware : OPAL
>>> MMU : Hash
>>>
>>>
>>> But my system opal version 5.4.12.
>>> Thanks for reporting the issue, will have an look at it.
Were you able to take a look? I sent in a patch [3], that hasn’t gotten
any response.
Kind regards,
Paul
>> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8100775d59a6789c3c6c309de26fac52f129cba8
> [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f3eac426657d985b97c92fa5f7ae1d43f04721f3
[3]:
https://lore.kernel.org/all/20260511120413.254934-2-pmenzel@molgen.mpg.de/
^ permalink raw reply
* Re: [PATCH v2] powerpc/ps3: Remove unused struct table in setup_areas()
From: Amit Machhiwal @ 2026-07-13 9:27 UTC (permalink / raw)
To: Thorsten Blum
Cc: Geoff Levand, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Amit Machhiwal,
Geert Uytterhoeven, linuxppc-dev, linux-kernel
In-Reply-To: <20260713091731.97212-3-thorsten.blum@linux.dev>
On 2026/07/13 11:17 AM, Thorsten Blum wrote:
> The local table structure is not used - remove it.
>
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> Changes in v2:
> - Drop the %0 change because it is valid kernel-doc markup (Amit)
Thanks for addressing the comment and sending a v2!
Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
~Amit
> - v1: https://lore.kernel.org/r/20260712151300.3664-3-thorsten.blum@linux.dev/
> ---
> arch/powerpc/platforms/ps3/spu.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
> index e817def7f424..2c785bc72565 100644
> --- a/arch/powerpc/platforms/ps3/spu.c
> +++ b/arch/powerpc/platforms/ps3/spu.c
> @@ -190,8 +190,6 @@ static void spu_unmap(struct spu *spu)
>
> static int __init setup_areas(struct spu *spu)
> {
> - struct table {char* name; unsigned long addr; unsigned long size;};
> -
> spu_pdata(spu)->shadow = ioremap_prot(spu_pdata(spu)->shadow_addr,
> sizeof(struct spe_shadow),
> pgprot_noncached_wc(PAGE_KERNEL_RO));
^ permalink raw reply
* [PATCH v2] powerpc/ps3: Remove unused struct table in setup_areas()
From: Thorsten Blum @ 2026-07-13 9:17 UTC (permalink / raw)
To: Geoff Levand, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP)
Cc: Amit Machhiwal, Thorsten Blum, Geert Uytterhoeven, linuxppc-dev,
linux-kernel
The local table structure is not used - remove it.
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Changes in v2:
- Drop the %0 change because it is valid kernel-doc markup (Amit)
- v1: https://lore.kernel.org/r/20260712151300.3664-3-thorsten.blum@linux.dev/
---
arch/powerpc/platforms/ps3/spu.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
index e817def7f424..2c785bc72565 100644
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -190,8 +190,6 @@ static void spu_unmap(struct spu *spu)
static int __init setup_areas(struct spu *spu)
{
- struct table {char* name; unsigned long addr; unsigned long size;};
-
spu_pdata(spu)->shadow = ioremap_prot(spu_pdata(spu)->shadow_addr,
sizeof(struct spe_shadow),
pgprot_noncached_wc(PAGE_KERNEL_RO));
^ permalink raw reply related
* Re: [PATCH] powerpc/ps3: Remove unused struct table in setup_areas()
From: Thorsten Blum @ 2026-07-13 9:02 UTC (permalink / raw)
To: Geoff Levand, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), linuxppc-dev,
linux-kernel
In-Reply-To: <20260713134356.62f55781-f6-amachhiw@linux.ibm.com>
On Mon, Jul 13, 2026 at 01:59:02PM +0530, Amit Machhiwal wrote:
> On 2026/07/12 05:13 PM, Thorsten Blum wrote:
> > The local table structure is not used - remove it.
> >
> > Remove % in the comment while at it.
> >
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> > ---
> > arch/powerpc/platforms/ps3/spu.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
> > index e817def7f424..c904f9fa1caa 100644
> > --- a/arch/powerpc/platforms/ps3/spu.c
> > +++ b/arch/powerpc/platforms/ps3/spu.c
> > @@ -185,13 +185,11 @@ static void spu_unmap(struct spu *spu)
> > * The current HV requires the spu shadow regs to be mapped with the
> > * PTE page protection bits set as read-only.
> > *
> > - * Returns: %0 on success or -errno on error.
> > + * Returns: 0 on success or -errno on error.
>
> The % prefix should actually be kept here I think. Per the kernel-doc
> documentation [1]:
>
> %CONST
> Name of a constant. (No cross-referencing, just formatting.)
>
> Examples:
>
> %0 %NULL %-1 %-EFAULT %-EINVAL %-ENOMEM
>
> So %0 is valid and intentional kernel-doc markup that renders the
> constant 0 with proper formatting.
Interesting - not sure I have seen this style before and plain 0 seems
to be far more common. There has been some discussion around it here:
https://lore.kernel.org/all/87ilamz4j5.fsf@meer.lwn.net/
I guess I'll send a v2 without the %0 change.
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH] crypto: powerpc/aes - use bool for encryption/decryption flag
From: Breno Leitao @ 2026-07-13 9:01 UTC (permalink / raw)
To: Thorsten Blum
Cc: Nayna Jain, Paulo Flabiano Smorigo, Herbert Xu, David S. Miller,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), linux-crypto, linuxppc-dev,
linux-kernel
In-Reply-To: <20260711145216.747128-3-thorsten.blum@linux.dev>
On Sat, Jul 11, 2026 at 04:52:17PM +0200, Thorsten Blum wrote:
> Use bool for the CBC encryption/decryption flag passed through
> p8_aes_cbc_crypt() to aes_p8_cbc_encrypt().
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [patch 4/4] entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution
From: Michal Suchánek @ 2026-07-13 8:44 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Michael Ellerman, Shrikanth Hegde, linuxppc-dev,
Huacai Chen, loongarch, Paul Walmsley, Palmer Dabbelt,
linux-riscv, Sven Schnelle, linux-s390, x86, Mark Rutland,
Jinjie Ruan, Magnus Lindholm, Mukesh Kumar Chaurasiya (IBM),
Jonathan Corbet, Radu Rendec
In-Reply-To: <20260712141346.772209074@kernel.org>
Hello,
On Sun, Jul 12, 2026 at 11:25:32PM +0200, Thomas Gleixner wrote:
> The return values of syscall_enter_from_user_mode[_work]() are
> non-intuitive. Both functions return the syscall number which should be
> invoked by the architecture specific syscall entry code. The returned
> number can be:
>
> - the unmodified syscall number which was handed in by the caller
>
> - a modified syscall number (ptrace, seccomp, trace/probe/bpf)
>
> That has an additional twist. If the return value is -1L then the caller is
> not allowed to modify the return value as that indicates that the modifying
> entity requests to abort the syscall and set the return value already. That
> can obviously not be differentiated from a syscall which handed in -1 as
> syscall number.
>
> The most trivial way to deal with that is:
>
> set_return_value(regs, -ENOSYS);
> nr = syscall_enter_from_user_mode(regs, nr);
> if (valid(nr))
> handle_syscall(regs, nr);
>
> That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not
> preset the return value, so when user space hands in -1 and there is
> nothing setting the return value in the entry work code, then the syscall
> is skipped but the return value is whatever random data has been in the
> return value register.
The reason why PowerPC and S390 do not preset the return value is that
the return value uses the same register as the syscall number. There are
apparently other architectures on which the return value overlaps with
the arguments which also do not preset the return value for that reason.
If they would use the generic entry the same problem would arise.
> Change the return values of syscall_enter_from_user_mode[_work]() to
> boolean and return false, when either ptrace or seccomp request to skip the
There is a difference between seccomp and ptrace.
When seccomp indicates to skip the syscall it has also set the syscall
return value.
However, when the syscall number is -1 and the return value is not
preset that does not indicate anything.
The return value can still hold garbage. ptrace does not have the
ability to indicate that a syscall is to be skipped, at least on the
entry trace. It needs to be skipped based on the syscall number being
invalid.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Remove unused struct table in setup_areas()
From: Amit Machhiwal @ 2026-07-13 8:29 UTC (permalink / raw)
To: Thorsten Blum
Cc: Geoff Levand, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), linuxppc-dev,
linux-kernel
In-Reply-To: <20260712151300.3664-3-thorsten.blum@linux.dev>
On 2026/07/12 05:13 PM, Thorsten Blum wrote:
> The local table structure is not used - remove it.
>
> Remove % in the comment while at it.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> arch/powerpc/platforms/ps3/spu.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
> index e817def7f424..c904f9fa1caa 100644
> --- a/arch/powerpc/platforms/ps3/spu.c
> +++ b/arch/powerpc/platforms/ps3/spu.c
> @@ -185,13 +185,11 @@ static void spu_unmap(struct spu *spu)
> * The current HV requires the spu shadow regs to be mapped with the
> * PTE page protection bits set as read-only.
> *
> - * Returns: %0 on success or -errno on error.
> + * Returns: 0 on success or -errno on error.
The % prefix should actually be kept here I think. Per the kernel-doc
documentation [1]:
%CONST
Name of a constant. (No cross-referencing, just formatting.)
Examples:
%0 %NULL %-1 %-EFAULT %-EINVAL %-ENOMEM
So %0 is valid and intentional kernel-doc markup that renders the
constant 0 with proper formatting.
The struct removal part looks good though.
[1]: https://docs.kernel.org/doc-guide/kernel-doc.html#highlights-and-cross-references
~Amit
> */
>
> static int __init setup_areas(struct spu *spu)
> {
> - struct table {char* name; unsigned long addr; unsigned long size;};
> -
> spu_pdata(spu)->shadow = ioremap_prot(spu_pdata(spu)->shadow_addr,
> sizeof(struct spe_shadow),
> pgprot_noncached_wc(PAGE_KERNEL_RO));
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Remove unused struct table in setup_areas()
From: Geert Uytterhoeven @ 2026-07-13 7:25 UTC (permalink / raw)
To: Thorsten Blum
Cc: Geoff Levand, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), linuxppc-dev,
linux-kernel
In-Reply-To: <20260712151300.3664-3-thorsten.blum@linux.dev>
On Sun, 12 Jul 2026 at 17:13, Thorsten Blum <thorsten.blum@linux.dev> wrote:
> The local table structure is not used - remove it.
>
> Remove % in the comment while at it.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
* Re: [PATCH] powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()
From: Geert Uytterhoeven @ 2026-07-13 7:21 UTC (permalink / raw)
To: Thorsten Blum
Cc: Geoff Levand, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Mackerras,
MOKUNO Masakazu, stable, Geoff Levand, linuxppc-dev, linux-kernel
In-Reply-To: <20260711130931.740719-3-thorsten.blum@linux.dev>
On Sat, 11 Jul 2026 at 15:10, Thorsten Blum <thorsten.blum@linux.dev> wrote:
> If lv1_put_iopte() fails in dma_ioc0_map_pages(), the error path
> decrements iopage but keeps using the failed mapping's offset. As a
> result, it repeatedly tries to invalidate the failed IOPTE slot and
> leaves the already installed IOPTEs valid.
>
> Recompute offset and invalidate the installed IOPTEs instead.
>
> Fixes: 6bb5cf102541 ("[POWERPC] PS3: System-bus rework")
> Cc: stable@vger.kernel.org
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
* Re: [patch 06/18] riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack()
From: Guo Ren @ 2026-07-13 7:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Peter Zijlstra, Paul Walmsley, Palmer Dabbelt, linux-riscv,
Michael Ellerman, Shrikanth Hegde, linuxppc-dev, Kees Cook,
Huacai Chen, loongarch, Sven Schnelle, linux-s390, x86,
Mark Rutland, Jinjie Ruan, Andy Lutomirski, Oleg Nesterov,
Richard Henderson, Russell King, Catalin Marinas,
Geert Uytterhoeven, Thomas Bogendoerfer, Helge Deller,
Yoshinori Sato, Richard Weinberger, Chris Zankel,
linux-arm-kernel, linux-alpha, linux-csky, linux-m68k, linux-mips,
linux-parisc, linux-sh, linux-um, Arnd Bergmann, Vineet Gupta,
Will Deacon, Brian Cain, Michal Simek, Dinh Nguyen,
David S. Miller, Andreas Larsson, linux-snps-arc, linux-hexagon,
linux-openrisc, sparclinux, linux-arch, Michal Suchánek,
Jonathan Corbet, linux-doc
In-Reply-To: <20260707190253.974626922@kernel.org>
On Wed, Jul 8, 2026 at 3:06 AM Thomas Gleixner <tglx@kernel.org> wrote:
>
> syscall_enter_from_user_mode_randomize_stack() replaces
> syscall_enter_from_user_mode() and the subsequent invocation of
> add_random_kstack_offset().
>
> The advantage is that it applies the stack randomization right after
> enter_from_user_mode() and thereby avoids the overhead of get/put_cpu_var()
> as that code is invoked with interrupts disabled.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Paul Walmsley <pjw@kernel.org>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: linux-riscv@lists.infradead.org
> ---
> arch/riscv/kernel/traps.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> --- a/arch/riscv/kernel/traps.c
> +++ b/arch/riscv/kernel/traps.c
> @@ -7,7 +7,6 @@
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/irqflags.h>
> -#include <linux/randomize_kstack.h>
> #include <linux/sched.h>
> #include <linux/sched/debug.h>
> #include <linux/sched/signal.h>
> @@ -333,9 +332,7 @@ void do_trap_ecall_u(struct pt_regs *reg
>
> riscv_v_vstate_discard(regs);
>
> - syscall = syscall_enter_from_user_mode(regs, syscall);
> -
> - add_random_kstack_offset();
> + syscall = syscall_enter_from_user_mode_randomize_stack(regs, syscall);
Reviewed-by: Guo Ren <guoren@kernel.org>
--
Best Regards
Guo Ren
^ permalink raw reply
* Re: [PATCH RESEND] syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
From: Thomas Weißschuh @ 2026-07-13 7:01 UTC (permalink / raw)
To: Jinjie Ruan
Cc: chenhuacai, kernel, maddy, mpe, npiggin, chleroy, pjw, palmer,
aou, alex, hca, gor, agordeev, borntraeger, svens, tglx, mingo,
bp, dave.hansen, hpa, nathan, kees, xur, arnd, peterz, gourry,
lukas.bulwahn, ryan.roberts, yangtiezhu, mchauras, sshegde,
austin.kim, jchrist, x86, linux-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390
In-Reply-To: <20260713035422.582771-1-ruanjinjie@huawei.com>
On Mon, Jul 13, 2026 at 11:54:22AM +0800, Jinjie Ruan wrote:
> Currently, only x86 genuinely implements and supports Syscall User
> Dispatch (SUD). Multiple architectures provide a stub
> arch_syscall_is_vdso_sigreturn() returning 'false' simply to satisfy
> GENERIC_ENTRY compilation, which creates a false impression of feature
> support.
>
> Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH to decouple this mechanism
> from GENERIC_ENTRY. Select it exclusively on x86 and remove the redundant
> stub functions from other architectures.
>
> Link: https://lore.kernel.org/linux-arm-kernel/akZgV0Y4YAmB43_g@J2N7QTR9R3.cambridge.arm.com/
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Gregory Price <gourry@gourry.net>
> Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> v1 -> RESEND
> - Define missing ARCH_SUPPORTS_SYSCALL_USER_DISPATCH.
If code is changed it is not a resend. Instead it should have been v2.
> ---
> arch/Kconfig | 4 ++++
> arch/loongarch/include/asm/syscall.h | 6 ------
> arch/powerpc/include/asm/syscall.h | 5 -----
> arch/riscv/include/asm/syscall.h | 5 -----
> arch/s390/include/asm/syscall.h | 5 -----
> arch/x86/Kconfig | 1 +
> 6 files changed, 5 insertions(+), 21 deletions(-)
(...)
^ permalink raw reply
* Re: [PATCH v2 0/3] powerpc/crash: protect kdump from active watchdogs
From: Ritesh Harjani @ 2026-07-13 6:40 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev, maddy, mpe
Cc: npiggin, chleroy, shivangu, hbathini, mahesh, adityag, venkat88,
stable
In-Reply-To: <91e04278-aa90-4cbc-aeb4-f4663bf1f058@linux.ibm.com>
Sourabh Jain <sourabhjain@linux.ibm.com> writes:
> On 13/07/26 10:51, Ritesh Harjani (IBM) wrote:
>> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>>
>>> Changelog:
>>> ==========
>>>
>>> v2:
>>> - Move H_WATCHDOG definitions to a common header for shared use
>>> across pseries code. 1/3
>>> - Added a new patch to handle pseries watchdog device registration
>>> failure. 2/3
>>> - Stop active watchdogs in crash hanlder. 3/3 Ritesh
>>> - Add suggested-by tag 1/3 & 3/3
>>
>> Reviewed the changes and mostly looks good with some minor nits added to
>> the individual patches.
>>
>> Small request -
>> Could you please also update test results with v3 in your changelog
>> (since you mentioned we are able to reproduce the issue easily with your
>> test code).
>
> I tested this fix with the program I shared in cover letter. The watchdog
> was successfully stopped even when H_WATCHDOG is called form crash
> handler. I will share my test details in v3 cover letter also.
>
>>
>>
>> aah one other thing I just noticed since you are ccing stable and you
>> added a Fixes tag in patch-3.
>> Patch-3 alone cannot be easily backported now due to patch-1 and
>> patch-2. There must be a way to define the dependencies if you are
>> looking for backporting the fix patch to stable tree, please check that
>> and follow that accordingly in v3.
>
> I thought about that as well, but since they are part of the same patch
> series,
> I assumed they would be picked together. However, I don't think that
> will work
> in all cases.
>
> I checked the older commits and noticed that a backport note was added.
> I think
> we can do the same for the fix patch. I'll add a note indicating that the
> following patches should be backported first:
>
> powerpc/pseries: Move H_WATCHDOG definitions to a common header
> powerpc/pseries: Handle and log pseries-wdt registration failures
>
> Since these patches are not upstream yet, I'll refer to them by their
> commit titles.
>
> Does that look good to you?
>
Documentation/process/stable-kernel-rules.rst
Note that for a patch series, you do not have to list as prerequisites the
patches present in the series itself. For example, if you have the following
patch series::
patch1
patch2
where patch2 depends on patch1, you do not have to list patch1 as
prerequisite of patch2 if you have already marked patch1 for stable
inclusion.
In that case, I think, we should mark all 3 patches for stable inclusion.
patch 1/3 Cc: stable@vger.kernel.org
patch 2/3 Cc: stable@vger.kernel.org
patch 3/3 Cc: stable@vger.kernel.org
Fixes: 69472ffa6575 ("watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers")
-ritesh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox