On 7/30/26 05:08, Harry Yoo wrote:
>
>
> On 7/29/26 11:14 PM, Vlastimil Babka (SUSE) wrote:
>> On 7/29/26 10:20, Harry Yoo (Oracle) wrote:
>>
>> ...
>>
>>> 8: 8e69c83a1e52 ! 8: aeaf2ab60046 slub_kunit: extend the test for
>>> kfree_rcu_nolock()
>>> @@ lib/tests/slub_kunit.c: struct test_nolock_context {
>>> - gfp_t gfp = (i % 2) ? GFP_KERNEL :
>>> GFP_KERNEL_ACCOUNT;
>>> + gfp_t gfp = (i & 1) ? GFP_KERNEL :
>>> GFP_KERNEL_ACCOUNT;
>>>
>>> - objects[j] = kmalloc_obj(*objects[j], gfp);
>>> +- objects[j] = kmalloc(64, gfp);
>>> ++ objects[j] = kmalloc_obj(*objects[j], gfp);
>>> if (!objects[j]) {
>>> + j--;
>>> + while (j >= 0)
>>> @@ lib/tests/slub_kunit.c: static void test_kmalloc_kfree(void)
>>> }
>>> }
>>>
>>> Link:
>>> https://lore.kernel.org/linux-mm/[email protected]
>>> [1]
>>> Link:
>>> https://lore.kernel.org/linux-mm/[email protected]
>>> [2]
>>> Acked-by: Vlastimil Babka (SUSE) <[email protected]>
>>> Signed-off-by: Harry Yoo (Oracle) <[email protected]>
>>> Link:
>>> https://lore.kernel.org/linux-mm/[email protected]
>>> Signed-off-by: Harry Yoo (Oracle) <[email protected]>
>>> Link:
>>> https://lore.kernel.org/linux-mm/[email protected]
>>> [1]
>>> Link:
>>> https://lore.kernel.org/linux-mm/[email protected]
>>> [2]
>>> Suggested-by: Vlastimil Babka (SUSE) <[email protected]>
>>> Signed-off-by: Harry Yoo (Oracle) <[email protected]>
>>> Signed-off-by: Harry Yoo (Oracle) <[email protected]>
>>> Signed-off-by: Harry Yoo (Oracle) <[email protected]>
>>
>> Wonder what produced this weird block of assorted trailers? "b4 prep
>> --compare-to vX" never did that for me?
>
> Interesting. I checked it again with `b4 prep --compare-to v4`, but the
> command didn't produce this. Looking at the cover letter
> `b4 prep --edit-cover` It's not even there.
>
> Probably it was produced during b4 send --no-sign? hmm...
Hmm let's see if it ever happens again.
>>> ---
>>> Harry Yoo (Oracle) (8):
>>> mm/slab, slub_kunit: register kprobe to trigger _nolock APIs
>>> mm/slab: handle the !allow_spin case in kfree_rcu_sheaf()
>>> mm/slab: use call_rcu() in unknown context if irqs are enabled
>>> mm/slab: extend deferred free mechanism to handle rcu sheaves
>>> mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT
>>> mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batching
>>> mm/slab: introduce kfree_rcu_nolock()
>>> slub_kunit: extend the test for kfree_rcu_nolock()
>>>
>>> include/linux/rcupdate.h | 32 ++++++-
>>> include/linux/slab.h | 16 +---
>>> include/linux/types.h | 8 ++
>>> include/trace/events/rcu.h | 2 +-
>>> lib/tests/slub_kunit.c | 190 ++++++++++++++++++++++++++++-----------
>>> mm/slab.h | 52 ++++++++++-
>>> mm/slab_common.c | 81 +++++++++++++----
>>> mm/slub.c | 220
>>> ++++++++++++++++++++++++++++-----------------
>>> 8 files changed, 433 insertions(+), 168 deletions(-)
>>
>> Applied to slab/for-7.3/kfree_rcu_nolock and merged go slab/for-next, thanks!
>
> Thanks a lot!
>
>> Used slab/for-next-fixes as a base for a better topic branch indepdencence.
>
> Ah, I see. thanks.
>
> So slab/for-next is not a good base unless it depends too much on
> existing commits on the branch?
>
> And usually it's better to use the base (slab/for-next-fixes,
> in this case) of slab/for-next as a base?
Yeah. Hopefully we'll figure out some documented guidelines for this in the
upcoming mm-next meetings.
>>> ---
>>> base-commit: ffc64805cebac330b2a60b2f1f144fcc35b8ab46
>>> change-id: 20260615-kfree_rcu_nolock-e5502555992f
>>>
>>> Best regards,
>
