All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4] gpio: sim: fix an invalid __free() usage
@ 2023-09-18 14:55 Bartosz Golaszewski
  2023-09-18 15:31 ` Andy Shevchenko
  0 siblings, 1 reply; 8+ messages in thread
From: Bartosz Golaszewski @ 2023-09-18 14:55 UTC (permalink / raw)
  To: Linus Walleij, Andy Shevchenko, Kent Gibson, Alexey Dobriyan,
	Peter Zijlstra, Linus Torvalds, akpm
  Cc: linux-gpio, linux-kernel, Bartosz Golaszewski

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpio_sim_make_line_names() returns NULL or ERR_PTR() so we must not use
__free(kfree) on the returned address. Split this function into two, one
that determines the size of the "gpio-line-names" array to allocate and
one that actually sets the names at correct offsets. The allocation and
assignment of the managed pointer happens in between.

Fixes: 3faf89f27aab ("gpio: sim: simplify code with cleanup helpers")
Reported-by: Alexey Dobriyan <adobriyan@gmail.com>
Closes: https://lore.kernel.org/all/07c32bf1-6c1a-49d9-b97d-f0ae4a2b42ab@p183/
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
Linus,

I followed the pattern for determining the size of the line-names array
from your patch in the end but with a changed variable naming. If this is
fine, I'll queue it for fixes for the next rc.

Bart

v3 -> v4:
- simplify the line counting logic

v2 -> v3:
- restore the offset out-of-bounds checks

v1 -> v2:
- split the line name setting into two parts

 drivers/gpio/gpio-sim.c | 59 +++++++++++++++--------------------------
 1 file changed, 22 insertions(+), 37 deletions(-)

diff --git a/drivers/gpio/gpio-sim.c b/drivers/gpio/gpio-sim.c
index 460389bb8e3f..b66abb55ef4d 100644
--- a/drivers/gpio/gpio-sim.c
+++ b/drivers/gpio/gpio-sim.c
@@ -718,52 +718,32 @@ gpio_sim_device_config_live_show(struct config_item *item, char *page)
 	return sprintf(page, "%c\n", live ? '1' : '0');
 }
 
-static char **gpio_sim_make_line_names(struct gpio_sim_bank *bank,
-				       unsigned int *line_names_size)
+static unsigned int gpio_sim_get_line_names_size(struct gpio_sim_bank *bank)
 {
-	unsigned int max_offset = 0;
-	bool has_line_names = false;
 	struct gpio_sim_line *line;
-	char **line_names;
+	unsigned int size = 0;
 
 	list_for_each_entry(line, &bank->line_list, siblings) {
-		if (line->offset >= bank->num_lines)
+		if (!line->name || (line->offset >= bank->num_lines))
 			continue;
 
-		if (line->name) {
-			if (line->offset > max_offset)
-				max_offset = line->offset;
-
-			/*
-			 * max_offset can stay at 0 so it's not an indicator
-			 * of whether line names were configured at all.
-			 */
-			has_line_names = true;
-		}
+		size = line->offset + 1;
 	}
 
-	if (!has_line_names)
-		/*
-		 * This is not an error - NULL means, there are no line
-		 * names configured.
-		 */
-		return NULL;
-
-	*line_names_size = max_offset + 1;
+	return size;
+}
 
-	line_names = kcalloc(*line_names_size, sizeof(*line_names), GFP_KERNEL);
-	if (!line_names)
-		return ERR_PTR(-ENOMEM);
+static void
+gpio_sim_set_line_names(struct gpio_sim_bank *bank, char **line_names)
+{
+	struct gpio_sim_line *line;
 
 	list_for_each_entry(line, &bank->line_list, siblings) {
-		if (line->offset >= bank->num_lines)
+		if (!line->name || (line->offset >= bank->num_lines))
 			continue;
 
-		if (line->name && (line->offset <= max_offset))
-			line_names[line->offset] = line->name;
+		line_names[line->offset] = line->name;
 	}
-
-	return line_names;
 }
 
 static void gpio_sim_remove_hogs(struct gpio_sim_device *dev)
@@ -867,7 +847,7 @@ gpio_sim_make_bank_swnode(struct gpio_sim_bank *bank,
 			  struct fwnode_handle *parent)
 {
 	struct property_entry properties[GPIO_SIM_PROP_MAX];
-	unsigned int prop_idx = 0, line_names_size = 0;
+	unsigned int prop_idx = 0, line_names_size;
 	char **line_names __free(kfree) = NULL;
 
 	memset(properties, 0, sizeof(properties));
@@ -878,14 +858,19 @@ gpio_sim_make_bank_swnode(struct gpio_sim_bank *bank,
 		properties[prop_idx++] = PROPERTY_ENTRY_STRING("gpio-sim,label",
 							       bank->label);
 
-	line_names = gpio_sim_make_line_names(bank, &line_names_size);
-	if (IS_ERR(line_names))
-		return ERR_CAST(line_names);
+	line_names_size = gpio_sim_get_line_names_size(bank);
+	if (line_names_size) {
+		line_names = kcalloc(line_names_size, sizeof(*line_names),
+				     GFP_KERNEL);
+		if (!line_names)
+			return ERR_PTR(-ENOMEM);
+
+		gpio_sim_set_line_names(bank, line_names);
 
-	if (line_names)
 		properties[prop_idx++] = PROPERTY_ENTRY_STRING_ARRAY_LEN(
 						"gpio-line-names",
 						line_names, line_names_size);
+	}
 
 	return fwnode_create_software_node(properties, parent);
 }
-- 
2.39.2


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

* Re: [PATCH v4] gpio: sim: fix an invalid __free() usage
  2023-09-18 14:55 [PATCH v4] gpio: sim: fix an invalid __free() usage Bartosz Golaszewski
@ 2023-09-18 15:31 ` Andy Shevchenko
  2023-09-19  7:31   ` brgl
  0 siblings, 1 reply; 8+ messages in thread
From: Andy Shevchenko @ 2023-09-18 15:31 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Linus Walleij, Kent Gibson, Alexey Dobriyan, Peter Zijlstra,
	Linus Torvalds, akpm, linux-gpio, linux-kernel,
	Bartosz Golaszewski

On Mon, Sep 18, 2023 at 04:55:33PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> gpio_sim_make_line_names() returns NULL or ERR_PTR() so we must not use
> __free(kfree) on the returned address. Split this function into two, one
> that determines the size of the "gpio-line-names" array to allocate and
> one that actually sets the names at correct offsets. The allocation and
> assignment of the managed pointer happens in between.

...

> +	unsigned int size = 0;
>  
>  	list_for_each_entry(line, &bank->line_list, siblings) {
> +		if (!line->name || (line->offset >= bank->num_lines))
>  			continue;
>  
> +		size = line->offset + 1;
>  	}
>  
> +	return size;

So, now the function iterates over all lines and returns the size of the last
match, correct?

Why not

	list_for_each_entry_reversed() {
		if (line->name && ())
			break;
	}

	return size;

?

...

> +static void
> +gpio_sim_set_line_names(struct gpio_sim_bank *bank, char **line_names)
> +{
> +	struct gpio_sim_line *line;
>  
>  	list_for_each_entry(line, &bank->line_list, siblings) {
> -		if (line->offset >= bank->num_lines)
> +		if (!line->name || (line->offset >= bank->num_lines))
>  			continue;
>  
> -		if (line->name && (line->offset <= max_offset))
> -			line_names[line->offset] = line->name;
> +		line_names[line->offset] = line->name;
>  	}
> -
> -	return line_names;
>  }

Can be done in the similar (I see the difference) way for the consistency with
above.

...

> +	line_names_size = gpio_sim_get_line_names_size(bank);

> +	if (line_names_size) {

Of course this can be replace with...

> +		line_names = kcalloc(line_names_size, sizeof(*line_names),
> +				     GFP_KERNEL);

> +		if (!line_names)

ZERO_OR_NULL_PTR() check here, but I assume we discourage use of it.

> +			return ERR_PTR(-ENOMEM);
> +
> +		gpio_sim_set_line_names(bank, line_names);
>  
> -	if (line_names)
>  		properties[prop_idx++] = PROPERTY_ENTRY_STRING_ARRAY_LEN(
>  						"gpio-line-names",
>  						line_names, line_names_size);
> +	}

-- 
With Best Regards,
Andy Shevchenko



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

* Re: [PATCH v4] gpio: sim: fix an invalid __free() usage
  2023-09-18 15:31 ` Andy Shevchenko
@ 2023-09-19  7:31   ` brgl
  2023-09-19  7:37     ` Kent Gibson
  2023-09-19 10:49     ` Andy Shevchenko
  0 siblings, 2 replies; 8+ messages in thread
From: brgl @ 2023-09-19  7:31 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Linus Walleij, Kent Gibson, Alexey Dobriyan, Peter Zijlstra,
	Linus Torvalds, akpm, linux-gpio, linux-kernel,
	Bartosz Golaszewski, Bartosz Golaszewski

On Mon, 18 Sep 2023 17:31:36 +0200, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> On Mon, Sep 18, 2023 at 04:55:33PM +0200, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>
>> gpio_sim_make_line_names() returns NULL or ERR_PTR() so we must not use
>> __free(kfree) on the returned address. Split this function into two, one
>> that determines the size of the "gpio-line-names" array to allocate and
>> one that actually sets the names at correct offsets. The allocation and
>> assignment of the managed pointer happens in between.
>
> ...
>
>> +	unsigned int size = 0;
>>
>>  	list_for_each_entry(line, &bank->line_list, siblings) {
>> +		if (!line->name || (line->offset >= bank->num_lines))
>>  			continue;
>>
>> +		size = line->offset + 1;
>>  	}
>>
>> +	return size;
>
> So, now the function iterates over all lines and returns the size of the last
> match, correct?
>
> Why not
>
> 	list_for_each_entry_reversed() {
> 		if (line->name && ())
> 			break;
> 	}
>
> 	return size;
>
> ?

Because the line objects are not sorted by offset. They are added at the end
of the list in the order the user creates their corresponding configfs groups.

>
> ...
>
>> +static void
>> +gpio_sim_set_line_names(struct gpio_sim_bank *bank, char **line_names)
>> +{
>> +	struct gpio_sim_line *line;
>>
>>  	list_for_each_entry(line, &bank->line_list, siblings) {
>> -		if (line->offset >= bank->num_lines)
>> +		if (!line->name || (line->offset >= bank->num_lines))
>>  			continue;
>>
>> -		if (line->name && (line->offset <= max_offset))
>> -			line_names[line->offset] = line->name;
>> +		line_names[line->offset] = line->name;
>>  	}
>> -
>> -	return line_names;
>>  }
>
> Can be done in the similar (I see the difference) way for the consistency with
> above.
>
> ...
>
>> +	line_names_size = gpio_sim_get_line_names_size(bank);
>
>> +	if (line_names_size) {
>
> Of course this can be replace with...
>
>> +		line_names = kcalloc(line_names_size, sizeof(*line_names),
>> +				     GFP_KERNEL);
>
>> +		if (!line_names)
>
> ZERO_OR_NULL_PTR() check here, but I assume we discourage use of it.

Why? There are less than 40 instances of using it in the kernel. kmalloc()
returns NULL on failure.

Bart

>
>> +			return ERR_PTR(-ENOMEM);
>> +
>> +		gpio_sim_set_line_names(bank, line_names);
>>
>> -	if (line_names)
>>  		properties[prop_idx++] = PROPERTY_ENTRY_STRING_ARRAY_LEN(
>>  						"gpio-line-names",
>>  						line_names, line_names_size);
>> +	}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
>

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

* Re: [PATCH v4] gpio: sim: fix an invalid __free() usage
  2023-09-19  7:31   ` brgl
@ 2023-09-19  7:37     ` Kent Gibson
  2023-09-19  7:46       ` brgl
  2023-09-19 10:49     ` Andy Shevchenko
  1 sibling, 1 reply; 8+ messages in thread
From: Kent Gibson @ 2023-09-19  7:37 UTC (permalink / raw)
  To: brgl
  Cc: Andy Shevchenko, Linus Walleij, Alexey Dobriyan, Peter Zijlstra,
	Linus Torvalds, akpm, linux-gpio, linux-kernel,
	Bartosz Golaszewski

On Tue, Sep 19, 2023 at 12:31:36AM -0700, brgl@bgdev.pl wrote:
> On Mon, 18 Sep 2023 17:31:36 +0200, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> said:
> > On Mon, Sep 18, 2023 at 04:55:33PM +0200, Bartosz Golaszewski wrote:
> >> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>
> >> gpio_sim_make_line_names() returns NULL or ERR_PTR() so we must not use
> >> __free(kfree) on the returned address. Split this function into two, one
> >> that determines the size of the "gpio-line-names" array to allocate and
> >> one that actually sets the names at correct offsets. The allocation and
> >> assignment of the managed pointer happens in between.
> >
> > ...
> >
> >> +	unsigned int size = 0;
> >>
> >>  	list_for_each_entry(line, &bank->line_list, siblings) {
> >> +		if (!line->name || (line->offset >= bank->num_lines))
> >>  			continue;
> >>
> >> +		size = line->offset + 1;
> >>  	}
> >>
> >> +	return size;
> >
> > So, now the function iterates over all lines and returns the size of the last
> > match, correct?
> >
> > Why not
> >
> > 	list_for_each_entry_reversed() {
> > 		if (line->name && ())
> > 			break;
> > 	}
> >
> > 	return size;
> >
> > ?
> 
> Because the line objects are not sorted by offset. They are added at the end
> of the list in the order the user creates their corresponding configfs groups.
> 

Then your patch is also broken as it uses the last named entry,
not the named entry with the greatest offset??

Cheers,
Kent.

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

* Re: [PATCH v4] gpio: sim: fix an invalid __free() usage
  2023-09-19  7:37     ` Kent Gibson
@ 2023-09-19  7:46       ` brgl
  0 siblings, 0 replies; 8+ messages in thread
From: brgl @ 2023-09-19  7:46 UTC (permalink / raw)
  To: Kent Gibson
  Cc: Andy Shevchenko, Linus Walleij, Alexey Dobriyan, Peter Zijlstra,
	Linus Torvalds, akpm, linux-gpio, linux-kernel,
	Bartosz Golaszewski, brgl

On Tue, 19 Sep 2023 09:37:17 +0200, Kent Gibson <warthog618@gmail.com> said:
> On Tue, Sep 19, 2023 at 12:31:36AM -0700, brgl@bgdev.pl wrote:
>> On Mon, 18 Sep 2023 17:31:36 +0200, Andy Shevchenko
>> <andriy.shevchenko@linux.intel.com> said:
>> > On Mon, Sep 18, 2023 at 04:55:33PM +0200, Bartosz Golaszewski wrote:
>> >> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>> >>
>> >> gpio_sim_make_line_names() returns NULL or ERR_PTR() so we must not use
>> >> __free(kfree) on the returned address. Split this function into two, one
>> >> that determines the size of the "gpio-line-names" array to allocate and
>> >> one that actually sets the names at correct offsets. The allocation and
>> >> assignment of the managed pointer happens in between.
>> >
>> > ...
>> >
>> >> +	unsigned int size = 0;
>> >>
>> >>  	list_for_each_entry(line, &bank->line_list, siblings) {
>> >> +		if (!line->name || (line->offset >= bank->num_lines))
>> >>  			continue;
>> >>
>> >> +		size = line->offset + 1;
>> >>  	}
>> >>
>> >> +	return size;
>> >
>> > So, now the function iterates over all lines and returns the size of the last
>> > match, correct?
>> >
>> > Why not
>> >
>> > 	list_for_each_entry_reversed() {
>> > 		if (line->name && ())
>> > 			break;
>> > 	}
>> >
>> > 	return size;
>> >
>> > ?
>>
>> Because the line objects are not sorted by offset. They are added at the end
>> of the list in the order the user creates their corresponding configfs groups.
>>
>
> Then your patch is also broken as it uses the last named entry,
> not the named entry with the greatest offset??
>
> Cheers,
> Kent.
>

Yes, of course it is. Ironically v3 was at least correct in this part.

Thanks
Bart

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

* Re: [PATCH v4] gpio: sim: fix an invalid __free() usage
  2023-09-19  7:31   ` brgl
  2023-09-19  7:37     ` Kent Gibson
@ 2023-09-19 10:49     ` Andy Shevchenko
  2023-09-23 18:19       ` Linus Torvalds
  1 sibling, 1 reply; 8+ messages in thread
From: Andy Shevchenko @ 2023-09-19 10:49 UTC (permalink / raw)
  To: brgl
  Cc: Linus Walleij, Kent Gibson, Alexey Dobriyan, Peter Zijlstra,
	Linus Torvalds, akpm, linux-gpio, linux-kernel,
	Bartosz Golaszewski

On Tue, Sep 19, 2023 at 12:31:36AM -0700, brgl@bgdev.pl wrote:
> On Mon, 18 Sep 2023 17:31:36 +0200, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> said:
> > On Mon, Sep 18, 2023 at 04:55:33PM +0200, Bartosz Golaszewski wrote:

...

> > Of course this can be replace with...
> >
> >> +		line_names = kcalloc(line_names_size, sizeof(*line_names),
> >> +				     GFP_KERNEL);
> >
> >> +		if (!line_names)
> >
> > ZERO_OR_NULL_PTR() check here, but I assume we discourage use of it.
> 
> Why? There are less than 40 instances of using it in the kernel. kmalloc()
> returns NULL on failure.

Nope, k*alloc*() returns ZERO or NULL on failure. That's what most developers
are missing :-)

> >> +			return ERR_PTR(-ENOMEM);

Hence either one needs to check for 0 the size given to the kmalloc(),
_or_ to check for all possible return values from it.

-- 
With Best Regards,
Andy Shevchenko



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

* Re: [PATCH v4] gpio: sim: fix an invalid __free() usage
  2023-09-19 10:49     ` Andy Shevchenko
@ 2023-09-23 18:19       ` Linus Torvalds
  2023-09-25  6:58         ` Andy Shevchenko
  0 siblings, 1 reply; 8+ messages in thread
From: Linus Torvalds @ 2023-09-23 18:19 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: brgl, Linus Walleij, Kent Gibson, Alexey Dobriyan,
	Peter Zijlstra, akpm, linux-gpio, linux-kernel,
	Bartosz Golaszewski

On Tue, 19 Sept 2023 at 03:49, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> Nope, k*alloc*() returns ZERO or NULL on failure. That's what most developers
> are missing :-)

Absolutely not.

k*alloc() returns NULL on failure. Absolutely nothing else.

On *success*, it can return the special ZERO_SIZE_PTR. But that is
*not* a failure at all. It's very much a successful pointer.

Now, it's a pointer that you can't actually dereference, but that's
very much intentional. You can't dereference it, because you asked for
a zero-sized allocation. You got a zero-sized allocation.

But please never *ever* think it's a failure. It's very much not a
failure case, and it is very much intentional.

It's different from NULL exactly *because* it's successful, and
exactly so that you can write

     ptr = kmalloc(size);
     if (!ptr)
          return -ENOMEM;

without having to worry about the "size is zero" case.

The standard user-space "malloc()" library is misdesigned. Surprise
surprise. The kernel isn't.

                Linus

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

* Re: [PATCH v4] gpio: sim: fix an invalid __free() usage
  2023-09-23 18:19       ` Linus Torvalds
@ 2023-09-25  6:58         ` Andy Shevchenko
  0 siblings, 0 replies; 8+ messages in thread
From: Andy Shevchenko @ 2023-09-25  6:58 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: brgl, Linus Walleij, Kent Gibson, Alexey Dobriyan,
	Peter Zijlstra, akpm, linux-gpio, linux-kernel,
	Bartosz Golaszewski

On Sat, Sep 23, 2023 at 11:19:08AM -0700, Linus Torvalds wrote:
> On Tue, 19 Sept 2023 at 03:49, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > Nope, k*alloc*() returns ZERO or NULL on failure. That's what most developers
> > are missing :-)
> 
> Absolutely not.
> 
> k*alloc() returns NULL on failure. Absolutely nothing else.
> 
> On *success*, it can return the special ZERO_SIZE_PTR. But that is
> *not* a failure at all. It's very much a successful pointer.
> 
> Now, it's a pointer that you can't actually dereference, but that's
> very much intentional. You can't dereference it, because you asked for
> a zero-sized allocation. You got a zero-sized allocation.

"A-ha" moment to me, thank you for elaboration!

> But please never *ever* think it's a failure. It's very much not a
> failure case, and it is very much intentional.
> 
> It's different from NULL exactly *because* it's successful, and
> exactly so that you can write
> 
>      ptr = kmalloc(size);
>      if (!ptr)
>           return -ENOMEM;
> 
> without having to worry about the "size is zero" case.
> 
> The standard user-space "malloc()" library is misdesigned. Surprise
> surprise. The kernel isn't.

-- 
With Best Regards,
Andy Shevchenko



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

end of thread, other threads:[~2023-09-25  6:58 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-18 14:55 [PATCH v4] gpio: sim: fix an invalid __free() usage Bartosz Golaszewski
2023-09-18 15:31 ` Andy Shevchenko
2023-09-19  7:31   ` brgl
2023-09-19  7:37     ` Kent Gibson
2023-09-19  7:46       ` brgl
2023-09-19 10:49     ` Andy Shevchenko
2023-09-23 18:19       ` Linus Torvalds
2023-09-25  6:58         ` Andy Shevchenko

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.