<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/resctrl, branch v7.0.10</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>arm_mpam: Check whether the config array is allocated before destroying it</title>
<updated>2026-05-23T11:09:43+00:00</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2026-05-08T16:23:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8eb6dc76eeae5302c0d885906a0e469ef9630a59'/>
<id>8eb6dc76eeae5302c0d885906a0e469ef9630a59</id>
<content type='text'>
commit 6ccbb613b42a1f1ba7bfd547a148f644a902a25c upstream.

__destroy_component_cfg() is called to free the configuration array.
It uses the embedded 'garbage' structure, which means the array has
to be allocated.

If __destroy_component_cfg() is called from mpam_disable() before the
configuration was ever allocated, then a NULL pointer is dereferenced.

Check for this case and return early if the configuration is not
allocated.

__destroy_component_cfg() also frees the mbwu_state as this is allocated
by __allocate_component_cfg(). As the mbwu_state is allocated after
comp-&gt;cfg is set, and is also under mpam_list_lock, only the first
pointer needs checking.

Fixes: 3bd04fe7d807 ("arm_mpam: Extend reset logic to allow devices to be reset any time")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Reviewed-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6ccbb613b42a1f1ba7bfd547a148f644a902a25c upstream.

__destroy_component_cfg() is called to free the configuration array.
It uses the embedded 'garbage' structure, which means the array has
to be allocated.

If __destroy_component_cfg() is called from mpam_disable() before the
configuration was ever allocated, then a NULL pointer is dereferenced.

Check for this case and return early if the configuration is not
allocated.

__destroy_component_cfg() also frees the mbwu_state as this is allocated
by __allocate_component_cfg(). As the mbwu_state is allocated after
comp-&gt;cfg is set, and is also under mpam_list_lock, only the first
pointer needs checking.

Fixes: 3bd04fe7d807 ("arm_mpam: Extend reset logic to allow devices to be reset any time")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Reviewed-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Fix false positive assert failure during mpam_disable()</title>
<updated>2026-05-23T11:09:43+00:00</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2026-05-08T16:23:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ad75f1883796d780f6c1c75de39ce5ffe0a5b750'/>
<id>ad75f1883796d780f6c1c75de39ce5ffe0a5b750</id>
<content type='text'>
commit f1caff3335ea6eab88cdc84ec8f2e3c45ca05486 upstream.

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: 3bd04fe7d807 ("arm_mpam: Extend reset logic to allow devices to be reset any time")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Reviewed-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f1caff3335ea6eab88cdc84ec8f2e3c45ca05486 upstream.

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: 3bd04fe7d807 ("arm_mpam: Extend reset logic to allow devices to be reset any time")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Reviewed-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Improve check for whether or not NRDY is hardware managed</title>
<updated>2026-05-23T11:09:43+00:00</updated>
<author>
<name>Ben Horgan</name>
<email>ben.horgan@arm.com</email>
</author>
<published>2026-05-07T15:28:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3a2cbb6792066195ca9d509456f57c7c3feb41ea'/>
<id>3a2cbb6792066195ca9d509456f57c7c3feb41ea</id>
<content type='text'>
commit ccad6001be5c38426ccf45790c411467ad3c03c6 upstream.

mpam_ris_hw_probe_csu_nrdy() sets and clears MSMON_CSU.NRDY and checks
whether it's configuration sticks. However, hardware isn't given a chance
to disagree. Based on rule LRTGP, in MPAM specification IHI0099 version
B.b, the hardware will set NRDY if it needs time to establish a count after
a configuration change.

Enable the monitor so that NRDY becomes relevant and change the
configuration after clearing NRDY to try and coax the hardware into setting
it.

Fixes: 8c90dc68a5de ("arm_mpam: Probe the hardware features resctrl supports")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ccad6001be5c38426ccf45790c411467ad3c03c6 upstream.

mpam_ris_hw_probe_csu_nrdy() sets and clears MSMON_CSU.NRDY and checks
whether it's configuration sticks. However, hardware isn't given a chance
to disagree. Based on rule LRTGP, in MPAM specification IHI0099 version
B.b, the hardware will set NRDY if it needs time to establish a count after
a configuration change.

Enable the monitor so that NRDY becomes relevant and change the
configuration after clearing NRDY to try and coax the hardware into setting
it.

Fixes: 8c90dc68a5de ("arm_mpam: Probe the hardware features resctrl supports")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Pretend that NRDY is always hardware managed</title>
<updated>2026-05-23T11:09:43+00:00</updated>
<author>
<name>Ben Horgan</name>
<email>ben.horgan@arm.com</email>
</author>
<published>2026-05-07T15:28:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dd061aca2085e5a5333a01dbb154f935e298cef3'/>
<id>dd061aca2085e5a5333a01dbb154f935e298cef3</id>
<content type='text'>
commit 4387970bbd84fd14e0c49c3089c5061ccd86b98a upstream.

Rule ZTXDS of the MPAM specification, IHI009 version B.b, states: "If a
monitor does not support automatic updates of NRDY, software can use that
bit for any purpose."

As software is not reliably informed whether or not the monitor supports
automatic updates of NRDY always assume that hardware may manage NRDY but
don't rely on it. When NRDY is truly untouched by hardware then, as it is
written to 0 on configuration, it will always read 0.

At probe it's checked if MSMON_CSU.NRDY and MSMON_MBWU.NRDY are hardware
managed but not MSMON_MBWU_L.NDRY. Specialize the checking for hardware
managed NRDY to CSU counters as this is the only case where hardware
management makes sense. Continue to inform the user if MSMON_CSU.NRDY
appears to be hardware managed but the firmware doesn't provide the
associated time limit for the automatic clearing of NRDY. Remove the NRDY
feature flags as they are now unused.

Fixes: 8c90dc68a5de ("arm_mpam: Probe the hardware features resctrl supports")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4387970bbd84fd14e0c49c3089c5061ccd86b98a upstream.

Rule ZTXDS of the MPAM specification, IHI009 version B.b, states: "If a
monitor does not support automatic updates of NRDY, software can use that
bit for any purpose."

As software is not reliably informed whether or not the monitor supports
automatic updates of NRDY always assume that hardware may manage NRDY but
don't rely on it. When NRDY is truly untouched by hardware then, as it is
written to 0 on configuration, it will always read 0.

At probe it's checked if MSMON_CSU.NRDY and MSMON_MBWU.NRDY are hardware
managed but not MSMON_MBWU_L.NDRY. Specialize the checking for hardware
managed NRDY to CSU counters as this is the only case where hardware
management makes sense. Continue to inform the user if MSMON_CSU.NRDY
appears to be hardware managed but the firmware doesn't provide the
associated time limit for the automatic clearing of NRDY. Remove the NRDY
feature flags as they are now unused.

Fixes: 8c90dc68a5de ("arm_mpam: Probe the hardware features resctrl supports")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Fix monitor instance selection when checking for hardware NRDY</title>
<updated>2026-05-23T11:09:42+00:00</updated>
<author>
<name>Ben Horgan</name>
<email>ben.horgan@arm.com</email>
</author>
<published>2026-05-07T15:28:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1a3d777ff442be3e5fe7b0dfec3b51f1ad024e1b'/>
<id>1a3d777ff442be3e5fe7b0dfec3b51f1ad024e1b</id>
<content type='text'>
commit 1ef2a89584b7b788b2603590d886db076b2f24cc upstream.

In _mpam_ris_hw_probe_hw_nrdy() a new register value to select the first
monitor and relevant RIS is prepared in mon_sel. However, it is written to
the monitor value register, e.g. MSMON_CSU, rather than MSMON_CFG_MON_SEL.

As MSMON_CFG_MON_SEL is a 32 bit register update the type of mon_sel to
u32.  Write mon_sel to the intended register, MSMON_CFG_MON_SEL.

Fixes: 8c90dc68a5de ("arm_mpam: Probe the hardware features resctrl supports")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1ef2a89584b7b788b2603590d886db076b2f24cc upstream.

In _mpam_ris_hw_probe_hw_nrdy() a new register value to select the first
monitor and relevant RIS is prepared in mon_sel. However, it is written to
the monitor value register, e.g. MSMON_CSU, rather than MSMON_CFG_MON_SEL.

As MSMON_CFG_MON_SEL is a 32 bit register update the type of mon_sel to
u32.  Write mon_sel to the intended register, MSMON_CFG_MON_SEL.

Fixes: 8c90dc68a5de ("arm_mpam: Probe the hardware features resctrl supports")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Reset when feature configuration bit unset</title>
<updated>2026-05-23T11:08:35+00:00</updated>
<author>
<name>Ben Horgan</name>
<email>ben.horgan@arm.com</email>
</author>
<published>2026-03-13T14:45:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=72480ec9b0955fc2398834970015cf4009f0db6e'/>
<id>72480ec9b0955fc2398834970015cf4009f0db6e</id>
<content type='text'>
[ Upstream commit a1cb6577f575ba5ec2583caf4f791a86754dbf69 ]

To indicate that the configuration, of the controls used by resctrl, in a
RIS need resetting to driver defaults the reset flags in mpam_config are
set. However, these flags are only ever set temporarily at RIS scope in
mpam_reset_ris() and hence mpam_cpu_online() will never reset these
controls to default. As the hardware reset is unknown this leads to unknown
configuration when the control values haven't been configured away from the
defaults.

Use the policy that an unset feature configuration bit means reset. In this
way the mpam_config in the component can encode that it should be in reset
state and mpam_reprogram_msc() will reset controls as needed.

Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
[ morse: Removed unused reset flags from config structure ]
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a1cb6577f575ba5ec2583caf4f791a86754dbf69 ]

To indicate that the configuration, of the controls used by resctrl, in a
RIS need resetting to driver defaults the reset flags in mpam_config are
set. However, these flags are only ever set temporarily at RIS scope in
mpam_reset_ris() and hence mpam_cpu_online() will never reset these
controls to default. As the hardware reset is unknown this leads to unknown
configuration when the control values haven't been configured away from the
defaults.

Use the policy that an unset feature configuration bit means reset. In this
way the mpam_config in the component can encode that it should be in reset
state and mpam_reprogram_msc() will reset controls as needed.

Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
[ morse: Removed unused reset flags from config structure ]
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Ensure in_reset_state is false after applying configuration</title>
<updated>2026-05-23T11:08:35+00:00</updated>
<author>
<name>Zeng Heng</name>
<email>zengheng4@huawei.com</email>
</author>
<published>2026-03-13T14:45:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=98c522c9b17c89011038fda2f2b342ca4c5e9bf3'/>
<id>98c522c9b17c89011038fda2f2b342ca4c5e9bf3</id>
<content type='text'>
[ Upstream commit f91e913355f49c878fc77f995fd71b7800352bd2 ]

The per-RIS flag, in_reset_state, indicates whether or not the MSC
registers are in reset state, and allows avoiding resetting when they are
already in reset state. However, when mpam_apply_config() updates the
configuration it doesn't update the in_reset_state flag and so even after
the configuration update in_reset_state can be true and mpam_reset_ris()
will skip the actual register restoration on subsequent resets.

Once resctrl has a MPAM backend it will use resctrl_arch_reset_all_ctrls()
to reset the MSC configuration on unmount and, if the in_reset_state flag
is bogusly true, fail to reset the MSC configuration. The resulting
non-reset MSC configuration can lead to persistent performance restrictions
even after resctrl is unmounted.

Fix by clearing in_reset_state to false immediately after successful
configuration application, ensuring that the next reset operation
properly restores MSC register defaults.

Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
Signed-off-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Acked-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
[Horgan: rewrite commit message to not be specific to resctrl unmount]
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Reviewed-by: Jonathan Cameron &lt;jonathan.cameron@huawei.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f91e913355f49c878fc77f995fd71b7800352bd2 ]

The per-RIS flag, in_reset_state, indicates whether or not the MSC
registers are in reset state, and allows avoiding resetting when they are
already in reset state. However, when mpam_apply_config() updates the
configuration it doesn't update the in_reset_state flag and so even after
the configuration update in_reset_state can be true and mpam_reset_ris()
will skip the actual register restoration on subsequent resets.

Once resctrl has a MPAM backend it will use resctrl_arch_reset_all_ctrls()
to reset the MSC configuration on unmount and, if the in_reset_state flag
is bogusly true, fail to reset the MSC configuration. The resulting
non-reset MSC configuration can lead to persistent performance restrictions
even after resctrl is unmounted.

Fix by clearing in_reset_state to false immediately after successful
configuration application, ensuring that the next reset operation
properly restores MSC register defaults.

Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
Signed-off-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Acked-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
[Horgan: rewrite commit message to not be specific to resctrl unmount]
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Reviewed-by: Jonathan Cameron &lt;jonathan.cameron@huawei.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Force __iomem casts</title>
<updated>2026-03-13T14:17:30+00:00</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>krzysztof.kozlowski@oss.qualcomm.com</email>
</author>
<published>2026-03-06T18:27:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fb75437b447875ae97ea3a173e734dbd553a3881'/>
<id>fb75437b447875ae97ea3a173e734dbd553a3881</id>
<content type='text'>
Code allocates standard kernel memory to pass to the MPAM, which expects
__iomem.  The code is safe, because __iomem accessors should work fine
on kernel mapped memory, however leads to sparse warnings:

  test_mpam_devices.c:327:42: warning: incorrect type in initializer (different address spaces)
  test_mpam_devices.c:327:42:    expected char [noderef] __iomem *buf
  test_mpam_devices.c:327:42:    got void *
  test_mpam_devices.c:342:24: warning: cast removes address space '__iomem' of expression

Cast the pointer to memory via __force to silence them.

Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@oss.qualcomm.com&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202512160133.eAzPdJv2-lkp@intel.com/
Acked-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Code allocates standard kernel memory to pass to the MPAM, which expects
__iomem.  The code is safe, because __iomem accessors should work fine
on kernel mapped memory, however leads to sparse warnings:

  test_mpam_devices.c:327:42: warning: incorrect type in initializer (different address spaces)
  test_mpam_devices.c:327:42:    expected char [noderef] __iomem *buf
  test_mpam_devices.c:327:42:    got void *
  test_mpam_devices.c:342:24: warning: cast removes address space '__iomem' of expression

Cast the pointer to memory via __force to silence them.

Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@oss.qualcomm.com&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202512160133.eAzPdJv2-lkp@intel.com/
Acked-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Disable preemption when making accesses to fake MSC in kunit test</title>
<updated>2026-03-13T14:17:30+00:00</updated>
<author>
<name>Ben Horgan</name>
<email>ben.horgan@arm.com</email>
</author>
<published>2026-03-06T18:27:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c1376f1ff3f016a4b84e8030ed69df82e018d231'/>
<id>c1376f1ff3f016a4b84e8030ed69df82e018d231</id>
<content type='text'>
Accesses to MSC must be made from a cpu that is affine to that MSC and the
driver checks this in __mpam_write_reg() using smp_processor_id(). A fake
in-memory MSC is used for testing. When using that, it doesn't matter which
cpu we access it from but calling smp_processor_id() from a preemptible
context gives warnings when running with CONFIG_DEBUG_PREEMPT.

Add a test helper that wraps mpam_reset_msc_bitmap() with preemption
disabled to ensure all (fake) MSC accesses are made with preemption
disabled.

Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Accesses to MSC must be made from a cpu that is affine to that MSC and the
driver checks this in __mpam_write_reg() using smp_processor_id(). A fake
in-memory MSC is used for testing. When using that, it doesn't matter which
cpu we access it from but calling smp_processor_id() from a preemptible
context gives warnings when running with CONFIG_DEBUG_PREEMPT.

Add a test helper that wraps mpam_reset_msc_bitmap() with preemption
disabled to ensure all (fake) MSC accesses are made with preemption
disabled.

Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Fix null pointer dereference when restoring bandwidth counters</title>
<updated>2026-03-13T14:17:30+00:00</updated>
<author>
<name>Ben Horgan</name>
<email>ben.horgan@arm.com</email>
</author>
<published>2026-03-06T18:27:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4ad79c874e53ebb7fe3b8ae7ac6c858a2121f415'/>
<id>4ad79c874e53ebb7fe3b8ae7ac6c858a2121f415</id>
<content type='text'>
When an MSC supporting memory bandwidth monitoring is brought offline and
then online, mpam_restore_mbwu_state() calls __ris_msmon_read() via ipi to
restore the configuration of the bandwidth counters. It doesn't care about
the value read, mbwu_arg.val, and doesn't set it leading to a null pointer
dereference when __ris_msmon_read() adds to it. This results in a kernel
oops with a call trace such as:

Call trace:
__ris_msmon_read+0x19c/0x64c (P)
mpam_restore_mbwu_state+0xa0/0xe8
smp_call_on_cpu_callback+0x1c/0x38
process_one_work+0x154/0x4b4
worker_thread+0x188/0x310
kthread+0x11c/0x130
ret_from_fork+0x10/0x20

Provide a local variable for val to avoid __ris_msmon_read() dereferencing
a null pointer when adding to val.

Fixes: 41e8a14950e1 ("arm_mpam: Track bandwidth counter state for power management")
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When an MSC supporting memory bandwidth monitoring is brought offline and
then online, mpam_restore_mbwu_state() calls __ris_msmon_read() via ipi to
restore the configuration of the bandwidth counters. It doesn't care about
the value read, mbwu_arg.val, and doesn't set it leading to a null pointer
dereference when __ris_msmon_read() adds to it. This results in a kernel
oops with a call trace such as:

Call trace:
__ris_msmon_read+0x19c/0x64c (P)
mpam_restore_mbwu_state+0xa0/0xe8
smp_call_on_cpu_callback+0x1c/0x38
process_one_work+0x154/0x4b4
worker_thread+0x188/0x310
kthread+0x11c/0x130
ret_from_fork+0x10/0x20

Provide a local variable for val to avoid __ris_msmon_read() dereferencing
a null pointer when adding to val.

Fixes: 41e8a14950e1 ("arm_mpam: Track bandwidth counter state for power management")
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
