On Thu, 21 Mar 2019, Waiman Long wrote: > When releasing kernel data structures, freeing up the memory > occupied by those objects is usually the last step. To avoid races, > the release operation is commonly done with a lock held. However, the > freeing operations do not need to be under lock, but are in many cases. > > In some complex cases where the locks protect many different memory > objects, that can be a problem especially if some memory debugging > features like KASAN are enabled. In those cases, freeing memory objects > under lock can greatly lengthen the lock hold time. This can even lead > to soft/hard lockups in some extreme cases. > > To make it easer to defer freeing memory objects until after unlock, > a kernel memory freeing queue mechanism is now added. It is modelled > after the wake_q mechanism for waking up tasks without holding a lock. It is already pretty easy. You just store the pointer to the slab object in a local variable, finish all the unlocks and then free the objects. This is done in numerous places of the kernel. I fear that the automated mechanism will make the code more difficult to read and result in a loss of clarity of the sequencing of events in releasing locks and objects. Also there is already kfree_rcu which does a similar thing to what you are proposing here and is used in numerous places.
