linux-kernel - Re: [PATCH] TOMOYO: Add garbage collector support. (v2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 May 2009 21:12:18 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:	jmorris@...ei.org, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] TOMOYO: Add garbage collector support. (v2)

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/