Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 27 Mar 2024 08:23:12 +0100 | Subject | Re: Re [patch RFC] mm/slab: introduce KZALLOC_FREE() cleanup-ed allocation macro | From | 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
| ![\](/images/icornerr.gif) |