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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/25/24 20:00, Dan Williams wrote:
Przemek Kitszel wrote:
From: Jiri Pirko <jiri@xxxxxxxxxx>

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@xxxxxxxxxx>
---
  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@xxxxxxxxxxxxxx

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux