From: Michael Neuling <mikey@neuling.org>
To: Anju T Sudhakar <anju@linux.vnet.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: maddy@linux.vnet.ibm.com, ppaidipe@linux.vnet.ibm.com
Subject: Re: [PATCH] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()
Date: Sat, 12 May 2018 09:45:37 +1000 [thread overview]
Message-ID: <1526082337.11357.17.camel@neuling.org> (raw)
In-Reply-To: <1526046222-17842-1-git-send-email-anju@linux.vnet.ibm.com>
On Fri, 2018-05-11 at 19:13 +0530, Anju T Sudhakar wrote:
> Currently memory is allocated for core-imc based on cpu_present_mask, whi=
ch
> has
> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per cor=
e)
> as as array index to access the memory.
> So in a system with guarded cores, since allocation happens based on
> cpu_present_mask, (cpu number / threads per core) bounds the index and le=
ads
> to memory overflow.
>=20
> The issue is exposed in a guard test.
> The guard test will make some CPU's as un-available to the system during =
boot
> time as well as at runtime. So when the cpu is unavailable to the system
> during
> boot time, the memory allocation happens depending on the number of avail=
able
> cpus. And when we access the memory using (cpu number / threads per core)=
as
> the
> index the system crashes due to memory overflow.
>=20
> Allocating memory for core-imc based on cpu_possible_mask, which has
> bit 'cpu' set iff cpu is populatable, will fix this issue.
>=20
> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Thanks, this should be:=20
Cc: <stable@vger.kernel.org> # 4.14
> ---
> arch/powerpc/perf/imc-pmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index d7532e7..75fb23c 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -1146,7 +1146,7 @@ static int init_nest_pmu_ref(void)
> =20
> static void cleanup_all_core_imc_memory(void)
> {
> - int i, nr_cores =3D DIV_ROUND_UP(num_present_cpus(), threads_per_core);
> + int i, nr_cores =3D DIV_ROUND_UP(num_possible_cpus(),
> threads_per_core);
> struct imc_mem_info *ptr =3D core_imc_pmu->mem_info;
> int size =3D core_imc_pmu->counter_mem_size;
> =20
> @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, st=
ruct
> device_node *parent,
> if (!pmu_ptr->pmu.name)
> return -ENOMEM;
> =20
> - nr_cores =3D DIV_ROUND_UP(num_present_cpus(),
> threads_per_core);
> + nr_cores =3D DIV_ROUND_UP(num_possible_cpus(),
> threads_per_core);
> pmu_ptr->mem_info =3D kcalloc(nr_cores, sizeof(struct
> imc_mem_info),
> GFP_KERNEL);
> =20
next prev parent reply other threads:[~2018-05-11 23:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-11 13:43 [PATCH] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus() Anju T Sudhakar
2018-05-11 23:45 ` Michael Neuling [this message]
2018-05-14 6:47 ` Madhavan Srinivasan
2018-05-12 0:35 ` Balbir Singh
2018-05-14 8:32 ` Anju T Sudhakar
2018-05-14 10:49 ` Michael Ellerman
2018-05-14 8:36 ` Anju T Sudhakar
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=1526082337.11357.17.camel@neuling.org \
--to=mikey@neuling.org \
--cc=anju@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.vnet.ibm.com \
--cc=ppaidipe@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).