All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Horgan <ben.horgan@arm.com>
To: James Morse <james.morse@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, zengheng4@huawei.com
Cc: wangkefeng.wang@huawei.com, xry111@xry111.site,
	catalin.marinas@arm.com, yang@os.amperecomputing.com,
	reinette.chatre@intel.com, will@kernel.org, thuth@redhat.com,
	mrigendra.chaubey@gmail.com, fenghuay@nvidia.com,
	ahmed.genidi@arm.com
Subject: Re: [PATCH v3 1/4] arm_mpam: Fix false positive assert failure during mpam_disable()
Date: Mon, 11 May 2026 12:19:06 +0100	[thread overview]
Message-ID: <3f51d2a8-e699-4acf-9903-e62e27d2213a@arm.com> (raw)
In-Reply-To: <20260508162341.3762549-2-james.morse@arm.com>

Hi James,

On 5/8/26 17:23, James Morse wrote:
> mpam_assert_partid_sizes_fixed() is used to document that the caller
> doesn't expect the discovered PARTID size to change while it is walking
> a list sized by PARTID. Typically the MSC state is not written to until
> all the MSC have been discovered and this value is set.
> 
> However, if discovering the MSC fails and schedules mpam_disable(),
> then the MSC state is written to reset it. In this case the
> discovered PARTID size may be become smaller - but only PARTID 0
> will be used once resctrl_exit() has been called.
> 
> Skip the WARN_ON_ONCE() if mpam_disable_reason has been set.
> 
> Fixes: 3bd04fe7d807bb ("arm_mpam: Extend reset logic to allow devices to be reset at any time")
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  drivers/resctrl/mpam_devices.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 41b14344b16f..bef5e9e9e844 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -164,11 +164,17 @@ static void mpam_free_garbage(void)
>  /*
>   * Once mpam is enabled, new requestors cannot further reduce the available
>   * partid. Assert that the size is fixed, and new requestors will be turned
> - * away.
> + * away. This is needed when walking over structures sized by PARTID.
> + *
> + * During mpam_disable() these structures are not fixed, but the MSC state
> + * is still reset using whatever sizes have been discovered so far. As only
> + * PARTID 0 will be used after mpam_disable(), any race would be benign.
> + * Skip the check if a mpam_disable_reason has been set.
>   */
>  static void mpam_assert_partid_sizes_fixed(void)
>  {
> -	WARN_ON_ONCE(!partid_max_published);
> +	if (!mpam_disable_reason)
> +		WARN_ON_ONCE(!partid_max_published);

A little bit nasty to use mpam_disable_reason this way but a simple better way eludes me.

Reviewed-by: Ben Horgan <ben.horgan@arm.com>

Thanks,

Ben


>  }
>  
>  static u32 __mpam_read_reg(struct mpam_msc *msc, u16 reg)


  reply	other threads:[~2026-05-11 11:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08 16:23 [PATCH v3 0/4] arm_mpam: Add support for the MPAM v0.1 architecture version James Morse
2026-05-08 16:23 ` [PATCH v3 1/4] arm_mpam: Fix false positive assert failure during mpam_disable() James Morse
2026-05-11 11:19   ` Ben Horgan [this message]
2026-05-08 16:23 ` [PATCH v3 2/4] arm_mpam: Check whether the config array is allocated before destroying it James Morse
2026-05-11 11:23   ` Ben Horgan
2026-05-08 16:23 ` [PATCH v3 3/4] arm64: cpufeature: Add support for the MPAM v0.1 architecture version James Morse
2026-05-14 14:22   ` Catalin Marinas
2026-05-08 16:23 ` [PATCH v3 4/4] arm_mpam: Update architecture version check for MPAM MSC James Morse
2026-05-08 16:35   ` Ben Horgan
2026-05-09  6:26     ` Zeng Heng
2026-05-14 14:08 ` (subset) [PATCH v3 0/4] arm_mpam: Add support for the MPAM v0.1 architecture version Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3f51d2a8-e699-4acf-9903-e62e27d2213a@arm.com \
    --to=ben.horgan@arm.com \
    --cc=ahmed.genidi@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=fenghuay@nvidia.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrigendra.chaubey@gmail.com \
    --cc=reinette.chatre@intel.com \
    --cc=thuth@redhat.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=xry111@xry111.site \
    --cc=yang@os.amperecomputing.com \
    --cc=zengheng4@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.