On 2018-10-08 11:15:57 [+0200], Dmitry Vyukov wrote: > Hi Sebastian, Hi Dmitry, > This seems to beak quarantine_remove_cache( ) in the sense that some > object from the cache may still be in quarantine when > quarantine_remove_cache() returns. When quarantine_remove_cache() > returns all objects from the cache must be purged from quarantine. > That srcu and irq trickery is there for a reason. That loop should behave like your on_each_cpu() except it does not involve the remote CPU. > This code is also on hot path of kmallock/kfree, an additional > lock/unlock per operation is expensive. Adding 2 locked RMW per > kmalloc is not something that should be done only out of refactoring > reasons. But this is debug code anyway, right? And it is highly complex imho. Well, maybe only for me after I looked at it for the first time… > The original message from Clark mentions that the problem can be fixed > by just changing type of spinlock. This looks like a better and > simpler way to resolve the problem to me. I usually prefer to avoid adding raw_locks everywhere if it can be avoided. However given that this is debug code and a few additional us shouldn't matter here, I have no problem with Clark's initial patch (also the mem-free in irq-off region works in this scenario). Can you take it as-is or should I repost it with an acked-by? Sebastian
