Messages in this thread | | | Date | Sat, 11 Jun 2022 12:04:22 +0800 | Subject | Re: [PATCH 1/3] mm/slub: fix the race between validate_slab and slab_free | From | Rongwei Wang <> |
| |
On 6/8/22 8:23 PM, Christoph Lameter wrote: > On Wed, 8 Jun 2022, Rongwei Wang wrote: > >> If available, I think document the issue and warn this incorrect behavior is >> OK. But it still prints a large amount of confusing messages, and disturbs us? > > Correct it would be great if you could fix this in a way that does not > impact performance. > >>> are current operations on the slab being validated. >> And I am trying to fix it in following way. In a short, these changes only >> works under the slub debug mode, and not affects the normal mode (I'm not >> sure). It looks not elegant enough. And if all approve of this way, I can >> submit the next version. > > >> >> Anyway, thanks for your time:). >> -wrw >> >> @@ -3304,7 +3300,7 @@ static void __slab_free(struct kmem_cache *s, > struct >> slab *slab, >> >> { >> void *prior; >> - int was_frozen; >> + int was_frozen, to_take_off = 0; >> struct slab new; > > to_take_off has the role of !n ? Why is that needed? > >> - do { >> - if (unlikely(n)) { >> + spin_lock_irqsave(&n->list_lock, flags); >> + ret = free_debug_processing(s, slab, head, tail, cnt, addr); > > Ok so the idea is to take the lock only if kmem_cache_debug. That looks > ok. But it still adds a number of new branches etc to the free loop. > > Some performance tests would be useful. Hi Christoph
Thanks for your time! Do you have some advice in benchmarks that need me to test? And I find that hackbench and lkp was used frequently in mm/slub.c commits[1,2]. But I have no idea how to use these two benchmarks test to cover the above changes. Can you give some examples? Thanks very much!
Sorry for late reply!
[1]https://lore.kernel.org/lkml/20210301080404.GF12822@xsang-OptiPlex-9020/ [2]https://lore.kernel.org/linux-mm/20210128134512.GF3592@techsingularity.net/
| |