public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, akpm@osdl.org, torvalds@osdl.org
Subject: Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Date: Sun, 12 Aug 2007 23:36:05 +0200	[thread overview]
Message-ID: <20070812213605.GA25883@one.firstfloor.org> (raw)
In-Reply-To: <918222.44901.qm@web36614.mail.mud.yahoo.com>

On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote:
> 
> --- Andi Kleen <andi@firstfloor.org> wrote:
> 
> > > Entries are never deleted, although they can be modified.
> > 
> > The modification case still seems racy then.
> 
> Fair enough. I'll look into real list management.

You don't necessarily need more list management if you don't 
plan to remove entries, but just replace them.

e.g. what could work to atomically replace is: 

- Make the buffer a pointer to an allocated buffer that also
contains a struct rcu_head.
- Reader: Does rcu_read_lock() around list walk (that just disables
preemption on preemptible kernels and is otherwise a nop).
Also uses rcu_reference for reading the pointer. 
- Writer: Continues using the mutex to protect against other writers.
When changing an entry allocate a new buffer + rcu_head. Initialize
buffer. Replace pointer.  Free old buffer using call_rcu() 

The RCU would just make sure the buffer is not freed while other
CPUs are still accessing it. It also means they can use stale
rules for a time, but it is a strictly bounded time
(bounded to max time walking the list plus max time any interrupt
handlers inbetween run [admittedly that can be very long in theory, 
but it's all logically only a single rule check])

-Andi


  reply	other threads:[~2007-08-12 21:36 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-11 17:57 [PATCH] Smack: Simplified Mandatory Access Control Kernel Casey Schaufler
2007-08-11 19:12 ` Arjan van de Ven
2007-08-11 19:56   ` Casey Schaufler
2007-08-12  3:39     ` Keith Owens
2007-08-11 19:18 ` Kyle Moffett
2007-08-11 21:01   ` Casey Schaufler
2007-08-11 21:47     ` Kyle Moffett
2007-08-12  1:21       ` Casey Schaufler
2007-08-12  4:32         ` Kyle Moffett
2007-08-12 19:41           ` Casey Schaufler
2007-08-12 23:18             ` Crispin Cowan
2007-08-13  1:38             ` Kyle Moffett
2007-08-13  2:36               ` Joshua Brindle
2007-08-13  2:45                 ` Kyle Moffett
2007-08-13  4:23               ` Casey Schaufler
2007-08-16 20:58                 ` Pavel Machek
2007-08-17  4:56                   ` Casey Schaufler
2007-08-17  9:46                     ` Miguel Ojeda
2007-08-18  5:29                     ` Kyle Moffett
2007-08-19 21:12                       ` Valdis.Kletnieks
2007-08-21 13:16                         ` Kyle Moffett
2007-08-21 15:50                           ` Casey Schaufler
2007-08-22  3:43                             ` Kyle Moffett
2007-08-22  4:08                               ` Casey Schaufler
2007-09-07 16:02                               ` Casey Schaufler
2007-08-20 14:29                       ` Casey Schaufler
2007-08-21  7:37                         ` Pavel Machek
2007-08-21 15:35                           ` Casey Schaufler
2007-08-22  8:05                             ` Pavel Machek
2007-08-22 18:47                               ` Casey Schaufler
2007-08-23  7:14                                 ` Jan Engelhardt
2007-08-11 20:26 ` Jan Engelhardt
2007-08-11 23:22   ` Casey Schaufler
2007-08-12 11:16     ` Jan Engelhardt
2007-08-12 19:50       ` Casey Schaufler
2007-08-11 23:14 ` Andi Kleen
2007-08-12  1:36   ` Casey Schaufler
2007-08-12 11:49     ` Andi Kleen
2007-08-12 17:48       ` Casey Schaufler
2007-08-12 21:36         ` Andi Kleen [this message]
2007-08-12 21:46           ` Casey Schaufler
2007-08-12  3:45 ` Keith Owens
2007-08-12 17:16   ` Casey Schaufler

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=20070812213605.GA25883@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=akpm@osdl.org \
    --cc=casey@schaufler-ca.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox