From: Manfred Spraul <manfred@colorfullife.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rmaplock 2/6 SLAB_DESTROY_BY_RCU
Date: Tue, 13 Jul 2004 18:36:22 +0200 [thread overview]
Message-ID: <40F40F86.5030201@colorfullife.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0407122250390.4005-100000@localhost.localdomain>
Hugh Dickins wrote:
>It's okay to take anon_vma->lock after it's freed, so long as it remains
>a struct anon_vma (its list would become empty, or perhaps reused for an
>unrelated anon_vma: but no problem since we always check that the page
>located is the right one); but corruption if that memory gets reused for
>some other purpose.
>
>
>
An interesting idea:
The slab caches are object caches. If a rcu user only needs a valid
object but doesn't care which one then there is no need to wait for a
quiescent cycle after free - the quiescent cycle can be delayed until
the destructor is called.
But there are two flaws in your patch:
- you must disable poisoning and unmapping if SLAB_DESTROY_BY_RCU is set.
- either delay the dtor calls a well or fail if an object has a non-NULL
dtor and SLAB_DESTROY_BY_RCU is set.
--
Manfred
next prev parent reply other threads:[~2004-07-13 16:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-12 21:49 [PATCH] rmaplock 1/6 PageAnon in mapping Hugh Dickins
2004-07-12 21:50 ` [PATCH] rmaplock 2/6 kill page_map_lock Hugh Dickins
2004-07-12 21:52 ` [PATCH] rmaplock 2/6 SLAB_DESTROY_BY_RCU Hugh Dickins
2004-07-13 16:36 ` Manfred Spraul [this message]
2004-07-13 19:53 ` Hugh Dickins
2004-07-13 20:36 ` Manfred Spraul
2004-07-13 22:17 ` William Lee Irwin III
2004-07-14 20:25 ` Hugh Dickins
2004-07-12 21:53 ` [PATCH] rmaplock 4/6 mm lock ordering Hugh Dickins
2004-07-12 21:54 ` [PATCH] rmaplock 5/6 unuse_process mmap_sem Hugh Dickins
2004-07-12 21:55 ` [PATCH] rmaplock 6/6 swapoff use anon_vma Hugh Dickins
2004-07-13 4:48 ` [PATCH] rmaplock 1/6 PageAnon in mapping Andrew Morton
2004-07-13 7:08 ` Hugh Dickins
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=40F40F86.5030201@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.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.