From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: jmorris@namei.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] TOMOYO: Add garbage collector support. (v2)
Date: Tue, 26 May 2009 21:12:18 -0700 [thread overview]
Message-ID: <20090527041218.GA6882@linux.vnet.ibm.com> (raw)
In-Reply-To: <200905270125.n4R1PS0U031926@www262.sakura.ne.jp>
On Wed, May 27, 2009 at 10:25:28AM +0900, Tetsuo Handa wrote:
> Hello.
>
> Paul E. McKenney wrote:
> > The list_del_rcu() primitive is designed for removing elements from
> > lists that have concurrent readers, and it therefore avoids changing the
> > ->next pointer. That said, I don't immediately see whether or not there
> > is some other reason you need to keep it on the list. And do you need
> > the ->prev pointer to stay valid? If not, you might be able to use it
> > in place of the ->is_deleted flag.
>
> I don't need ->prev pointer.
>
> > > Use of RCU does not help here because we need to keep the item valid as long as
> > > the item is referred by ->read_var1 or ->read_var2 or ->write_var1 .
> >
> > You would indeed need some way of tracking those references. One
> > approach is to make the RCU callback check to see if any of them
> > reference the to-be-deleted object, reposting itself if so. This
> > approach assumes that such a reference is short-lived, of course.
> >
> > If the ->read_var1 and other references are long-lived, could you
> > post an RCU callback when the last such reference was removed?
>
> The reference stored in ->read_var1 / ->read_var2 / ->write_var1 are long-lived
> (it varies from less than one second to more than many hours).
Then one approach would be to check the ->is_deleted flag (or the
->prev pointer) when removing one of the ->read_varN references.
If the flag is set, and if no other ->read_varN references the same
object, post an RCU callback to clean it up.
Of course, when removing the object to start with, you could check
the references, and if none of them referenced the object, you could
post the callback immediately.
Or something similar.
> Well, it's time for me to read all Documentation/RCU/* .
I would also recommend the three-part LWN series as a starting point:
# http://lwn.net/Articles/262464/ (What is RCU, Fundamentally?)
# http://lwn.net/Articles/263130/ (What is RCU's Usage?)
# http://lwn.net/Articles/264090/ (What is RCU's API?)
Thanx, Paul
next prev parent reply other threads:[~2009-05-27 4:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 13:31 [TOMOYO 0/2] Final patches for kenrel 2.6.30 Tetsuo Handa
2009-04-08 13:31 ` [TOMOYO 1/2] tomoyo: add Documentation/tomoyo.txt Tetsuo Handa
2009-04-10 12:26 ` Peter Dolding
2009-04-10 17:10 ` Pavel Machek
2009-04-13 2:04 ` Tetsuo Handa
2009-04-29 13:13 ` Pavel Machek
2009-05-01 10:24 ` Pavel Machek
2009-05-01 13:07 ` Tetsuo Handa
2009-05-03 21:56 ` Pavel Machek
2009-05-04 6:24 ` Tetsuo Handa
2009-05-06 12:16 ` Tetsuo Handa
2009-05-07 11:42 ` [TOMOYO] Add garbage collector support Tetsuo Handa
2009-05-08 1:43 ` James Morris
2009-05-08 2:10 ` Tetsuo Handa
2009-05-08 8:26 ` James Morris
2009-05-08 9:22 ` Tetsuo Handa
2009-05-08 9:32 ` Pavel Machek
2009-05-14 12:08 ` [PATCH] TOMOYO: Add garbage collector support. (v2) Tetsuo Handa
2009-05-15 1:49 ` James Morris
2009-05-16 12:07 ` Tetsuo Handa
2009-05-25 0:37 ` Tetsuo Handa
2009-05-25 0:39 ` Tetsuo Handa
2009-05-25 0:41 ` Tetsuo Handa
2009-05-27 0:16 ` Paul E. McKenney
2009-05-27 1:25 ` Tetsuo Handa
2009-05-27 4:12 ` Paul E. McKenney [this message]
2009-06-01 13:27 ` Tetsuo Handa
2009-06-02 0:11 ` Serge E. Hallyn
2009-06-02 0:30 ` Tetsuo Handa
2009-06-02 1:03 ` Serge E. Hallyn
2009-06-02 1:16 ` Tetsuo Handa
2009-06-02 3:35 ` Paul E. McKenney
2009-04-08 13:31 ` [TOMOYO 2/2] Hello Tetsuo Handa
2009-04-10 11:55 ` Tetsuo Handa
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=20090527041218.GA6882@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox