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] [day] [month] [year] [list]

Message-ID: <20090602033539.GA6846@linux.vnet.ibm.com>
Date:	Mon, 1 Jun 2009 20:35:39 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:	serge@...lyn.com, serue@...ibm.com,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] TOMOYO: Add garbage collector support. (v2)

On Tue, Jun 02, 2009 at 10:16:54AM +0900, Tetsuo Handa wrote:
> Serge E. Hallyn wrote:
> > All readers should walk the list under rcu_read_lock, so if the manage
> > to reach ->entry, then entry.list->next will be a valid entry on the live
> > list until the next rcu cycle.
> 
> I have to tell you one thing.
> Reader traverses the list via read(2) system call.
> It means that reader can't read all elements in the list within a single
> read(2) system call.
> Thus, reader grabs a reference on an element (i.e. p->entry.users) before
> leaving reader section and drops that reference after entering reader section.
> 
> Yes, it would be possible for readers to walk the list under rcu_read_lock(),
> but it is not sufficient for GC to simply call synchronize_rcu(). GC has to
> wait for p->entry.users to become 0 before modifying p->entry.list.next .

The usual approach would be for the code that causes p->entry.users
to become zero to do the list_del_rcu() and then pass the entry to
call_rcu().  Or execute synchronize_rcu() if blocking is permissible.

Of course, it is necessary to handle the race where one task decrements
the counter to zero while another increments it back up to 1.  One way to
handle this is to use atomic_inc_not_zero() when acquiring a reference,
thus refusing to acquire the reference if the count is already zero.
But your GC would need to handle this same race condition, so whatever
you were doing in that case should work here as well.

							Thanx, Paul

> > BTW I'm not telling you have to do this, so if you just don't want to, then
> > just say so.  But so long as you come back to me with technical reasons
> > why you can't, then I take it you're interested in a technical solution :)
> > and can't help but respond...
> 
> I see. I'll post only (1) and (2).
> 
> Thank you for your suggestion and time.
> --
> 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/
--
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/