Re: [PATCH 1/2] lib/genalloc: don't dereference a NULL pool in gen_pool_dma_[z]alloc()

[Fredrik Noring <fredrik.noring@gmail.com>]

Hi Amit,

On Fri, Nov 06, 2026 at 09:02:32AM -0500, Amit Patole wrote:
> gen_pool_dma_alloc() returned NULL for a NULL pool since it was added.
> Commit cf394fc5f715 ("lib/genalloc.c: Add algorithm, align and zeroed
> family of DMA allocators") moved that check into
> gen_pool_dma_alloc_algo(), but gen_pool_dma_alloc() now reads
> pool->algo and pool->data before calling it, so a NULL pool is
> dereferenced instead. gen_pool_dma_zalloc(), added by the same commit,
> has the same problem. The _algo() and _align() variants still return
> NULL.
> 
> All in-tree callers check the pool before calling, so this is not
> known to be reachable today, but the four entry points disagree and
> the original behaviour is easy to restore. Check for a NULL pool before
> dereferencing it.

If this change is accepted, may I suggest that the corresponding
documentation

	@pool: pool to allocate from

is updated to (something like)

	@pool: pool to allocate from, or %NULL

as well? There seem to be 8 instances, but some of the others currently
don't accept %NULL, for example gen_pool_virt_to_phys(), which I suppose
could be made to return -1 in that case?

And then there's gen_pool_destroy(), which currently doesn't accept
%NULL either. Error paths can often be simplified if free/destroy/release/etc.
accept %NULL.

I'm not up-to-date with the latest NULL handling policy in the kernel,
but I think some inconsistencies can be found still. :-)

Fredrik