LKML Archive mirror
 help / color / mirror / Atom feed
* [PATCH] perf/x86/rapl: Prefer struct_size over open coded arithmetic
@ 2024-03-17 16:44 Erick Archer
  2024-03-17 20:14 ` Gustavo A. R. Silva
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Erick Archer @ 2024-03-17 16:44 UTC (permalink / raw
  To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
	Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
	Ian Rogers, Adrian Hunter, Thomas Gleixner, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Kees Cook, Gustavo A. R. Silva
  Cc: Erick Archer, x86, linux-perf-users, linux-kernel,
	linux-hardening

This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1][2].

As the "rapl_pmus" variable is a pointer to "struct rapl_pmus" and
this structure ends in a flexible array:

struct rapl_pmus {
	[...]
	struct rapl_pmu *pmus[] __counted_by(maxdie);
};

the preferred way in the kernel is to use the struct_size() helper to
do the arithmetic instead of the calculation "size + count * size" in
the kzalloc() function.

This way, the code is more readable and safer.

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1]
Link: https://github.com/KSPP/linux/issues/160 [2]
Signed-off-by: Erick Archer <erick.archer@gmx.com>
---
 arch/x86/events/rapl.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
index fb2b1961e5a3..8ef08b5d55a7 100644
--- a/arch/x86/events/rapl.c
+++ b/arch/x86/events/rapl.c
@@ -675,10 +675,8 @@ static const struct attribute_group *rapl_attr_update[] = {
 static int __init init_rapl_pmus(void)
 {
 	int maxdie = topology_max_packages() * topology_max_dies_per_package();
-	size_t size;

-	size = sizeof(*rapl_pmus) + maxdie * sizeof(struct rapl_pmu *);
-	rapl_pmus = kzalloc(size, GFP_KERNEL);
+	rapl_pmus = kzalloc(struct_size(rapl_pmus, pmus, maxdie), GFP_KERNEL);
 	if (!rapl_pmus)
 		return -ENOMEM;

--
2.25.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] perf/x86/rapl: Prefer struct_size over open coded arithmetic
  2024-03-17 16:44 [PATCH] perf/x86/rapl: Prefer struct_size over open coded arithmetic Erick Archer
@ 2024-03-17 20:14 ` Gustavo A. R. Silva
  2024-03-18 23:40 ` Kees Cook
  2024-03-21 20:10 ` [tip: perf/core] perf/x86/rapl: Prefer struct_size() " tip-bot2 for Erick Archer
  2 siblings, 0 replies; 5+ messages in thread
From: Gustavo A. R. Silva @ 2024-03-17 20:14 UTC (permalink / raw
  To: Erick Archer, Peter Zijlstra, Ingo Molnar,
	Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
	Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
	Thomas Gleixner, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Kees Cook, Gustavo A. R. Silva
  Cc: x86, linux-perf-users, linux-kernel, linux-hardening



On 3/17/24 10:44, Erick Archer wrote:
> This is an effort to get rid of all multiplications from allocation
> functions in order to prevent integer overflows [1][2].
> 
> As the "rapl_pmus" variable is a pointer to "struct rapl_pmus" and
> this structure ends in a flexible array:
> 
> struct rapl_pmus {
> 	[...]
> 	struct rapl_pmu *pmus[] __counted_by(maxdie);
> };
> 
> the preferred way in the kernel is to use the struct_size() helper to
> do the arithmetic instead of the calculation "size + count * size" in
> the kzalloc() function.
> 
> This way, the code is more readable and safer.
> 
> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1]
> Link: https://github.com/KSPP/linux/issues/160 [2]
> Signed-off-by: Erick Archer <erick.archer@gmx.com>
LGTM:

Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks!
--
Gustavo

> ---
>   arch/x86/events/rapl.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
> index fb2b1961e5a3..8ef08b5d55a7 100644
> --- a/arch/x86/events/rapl.c
> +++ b/arch/x86/events/rapl.c
> @@ -675,10 +675,8 @@ static const struct attribute_group *rapl_attr_update[] = {
>   static int __init init_rapl_pmus(void)
>   {
>   	int maxdie = topology_max_packages() * topology_max_dies_per_package();
> -	size_t size;
> 
> -	size = sizeof(*rapl_pmus) + maxdie * sizeof(struct rapl_pmu *);
> -	rapl_pmus = kzalloc(size, GFP_KERNEL);
> +	rapl_pmus = kzalloc(struct_size(rapl_pmus, pmus, maxdie), GFP_KERNEL);
>   	if (!rapl_pmus)
>   		return -ENOMEM;
> 
> --
> 2.25.1
> 
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] perf/x86/rapl: Prefer struct_size over open coded arithmetic
  2024-03-17 16:44 [PATCH] perf/x86/rapl: Prefer struct_size over open coded arithmetic Erick Archer
  2024-03-17 20:14 ` Gustavo A. R. Silva
@ 2024-03-18 23:40 ` Kees Cook
  2024-03-19  3:49   ` Gustavo A. R. Silva
  2024-03-21 20:10 ` [tip: perf/core] perf/x86/rapl: Prefer struct_size() " tip-bot2 for Erick Archer
  2 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2024-03-18 23:40 UTC (permalink / raw
  To: Erick Archer
  Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
	Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
	Ian Rogers, Adrian Hunter, Thomas Gleixner, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Gustavo A. R. Silva, x86,
	linux-perf-users, linux-kernel, linux-hardening

On Sun, Mar 17, 2024 at 05:44:42PM +0100, Erick Archer wrote:
> This is an effort to get rid of all multiplications from allocation
> functions in order to prevent integer overflows [1][2].
> 
> As the "rapl_pmus" variable is a pointer to "struct rapl_pmus" and
> this structure ends in a flexible array:
> 
> struct rapl_pmus {
> 	[...]
> 	struct rapl_pmu *pmus[] __counted_by(maxdie);
> };
> 
> the preferred way in the kernel is to use the struct_size() helper to
> do the arithmetic instead of the calculation "size + count * size" in
> the kzalloc() function.
> 
> This way, the code is more readable and safer.
> 
> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1]
> Link: https://github.com/KSPP/linux/issues/160 [2]
> Signed-off-by: Erick Archer <erick.archer@gmx.com>

Thanks!

Reviewed-by: Kees Cook <keescook@chromium.org>

I was inspired to come up with a Coccinelle script to find this pattern.
This seems to do it, though it also removes the blank line. I'm not sure
how to stop it from doing that. I'm running this treewide to see if I
can find others...

// Options: --no-includes --include-headers

@allocation@
type SIZE_TYPE;
identifier SIZE;
type PTR_TYPE;
PTR_TYPE *PTR;
identifier ALLOC =~ "kmalloc|kzalloc|kmalloc_node|kzalloc_node|vmalloc|vzalloc|kvmalloc|kvzalloc";
@@

	SIZE_TYPE SIZE;
	...
	PTR = ALLOC(..., SIZE, ...)

@structure@
type allocation.PTR_TYPE;
type FLEX_TYPE;
identifier FLEX;
@@

	PTR_TYPE {
		...
 		FLEX_TYPE FLEX[];
		...
	};

@single_shot_sizing@
type allocation.SIZE_TYPE;
identifier allocation.SIZE;
type allocation.PTR_TYPE;
PTR_TYPE *allocation.PTR;
identifier allocation.ALLOC;
type structure.FLEX_TYPE;
identifier structure.FLEX;
expression COUNT;
@@

- 	SIZE_TYPE SIZE;
 	... when != SIZE
-	SIZE = (\(sizeof(*PTR)\|sizeof(PTR_TYPE)\) + ((COUNT) * \(sizeof(*PTR->FLEX)\|sizeof(PTR->FLEX[0])\|sizeof(FLEX_TYPE)\)));
 	... when != SIZE
 	PTR = ALLOC(...,
-			SIZE
+			struct_size(PTR, FLEX, COUNT)
 			, ...)
 	... when != SIZE

@reused_sizing@
type allocation.SIZE_TYPE;
identifier allocation.SIZE;
type allocation.PTR_TYPE;
PTR_TYPE *allocation.PTR;
identifier allocation.ALLOC;
type structure.FLEX_TYPE;
identifier structure.FLEX;
expression COUNT;
@@

  	SIZE_TYPE SIZE;
 	...
	SIZE =
-		(\(sizeof(*PTR)\|sizeof(PTR_TYPE)\) + ((COUNT) * \(sizeof(*PTR->FLEX)\|sizeof(PTR->FLEX[0])\|sizeof(FLEX_TYPE)\)))
+		struct_size(PTR, FLEX, COUNT)
	;
 	... when != SIZE
 	PTR = ALLOC(..., SIZE , ...)


-- 
Kees Cook

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] perf/x86/rapl: Prefer struct_size over open coded arithmetic
  2024-03-18 23:40 ` Kees Cook
@ 2024-03-19  3:49   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 5+ messages in thread
From: Gustavo A. R. Silva @ 2024-03-19  3:49 UTC (permalink / raw
  To: Kees Cook, Erick Archer
  Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
	Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
	Ian Rogers, Adrian Hunter, Thomas Gleixner, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Gustavo A. R. Silva, x86,
	linux-perf-users, linux-kernel, linux-hardening



On 18/03/24 17:40, Kees Cook wrote:
> On Sun, Mar 17, 2024 at 05:44:42PM +0100, Erick Archer wrote:
>> This is an effort to get rid of all multiplications from allocation
>> functions in order to prevent integer overflows [1][2].
>>
>> As the "rapl_pmus" variable is a pointer to "struct rapl_pmus" and
>> this structure ends in a flexible array:
>>
>> struct rapl_pmus {
>> 	[...]
>> 	struct rapl_pmu *pmus[] __counted_by(maxdie);
>> };
>>
>> the preferred way in the kernel is to use the struct_size() helper to
>> do the arithmetic instead of the calculation "size + count * size" in
>> the kzalloc() function.
>>
>> This way, the code is more readable and safer.
>>
>> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1]
>> Link: https://github.com/KSPP/linux/issues/160 [2]
>> Signed-off-by: Erick Archer <erick.archer@gmx.com>
> 
> Thanks!
> 
> Reviewed-by: Kees Cook <keescook@chromium.org>
> 
> I was inspired to come up with a Coccinelle script to find this pattern.
> This seems to do it, though it also removes the blank line. I'm not sure
> how to stop it from doing that. I'm running this treewide to see if I
> can find others...
> 
> // Options: --no-includes --include-headers

with --no-includes this one is missed in arch/x86/events/:

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 258e2cdf28fa..213fe48f9391 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -350,12 +350,11 @@ static void uncore_pmu_init_hrtimer(struct intel_uncore_box *box)
  static struct intel_uncore_box *uncore_alloc_box(struct intel_uncore_type *type,
                                                  int node)
  {
-       int i, size, numshared = type->num_shared_regs ;
+       int i, numshared = type->num_shared_regs ;
         struct intel_uncore_box *box;

-       size = sizeof(*box) + numshared * sizeof(struct intel_uncore_extra_reg);
-
-       box = kzalloc_node(size, GFP_KERNEL, node);
+       box = kzalloc_node(struct_size(box, shared_regs, numshared),
+                          GFP_KERNEL, node);
         if (!box)
                 return NULL;

Funny thing is that in this case it's quite convenient that the script removes
the blank like. :P

--
Gustavo


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [tip: perf/core] perf/x86/rapl: Prefer struct_size() over open coded arithmetic
  2024-03-17 16:44 [PATCH] perf/x86/rapl: Prefer struct_size over open coded arithmetic Erick Archer
  2024-03-17 20:14 ` Gustavo A. R. Silva
  2024-03-18 23:40 ` Kees Cook
@ 2024-03-21 20:10 ` tip-bot2 for Erick Archer
  2 siblings, 0 replies; 5+ messages in thread
From: tip-bot2 for Erick Archer @ 2024-03-21 20:10 UTC (permalink / raw
  To: linux-tip-commits
  Cc: Erick Archer, Ingo Molnar, Gustavo A. R. Silva, Kees Cook, x86,
	linux-kernel

The following commit has been merged into the perf/core branch of tip:

Commit-ID:     dfbc411e0a5ea72fdd563b2c7d627e9d993d865c
Gitweb:        https://git.kernel.org/tip/dfbc411e0a5ea72fdd563b2c7d627e9d993d865c
Author:        Erick Archer <erick.archer@gmx.com>
AuthorDate:    Sun, 17 Mar 2024 17:44:42 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 21 Mar 2024 20:58:43 +01:00

perf/x86/rapl: Prefer struct_size() over open coded arithmetic

This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows:

  https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
  https://github.com/KSPP/linux/issues/160

As the "rapl_pmus" variable is a pointer to "struct rapl_pmus" and
this structure ends in a flexible array:

  struct rapl_pmus {
	[...]
	struct rapl_pmu *pmus[] __counted_by(maxdie);
  };

the preferred way in the kernel is to use the struct_size() helper to
do the arithmetic instead of the calculation "size + count * size" in
the kzalloc() function.

This way, the code is more readable and safer.

Signed-off-by: Erick Archer <erick.archer@gmx.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20240317164442.6729-1-erick.archer@gmx.com
---
 arch/x86/events/rapl.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
index fb2b196..8ef08b5 100644
--- a/arch/x86/events/rapl.c
+++ b/arch/x86/events/rapl.c
@@ -675,10 +675,8 @@ static const struct attribute_group *rapl_attr_update[] = {
 static int __init init_rapl_pmus(void)
 {
 	int maxdie = topology_max_packages() * topology_max_dies_per_package();
-	size_t size;
 
-	size = sizeof(*rapl_pmus) + maxdie * sizeof(struct rapl_pmu *);
-	rapl_pmus = kzalloc(size, GFP_KERNEL);
+	rapl_pmus = kzalloc(struct_size(rapl_pmus, pmus, maxdie), GFP_KERNEL);
 	if (!rapl_pmus)
 		return -ENOMEM;
 

^ permalink raw reply related	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-03-21 20:10 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-17 16:44 [PATCH] perf/x86/rapl: Prefer struct_size over open coded arithmetic Erick Archer
2024-03-17 20:14 ` Gustavo A. R. Silva
2024-03-18 23:40 ` Kees Cook
2024-03-19  3:49   ` Gustavo A. R. Silva
2024-03-21 20:10 ` [tip: perf/core] perf/x86/rapl: Prefer struct_size() " tip-bot2 for Erick Archer

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 read-only IMAP folder(s) and NNTP newsgroup(s).