From nobody Tue Apr 7 18:51:34 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B120032FA22 for ; Fri, 27 Feb 2026 11:03:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772190207; cv=none; b=DJ4svPw9PeKI7cW5SlBfgmS8ppO1Nmn46hwbNX6HpZP9lBdT0xvmF0Gejmsa7isJafDROlq35QClsxYPtyOLJzO3ZGPE7D0Ya/UKpGEPpKM7FUdlpv6Dpm3GoXvsq7idSkCNJUUih2BNObhlrRRi+tmuz0dZ4sA8PLRqcUjlVfo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772190207; c=relaxed/simple; bh=2mojGTaCEU+/fFbJyGKfUXf0TB7iY3GsCCBUFCyVPeI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PHIZdEQ26bb7W6a4pcOjreRFZXjxPMs7OG9AffipC2Sz6JIYp3VshO/A1naI3kX2qgOhkCyIZP5oU3suWTmch9Q+WW976+3jYeBmKN+9Q/yt6z/uLrbCPAE2Y9bnF4Js7teubQ8Nf/ss0eTzLD02SYg2rMwfVqthhZ8Lr+387fo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DC6C31516; Fri, 27 Feb 2026 03:03:19 -0800 (PST) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id CE7073F7BD; Fri, 27 Feb 2026 03:03:24 -0800 (PST) From: Ben Horgan To: ben.horgan@arm.com Cc: james.morse@arm.com, reinette.chatre@intel.com, fenghuay@nvidia.com, gshan@redhat.com, zengheng4@huawei.com, jonathan.cameron@huawei.com, tan.shaopeng@jp.fujitsu.com, linux-kernel@vger.kernel.org Subject: [PATCH v1 1/2] arm_mpam: Fix null pointer dereference when restoring bandwidth counters Date: Fri, 27 Feb 2026 11:03:13 +0000 Message-ID: <20260227110314.4038066-2-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260227110314.4038066-1-ben.horgan@arm.com> References: <20260227110314.4038066-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 man= agement") Signed-off-by: Ben Horgan Reviewed-by: James Morse --- drivers/resctrl/mpam_devices.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c index 1eebc2602187..0666be6b0e88 100644 --- a/drivers/resctrl/mpam_devices.c +++ b/drivers/resctrl/mpam_devices.c @@ -1428,6 +1428,7 @@ static void mpam_reprogram_ris_partid(struct mpam_msc= _ris *ris, u16 partid, static int mpam_restore_mbwu_state(void *_ris) { int i; + u64 val; struct mon_read mwbu_arg; struct mpam_msc_ris *ris =3D _ris; struct mpam_class *class =3D ris->vmsc->comp->class; @@ -1437,6 +1438,7 @@ static int mpam_restore_mbwu_state(void *_ris) mwbu_arg.ris =3D ris; mwbu_arg.ctx =3D &ris->mbwu_state[i].cfg; mwbu_arg.type =3D mpam_msmon_choose_counter(class); + mwbu_arg.val =3D &val; =20 __ris_msmon_read(&mwbu_arg); } --=20 2.43.0 From nobody Tue Apr 7 18:51:34 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5E7C03ED138 for ; Fri, 27 Feb 2026 11:03:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772190209; cv=none; b=EcG8NVHbwL2812t9CZbLsEIbeH8ngOU3eVyUBRyjiItOrDAvEjPoQfqQJwEZG/fqcydJcGkI2Oa+6mLaL8bXFgn8qkaZ+i0PthWdb8P3V2jOhs49eVjcIGkb9BGuIJIGpOfVdKqDiYU85KbY+GjcQB8CBLw2uN+Lt2omrGpeBU4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772190209; c=relaxed/simple; bh=dMYSGYPirwWrz+Ilos5feJBvYav4FFGBQUJbOykpp7Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ChevKMG1VLitKgQ3+y+NVJ1EU6MI/hrDqcxXUmXZv4NzB1+8Cw/w3gxmXTleqTHhTLXtUlHT2hM7FSX/dZGbWLf9rLdhvMuipiJ3U7v7f9AQXuAtc/u7ua36vCD9NzQvltw250rcG6tvkmterr/IBkagtCx0+tVT0jmWslUs0L4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 81FDB169C; Fri, 27 Feb 2026 03:03:21 -0800 (PST) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 772933F7BD; Fri, 27 Feb 2026 03:03:26 -0800 (PST) From: Ben Horgan To: ben.horgan@arm.com Cc: james.morse@arm.com, reinette.chatre@intel.com, fenghuay@nvidia.com, gshan@redhat.com, zengheng4@huawei.com, jonathan.cameron@huawei.com, tan.shaopeng@jp.fujitsu.com, linux-kernel@vger.kernel.org Subject: [PATCH v1 2/2] arm_mpam: Disable preemption when making accesses to fake MSC in kunit test Date: Fri, 27 Feb 2026 11:03:14 +0000 Message-ID: <20260227110314.4038066-3-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260227110314.4038066-1-ben.horgan@arm.com> References: <20260227110314.4038066-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 Reviewed-by: James Morse --- drivers/resctrl/test_mpam_devices.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/resctrl/test_mpam_devices.c b/drivers/resctrl/test_mpa= m_devices.c index 3e8d564a0c64..75bd41bcc395 100644 --- a/drivers/resctrl/test_mpam_devices.c +++ b/drivers/resctrl/test_mpam_devices.c @@ -322,6 +322,14 @@ static void test_mpam_enable_merge_features(struct kun= it *test) mutex_unlock(&mpam_list_lock); } =20 +static void __test_mpam_reset_msc_bitmap(struct mpam_msc *msc, u16 reg, u1= 6 wd) +{ + /* Avoid warnings when running with CONFIG_DEBUG_PREEMPT */ + guard(preempt)(); + + mpam_reset_msc_bitmap(msc, reg, wd); +} + static void test_mpam_reset_msc_bitmap(struct kunit *test) { char __iomem *buf =3D kunit_kzalloc(test, SZ_16K, GFP_KERNEL); @@ -341,31 +349,31 @@ static void test_mpam_reset_msc_bitmap(struct kunit *= test) =20 test_result =3D (u32 *)(buf + MPAMCFG_CPBM); =20 - mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 0); + __test_mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 0); KUNIT_EXPECT_EQ(test, test_result[0], 0); KUNIT_EXPECT_EQ(test, test_result[1], 0); test_result[0] =3D 0; test_result[1] =3D 0; =20 - mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 1); + __test_mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 1); KUNIT_EXPECT_EQ(test, test_result[0], 1); KUNIT_EXPECT_EQ(test, test_result[1], 0); test_result[0] =3D 0; test_result[1] =3D 0; =20 - mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 16); + __test_mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 16); KUNIT_EXPECT_EQ(test, test_result[0], 0xffff); KUNIT_EXPECT_EQ(test, test_result[1], 0); test_result[0] =3D 0; test_result[1] =3D 0; =20 - mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 32); + __test_mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 32); KUNIT_EXPECT_EQ(test, test_result[0], 0xffffffff); KUNIT_EXPECT_EQ(test, test_result[1], 0); test_result[0] =3D 0; test_result[1] =3D 0; =20 - mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 33); + __test_mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 33); KUNIT_EXPECT_EQ(test, test_result[0], 0xffffffff); KUNIT_EXPECT_EQ(test, test_result[1], 1); test_result[0] =3D 0; --=20 2.43.0