On 6/1/26 08:39, Harry Yoo wrote:
>
>
> On 5/29/26 10:50 PM, Christoph Hellwig wrote:
>> On Fri, May 29, 2026 at 01:54:48PM +0200, Vlastimil Babka (SUSE) wrote:
>>> Thanks, I applied it to slab/for-7.2/alloc_bulk and merged to slab/for-next
>>> (it's still yankable in case of issues)
>>>
>>> Did some fixups below (the comment was stale prior to the patch; restored
>>> unlikely(), simplified one line).
>>>
>>> A test merge into yesterday's -next found a conflict in drivers/gpu/drm/
>>> panthor/panthor_mmu.c. Commit 1013bf53650e ("drm/panthor: Split
>>> panthor_vm_prepare_map_op_ctx() to prepare for reclaim") moved the changed
>>> codeto a new function panthor_vm_op_ctx_prealloc_pts().
>>> But it's solvable so no need for a complicated coordination I think.
>>
>> Ok, thanks. The two Sashiko complains also look like they had merrits,
>> but I won't get to looking into them until Monday.
> The review:
> https://sashiko.dev/#/patchset/20260528093437.2519248-2-hch%40lst.de
>
> So there is a user who might call kmem_cache_alloc_bulk() with size = 0
I don't know if it can really happen there, but maybe DRM folks can tell us.
> (although the comment says @size must be larger than 0!) and
The comment is however new, the caller existed when there was no comment and
the return value 0 when asked for 0 was working there.
> kmem_cache_alloc_bulk() returning 0 was considered a success in that case.
>
> Either fixing kmem_cache_alloc_bulk() (and the comment) or fixing the
> user sounds fine to me.
Would it be wrong if we just returned true for size of 0? Would something
else break?
> And yeah freeing an object via kfree() allocated via kvmalloc is a bug...
Yep.
