Qu Wenruo @ 2026-02-24 17:24 +1030:

> 在 2026/2/24 17:16, Miquel Sabaté Solà 写道:
>> Johannes Thumshirn @ 2026-02-24 06:32 GMT:
>>
>>> On 2/24/26 12:45 AM, Miquel Sabaté Solà wrote:
>>>> Commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family")
>>>> introduced, among many others, the kzalloc_objs() helper, which has some
>>>> benefits over kcalloc().
>>> Namely?
>> I didn't want to repeat the arguments from the quoted commit
>> 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family"). Namely:
>
> If you assume every btrfs developer is aware of all slab/mm/vfs/whatever
> subsystem development, then I'd say you're wrong.

To be fair, what I quoted comes from the git log for that commit. So I
was not assuming a subscription to any list or following of other
subsystems. If that's how I sounded, then I apologise.

>
> Thus you should mention the commit (which is not yet in our developmenet tree),
> and at least have a short reason on the benefit.

Regardless of the above, both you and Johannes bring a fair point. I
will expand the git message just so people don't have to lookup in other
places to get the full context of the change. I'll do that on v2.

Thanks!
Miquel

>
>>
>>> Internal introspection of the allocated type now becomes possible,
>>> allowing for future alignment-aware choices to be made by the
>>> allocator and future hardening work that can be type sensitive.
>> Should I put this in the commit message as well, regardless of the
>> commit explaining this being quoted?
>> There's also the argument of dropping 'sizeof' to be more ergonomic. To
>> me, though, and considering how these helpers have been applied
>> tree-wide, I see this change more as aligning us with this recent
>> tree-wide move, which also affected btrfs (see commit 69050f8d6d07
>> "treewide: Replace kmalloc with kmalloc_obj for non-scalar types").