On Mon, Feb 9, 2026 at 1:38 AM Vlastimil Babka <[email protected]> wrote: > > On 2/6/26 21:09, Alexei Starovoitov wrote: > > On Fri, Feb 6, 2026 at 1:35 AM Harry Yoo <[email protected]> wrote: > >> > >> Since kfree() now supports freeing objects allocated with > >> kmalloc_nolock(), free one bit in enum object_flags. > >> > >> Signed-off-by: Harry Yoo <[email protected]> > > > > For patches 3 and 4: > > > > Acked-by: Alexei Starovoitov <[email protected]> > > > > I think patches 3 and 4 are ready. > > Would be great to land them for this merge window > > (if Vlastimil agrees). > > We should have an ack from Catalin for kmemleak. Also better take them out > of the RFC and send as 2 non-rfc patches first, with cc list reduced > accordingly etc. > > Then I can put them to -next and try sending second merge window PR next > week. Can you also point to any bug reports that would be fixed? (that you > had to work around or delay merging or something) that would help the > argument to not wait a cycle.
Here is one example: https://lore.kernel.org/all/[email protected]/ " RFC v1 tried to switch to kmalloc_nolock() unconditionally. However, as there is substantial performance loss in socket local storage due to 1) defer_free() in kfree_nolock() and 2) no kfree_rcu() batching, replacing kzalloc() is postponed until necessary improvements in mm land. " This patch addresses both 1 and 2. The freeing is done in a good context. The only reason we use kfree_nolock() and suffer from defer_free and lack of batching is due to kmalloc_nolock()->kfree_nolock() matching requirement. So this small patch is a big deal. We will be able to use kmalloc_nolock() -> kfree_rcu().
