* Re: [PATCH v2 05/20] drm/colorop: Create drm_atomic_helper_colorop_create_state()
From: Thomas Zimmermann @ 2026-04-21 13:13 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-5-c63f1134e76c@kernel.org>
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software state, reset it,
> but also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> And reset() isn't fallible, which makes it harder to handle
> initialization errors properly.
>
> It's also only relevant for some drivers, since all the helpers for
> reset only create a new state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect: atomic_create_state
> to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Let's continue the transition to the new pattern with drm_colorop.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/drm_colorop.c | 23 +++++++++++++++++++++++
> include/drm/drm_colorop.h | 2 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index 6a26b83b260e8d8e83c703ecde490a7a8740ebfb..7bfaf2617ec315f42d80ac72a5eaaef868e65657 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -521,10 +521,33 @@ static void __drm_colorop_state_init(struct drm_colorop_state *colorop_state,
> &val);
> colorop_state->curve_1d_type = val;
> }
> }
>
> +/**
> + * drm_atomic_helper_colorop_create_state - Allocates and initializes colorop atomic state
> + * @colorop: drm colorop
> + *
> + * Initializes a pristine @drm_colorop_state.
> + *
> + * RETURNS:
> + * Pointer to new colorop state, or ERR_PTR on failure.
> + */
> +struct drm_colorop_state *
> +drm_atomic_helper_colorop_create_state(struct drm_colorop *colorop)
> +{
> + struct drm_colorop_state *state;
> +
> + state = kzalloc_obj(*state);
> + if (!state)
> + return ERR_PTR(-ENOMEM);
> +
> + __drm_colorop_state_init(state, colorop);
> +
> + return state;
> +}
> +
> /**
> * __drm_colorop_reset - reset state on colorop
> * @colorop: drm colorop
> * @colorop_state: colorop state to assign
> *
> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> index bd082854ca74cac90b42020b09206a8516687666..874ed693329c0ecf94567c094744fe86fd08e382 100644
> --- a/include/drm/drm_colorop.h
> +++ b/include/drm/drm_colorop.h
> @@ -423,10 +423,12 @@ int drm_plane_colorop_3dlut_init(struct drm_device *dev, struct drm_colorop *col
> struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
> uint32_t lut_size,
> enum drm_colorop_lut3d_interpolation_type interpolation,
> uint32_t flags);
>
> +struct drm_colorop_state *
> +drm_atomic_helper_colorop_create_state(struct drm_colorop *colorop);
> struct drm_colorop_state *
> drm_atomic_helper_colorop_duplicate_state(struct drm_colorop *colorop);
>
> void drm_colorop_atomic_destroy_state(struct drm_colorop *colorop,
> struct drm_colorop_state *state);
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 04/20] drm/colorop: Rename __drm_colorop_state_reset()
From: Thomas Zimmermann @ 2026-04-21 13:13 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-4-c63f1134e76c@kernel.org>
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> __drm_colorop_state_reset() is used to initialize a newly allocated
> drm_colorop_state, and is being typically called by drm_colorop_reset().
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_colorop_state instance, we will need to call
> __drm_colorop_state_reset() from both the reset and atomic_create paths.
>
> To avoid any confusion, we can thus rename __drm_colorop_state_reset()
> to __drm_colorop_state_init().
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
This makes sense considering the next patch
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/drm_colorop.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index 373cd0ddb8fd4478874509ed12c95451c1f66203..6a26b83b260e8d8e83c703ecde490a7a8740ebfb 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -498,19 +498,19 @@ void drm_colorop_atomic_destroy_state(struct drm_colorop *colorop,
> __drm_atomic_helper_colorop_destroy_state(state);
> kfree(state);
> }
>
> /**
> - * __drm_colorop_state_reset - resets colorop state to default values
> + * __drm_colorop_state_init - Initializes colorop state to default values
> * @colorop_state: atomic colorop state, must not be NULL
> * @colorop: colorop object, must not be NULL
> *
> * Initializes the newly allocated @colorop_state with default
> * values. This is useful for drivers that subclass the colorop state.
> */
> -static void __drm_colorop_state_reset(struct drm_colorop_state *colorop_state,
> - struct drm_colorop *colorop)
> +static void __drm_colorop_state_init(struct drm_colorop_state *colorop_state,
> + struct drm_colorop *colorop)
> {
> u64 val;
>
> colorop_state->colorop = colorop;
> colorop_state->bypass = true;
> @@ -537,11 +537,11 @@ static void __drm_colorop_state_reset(struct drm_colorop_state *colorop_state,
> */
> static void __drm_colorop_reset(struct drm_colorop *colorop,
> struct drm_colorop_state *colorop_state)
> {
> if (colorop_state)
> - __drm_colorop_state_reset(colorop_state, colorop);
> + __drm_colorop_state_init(colorop_state, colorop);
>
> colorop->state = colorop_state;
> }
>
> void drm_colorop_reset(struct drm_colorop *colorop)
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 03/20] drm/mode-config: Mention drm_mode_config_reset() culprits
From: Thomas Zimmermann @ 2026-04-21 13:08 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260320-drm-mode-config-init-v2-3-c63f1134e76c@kernel.org>
Hi
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> drm_mode_config_reset() does not reset drm_private_states by design.
>
> This is especially significant for the DP MST and tunneling code that
> expect to be preserved across a suspend/resume cycle, where
> drm_mode_config_reset() is also used.
Do we really? There's drm_mode_config_helper_suspend/resume(). Why would
drivers do a drm_mode_config_reset().
Best regards
Thomas
>
> Let's document this expectation.
>
> Link: https://lore.kernel.org/dri-devel/aOaQLx-7EpsHRwkH@ideak-desk/
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_mode_config.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 66f7dc37b5970c0a08f8dde008aef56376c59f37..cba527571ca66d3aa6dc652c87e03a19815d1d41 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -187,10 +187,14 @@ int drm_mode_getresources(struct drm_device *dev, void *data,
> * @dev: drm device
> *
> * This functions calls all the crtc's, encoder's and connector's ->reset
> * callback. Drivers can use this in e.g. their driver load or resume code to
> * reset hardware and software state.
> + *
> + * Note that @drm_private_obj structures are expected to be stable across
> + * suspend/resume cycles, and @drm_mode_config_reset() does not affect these
> + * structures.
> */
> void drm_mode_config_reset(struct drm_device *dev)
> {
> struct drm_crtc *crtc;
> struct drm_colorop *colorop;
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [RFC, PATCH 00/12] userfaultfd: working set tracking for VM guest memory
From: David Hildenbrand (Arm) @ 2026-04-21 13:03 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Andrew Morton, Peter Xu, Lorenzo Stoakes, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Liam R . Howlett, Zi Yan,
Jonathan Corbet, Shuah Khan, Sean Christopherson, Paolo Bonzini,
linux-mm, linux-kernel, linux-doc, linux-kselftest, kvm
In-Reply-To: <aeTnlQUOOh-dHG8z@thinkstation>
On 4/19/26 16:33, Kiryl Shutsemau wrote:
> On Fri, Apr 17, 2026 at 01:26:34PM +0100, Kiryl Shutsemau wrote:
>>> Leaving NUMA-balancing aside, a simple
>>> mprotect(PROT_NONE)+mprotect(PROT_READ) would already be problematic to
>>> distinguish both cases.
>>
>> Hm. I didn't consider this case (miss some uffd lore). Will rework to
>> reuse existing PTE bit.
>
> See https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git uffd/rfc-v3
>
Quick feedback from skimming over it:
1) ARCH_SUPPORTS_PROT_NONE needs some thought, because I am pretty sure all
architectures support something like mprotect(PROT_NONE), and the config
option might be misleading.
So you very likely want to express different semantics here. You want to
know whether pte_protnone()/pmd_protnone() works.
2) The other stuff is really just an extension of existing WP handling.
I suspect we want to have some reasonable cleanups to not end up in
common code with
@@ -1841,7 +1841,7 @@ static void copy_huge_non_present_pmd(
add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR);
mm_inc_nr_ptes(dst_mm);
pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable);
- if (!userfaultfd_wp(dst_vma))
+ if (!userfaultfd_wp(dst_vma) && !userfaultfd_rwp(dst_vma))
pmd = pmd_swp_clear_uffd_wp(pmd);
set_pmd_at(dst_mm, addr, dst_pmd, pmd);
All the uffd handling should be better isolated (i.e., a single vma check?),
and likely the uffd bit should be abstracted away from being called "wp" to
something more generic.
Maybe it's simply a "uffd" flag which's semantics depend
on the vma flags.
Maybe something like:
@@ -1841,7 +1841,7 @@ static void copy_huge_non_present_pmd(
add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR);
mm_inc_nr_ptes(dst_mm);
pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable);
if (!userfaultfd_uses_pte_bit(dst_vma))
pmd = pmd_swp_clear_uffd(pmd);
set_pmd_at(dst_mm, addr, dst_pmd, pmd);
Not sure, needs another thought. But I think there are some decent
cleanups to be had.
3) Some other stuff needs a second thought, like
diff --git a/mm/gup.c b/mm/gup.c
index 8e7dc2c6ee738..08fc18f1290d4 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -695,7 +695,8 @@ static inline bool can_follow_write_pmd(pmd_t pmd, struct page *page,
/* ... and a write-fault isn't required for other reasons. */
if (pmd_needs_soft_dirty_wp(vma, pmd))
return false;
- return !userfaultfd_huge_pmd_wp(vma, pmd);
+ return !userfaultfd_huge_pmd_wp(vma, pmd) &&
+ !userfaultfd_huge_pmd_rwp(vma, pmd);
}
How can a pte be writable and prot_none at the same time? Maybe just confused AI
output that you should carefully double check before sending that out officially.
4) How do we want to handle PM_UFFD_WP?
We are pretty much out of flags soon. Overloading PM_UFFD_WP means that we will not
be able to easily support using a separate bit.
But our internal design will not easily allow that either, and I am not really
sure we want to go down that path any time soon.
Maybe we could document this for now as "In WP VMAs, indicated WP PTEs.
Otherwise, in RWP VMAs, indicates RWP.". Whenever we would allow both at the
same time, we could change the semantics. User space would fail to create one
with both protection types for now either way.
--
Cheers,
David
^ permalink raw reply related
* Re: [PATCH v2 02/20] drm/atomic: Drop drm_private_state.obj assignment from create_state
From: Thomas Zimmermann @ 2026-04-21 13:03 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-2-c63f1134e76c@kernel.org>
Hi
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> The initial intent of the atomic_create_state helper was to simply
> allocate a proper drm_private_state and returning it, without any side
> effect.
>
> However, the __drm_atomic_helper_private_obj_create_state() introduces a
> side effect by setting the drm_private_obj.state to the newly allocated
> state.
>
> This assignment defeats the purpose, but is also redundant since
> the only caller, drm_atomic_private_obj_init(), will also set this
> pointer to the newly allocated state.
Is this paragraph no longer up to date? Grepping for
__drm_atomic_helper_private_obj_create_state returns plenty of callers.
Best regards Thomas
>
> Let's drop the assignment in __drm_atomic_helper_private_obj_create_state().
>
> Fixes: e7be39ed1716 ("drm/atomic-helper: Add private_obj atomic_create_state helper")
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 76746ad4a1bbb7142c067c93dd05fbec5d2f98eb..875149494b00e1eb7481e87d7d7038103b72b7e3 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -729,12 +729,10 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_destroy_state);
> void __drm_atomic_helper_private_obj_create_state(struct drm_private_obj *obj,
> struct drm_private_state *state)
> {
> if (state)
> state->obj = obj;
> -
> - obj->state = state;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_private_obj_create_state);
>
> /**
> * __drm_atomic_helper_private_obj_duplicate_state - copy atomic private state
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 01/20] drm/colorop: Fix typos in the doc
From: Thomas Zimmermann @ 2026-04-21 13:01 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-1-c63f1134e76c@kernel.org>
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> In the documentation of drm_colorop introduced by commit cfc27680ee20
> ("drm/colorop: Introduce new drm_colorop mode object"), the
> documentation of __drm_colorop_state_reset() and __drm_colorop_reset()
> were mentioning CRTC when they really meant colorop, probably due to
> copy and paste.
>
> Fixes: cfc27680ee20 ("drm/colorop: Introduce new drm_colorop mode object")
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/drm_colorop.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index 566816e3c6f0c7d172534966fcfe56982e6505f3..373cd0ddb8fd4478874509ed12c95451c1f66203 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -503,11 +503,11 @@ void drm_colorop_atomic_destroy_state(struct drm_colorop *colorop,
> * __drm_colorop_state_reset - resets colorop state to default values
> * @colorop_state: atomic colorop state, must not be NULL
> * @colorop: colorop object, must not be NULL
> *
> * Initializes the newly allocated @colorop_state with default
> - * values. This is useful for drivers that subclass the CRTC state.
> + * values. This is useful for drivers that subclass the colorop state.
> */
> static void __drm_colorop_state_reset(struct drm_colorop_state *colorop_state,
> struct drm_colorop *colorop)
> {
> u64 val;
> @@ -526,14 +526,14 @@ static void __drm_colorop_state_reset(struct drm_colorop_state *colorop_state,
> /**
> * __drm_colorop_reset - reset state on colorop
> * @colorop: drm colorop
> * @colorop_state: colorop state to assign
> *
> - * Initializes the newly allocated @colorop_state and assigns it to
> - * the &drm_crtc->state pointer of @colorop, usually required when
> - * initializing the drivers or when called from the &drm_colorop_funcs.reset
> - * hook.
> + * Initializes the newly allocated @colorop_state and assigns it to the
> + * &drm_colorop->state pointer of @colorop, usually required when
> + * initializing the drivers or when called from the
> + * &drm_colorop_funcs.reset hook.
> *
> * This is useful for drivers that subclass the colorop state.
> */
> static void __drm_colorop_reset(struct drm_colorop *colorop,
> struct drm_colorop_state *colorop_state)
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: David Woodhouse @ 2026-04-21 12:06 UTC (permalink / raw)
To: Geert Uytterhoeven, Herbert Xu
Cc: Jakub Kicinski, davem, netdev, edumazet, pabeni, andrew+netdev,
horms, corbet, skhan, linux, tsbogend, maddy, mpe, npiggin,
chleroy, 3chas3, razor, idosch, jani.nikula, mchehab+huawei,
tytso, ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, andriy.shevchenko, rdunlap, akpm, linux-doc,
linux-mips, linuxppc-dev, bridge
In-Reply-To: <CAMuHMdU96F_42faeqNzDwaXks7mFrLrkPSJB_QTwxEn9HmVWpQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
On Tue, 2026-04-21 at 13:57 +0200, Geert Uytterhoeven wrote:
> Hi Herbert,
>
> On Tue, 21 Apr 2026 at 13:51, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > On Tue, Apr 21, 2026 at 10:26:18AM +0100, David Woodhouse wrote:
> > > I suspect they don't have a huge amount of interest in the Solos any
> > > more, or the Geode-based SBC they sold with two of them on-board. But
> > > OpenWrt does still support them, and I even have one here (although no
> > > ADSL line to test it with). They were briefly popular as fully Linux-
> > > supported ADSL routers.
> >
> > ADSL is history, it only ever made sense in rich countries where
> > physical copper cables were pre-installed in homes. While rich
> > countries have moved to fibre, the rest of the world won't use
> > ADSL either because there is no copper cable to begin with. So
> > it's actually cheaper to just lay a fibre cable for a new install.
>
> I am afraid the move to fibre hasn't been completed yet.
> ADSL (VDSL2?) is still being used.
VSDL is different, and isn't ATM-based. But even ADSL is still in use;
in the UK some rural areas haven't got fibre yet.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: Geert Uytterhoeven @ 2026-04-21 11:57 UTC (permalink / raw)
To: Herbert Xu
Cc: David Woodhouse, Jakub Kicinski, davem, netdev, edumazet, pabeni,
andrew+netdev, horms, corbet, skhan, linux, tsbogend, maddy, mpe,
npiggin, chleroy, 3chas3, razor, idosch, jani.nikula,
mchehab+huawei, tytso, ebiggers, johannes.berg, jonathan.cameron,
kees, kuniyu, fourier.thomas, andriy.shevchenko, rdunlap, akpm,
linux-doc, linux-mips, linuxppc-dev, bridge
In-Reply-To: <aedkZ5bizasuBPI8@gondor.apana.org.au>
Hi Herbert,
On Tue, 21 Apr 2026 at 13:51, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Apr 21, 2026 at 10:26:18AM +0100, David Woodhouse wrote:
> > I suspect they don't have a huge amount of interest in the Solos any
> > more, or the Geode-based SBC they sold with two of them on-board. But
> > OpenWrt does still support them, and I even have one here (although no
> > ADSL line to test it with). They were briefly popular as fully Linux-
> > supported ADSL routers.
>
> ADSL is history, it only ever made sense in rich countries where
> physical copper cables were pre-installed in homes. While rich
> countries have moved to fibre, the rest of the world won't use
> ADSL either because there is no copper cable to begin with. So
> it's actually cheaper to just lay a fibre cable for a new install.
I am afraid the move to fibre hasn't been completed yet.
ADSL (VDSL2?) is still being used.
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 net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: Herbert Xu @ 2026-04-21 11:49 UTC (permalink / raw)
To: David Woodhouse
Cc: Jakub Kicinski, davem, netdev, edumazet, pabeni, andrew+netdev,
horms, corbet, skhan, linux, tsbogend, maddy, mpe, npiggin,
chleroy, 3chas3, razor, idosch, jani.nikula, mchehab+huawei,
tytso, geert, ebiggers, johannes.berg, jonathan.cameron, kees,
kuniyu, fourier.thomas, andriy.shevchenko, rdunlap, akpm,
linux-doc, linux-mips, linuxppc-dev, bridge
In-Reply-To: <c7506c225ce22a71c03abc2673823cf84bbb5b0d.camel@infradead.org>
On Tue, Apr 21, 2026 at 10:26:18AM +0100, David Woodhouse wrote:
>
> I suspect they don't have a huge amount of interest in the Solos any
> more, or the Geode-based SBC they sold with two of them on-board. But
> OpenWrt does still support them, and I even have one here (although no
> ADSL line to test it with). They were briefly popular as fully Linux-
> supported ADSL routers.
ADSL is history, it only ever made sense in rich countries where
physical copper cables were pre-installed in homes. While rich
countries have moved to fibre, the rest of the world won't use
ADSL either because there is no copper cable to begin with. So
it's actually cheaper to just lay a fibre cable for a new install.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v7 4/5] drm: Suppress intentional warning backtraces in scaling unit tests
From: Jani Nikula @ 2026-04-21 11:50 UTC (permalink / raw)
To: Albert Esteve, Peter Zijlstra
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter, Maíra Canal,
Alessandro Carminati, Simona Vetter
In-Reply-To: <CADSE00JJq6fsYbkFN5hBD=-ZWsFG9p4_C55fp3MupMJQj0QCUQ@mail.gmail.com>
On Tue, 21 Apr 2026, Albert Esteve <aesteve@redhat.com> wrote:
> On Mon, Apr 20, 2026 at 4:47 PM Peter Zijlstra <peterz@infradead.org> wrote:
>>
>> On Mon, Apr 20, 2026 at 02:28:06PM +0200, Albert Esteve wrote:
>> > From: Guenter Roeck <linux@roeck-us.net>
>> >
>> > The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
>> > intentionally trigger warning backtraces by providing bad parameters to
>> > the tested functions. What is tested is the return value, not the existence
>> > of a warning backtrace. Suppress the backtraces to avoid clogging the
>> > kernel log and distraction from real problems.
>> >
>> > Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
>> > Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
>> > Acked-by: Maíra Canal <mcanal@igalia.com>
>> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> > Cc: David Airlie <airlied@gmail.com>
>> > Cc: Daniel Vetter <daniel@ffwll.ch>
>> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> > Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
>> > Signed-off-by: Albert Esteve <aesteve@redhat.com>
>> > ---
>> > drivers/gpu/drm/tests/drm_rect_test.c | 14 ++++++++++++++
>> > 1 file changed, 14 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/tests/drm_rect_test.c b/drivers/gpu/drm/tests/drm_rect_test.c
>> > index 17e1f34b76101..1dd7d819165e7 100644
>> > --- a/drivers/gpu/drm/tests/drm_rect_test.c
>> > +++ b/drivers/gpu/drm/tests/drm_rect_test.c
>> > @@ -409,8 +409,15 @@ static void drm_test_rect_calc_hscale(struct kunit *test)
>> > const struct drm_rect_scale_case *params = test->param_value;
>> > int scaling_factor;
>> >
>> > + /*
>> > + * drm_rect_calc_hscale() generates a warning backtrace whenever bad
>> > + * parameters are passed to it. This affects all unit tests with an
>> > + * error code in expected_scaling_factor.
>> > + */
>> > + KUNIT_START_SUPPRESSED_WARNING(test);
>> > scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
>> > params->min_range, params->max_range);
>> > + KUNIT_END_SUPPRESSED_WARNING(test);
>>
>> Would not something like:
>>
>> scoped_kunit_suppress() {
>> scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
>> params->min_range, params->max_range);
>> }
>>
>> be better?
>
> Since KUnit already has a few macros in its API it didn't occur to me.
> Good idea, I like it. And I guess the scope approach matches well with
> your __cleanup comment in the first patch. If no one opposes, I will
> work toward that pattern for the next version.
There's a catch with kunit and __cleanup and thus (scoped) guards. Kunit
runs in ktreads, asserts lead to kthread_exit() and the __cleanup won't
be called.
Warning suppression being part of kunit infrastructure, asserts can and
should end the suppression too. But setting the example (scoped) guards
are safe in kunit tests in general feels like a trap waiting to happen.
BR,
Jani.
>
>>
>> Also, how can you stand all this screaming in the code?
>>
>
> Again, KUnit already contains many macros, so this use didn't register
> as such. Now I will not be able to unsee it.
>
>
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: David Woodhouse @ 2026-04-21 9:26 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, razor,
idosch, jani.nikula, mchehab+huawei, tytso, herbert, geert,
ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, andriy.shevchenko, rdunlap, akpm, linux-doc,
linux-mips, linuxppc-dev, bridge
In-Reply-To: <20260421021943.1295109-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]
On Mon, 2026-04-20 at 19:19 -0700, Jakub Kicinski wrote:
> Remove the ATM protocol modules and PCI/SBUS ATM device drivers
> that are no longer in active use.
>
> The ATM core protocol stack, PPPoATM, and USB DSL modem drivers
> (drivers/usb/atm/) are retained in-tree to maintain PPP over ATM
> (PPPoA) support for DSL connections.
>
> Removed ATM protocol modules:
> - net/atm/clip.c - Classical IP over ATM (RFC 2225)
> - net/atm/br2684.c - RFC 2684 bridged protocols
I believe PPPoE over BR2684 is also used on ADSL lines.
https://git.kernel.org/torvalds/c/ae088d663bee strongly seems to imply
that I used to use it myself, or at least was *able* to switch to it
for testing (although I could have sworn I mostly used PPPoA).
> - net/atm/lec.c - LAN Emulation Client (LANE)
> - net/atm/mpc.c, mpoa_caches.c, mpoa_proc.c - Multi-Protocol Over ATM
>
> Removed PCI/SBUS ATM device drivers (drivers/atm/):
> - adummy, atmtcp - software/testing ATM devices
> - eni - Efficient Networks ENI155P (OC-3, ~1995)
> - fore200e - FORE Systems 200E PCI/SBUS (OC-3, ~1999)
> - he - ForeRunner HE (OC-3/OC-12, ~2000)
> - idt77105 - IDT 77105 25 Mbps ATM PHY
> - idt77252 - IDT 77252 NICStAR II (OC-3, ~2000)
> - iphase - Interphase ATM PCI (OC-3/DS3/E3)
> - lanai - Efficient Networks Speedstream 3010
> - nicstar - IDT 77201 NICStAR (155/25 Mbps, ~1999)
> - solos-pci - Traverse Technologies ADSL2+ PCI (defunct vendor)
Traverse still exists: https://traverse.com.au/
I suspect they don't have a huge amount of interest in the Solos any
more, or the Geode-based SBC they sold with two of them on-board. But
OpenWrt does still support them, and I even have one here (although no
ADSL line to test it with). They were briefly popular as fully Linux-
supported ADSL routers.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 16/23] genirq/cpuhotplug: Use RCU to protect access of HK_TYPE_MANAGED_IRQ cpumask
From: Thomas Gleixner @ 2026-04-21 9:02 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-17-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_MANAGED_IRQ cpumask is going to be changeable at run time,
> use RCU to protect access to the cpumask.
>
> To enable the new HK_TYPE_MANAGED_IRQ cpumask to take effect, the
> following steps can be done.
Can be done?
> 1) Update the HK_TYPE_MANAGED_IRQ cpumask to take out the newly isolated
> CPUs and add back the de-isolated CPUs.
> 2) Tear down the affected CPUs to cause irq_migrate_all_off_this_cpu()
> to be called on the affected CPUs to migrate the irqs to other
> HK_TYPE_MANAGED_IRQ housekeeping CPUs.
> 3) Bring up the previously offline CPUs to invoke
> irq_affinity_online_cpu() to allow the newly de-isolated CPUs to
> be used for managed irqs.
Which previously offline CPUs?
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 2e8072437826..8270c4de260b 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -263,6 +263,7 @@ int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask, bool
> housekeeping_enabled(HK_TYPE_MANAGED_IRQ)) {
> const struct cpumask *hk_mask;
>
> + guard(rcu)();
> hk_mask = housekeeping_cpumask(HK_TYPE_MANAGED_IRQ);
>
> cpumask_and(tmp_mask, mask, hk_mask);
How is this hunk related to $Subject?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 11/23] hrtimer: Use RCU to protect access of HK_TYPE_TIMER cpumask
From: Thomas Gleixner @ 2026-04-21 8:59 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-12-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_TIMER cpumask is going to be changeable at run time, use
As the ...
> RCU to protect access to the cpumask.
>
> The access of HK_TYPE_TIMER cpumask within hrtimers_cpu_dying() is
> protected as interrupt is disabled and all the other CPUs are stopped
interrupts are disabled
> when this function is invoked as part of the CPU tear down process.
^ permalink raw reply
* Re: [PATCH 10/23] cpu: Use RCU to protect access of HK_TYPE_TIMER cpumask
From: Thomas Gleixner @ 2026-04-21 8:57 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-11-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_TIMER cpumask is going to be changeable at run time, use
> RCU to protect access to the cpumask.
>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> kernel/cpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index bc4f7a9ba64e..0d02b5d7a7ba 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -1890,6 +1890,8 @@ int freeze_secondary_cpus(int primary)
> cpu_maps_update_begin();
> if (primary == -1) {
> primary = cpumask_first(cpu_online_mask);
> +
> + guard(rcu)();
> if (!housekeeping_cpu(primary, HK_TYPE_TIMER))
> primary = housekeeping_any_cpu(HK_TYPE_TIMER);
housekeeping_cpu() and housekeeping_any_cpu() can operate on two
different CPU masks once the runtime update is enabled.
Seriously?
^ permalink raw reply
* Re: [PATCH v25 0/7] firmware: imx: driver for NXP secure-enclave
From: Frank Li @ 2026-04-21 8:57 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Pankaj Gupta, Jonathan Corbet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <e5989438-c063-4395-919c-2beaf8e937c8@kontron.de>
On Tue, Apr 21, 2026 at 09:52:13AM +0200, Frieder Schrempf wrote:
> On 24.02.26 12:18, Frieder Schrempf wrote:
> > On 29.01.26 17:58, Pankaj Gupta wrote:
> >> Hi Shawn,
> >>
> >> This is a gentle follow‑up regarding the patch-set.
> >>
> >> In v25, I addressed all automated feedback from kernel CI (warning fixes and checkpatch‑strict resolution), with no further changes requested by reviewers.
> >> Patch 5/7 has also received a Reviewed-by tag from Frank Li (NXP).
> >>
> >> I have not seen additional feedback.
> >> I would appreciate any update on the review/merge status, or guidance on further changes needed to move the series forward.
> >>
> >> Thanks for your time and continued support.
> >
> > How close are we to getting this patchset merged? Work on this has been
> > ongoing for almost three years now and it would be really helpful to
> > have this in the kernel.
> >
> > Thanks!
>
> Gentle ping! Can someone please provide information on what needs to be
> done to get this merged?
Thank you test this. I just took over imx ownship from shawn. I need get
famillar with work flow and get dts part merge smoothly.
I will try to send this as independent pull request at earily of v7.1
Frank
>
> Thanks!
^ permalink raw reply
* Re: [PATCH 05/23] tick: Pass timer tick job to an online HK CPU in tick_cpu_dying()
From: Thomas Gleixner @ 2026-04-21 8:55 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-6-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> In tick_cpu_dying(), if the dying CPU is the current timekeeper,
> it has to pass the job over to another CPU. The current code passes
> it to another online CPU. However, that CPU may not be a timer tick
> housekeeping CPU. If that happens, another CPU will have to manually
> take it over again later. Avoid this unnecessary work by directly
> assigning an online housekeeping CPU.
>
> Use READ_ONCE/WRITE_ONCE() to access tick_do_timer_cpu in case the
> non-HK CPUs may not be in stop machine in the future.
'may not be in the future' is yet more handwaving without
content. Please write your change logs in a way so that people who have
not spent months on this can follow.
> @@ -394,12 +395,19 @@ int tick_cpu_dying(unsigned int dying_cpu)
> {
> /*
> * If the current CPU is the timekeeper, it's the only one that can
> - * safely hand over its duty. Also all online CPUs are in stop
> - * machine, guaranteed not to be idle, therefore there is no
> + * safely hand over its duty. Also all online housekeeping CPUs are
> + * in stop machine, guaranteed not to be idle, therefore there is no
> * concurrency and it's safe to pick any online successor.
> */
> - if (tick_do_timer_cpu == dying_cpu)
> - tick_do_timer_cpu = cpumask_first(cpu_online_mask);
> + if (READ_ONCE(tick_do_timer_cpu) == dying_cpu) {
> + unsigned int new_cpu;
> +
> + guard(rcu)();
What's this guard for?
> + new_cpu = cpumask_first_and(cpu_online_mask, housekeeping_cpumask(HK_TYPE_TICK));
Why has this to use housekeeping_cpumask() and does not use
tick_nohz_full_mask?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v7 4/5] drm: Suppress intentional warning backtraces in scaling unit tests
From: Albert Esteve @ 2026-04-21 8:49 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter, Maíra Canal,
Alessandro Carminati, Simona Vetter
In-Reply-To: <20260420144702.GM3102624@noisy.programming.kicks-ass.net>
On Mon, Apr 20, 2026 at 4:47 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Apr 20, 2026 at 02:28:06PM +0200, Albert Esteve wrote:
> > From: Guenter Roeck <linux@roeck-us.net>
> >
> > The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
> > intentionally trigger warning backtraces by providing bad parameters to
> > the tested functions. What is tested is the return value, not the existence
> > of a warning backtrace. Suppress the backtraces to avoid clogging the
> > kernel log and distraction from real problems.
> >
> > Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> > Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> > Acked-by: Maíra Canal <mcanal@igalia.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: David Airlie <airlied@gmail.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> > Signed-off-by: Albert Esteve <aesteve@redhat.com>
> > ---
> > drivers/gpu/drm/tests/drm_rect_test.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/tests/drm_rect_test.c b/drivers/gpu/drm/tests/drm_rect_test.c
> > index 17e1f34b76101..1dd7d819165e7 100644
> > --- a/drivers/gpu/drm/tests/drm_rect_test.c
> > +++ b/drivers/gpu/drm/tests/drm_rect_test.c
> > @@ -409,8 +409,15 @@ static void drm_test_rect_calc_hscale(struct kunit *test)
> > const struct drm_rect_scale_case *params = test->param_value;
> > int scaling_factor;
> >
> > + /*
> > + * drm_rect_calc_hscale() generates a warning backtrace whenever bad
> > + * parameters are passed to it. This affects all unit tests with an
> > + * error code in expected_scaling_factor.
> > + */
> > + KUNIT_START_SUPPRESSED_WARNING(test);
> > scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
> > params->min_range, params->max_range);
> > + KUNIT_END_SUPPRESSED_WARNING(test);
>
> Would not something like:
>
> scoped_kunit_suppress() {
> scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
> params->min_range, params->max_range);
> }
>
> be better?
Since KUnit already has a few macros in its API it didn't occur to me.
Good idea, I like it. And I guess the scope approach matches well with
your __cleanup comment in the first patch. If no one opposes, I will
work toward that pattern for the next version.
>
> Also, how can you stand all this screaming in the code?
>
Again, KUnit already contains many macros, so this use didn't register
as such. Now I will not be able to unsee it.
^ permalink raw reply
* Re: [PATCH 04/23] tick/nohz: Allow runtime changes in full dynticks CPUs
From: Thomas Gleixner @ 2026-04-21 8:50 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-5-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> Full dynticks can only be enabled if "nohz_full" boot option has been
> been specified with or without parameter. Any change in the list of
> nohz_full CPUs have to be reflected in tick_nohz_full_mask. Introduce
> a new tick_nohz_full_update_cpus() helper that can be called to update
> the tick_nohz_full_mask at run time. The housekeeping_update() function
> is modified to call the new helper when the HK_TYPE_KERNEL_NOSIE cpumask
> is going to be changed.
>
> We also need to enable CPU context tracking for those CPUs that
We need nothing. Use passive voice for change logs as requested in
documentation.
> are in tick_nohz_full_mask. So remove __init from tick_nohz_init()
> and ct_cpu_track_user() so that they be called later when an isolated
> cpuset partition is being created. The __ro_after_init attribute is
> taken away from context_tracking_key as well.
>
> Also add a new ct_cpu_untrack_user() function to reverse the action of
> ct_cpu_track_user() in case we need to disable the nohz_full mode of
> a CPU.
>
> With nohz_full enabled, the boot CPU (typically CPU 0) will be the
> tick CPU which cannot be shut down easily. So the boot CPU should not
> be used in an isolated cpuset partition.
>
> With runtime modification of nohz_full CPUs, tick_do_timer_cpu can become
> TICK_DO_TIMER_NONE. So remove the two TICK_DO_TIMER_NONE WARN_ON_ONCE()
> checks in tick-sched.c to avoid unnecessary warnings.
in tick-sched.c? Describe the functions which contain that.
> static inline void tick_nohz_task_switch(void)
> diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
> index 925999de1a28..394e432630a3 100644
> --- a/kernel/context_tracking.c
> +++ b/kernel/context_tracking.c
> @@ -411,7 +411,7 @@ static __always_inline void ct_kernel_enter(bool user, int offset) { }
> #define CREATE_TRACE_POINTS
> #include <trace/events/context_tracking.h>
>
> -DEFINE_STATIC_KEY_FALSE_RO(context_tracking_key);
> +DEFINE_STATIC_KEY_FALSE(context_tracking_key);
> EXPORT_SYMBOL_GPL(context_tracking_key);
>
> static noinstr bool context_tracking_recursion_enter(void)
> @@ -674,9 +674,9 @@ void user_exit_callable(void)
> }
> NOKPROBE_SYMBOL(user_exit_callable);
>
> -void __init ct_cpu_track_user(int cpu)
> +void ct_cpu_track_user(int cpu)
> {
> - static __initdata bool initialized = false;
> + static bool initialized;
>
> if (cpu == CONTEXT_TRACKING_FORCE_ENABLE) {
> static_branch_inc(&context_tracking_key);
> @@ -700,6 +700,15 @@ void __init ct_cpu_track_user(int cpu)
> initialized = true;
> }
>
> +void ct_cpu_untrack_user(int cpu)
> +{
> + if (!per_cpu(context_tracking.active, cpu))
> + return;
> +
> + per_cpu(context_tracking.active, cpu) = false;
> + static_branch_dec(&context_tracking_key);
> +}
> +
Why is this in a patch which makes tick/nohz related changes? This is a
preparatory change, so make it that way and do not bury it inside
something else.
> +/* Get the new set of run-time nohz CPU list & update accordingly */
> +void tick_nohz_full_update_cpus(struct cpumask *cpumask)
> +{
> + int cpu;
> +
> + if (!tick_nohz_full_running) {
> + pr_warn_once("Full dynticks cannot be enabled without the nohz_full kernel boot parameter!\n");
That's the result of this enforced enable hackery. Make this work
properly.
> + return;
> + }
> +
> + /*
> + * To properly enable/disable nohz_full dynticks for the affected CPUs,
> + * the new nohz_full CPUs have to be copied to tick_nohz_full_mask and
> + * ct_cpu_track_user/ct_cpu_untrack_user() will have to be called
> + * for those CPUs that have their states changed. Those CPUs should be
> + * in an offline state.
> + */
> + for_each_cpu_andnot(cpu, cpumask, tick_nohz_full_mask) {
> + WARN_ON_ONCE(cpu_online(cpu));
> + ct_cpu_track_user(cpu);
> + cpumask_set_cpu(cpu, tick_nohz_full_mask);
> + }
> +
> + for_each_cpu_andnot(cpu, tick_nohz_full_mask, cpumask) {
> + WARN_ON_ONCE(cpu_online(cpu));
> + ct_cpu_untrack_user(cpu);
> + cpumask_clear_cpu(cpu, tick_nohz_full_mask);
> + }
> +}
So this writes to tick_nohz_full_mask while other CPUs can access
it. That's just wrong and I'm not at all interested in the resulting
KCSAN warnings.
tick_nohz_full_mask needs to become a RCU protected pointer, which is
updated once the new mask is established in a separately allocated one.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v7 2/5] bug/kunit: Reduce runtime impact of warning backtrace suppression
From: Albert Esteve @ 2026-04-21 8:41 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Alessandro Carminati
In-Reply-To: <20260420144453.GK3102624@noisy.programming.kicks-ass.net>
On Mon, Apr 20, 2026 at 4:45 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Apr 20, 2026 at 02:28:04PM +0200, Albert Esteve wrote:
> > From: Alessandro Carminati <acarmina@redhat.com>
> >
> > KUnit support is not consistently present across distributions, some
> > include it in their stock kernels, while others do not.
> > While both KUNIT and KUNIT_SUPPRESS_BACKTRACE can be considered debug
> > features, the fact that some distros ship with KUnit enabled means it's
> > important to minimize the runtime impact of this patch.
> >
> > To that end, this patch adds an atomic counter that tracks the number
> > of active suppressions. __kunit_is_suppressed_warning() checks this
> > counter first and returns immediately when no suppressions are active,
> > avoiding RCU-protected list traversal in the common case.
> >
> > Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> > Signed-off-by: Albert Esteve <aesteve@redhat.com>
> > ---
> > lib/kunit/bug.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/lib/kunit/bug.c b/lib/kunit/bug.c
> > index 356c8a5928828..a7a88f0670d44 100644
> > --- a/lib/kunit/bug.c
> > +++ b/lib/kunit/bug.c
> > @@ -8,6 +8,7 @@
> >
> > #include <kunit/bug.h>
> > #include <kunit/resource.h>
> > +#include <linux/atomic.h>
> > #include <linux/export.h>
> > #include <linux/rculist.h>
> > #include <linux/sched.h>
> > @@ -15,11 +16,13 @@
> > #ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> >
> > static LIST_HEAD(suppressed_warnings);
> > +static atomic_t suppressed_warnings_cnt = ATOMIC_INIT(0);
> >
> > static void __kunit_suppress_warning_remove(struct __suppressed_warning *warning)
> > {
> > list_del_rcu(&warning->node);
> > synchronize_rcu(); /* Wait for readers to finish */
> > + atomic_dec(&suppressed_warnings_cnt);
> > }
> >
> > KUNIT_DEFINE_ACTION_WRAPPER(__kunit_suppress_warning_cleanup,
> > @@ -37,6 +40,7 @@ __kunit_start_suppress_warning(struct kunit *test)
> > return NULL;
> >
> > warning->task = current;
> > + atomic_inc(&suppressed_warnings_cnt);
> > list_add_rcu(&warning->node, &suppressed_warnings);
> >
> > ret = kunit_add_action_or_reset(test,
> > @@ -68,6 +72,9 @@ bool __kunit_is_suppressed_warning(void)
> > {
> > struct __suppressed_warning *warning;
> >
> > + if (!atomic_read(&suppressed_warnings_cnt))
> > + return false;
> > +
> > rcu_read_lock();
> > list_for_each_entry_rcu(warning, &suppressed_warnings, node) {
> > if (warning->task == current) {
> >
>
> So the thing you're skipping is:
>
> rcu_read_lock();
> list_for_each_entry_rcu() {
> }
> rcu_read_unlock();
>
> Which is really cheap. Did you actually have performance numbers for
> this?
No, I do not have performance numbers. I kept the counter and the
separate patch for consistency with the previous version of the
series. But you have a good point, the skipped part is really cheap.
>
> A possibly better option is to add a static_branch() that could elide
> any and all memory access.
>
Previous version had static_branch and I removed it because I
understood from the discussion that the gains would not be significant
as performance gains are irrelevant in warn slowpath. But I think it
would make sense for a disabled feature. I will rework this for the
next version, remove the counter and use static_branch as suggested.
^ permalink raw reply
* Re: [PATCH 03/23] tick/nohz: Make nohz_full parameter optional
From: Thomas Gleixner @ 2026-04-21 8:32 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-4-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> To provide nohz_full tick support, there is a set of tick dependency
> masks that need to be evaluated on every IRQ and context switch.
s/IRQ/interrupt/
This is a changelog and not a SMS service.
> Switching on nohz_full tick support at runtime will be problematic
> as some of the tick dependency masks may not be properly set causing
> problem down the road.
That's useless blurb with zero content.
> Allow nohz_full boot option to be specified without any
> parameter to force enable nohz_full tick support without any
> CPU in the tick_nohz_full_mask yet. The context_tracking_key and
> tick_nohz_full_running flag will be enabled in this case to make
> tick_nohz_full_enabled() return true.
I kinda can crystal-ball what you are trying to say here, but that does
not make it qualified as a proper change log.
> There is still a small performance overhead by force enable nohz_full
> this way. So it should only be used if there is a chance that some
> CPUs may become isolated later via the cpuset isolated partition
> functionality and better CPU isolation closed to nohz_full is desired.
Why has this key to be enabled on boot if there are no CPUs in the
isolated mask?
If you want to manage this dynamically at runtime then enable the key
once CPUs are isolated. Yes, it's more work, but that avoids the "should
only be used" nonsense and makes this more robust down the road.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v7 1/5] bug/kunit: Core support for suppressing warning backtraces
From: Albert Esteve @ 2026-04-21 8:29 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Alessandro Carminati, Guenter Roeck,
Kees Cook
In-Reply-To: <20260420144512.GL3102624@noisy.programming.kicks-ass.net>
On Mon, Apr 20, 2026 at 4:45 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Apr 20, 2026 at 02:28:03PM +0200, Albert Esteve wrote:
> > +bool __kunit_is_suppressed_warning(void)
> > +{
> > + struct __suppressed_warning *warning;
> > +
> > + rcu_read_lock();
>
> guard(rcu)();
Nice. I saw plenty of examples using explicit calls, but I had missed
the guard. Thanks for pointing it out.
>
> > + list_for_each_entry_rcu(warning, &suppressed_warnings, node) {
> > + if (warning->task == current) {
> > + warning->counter++;
> > + rcu_read_unlock();
> > + return true;
> > + }
> > + }
> > + rcu_read_unlock();
> > +
> > + return false;
> > +}
> > +
> > +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> >
> > --
> > 2.52.0
> >
>
^ permalink raw reply
* Re: [PATCH] docs/mm: clarify that we are not looking for LLM generated content
From: Vlastimil Babka (SUSE) @ 2026-04-21 8:26 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-doc
Cc: Andrew Morton, Lorenzo Stoakes, Liam R. Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jonathan Corbet, Shuah Khan,
Matthew Wilcox, Harry Yoo, linux-mm, linux-kernel
In-Reply-To: <20260420-llmdoc-v1-1-47d2091177c4@kernel.org>
On 4/20/26 23:03, David Hildenbrand (Arm) wrote:
> Let's make it clear that we are not looking for LLM generated content
> from contributors not familiar with the details of MM, as it shifts the
> real work onto reviewers.
>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Thanks!
> ---
> Documentation/mm/index.rst | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
> index 7aa2a8886908..13a79f5d092c 100644
> --- a/Documentation/mm/index.rst
> +++ b/Documentation/mm/index.rst
> @@ -7,6 +7,19 @@ of Linux. If you are looking for advice on simply allocating memory,
> see the :ref:`memory_allocation`. For controlling and tuning guides,
> see the :doc:`admin guide <../admin-guide/mm/index>`.
>
> +.. note::
> +
> + Unfortunately, parts of this guide are still incomplete or missing.
> + While we appreciate contributions, documentation in this area is hard
> + to get right and requires a lot of attention to detail. New contributors
> + should reach out to the relevant maintainers early.
> +
> + This guide is expected to reflect reality, which requires contributors
> + to have a detailed understanding. Documentation generated with LLMs
> + by contributors unfamiliar with these details shifts the real work onto
> + reviewers, which is why such contributions will be rejected without
> + further comment.
> +
> .. toctree::
> :maxdepth: 1
>
>
> ---
> base-commit: da6b5aae84beb0917ecb0c9fbc71169d145397ff
> change-id: 20260420-llmdoc-21bf5fadbd6f
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v7 1/5] bug/kunit: Core support for suppressing warning backtraces
From: Albert Esteve @ 2026-04-21 8:22 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Alessandro Carminati, Guenter Roeck,
Kees Cook
In-Reply-To: <20260420143951.GJ3102624@noisy.programming.kicks-ass.net>
On Mon, Apr 20, 2026 at 4:40 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Apr 20, 2026 at 02:28:03PM +0200, Albert Esteve wrote:
> > From: Alessandro Carminati <acarmina@redhat.com>
> >
> > Some unit tests intentionally trigger warning backtraces by passing bad
> > parameters to kernel API functions. Such unit tests typically check the
> > return value from such calls, not the existence of the warning backtrace.
> >
> > Such intentionally generated warning backtraces are neither desirable
> > nor useful for a number of reasons:
> > - They can result in overlooked real problems.
> > - A warning that suddenly starts to show up in unit tests needs to be
> > investigated and has to be marked to be ignored, for example by
> > adjusting filter scripts. Such filters are ad hoc because there is
> > no real standard format for warnings. On top of that, such filter
> > scripts would require constant maintenance.
> >
> > Solve the problem by providing a means to identify and suppress specific
> > warning backtraces while executing test code. Support suppressing multiple
> > backtraces while at the same time limiting changes to generic code to the
> > absolute minimum.
> >
> > Implementation details:
> > Suppression is checked at two points in the warning path:
> > - In warn_slowpath_fmt(), the check runs before any output, fully
> > suppressing both message and backtrace.
> > - In __report_bug(), the check runs before __warn() is called,
> > suppressing the backtrace and stack dump. Note that on this path,
> > the WARN() format message may still appear in the kernel log since
> > __warn_printk() runs before the trap that enters __report_bug().
>
> This is for architectures that implement __WARN_FLAGS but not
> __WARN_printf right? (which is arm64, loongarch, parisc, powerpc, riscv,
> sh, afaict). ARM64 should eventually get __WARN_printf, but other than
> that this should be fixable by moving __WARN_FLAGS() into
> __warn_printk() or so. This is the only __warn_printk() user anyway.
Right. On that path, __warn_printk() prints the message before
__WARN_FLAGS() triggers the trap into __report_bug(), so the
suppression check in __report_bug() only catches the backtrace.
Adding the suppression check to __warn_printk() as well should close
this gap, since it's the only caller in the generic __WARN_printf
path. Something like:
```
diff --git a/kernel/panic.c b/kernel/panic.c
index d7a7a679f56c4..cd73038b7c0bd 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -1108,9 +1108,14 @@ EXPORT_SYMBOL(warn_slowpath_fmt);
#else
void __warn_printk(const char *fmt, ...)
{
- bool rcu = warn_rcu_enter();
+ bool rcu;
va_list args;
+ if (__kunit_is_suppressed_warning())
+ return;
+
+ rcu = warn_rcu_enter();
+
pr_warn(CUT_HERE);
va_start(args, fmt);
```
Note that the suppression counter tracking may need a small adjustment
to avoid double-counting, since __report_bug() will still see the same
warning through the trap path, but the approach itself should be
straightforward.
>
>
> > diff --git a/include/kunit/bug.h b/include/kunit/bug.h
> > new file mode 100644
> > index 0000000000000..e52c9d21d9fe6
> > --- /dev/null
> > +++ b/include/kunit/bug.h
> > @@ -0,0 +1,56 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * KUnit helpers for backtrace suppression
> > + *
> > + * Copyright (C) 2025 Alessandro Carminati <acarmina@redhat.com>
> > + * Copyright (C) 2024 Guenter Roeck <linux@roeck-us.net>
> > + */
> > +
> > +#ifndef _KUNIT_BUG_H
> > +#define _KUNIT_BUG_H
> > +
> > +#ifndef __ASSEMBLY__
> > +
> > +#include <linux/kconfig.h>
> > +
> > +struct kunit;
> > +
> > +#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> > +
> > +#include <linux/types.h>
> > +
> > +struct task_struct;
> > +
> > +struct __suppressed_warning {
> > + struct list_head node;
> > + struct task_struct *task;
> > + int counter;
> > +};
> > +
> > +struct __suppressed_warning *
> > +__kunit_start_suppress_warning(struct kunit *test);
> > +void __kunit_end_suppress_warning(struct kunit *test,
> > + struct __suppressed_warning *warning);
> > +int __kunit_suppressed_warning_count(struct __suppressed_warning *warning);
> > +bool __kunit_is_suppressed_warning(void);
> > +
> > +#define KUNIT_START_SUPPRESSED_WARNING(test) \
> > + struct __suppressed_warning *__kunit_suppress = \
> > + __kunit_start_suppress_warning(test)
> > +
> > +#define KUNIT_END_SUPPRESSED_WARNING(test) \
> > + __kunit_end_suppress_warning(test, __kunit_suppress)
>
> We have __cleanup for this?
I was unfamiliar with this attribute. I have looked into it a bit, and
it could be a good fit. I saw a good example in seqlock. I could try
to use it for the next version.
>
> > +
> > +#define KUNIT_SUPPRESSED_WARNING_COUNT() \
> > + __kunit_suppressed_warning_count(__kunit_suppress)
> > +
> > +#else /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> > +
> > +#define KUNIT_START_SUPPRESSED_WARNING(test)
> > +#define KUNIT_END_SUPPRESSED_WARNING(test)
> > +#define KUNIT_SUPPRESSED_WARNING_COUNT() 0
> > +static inline bool __kunit_is_suppressed_warning(void) { return false; }
> > +
> > +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> > +#endif /* __ASSEMBLY__ */
> > +#endif /* _KUNIT_BUG_H */
>
> > diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
> > index 656f1fa35abcc..fe177ff3ebdef 100644
> > --- a/lib/kunit/Makefile
> > +++ b/lib/kunit/Makefile
> > @@ -16,8 +16,10 @@ ifeq ($(CONFIG_KUNIT_DEBUGFS),y)
> > kunit-objs += debugfs.o
> > endif
> >
> > -# KUnit 'hooks' are built-in even when KUnit is built as a module.
> > -obj-$(if $(CONFIG_KUNIT),y) += hooks.o
> > +# KUnit 'hooks' and bug handling are built-in even when KUnit is built
> > +# as a module.
> > +obj-$(if $(CONFIG_KUNIT),y) += hooks.o \
> > + bug.o
> >
> > obj-$(CONFIG_KUNIT_TEST) += kunit-test.o
> > obj-$(CONFIG_KUNIT_TEST) += platform-test.o
> > diff --git a/lib/kunit/bug.c b/lib/kunit/bug.c
> > new file mode 100644
> > index 0000000000000..356c8a5928828
> > --- /dev/null
> > +++ b/lib/kunit/bug.c
> > @@ -0,0 +1,84 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * KUnit helpers for backtrace suppression
> > + *
> > + * Copyright (C) 2025 Alessandro Carminati <acarmina@redhat.com>
> > + * Copyright (C) 2024 Guenter Roeck <linux@roeck-us.net>
> > + */
> > +
> > +#include <kunit/bug.h>
> > +#include <kunit/resource.h>
> > +#include <linux/export.h>
> > +#include <linux/rculist.h>
> > +#include <linux/sched.h>
> > +
> > +#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> > +
> > +static LIST_HEAD(suppressed_warnings);
> > +
> > +static void __kunit_suppress_warning_remove(struct __suppressed_warning *warning)
> > +{
> > + list_del_rcu(&warning->node);
> > + synchronize_rcu(); /* Wait for readers to finish */
> > +}
> > +
> > +KUNIT_DEFINE_ACTION_WRAPPER(__kunit_suppress_warning_cleanup,
> > + __kunit_suppress_warning_remove,
> > + struct __suppressed_warning *);
> > +
> > +struct __suppressed_warning *
> > +__kunit_start_suppress_warning(struct kunit *test)
> > +{
> > + struct __suppressed_warning *warning;
> > + int ret;
> > +
> > + warning = kunit_kzalloc(test, sizeof(*warning), GFP_KERNEL);
> > + if (!warning)
> > + return NULL;
> > +
> > + warning->task = current;
> > + list_add_rcu(&warning->node, &suppressed_warnings);
>
> What if anything serializes this global list?
I considered adding a spinlock, but since the KUnit executor runs
tests sequentially and it had not been a concern in previous versions,
I left it out to keep the changeset minimal unless someone complains.
If we want a hard guarantee, I'm happy to add the spinlock for the
next version.
>
> > +
> > + ret = kunit_add_action_or_reset(test,
> > + __kunit_suppress_warning_cleanup,
> > + warning);
> > + if (ret)
> > + return NULL;
> > +
> > + return warning;
> > +}
> > +EXPORT_SYMBOL_GPL(__kunit_start_suppress_warning);
> > +
> > +void __kunit_end_suppress_warning(struct kunit *test,
> > + struct __suppressed_warning *warning)
> > +{
> > + if (!warning)
> > + return;
> > + kunit_release_action(test, __kunit_suppress_warning_cleanup, warning);
> > +}
> > +EXPORT_SYMBOL_GPL(__kunit_end_suppress_warning);
> > +
> > +int __kunit_suppressed_warning_count(struct __suppressed_warning *warning)
> > +{
> > + return warning ? warning->counter : 0;
> > +}
> > +EXPORT_SYMBOL_GPL(__kunit_suppressed_warning_count);
> > +
> > +bool __kunit_is_suppressed_warning(void)
> > +{
> > + struct __suppressed_warning *warning;
> > +
> > + rcu_read_lock();
> > + list_for_each_entry_rcu(warning, &suppressed_warnings, node) {
> > + if (warning->task == current) {
> > + warning->counter++;
> > + rcu_read_unlock();
> > + return true;
> > + }
> > + }
> > + rcu_read_unlock();
> > +
> > + return false;
> > +}
> > +
> > +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> >
> > --
> > 2.52.0
> >
>
^ permalink raw reply related
* Re: [PATCH] Documentation: coding-assistants: add optional Acted-By: trailer
From: Vlastimil Babka @ 2026-04-21 7:57 UTC (permalink / raw)
To: Blake, Greg KH
Cc: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <IF6AC3bPCYsGyyxsgSQlwZXnA3BJJh61OW6a3KznzbsmDPG4DtricBAzsxyOjDQZ-RHBEkgsjRdaVKQ6i8gqv1bd2AGwC0BTJwBErNHOqx4=@truealter.com>
On 4/21/26 03:04, Blake wrote:
> On Tuesday, 21 April 2026 at 3:40 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> I really do not understand, how would this actually be used?
>> And as you have to have a signed-off-by, why would you use two
>> different names for yourself this way?
>
> Signed-off-by and Acted-By answer different questions. Signed-off-by
> requires a real name for DCO attestation.
AFAIU that's an outdated claim. See:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330
^ permalink raw reply
* Re: [PATCH v25 0/7] firmware: imx: driver for NXP secure-enclave
From: Frieder Schrempf @ 2026-04-21 7:52 UTC (permalink / raw)
To: Pankaj Gupta, Jonathan Corbet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Frank Li
In-Reply-To: <6543cf20-01e3-4dc2-b4b0-08935527f440@kontron.de>
On 24.02.26 12:18, Frieder Schrempf wrote:
> On 29.01.26 17:58, Pankaj Gupta wrote:
>> Hi Shawn,
>>
>> This is a gentle follow‑up regarding the patch-set.
>>
>> In v25, I addressed all automated feedback from kernel CI (warning fixes and checkpatch‑strict resolution), with no further changes requested by reviewers.
>> Patch 5/7 has also received a Reviewed-by tag from Frank Li (NXP).
>>
>> I have not seen additional feedback.
>> I would appreciate any update on the review/merge status, or guidance on further changes needed to move the series forward.
>>
>> Thanks for your time and continued support.
>
> How close are we to getting this patchset merged? Work on this has been
> ongoing for almost three years now and it would be really helpful to
> have this in the kernel.
>
> Thanks!
Gentle ping! Can someone please provide information on what needs to be
done to get this merged?
Thanks!
^ 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