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 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.