Re: [PATCH] checkpatch: add uninitialized pointer with __free attribute check

[ally heev <allyheev@gmail.com>]

On Thu, Oct 23, 2025 at 4:01 PM ally heev <allyheev@gmail.com> 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.
```