[patch RFC] mm/slab: introduce KZALLOC_FREE() cleanup-ed allocation macro

[patch RFC] mm/slab: introduce KZALLOC_FREE() cleanup-ed allocation macro

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

With introduction of __free() macro using cleanup infrastructure, it
will very likely become quite common to see following pattern:
	type *var __free(kfree) = kzalloc(sizeof(*var), GFP_KERNEL);

To follow the CLASS() flow from cleanup.h, introduce a simple macro
KZALLOC_FREE() to wrap this over and allow the same flow.

Show an example usage in gpio-sim driver.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
---
 drivers/gpio/gpio-sim.c | 3 +--
 include/linux/slab.h    | 3 +++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-sim.c b/drivers/gpio/gpio-sim.c
index c4106e37e6db..997237b3d80c 100644
--- a/drivers/gpio/gpio-sim.c
+++ b/drivers/gpio/gpio-sim.c
@@ -1496,8 +1496,7 @@ gpio_sim_config_make_device_group(struct config_group *group, const char *name)
 {
 	int id;
 
-	struct gpio_sim_device *dev __free(kfree) = kzalloc(sizeof(*dev),
-							    GFP_KERNEL);
+	KZALLOC_FREE(struct gpio_sim_device *, dev, GFP_KERNEL);
 	if (!dev)
 		return ERR_PTR(-ENOMEM);
 
diff --git a/include/linux/slab.h b/include/linux/slab.h
index b5f5ee8308d0..baee6acd58d3 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -711,6 +711,9 @@ static inline __alloc_size(1) void *kzalloc(size_t size, gfp_t flags)
 	return kmalloc(size, flags | __GFP_ZERO);
 }
 
+#define KZALLOC_FREE(_type, var, _gfp_t)				\
+	_type var __free(kfree) = kzalloc(sizeof(*var), _gfp_t)
+
 /**
  * kzalloc_node - allocate zeroed memory from a particular memory node.
  * @size: how many bytes of memory are required.
-- 
2.44.0

Re: [patch RFC] mm/slab: introduce KZALLOC_FREE() cleanup-ed allocation macro

[David Rientjes]

On Fri, 15 Mar 2024, Jiri Pirko wrote:

> From: Jiri Pirko <jiri@nvidia.com>
> 
> With introduction of __free() macro using cleanup infrastructure, it
> will very likely become quite common to see following pattern:
> 	type *var __free(kfree) = kzalloc(sizeof(*var), GFP_KERNEL);
> 
> To follow the CLASS() flow from cleanup.h, introduce a simple macro
> KZALLOC_FREE() to wrap this over and allow the same flow.
> 
> Show an example usage in gpio-sim driver.
> 

Seems highly specialized especially for kzalloc specifically, so not sure 
this warrants its own macro.

> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
>  drivers/gpio/gpio-sim.c | 3 +--
>  include/linux/slab.h    | 3 +++
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-sim.c b/drivers/gpio/gpio-sim.c
> index c4106e37e6db..997237b3d80c 100644
> --- a/drivers/gpio/gpio-sim.c
> +++ b/drivers/gpio/gpio-sim.c
> @@ -1496,8 +1496,7 @@ gpio_sim_config_make_device_group(struct config_group *group, const char *name)
>  {
>  	int id;
>  
> -	struct gpio_sim_device *dev __free(kfree) = kzalloc(sizeof(*dev),
> -							    GFP_KERNEL);
> +	KZALLOC_FREE(struct gpio_sim_device *, dev, GFP_KERNEL);
>  	if (!dev)
>  		return ERR_PTR(-ENOMEM);
>  
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index b5f5ee8308d0..baee6acd58d3 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -711,6 +711,9 @@ static inline __alloc_size(1) void *kzalloc(size_t size, gfp_t flags)
>  	return kmalloc(size, flags | __GFP_ZERO);
>  }
>  
> +#define KZALLOC_FREE(_type, var, _gfp_t)				\
> +	_type var __free(kfree) = kzalloc(sizeof(*var), _gfp_t)
> +
>  /**
>   * kzalloc_node - allocate zeroed memory from a particular memory node.
>   * @size: how many bytes of memory are required.
> -- 
> 2.44.0
> 
> 

Re: [patch RFC] mm/slab: introduce KZALLOC_FREE() cleanup-ed allocation macro

[Jiri Pirko]

Fri, Mar 15, 2024 at 10:39:02PM CET, rientjes@google.com wrote:
>On Fri, 15 Mar 2024, Jiri Pirko wrote:
>
>> From: Jiri Pirko <jiri@nvidia.com>
>> 
>> With introduction of __free() macro using cleanup infrastructure, it
>> will very likely become quite common to see following pattern:
>> 	type *var __free(kfree) = kzalloc(sizeof(*var), GFP_KERNEL);
>> 
>> To follow the CLASS() flow from cleanup.h, introduce a simple macro
>> KZALLOC_FREE() to wrap this over and allow the same flow.
>> 
>> Show an example usage in gpio-sim driver.
>> 
>
>Seems highly specialized especially for kzalloc specifically, so not sure 
>this warrants its own macro.

Yeah, but having like 2-3 macro variants would probably cover vast
majority of usecases now. The rest could still do things manually.

Re [patch RFC] mm/slab: introduce KZALLOC_FREE() cleanup-ed allocation macro

[Przemek Kitszel]

> From: Jiri Pirko <jiri@nvidia.com>
> 
> With introduction of __free() macro using cleanup infrastructure, it
> will very likely become quite common to see following pattern:
> 	type *var __free(kfree) = kzalloc(sizeof(*var), GFP_KERNEL);
> 
> To follow the CLASS() flow from cleanup.h, introduce a simple macro
> KZALLOC_FREE() to wrap this over and allow the same flow.
> 
> Show an example usage in gpio-sim driver.
> 
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
>  drivers/gpio/gpio-sim.c | 3 +--
>  include/linux/slab.h    | 3 +++
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-sim.c b/drivers/gpio/gpio-sim.c
> index c4106e37e6db..997237b3d80c 100644
> --- a/drivers/gpio/gpio-sim.c
> +++ b/drivers/gpio/gpio-sim.c
> @@ -1496,8 +1496,7 @@ gpio_sim_config_make_device_group(struct config_group *group, const char *name)
>  {
>  	int id;
>  
> -	struct gpio_sim_device *dev __free(kfree) = kzalloc(sizeof(*dev),
> -							    GFP_KERNEL);
> +	KZALLOC_FREE(struct gpio_sim_device *, dev, GFP_KERNEL);
>  	if (!dev)
>  		return ERR_PTR(-ENOMEM);
>  
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index b5f5ee8308d0..baee6acd58d3 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -711,6 +711,9 @@ static inline __alloc_size(1) void *kzalloc(size_t size, gfp_t flags)
>  	return kmalloc(size, flags | __GFP_ZERO);
>  }
>  
> +#define KZALLOC_FREE(_type, var, _gfp_t)				\
> +	_type var __free(kfree) = kzalloc(sizeof(*var), _gfp_t)
> +

Nice, but I would rather see this wrapper in the cleanup.h file, that have all
of the rest of related stuff.

On top of that, I want to propose also a wrapper that is simpler in that it
does not allocate but just assigns null, with that in mind `_FREE` part of your
proposed name does not sound right.

Most of the similar functions that define or declare something are named
DEFINE_STH...

(Please CC me on any future version, I have to go, sorry).

>  /**
>   * kzalloc_node - allocate zeroed memory from a particular memory node.
>   * @size: how many bytes of memory are required.
> -- 
> 2.44.0
> 
> 

Re: Re [patch RFC] mm/slab: introduce KZALLOC_FREE() cleanup-ed allocation macro

[Dan Williams]

Przemek Kitszel wrote:
> > From: Jiri Pirko <jiri@nvidia.com>
> > 
> > With introduction of __free() macro using cleanup infrastructure, it
> > will very likely become quite common to see following pattern:
> > 	type *var __free(kfree) = kzalloc(sizeof(*var), GFP_KERNEL);
> > 
> > To follow the CLASS() flow from cleanup.h, introduce a simple macro
> > KZALLOC_FREE() to wrap this over and allow the same flow.
> > 
> > Show an example usage in gpio-sim driver.
> > 
> > Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> > ---
> >  drivers/gpio/gpio-sim.c | 3 +--
> >  include/linux/slab.h    | 3 +++
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpio/gpio-sim.c b/drivers/gpio/gpio-sim.c
> > index c4106e37e6db..997237b3d80c 100644
> > --- a/drivers/gpio/gpio-sim.c
> > +++ b/drivers/gpio/gpio-sim.c
> > @@ -1496,8 +1496,7 @@ gpio_sim_config_make_device_group(struct config_group *group, const char *name)
> >  {
> >  	int id;
> >  
> > -	struct gpio_sim_device *dev __free(kfree) = kzalloc(sizeof(*dev),
> > -							    GFP_KERNEL);
> > +	KZALLOC_FREE(struct gpio_sim_device *, dev, GFP_KERNEL);
> >  	if (!dev)
> >  		return ERR_PTR(-ENOMEM);
> >  
> > diff --git a/include/linux/slab.h b/include/linux/slab.h
> > index b5f5ee8308d0..baee6acd58d3 100644
> > --- a/include/linux/slab.h
> > +++ b/include/linux/slab.h
> > @@ -711,6 +711,9 @@ static inline __alloc_size(1) void *kzalloc(size_t size, gfp_t flags)
> >  	return kmalloc(size, flags | __GFP_ZERO);
> >  }
> >  
> > +#define KZALLOC_FREE(_type, var, _gfp_t)				\
> > +	_type var __free(kfree) = kzalloc(sizeof(*var), _gfp_t)
> > +
> 
> Nice, but I would rather see this wrapper in the cleanup.h file, that have all
> of the rest of related stuff.
> 
> On top of that, I want to propose also a wrapper that is simpler in that it
> does not allocate but just assigns null, with that in mind `_FREE` part of your
> proposed name does not sound right.

No, do not hide assignments within macros

http://lore.kernel.org/r/CAHk-=whYxkfLVtBW_B-PgNqhKOAThTbfoH5CxtOTkwOB6VOt6w@mail.gmail.com

I.e. the amount of incremenal cleverness that include/linux/cleanup.h
will tolerate is low. Any helper should look like typical C.

Re: Re [patch RFC] mm/slab: introduce KZALLOC_FREE() cleanup-ed allocation macro

[Przemek Kitszel]

On 3/25/24 20:00, Dan Williams wrote:
> Przemek Kitszel wrote:
>>> From: Jiri Pirko <jiri@nvidia.com>
>>>
>>> With introduction of __free() macro using cleanup infrastructure, it
>>> will very likely become quite common to see following pattern:
>>> 	type *var __free(kfree) = kzalloc(sizeof(*var), GFP_KERNEL);
>>>
>>> To follow the CLASS() flow from cleanup.h, introduce a simple macro
>>> KZALLOC_FREE() to wrap this over and allow the same flow.
>>>
>>> Show an example usage in gpio-sim driver.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>>> ---
>>>   drivers/gpio/gpio-sim.c | 3 +--
>>>   include/linux/slab.h    | 3 +++
>>>   2 files changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpio-sim.c b/drivers/gpio/gpio-sim.c
>>> index c4106e37e6db..997237b3d80c 100644
>>> --- a/drivers/gpio/gpio-sim.c
>>> +++ b/drivers/gpio/gpio-sim.c
>>> @@ -1496,8 +1496,7 @@ gpio_sim_config_make_device_group(struct config_group *group, const char *name)
>>>   {
>>>   	int id;
>>>   
>>> -	struct gpio_sim_device *dev __free(kfree) = kzalloc(sizeof(*dev),
>>> -							    GFP_KERNEL);
>>> +	KZALLOC_FREE(struct gpio_sim_device *, dev, GFP_KERNEL);
>>>   	if (!dev)
>>>   		return ERR_PTR(-ENOMEM);
>>>   
>>> diff --git a/include/linux/slab.h b/include/linux/slab.h
>>> index b5f5ee8308d0..baee6acd58d3 100644
>>> --- a/include/linux/slab.h
>>> +++ b/include/linux/slab.h
>>> @@ -711,6 +711,9 @@ static inline __alloc_size(1) void *kzalloc(size_t size, gfp_t flags)
>>>   	return kmalloc(size, flags | __GFP_ZERO);
>>>   }
>>>   
>>> +#define KZALLOC_FREE(_type, var, _gfp_t)				\
>>> +	_type var __free(kfree) = kzalloc(sizeof(*var), _gfp_t)
>>> +
>>
>> Nice, but I would rather see this wrapper in the cleanup.h file, that have all
>> of the rest of related stuff.
>>
>> On top of that, I want to propose also a wrapper that is simpler in that it
>> does not allocate but just assigns null, with that in mind `_FREE` part of your
>> proposed name does not sound right.
> 
> No, do not hide assignments within macros

As most general advice I agree, but here we have a specific case:
declare variable via macro; and that, (given the macro name would be
clearer), is expected to have assignment (or default (un)init).
I would even go one step further and remove also the asterisk from the
call site (and *hide* it in the macro definition).

See _DEFINE_FLEX() as example:
(there we change on-stack instead $this_thread on-heap-autofree)
https://elixir.bootlin.com/linux/v6.9-rc1/source/include/linux/overflow.h#L401 


> 
> http://lore.kernel.org/r/CAHk-=whYxkfLVtBW_B-PgNqhKOAThTbfoH5CxtOTkwOB6VOt6w@mail.gmail.com

Your thread is a more complex thing to what we have here.
And BTW, your original proposed solution is nice, and even if it hides
flow inside, it's almost obvious (the `return -EINTR` statement
is verbatim at call site). Allowing `else return -EINTR;` solution
proposed by @Linus is nicer, makes a good idiom, but is less obvious:
Imagine two developers that don't know the API (well), one writes:
`scoped_cond_guard(args);` and forgets to handle the error case,
the other by just looking at the code have no idea to append
`else handle_err();`.

> 
> I.e. the amount of incremenal cleverness that include/linux/cleanup.h
> will tolerate is low. Any helper should look like typical C