public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	serue@us.ibm.com, sds@tycho.nsa.gov, jmorris@namei.org,
	chrisw@sous-sol.org, dhowells@redhat.com,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, haradats@nttdata.co.jp,
	akpm@linux-foundation.org
Subject: Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.
Date: Thu, 16 Oct 2008 08:10:03 -0700	[thread overview]
Message-ID: <20081016151003.GA6772@linux.vnet.ibm.com> (raw)
In-Reply-To: <48F6BD8E.4050402@nttdata.co.jp>

On Thu, Oct 16, 2008 at 01:05:34PM +0900, Kentaro Takeda wrote:
> Paul E. McKenney wrote:
> > A few comments below -- some rcu_dereference()s are needed.
>
> This list doesn't use RCU since it is for Write-Once-Read-Many 
> situation (i.e. no-update and no-delete). TOMOYO Linux uses this list 
> for storing policy elements. Most of elements are allocated when the 
> kernel is loaded, and they are referred during lifetime of the kernel.
> 
> Since read_lock is not needed when referring this list, code of 
> TOMOYO keeps its simplicity. If TOMOYO used RCU or reader/writer lock,
> the code would be a jumble of read_lock and it would be almost 
> impossible to maintain and review the code... X-p This is the reason 
> why TOMOYO uses this WORM list.
> 
> Though size of policy increases with learning mode, the same 
> pathnames once learned will be reused. So memory usage of TOMOYO 
> doesn't increase infinitely; if still worried, we can set memory 
> quota.
> 
> > The general idea looks sound, at least as long as the lists remain
> > short.  Otherwise, the list scan in list1_add_tail_mb() will take
> > too long.
>
> Typically less than 100. The length of list won't matter since the 
> frequency of append is very low.

That sounds small enough to me.  If it becomes a problem some time in
the future, it will be easy for you to add a tail pointer or some such.

> Paul, would you review this list from the perspective of WORM list?

Hmmm...  I thought I was reviewing it from that perspective.  You never
delete anything from the list, so you don't need RCU.

But fair enough.  How about the following?

	#define worm_dereference()	rcu_dereference()
	#define worm_assign_pointer()	rcu_assign_pointer()

Then put worm_dereference() where I told you to put rcu_dereference()
and also put worm_assign_pointer() where I suggested using
rcu_assign_pointer().

You might not be using RCU, but keep in mind that RCU is primarily about
-removing- items from a data structure.  When you -insert- items into
a data structure that is being concurrently read, as you are doing, you
must solve all the same problems that RCU has to solve for list insertion.
Please see http://lkml.org/lkml/2008/2/2/255 for examples showing why
this is needed.  This posting does indeed use RCU terminology, but it is
focused only on insertion, and therefore exactly describes the situation
that you are in.

I am sure that you will get back to me with any questions or objections
that you might have after looking this over.  ;-)

							Thanx, Paul

  reply	other threads:[~2008-10-16 15:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-09  4:28 [TOMOYO #10 (linux-next) 0/8] TOMOYO Linux Kentaro Takeda
2008-10-09  4:28 ` [TOMOYO #10 (linux-next) 1/8] Introduce new LSM hooks where vfsmount is available Kentaro Takeda
2008-10-09  4:28 ` [TOMOYO #10 (linux-next) 2/8] Add in_execve flag into task_struct Kentaro Takeda
2008-10-09  4:28 ` [TOMOYO #10 (linux-next) 3/8] LSM adapter functions Kentaro Takeda
2008-10-09  6:10   ` KAMEZAWA Hiroyuki
2008-10-09  6:57     ` Kentaro Takeda
2008-10-09  4:28 ` [TOMOYO #10 (linux-next) 4/8] Memory and pathname management functions Kentaro Takeda
2008-10-09  6:18   ` KAMEZAWA Hiroyuki
2008-10-09  7:17     ` Kentaro Takeda
2008-10-09  4:28 ` [TOMOYO #10 (linux-next) 5/8] Common functions for TOMOYO Linux Kentaro Takeda
2008-10-09  4:28 ` [TOMOYO #10 (linux-next) 6/8] Domain transition handler Kentaro Takeda
2008-10-09  4:28 ` [TOMOYO #10 (linux-next) 7/8] File operation restriction part Kentaro Takeda
2008-10-09 16:48   ` Serge E. Hallyn
2008-10-12  0:09     ` Tetsuo Handa
2008-10-15  1:29       ` Paul E. McKenney
2008-10-16  4:05         ` Kentaro Takeda
2008-10-16 15:10           ` Paul E. McKenney [this message]
2008-10-17  8:32             ` Kentaro Takeda
2008-10-17 14:56               ` Paul E. McKenney
2008-10-18 14:04                 ` Tetsuo Handa
2008-10-18 15:18                   ` Paul E. McKenney
2008-10-19 13:10                     ` Tetsuo Handa
2008-10-20  4:17                       ` Paul E. McKenney
2008-10-15 15:24       ` Serge E. Hallyn
2008-10-09  4:28 ` [TOMOYO #10 (linux-next) 8/8] Kconfig and Makefile Kentaro Takeda

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=20081016151003.GA6772@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=chrisw@sous-sol.org \
    --cc=dhowells@redhat.com \
    --cc=haradats@nttdata.co.jp \
    --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 \
    --cc=sds@tycho.nsa.gov \
    --cc=serue@us.ibm.com \
    --cc=takedakn@nttdata.co.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