[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <04967d96-cc03-4751-91f2-9f1ff80c6860@linux.intel.com>
Date: Mon, 27 Nov 2023 16:09:40 -0500
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: alexander.antonov@...ux.intel.com, peterz@...radead.org,
linux-kernel@...r.kernel.org
Cc: kyle.meyer@....com, alexey.v.bayduraev@...ux.intel.com
Subject: Re: [PATCH v2 0/2] Fix NULL pointer dereference issue during
discovering UPI topology
On 2023-11-27 1:52 p.m., alexander.antonov@...ux.intel.com wrote:
> From: Alexander Antonov <alexander.antonov@...ux.intel.com>
>
> The NULL dereference happens inside upi_fill_topology() procedure in
> case of disabling one of the sockets on the system.
>
> For example, if you disable the 2nd socket on a 4-socket system then
> uncore_max_dies() returns 3 and inside pmu_alloc_topology() memory will
> be allocated only for 3 sockets and stored in type->topology.
> In discover_upi_topology() memory is accessed by socket id from CPUNODEID
> registers which contain physical ids (from 0 to 3) and on the line:
>
> upi = &type->topology[nid][idx];
>
> out-of-bound access will happen and the 'upi' pointer will be passed to
> upi_fill_topology() where it will be dereferenced.
>
> To avoid this issue update the code to convert physical socket id to
> logical socket id in discover_upi_topology() before accessing memory.
>
> Changed in v2:
> 1. Factor out topology_gidnid_map() with common code for GIDNIDMAP procedure
>
> Alexander Antonov (2):
> perf/x86/intel/uncore: Fix NULL pointer dereference issue in
> upi_fill_topology()
> perf/x86/intel/uncore: Factor out topology_gidnid_map()
Reviewed-by: Kan Liang <kan.liang@...ux.intel.com>
Thanks,
Kan
>
> arch/x86/events/intel/uncore_snbep.c | 71 ++++++++++++++++------------
> 1 file changed, 40 insertions(+), 31 deletions(-)
>
Powered by blists - more mailing lists