From: Vladimir Davydov <vdavydov@parallels.com>
To: akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
devel@openvz.org, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>
Subject: Re: [PATCH -mm 0/3] slab: cleanup mem hotplug synchronization
Date: Sun, 6 Apr 2014 21:46:45 +0400 [thread overview]
Message-ID: <53419305.7090104@parallels.com> (raw)
In-Reply-To: <cover.1396779337.git.vdavydov@parallels.com>
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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Davydov <vdavydov@parallels.com>
To: <akpm@linux-foundation.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
<devel@openvz.org>, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>
Subject: Re: [PATCH -mm 0/3] slab: cleanup mem hotplug synchronization
Date: Sun, 6 Apr 2014 21:46:45 +0400 [thread overview]
Message-ID: <53419305.7090104@parallels.com> (raw)
In-Reply-To: <cover.1396779337.git.vdavydov@parallels.com>
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.
next prev parent reply other threads:[~2014-04-06 17:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-06 15:33 [PATCH -mm 0/3] slab: cleanup mem hotplug synchronization Vladimir Davydov
2014-04-06 15:33 ` Vladimir Davydov
2014-04-06 15:33 ` [PATCH -mm 1/3] mem-hotplug: turn mem_hotplug_mutex to rwsem Vladimir Davydov
2014-04-06 15:33 ` Vladimir Davydov
2014-04-06 15:33 ` [PATCH -mm 2/3] lockdep: mark rwsem_acquire_read as recursive Vladimir Davydov
2014-04-06 15:33 ` Vladimir Davydov
2014-04-07 8:13 ` Peter Zijlstra
2014-04-07 8:13 ` Peter Zijlstra
2014-04-07 8:26 ` Vladimir Davydov
2014-04-07 8:26 ` Vladimir Davydov
2014-04-06 15:33 ` [PATCH -mm 3/3] slab: lock_memory_hotplug for kmem_cache_{create,destroy,shrink} Vladimir Davydov
2014-04-06 15:33 ` Vladimir Davydov
2014-04-06 17:46 ` Vladimir Davydov [this message]
2014-04-06 17:46 ` [PATCH -mm 0/3] slab: cleanup mem hotplug synchronization Vladimir Davydov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53419305.7090104@parallels.com \
--to=vdavydov@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=penberg@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.