Messages in this thread | | | Date | Sun, 6 Apr 2014 21:46:45 +0400 | From | Vladimir Davydov <> | Subject | Re: [PATCH -mm 0/3] slab: cleanup mem hotplug synchronization |
| |
On 04/06/2014 07:33 PM, Vladimir Davydov wrote: > kmem_cache_{create,destroy,shrink} need to get a stable value of > cpu/node online mask, because they init/destroy/access per-cpu/node > kmem_cache parts, which can be allocated or destroyed on cpu/mem > hotplug. To protect against cpu hotplug, these functions use > {get,put}_online_cpus. However, they do nothing to synchronize with > memory hotplug - taking the slab_mutex does not eliminate the > possibility of race as described in patch 3. > > What we need there is something like get_online_cpus, but for memory. We > already have lock_memory_hotplug, which serves for the purpose, but it's > a bit of a hammer right now, because it's backed by a mutex. As a > result, it imposes some limitations to locking order, which are not > desirable, and can't be used just like get_online_cpus. I propose to > turn this mutex into an rw semaphore, which will be taken for reading in > lock_memory_hotplug and for writing in memory hotplug code (that's what > patch 1 does).
This is absolutely wrong, because down_read cannot be nested inside down/up_write critical section. Although it would work now, it could result in deadlocks in future. Please ignore this set completely.
Actually we need to implement a recursive rw semaphore here, just like cpu_hotplug_lock.
Sorry for the noise.
Thanks.
| |