| Message ID | 1526046222-17842-1-git-send-email-anju@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus() | expand |
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, which > has > bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core) > 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 leads > to memory overflow. > > 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 available > cpus. And when we access the memory using (cpu number / threads per core) as > the > index the system crashes due to memory overflow. > > Allocating memory for core-imc based on cpu_possible_mask, which has > bit 'cpu' set iff cpu is populatable, will fix this issue. > > Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> > Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> Thanks, this should be: Cc: <stable@vger.kernel.org> # 4.14 > --- > arch/powerpc/perf/imc-pmu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > 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) > > static void cleanup_all_core_imc_memory(void) > { > - int i, nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core); > + int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(), > threads_per_core); > struct imc_mem_info *ptr = core_imc_pmu->mem_info; > int size = core_imc_pmu->counter_mem_size; > > @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, struct > device_node *parent, > if (!pmu_ptr->pmu.name) > return -ENOMEM; > > - nr_cores = DIV_ROUND_UP(num_present_cpus(), > threads_per_core); > + nr_cores = DIV_ROUND_UP(num_possible_cpus(), > threads_per_core); > pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct > imc_mem_info), > GFP_KERNEL); >
On Fri, May 11, 2018 at 11:43 PM, Anju T Sudhakar <anju@linux.vnet.ibm.com> wrote: > Currently memory is allocated for core-imc based on cpu_present_mask, which has > bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core) > 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 leads > to memory overflow. > > 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 available > cpus. And when we access the memory using (cpu number / threads per core) as the > index the system crashes due to memory overflow. > > Allocating memory for core-imc based on cpu_possible_mask, which has > bit 'cpu' set iff cpu is populatable, will fix this issue. > > Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> > Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> > --- > arch/powerpc/perf/imc-pmu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) The changelog does not clearly call out the confusion between present and possible. Guarded CPUs are possible but not present, so it blows a hole when we assume the max length of our allocation is driven by our max present cpus, where as one of the cpus might be online and be beyond the max present cpus, due to the hole.. Reviewed-by: Balbir Singh <bsingharora@gmail.com> Balbir Singh.
On Saturday 12 May 2018 05:15 AM, Michael Neuling wrote: > 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, which >> has >> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core) >> 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 leads >> to memory overflow. >> >> 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 available >> cpus. And when we access the memory using (cpu number / threads per core) as >> the >> index the system crashes due to memory overflow. >> >> Allocating memory for core-imc based on cpu_possible_mask, which has >> bit 'cpu' set iff cpu is populatable, will fix this issue. >> >> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> >> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> > Thanks, this should be: > > Cc: <stable@vger.kernel.org> # 4.14 Thanks for marking to stable. But it should go to 4.14+ stable releases. Maddy >> --- >> arch/powerpc/perf/imc-pmu.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> 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) >> >> static void cleanup_all_core_imc_memory(void) >> { >> - int i, nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core); >> + int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(), >> threads_per_core); >> struct imc_mem_info *ptr = core_imc_pmu->mem_info; >> int size = core_imc_pmu->counter_mem_size; >> >> @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, struct >> device_node *parent, >> if (!pmu_ptr->pmu.name) >> return -ENOMEM; >> >> - nr_cores = DIV_ROUND_UP(num_present_cpus(), >> threads_per_core); >> + nr_cores = DIV_ROUND_UP(num_possible_cpus(), >> threads_per_core); >> pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct >> imc_mem_info), >> GFP_KERNEL); >>
Hi, On Saturday 12 May 2018 06:05 AM, Balbir Singh wrote: > On Fri, May 11, 2018 at 11:43 PM, Anju T Sudhakar > <anju@linux.vnet.ibm.com> wrote: >> Currently memory is allocated for core-imc based on cpu_present_mask, which has >> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core) >> 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 leads >> to memory overflow. >> >> 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 available >> cpus. And when we access the memory using (cpu number / threads per core) as the >> index the system crashes due to memory overflow. >> >> Allocating memory for core-imc based on cpu_possible_mask, which has >> bit 'cpu' set iff cpu is populatable, will fix this issue. >> >> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> >> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> >> --- >> arch/powerpc/perf/imc-pmu.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > The changelog does not clearly call out the confusion between present > and possible. > Guarded CPUs are possible but not present, so it blows a hole when we assume the > max length of our allocation is driven by our max present cpus, where > as one of the cpus > might be online and be beyond the max present cpus, due to the hole.. > > Reviewed-by: Balbir Singh <bsingharora@gmail.com> > > Balbir Singh. > Thanks for the review. OK. I will update the commit message here. Regards, Anju
On Friday 11 May 2018 07:13 PM, Anju T Sudhakar wrote: > Currently memory is allocated for core-imc based on cpu_present_mask, which has > bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core) > 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 leads > to memory overflow. > > 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 available > cpus. And when we access the memory using (cpu number / threads per core) as the > index the system crashes due to memory overflow. > > Allocating memory for core-imc based on cpu_possible_mask, which has > bit 'cpu' set iff cpu is populatable, will fix this issue. > > Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> > Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> # v4.14 + > --- > arch/powerpc/perf/imc-pmu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > 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) > > static void cleanup_all_core_imc_memory(void) > { > - int i, nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core); > + int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core); > struct imc_mem_info *ptr = core_imc_pmu->mem_info; > int size = core_imc_pmu->counter_mem_size; > > @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, struct device_node *parent, > if (!pmu_ptr->pmu.name) > return -ENOMEM; > > - nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core); > + nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core); > pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct imc_mem_info), > GFP_KERNEL); > <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p><br> </p> <br> <div class="moz-cite-prefix">On Friday 11 May 2018 07:13 PM, Anju T Sudhakar wrote:<br> </div> <blockquote type="cite" cite="mid:1526046222-17842-1-git-send-email-anju@linux.vnet.ibm.com"> <pre wrap="">Currently memory is allocated for core-imc based on cpu_present_mask, which has bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core) 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 leads to memory overflow. 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 available cpus. And when we access the memory using (cpu number / threads per core) as the index the system crashes due to memory overflow. Allocating memory for core-imc based on cpu_possible_mask, which has bit 'cpu' set iff cpu is populatable, will fix this issue. Reported-by: Pridhiviraj Paidipeddi <a class="moz-txt-link-rfc2396E" href="mailto:ppaidipe@linux.vnet.ibm.com"><ppaidipe@linux.vnet.ibm.com></a> Signed-off-by: Anju T Sudhakar <a class="moz-txt-link-rfc2396E" href="mailto:anju@linux.vnet.ibm.com"><anju@linux.vnet.ibm.com></a></pre> </blockquote> <br> Cc: <a class="moz-txt-link-rfc2396E" href="mailto:stable@vger.kernel.org"><stable@vger.kernel.org></a> # v4.14 +<br> <br> <blockquote type="cite" cite="mid:1526046222-17842-1-git-send-email-anju@linux.vnet.ibm.com"> <pre wrap=""> --- arch/powerpc/perf/imc-pmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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) static void cleanup_all_core_imc_memory(void) { - int i, nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core); + int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core); struct imc_mem_info *ptr = core_imc_pmu->mem_info; int size = core_imc_pmu->counter_mem_size; @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, struct device_node *parent, if (!pmu_ptr->pmu.name) return -ENOMEM; - nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core); + nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core); pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct imc_mem_info), GFP_KERNEL); </pre> </blockquote> <br> </body> </html>
Anju T Sudhakar <anju@linux.vnet.ibm.com> writes: > On Saturday 12 May 2018 06:05 AM, Balbir Singh wrote: >> On Fri, May 11, 2018 at 11:43 PM, Anju T Sudhakar >> <anju@linux.vnet.ibm.com> wrote: >>> Currently memory is allocated for core-imc based on cpu_present_mask, which has >>> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core) >>> 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 leads >>> to memory overflow. >>> >>> 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 available >>> cpus. And when we access the memory using (cpu number / threads per core) as the >>> index the system crashes due to memory overflow. >>> >>> Allocating memory for core-imc based on cpu_possible_mask, which has >>> bit 'cpu' set iff cpu is populatable, will fix this issue. >>> >>> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> >>> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> >>> --- >>> arch/powerpc/perf/imc-pmu.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >> The changelog does not clearly call out the confusion between present >> and possible. >> Guarded CPUs are possible but not present, so it blows a hole when we assume the >> max length of our allocation is driven by our max present cpus, where >> as one of the cpus >> might be online and be beyond the max present cpus, due to the hole.. >> >> Reviewed-by: Balbir Singh <bsingharora@gmail.com> > > Thanks for the review. > OK. I will update the commit message here. Yeah please do. "Guarded" CPUs is also not a well understand term, so please explain what that means for people who don't know. cheers
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) static void cleanup_all_core_imc_memory(void) { - int i, nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core); + int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core); struct imc_mem_info *ptr = core_imc_pmu->mem_info; int size = core_imc_pmu->counter_mem_size; @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, struct device_node *parent, if (!pmu_ptr->pmu.name) return -ENOMEM; - nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core); + nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core); pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct imc_mem_info), GFP_KERNEL);
Currently memory is allocated for core-imc based on cpu_present_mask, which has bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core) 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 leads to memory overflow. 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 available cpus. And when we access the memory using (cpu number / threads per core) as the index the system crashes due to memory overflow. Allocating memory for core-imc based on cpu_possible_mask, which has bit 'cpu' set iff cpu is populatable, will fix this issue. Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> --- arch/powerpc/perf/imc-pmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)