On Thu, Oct 23, 2025 at 4:01 PM ally heev <[email protected]> wrote: > > I would go futher and suggest that the pattern of: > > > > type foo __free(free_foo) = NULL; > > > > ...be made into a warning because that easily leads to situations where > > declaration order is out of sync with allocation order. I.e. can be made > > technically correct, but at a level of cleverness that undermines the > > benefit. > > But, does this pattern cause any real issue? I found allocating memory > later useful in cases like below > > arch/powerpc/perf/vpa-dtl.c > ``` > > struct vpa_pmu_buf *buf __free(kfree) = NULL; > struct page **pglist __free(kfree) = NULL; > > /* We need at least one page for this to work. */ > if (!nr_pages) > return NULL; > > if (cpu == -1) > cpu = raw_smp_processor_id(); > > buf = kzalloc_node(sizeof(*buf), GFP_KERNEL, > cpu_to_node(cpu)); > ``` >
I will take this back. Found this in `include/linux/cleanup.h` ``` * Given that the "__free(...) = NULL" pattern for variables defined at * the top of the function poses this potential interdependency problem * the recommendation is to always define and assign variables in one * statement and not group variable definitions at the top of the * function when __free() is used. ```
