On Mon, Sep 19, 2022 at 05:12:38PM +0800, Vlastimil Babka wrote:
On 9/19/22 05:12, Feng Tang wrote:[...]
Oops.. Thanks for catching it!The cause is inside kmem_cache_destroy():^ not set
kmem_cache_destroy
acquire lock/mutex
shutdown_cache
schedule_work(kmem_cache_release) (if RCU flag set)
release lock/mutex
kmem_cache_release (if RCU flag set)
I've fixed that up.
Got it, thanksin some certain timing, the scheduled work could be run beforeThanks!
the next RCU flag checking which will get a wrong state.
Fix it by caching the RCU flag inside protected area, just like 'refcnt'
Signed-off-by: Feng Tang <feng.tang@xxxxxxxxx>
---Actually that commit is already in Linus' rc5 too, so I will send your fix
note:
The error only happens on linux-next tree, and not in Linus' tree,
which already has Waiman's commit:
0495e337b703 ("mm/slab_common: Deleting kobject in kmem_cache_destroy()
without holding slab_mutex/cpu_hotplug_lock")
this week too. Added a Fixes: 0495e337b703 (...) too.
- Feng