Re: [PATCH] mm/slab: improve kmem_cache_alloc_bulk

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] BUG CONFIRMED: MSM UNMAP ioctls fail with -ENOMEM due to 0-size bulk allocation rejection.

Pre-existing issues:
- [High] BUG CONFIRMED: Kernel panic from kfree() on vmalloc pointer in bulk allocation error path.
--

commit 2defa6181f53f2235f7496349b8ea576d0868ab8
Author: Christoph Hellwig <hch@lst.de>

mm/slab: improve kmem_cache_alloc_bulk

This commit changes the return type of kmem_cache_alloc_bulk() from int
to bool. Callers are updated to check for boolean success or failure instead
of comparing the return value against the requested count.

> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 058c71c82cf54..533104d71f6ce 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -330,17 +330,15 @@ static int
>  msm_iommu_pagetable_prealloc_allocate(struct msm_mmu *mmu, struct msm_mmu_prealloc *p)
>  {
>  	struct kmem_cache *pt_cache = get_pt_cache(mmu);
> -	int ret;
>  
>  	p->pages = kvmalloc_objs(*p->pages, p->count);
>  	if (!p->pages)
>  		return -ENOMEM;
>  
> -	ret = kmem_cache_alloc_bulk(pt_cache, GFP_KERNEL, p->count, p->pages);
> -	if (ret != p->count) {
> +	if (!kmem_cache_alloc_bulk(pt_cache, GFP_KERNEL, p->count, p->pages)) {

[Severity: High]
If p->count is 0 (which can happen during UNMAP ioctls), kvmalloc_objs() 
returns ZERO_SIZE_PTR, which passes the !p->pages check.

However, the updated kmem_cache_alloc_bulk() returns false when size is 0.
Previously, it returned 0, which matched p->count, allowing the function to 
succeed. Now, a 0 count evaluates as a failure and incorrectly returns -ENOMEM. 
Could this inadvertently break UNMAP ioctls by rejecting 0-size allocations?

>  		kfree(p->pages);

[Severity: High]
This is a pre-existing issue, but p->pages is allocated using kvmalloc_objs(),
which can fall back to vmalloc for large allocations.

If the allocation was fulfilled by vmalloc, doesn't calling kfree() on this 
pointer cause a kernel panic? Should this be changed to kvfree() instead?

>  		p->pages = NULL;
> -		p->count = ret;
> +		p->count = 0;
>  		return -ENOMEM;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260528093437.2519248-2-hch@lst.de?part=1