All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kaigai Kohei" <kaigai@ak.jp.nec.com>
To: <paulmck@us.ibm.com>
Cc: "Stephen Smalley" <sds@epoch.ncsc.mil>,
	"SELinux-ML(Eng)" <selinux@tycho.nsa.gov>,
	"Linux Kernel ML(Eng)" <linux-kernel@vger.kernel.org>,
	"James Morris" <jmorris@redhat.com>
Subject: Re: RCU issue with SELinux (Re: SELINUX performance issues)
Date: Wed, 25 Aug 2004 18:51:53 +0900	[thread overview]
Message-ID: <024b01c48a89$26765b60$f97d220a@linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: 20040824230245.GA1243@us.ibm.com

Hi Paul, thanks for your comments.

> > I modified the following points:
> > - We hold the lock for hash backet when avc_insert() and avc_ss_reset() are
> >   called for safety.
> > - list_for_each_rcu() and list_entry() are replaced by list_for_entry().
> 
> One subtlety here...
> 
> The traversals that are protected by rcu_read_lock() (rather than an
> update-side spinlock) need to be list_for_each_entry_rcu() rather than
> list_for_each_entry().  The "_rcu()" is required in order to work
> reliably on Alpha, and has the added benefit of calling out exactly
> which traversals are RCU-protected.
> 
> Update-side code remains list_for_each_entry().

It was a simple misconception.
I fixed them in the take3-patch.

> > - avc_node_dual structure which contains two avc_node objects is defined. 
> >   It allows to do avc_update_node() without kmalloc() or any locks.
> 
> What happens when you have two consecutive updates to the same object?
> Don't you have to defer the second update until a grace period has
> elapsed since the first update in order to avoid confusing readers that
> are still accessing the original version?

I didn't imagine such a situation. Indeed, such thing may happen.

> One way to do this would be to set a "don't-touch-me" bit that is
> cleared by an RCU callback.  An update to an element with the
> "don't-touch-me" bit set would block until the bit clears.  There
> are probably better ways...

I think we can't apply this approach for the implementation
of avc_update_node(), because execution context isn't permitted to block.

I changed my opinion and implementation of avc_update_node().
If kmalloc() returns NULL in avc_update_node(), it returns -ENOMEM.

But this effect of changing the prototype is limited, because only
avc_has_perm_noaudit() and avc_update_cache() call avc_update_node().

Even if avc_update_node() return -ENOMEM to avc_has_perm_noaudit(),
avc_has_perm_noaudit() can ignore it, because the purpose is only
to control the audit-log floods.
This adverse effect is only that audit-logs are printed twice.

Nobody calls avc_update_cache(), which is only defined.

Some other trivial fixes are as follows:
- All list_for_each_entry() were replaced by list_for_each_entry_rcu().
- All spin_lock()/spin_unlock() were replaced by spin_lock_irqsave()
  /spin_unlock_restore().
- In avc_node_insert(), if an entry with the same ssid/tsid/tclass as new
  one exists, the older entry is replaced by the new one.

Thank you for the opinion as a specialist of RCU!
--------
Kai Gai <kaigai@ak.jp.nec.com>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

WARNING: multiple messages have this Message-ID (diff)
From: "Kaigai Kohei" <kaigai@ak.jp.nec.com>
To: <paulmck@us.ibm.com>
Cc: "Stephen Smalley" <sds@epoch.ncsc.mil>,
	"SELinux-ML(Eng)" <selinux@tycho.nsa.gov>,
	"Linux Kernel ML(Eng)" <linux-kernel@vger.kernel.org>,
	"James Morris" <jmorris@redhat.com>
Subject: Re: RCU issue with SELinux (Re: SELINUX performance issues)
Date: Wed, 25 Aug 2004 18:51:53 +0900	[thread overview]
Message-ID: <024b01c48a89$26765b60$f97d220a@linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: 20040824230245.GA1243@us.ibm.com

Hi Paul, thanks for your comments.

> > I modified the following points:
> > - We hold the lock for hash backet when avc_insert() and avc_ss_reset() are
> >   called for safety.
> > - list_for_each_rcu() and list_entry() are replaced by list_for_entry().
> 
> One subtlety here...
> 
> The traversals that are protected by rcu_read_lock() (rather than an
> update-side spinlock) need to be list_for_each_entry_rcu() rather than
> list_for_each_entry().  The "_rcu()" is required in order to work
> reliably on Alpha, and has the added benefit of calling out exactly
> which traversals are RCU-protected.
> 
> Update-side code remains list_for_each_entry().

It was a simple misconception.
I fixed them in the take3-patch.

> > - avc_node_dual structure which contains two avc_node objects is defined. 
> >   It allows to do avc_update_node() without kmalloc() or any locks.
> 
> What happens when you have two consecutive updates to the same object?
> Don't you have to defer the second update until a grace period has
> elapsed since the first update in order to avoid confusing readers that
> are still accessing the original version?

I didn't imagine such a situation. Indeed, such thing may happen.

> One way to do this would be to set a "don't-touch-me" bit that is
> cleared by an RCU callback.  An update to an element with the
> "don't-touch-me" bit set would block until the bit clears.  There
> are probably better ways...

I think we can't apply this approach for the implementation
of avc_update_node(), because execution context isn't permitted to block.

I changed my opinion and implementation of avc_update_node().
If kmalloc() returns NULL in avc_update_node(), it returns -ENOMEM.

But this effect of changing the prototype is limited, because only
avc_has_perm_noaudit() and avc_update_cache() call avc_update_node().

Even if avc_update_node() return -ENOMEM to avc_has_perm_noaudit(),
avc_has_perm_noaudit() can ignore it, because the purpose is only
to control the audit-log floods.
This adverse effect is only that audit-logs are printed twice.

Nobody calls avc_update_cache(), which is only defined.

Some other trivial fixes are as follows:
- All list_for_each_entry() were replaced by list_for_each_entry_rcu().
- All spin_lock()/spin_unlock() were replaced by spin_lock_irqsave()
  /spin_unlock_restore().
- In avc_node_insert(), if an entry with the same ssid/tsid/tclass as new
  one exists, the older entry is replaced by the new one.

Thank you for the opinion as a specialist of RCU!
--------
Kai Gai <kaigai@ak.jp.nec.com>


  reply	other threads:[~2004-08-25  9:54 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-16  9:33 RCU issue with SELinux (Re: SELINUX performance issues) Kaigai Kohei
2004-08-16  9:33 ` Kaigai Kohei
2004-08-16 15:19 ` James Morris
2004-08-16 15:19   ` James Morris
2004-08-20 13:36   ` Kaigai Kohei
2004-08-20 14:53     ` James Morris
2004-08-20 14:53       ` James Morris
2004-08-24  7:27       ` Kaigai Kohei
2004-08-24  7:27         ` Kaigai Kohei
2004-08-24 13:24         ` James Morris
2004-08-24 13:24           ` James Morris
2004-08-25  9:51           ` Kaigai Kohei
2004-08-25  9:51             ` Kaigai Kohei
2004-08-25 18:31             ` James Morris
2004-08-25 18:31               ` James Morris
2004-08-25  9:52           ` [PATCH]atomic_inc_return() for i386/x86_64 (Re: RCU issue with SELinux) Kaigai Kohei
2004-08-20 17:31     ` RCU issue with SELinux (Re: SELINUX performance issues) Luke Kenneth Casson Leighton
2004-08-20 17:31       ` Luke Kenneth Casson Leighton
2004-08-20 18:15       ` James Morris
2004-08-20 18:15         ` James Morris
2004-08-20 20:19     ` Paul E. McKenney
2004-08-20 20:35       ` James Morris
2004-08-20 20:35         ` James Morris
2004-08-24  7:27       ` Kaigai Kohei
2004-08-24  7:27         ` Kaigai Kohei
     [not found]     ` <1093014789.16585.186.camel@moss-spartans.epoch.ncsc.mil>
2004-08-24  7:25       ` Kaigai Kohei
2004-08-24 15:37         ` Stephen Smalley
2004-08-24 15:37           ` Stephen Smalley
2004-08-25  9:51           ` Kaigai Kohei
2004-08-25 15:50             ` Stephen Smalley
2004-08-25 15:50               ` Stephen Smalley
2004-08-25 16:11               ` Stephen Smalley
2004-08-25 16:11                 ` Stephen Smalley
2004-08-26  7:53               ` Kaigai Kohei
2004-08-26  7:53                 ` Kaigai Kohei
2004-08-26 13:24                 ` Stephen Smalley
2004-08-26 13:24                   ` Stephen Smalley
2004-08-27 11:07                   ` Kaigai Kohei
2004-08-27 11:07                     ` Kaigai Kohei
2004-08-30 11:17                   ` [PATCH]SELinux performance improvement by RCU (Re: RCU issue with SELinux) Kaigai Kohei
2004-08-30 15:35                     ` Stephen Smalley
2004-08-30 15:35                       ` Stephen Smalley
2004-08-30 16:13                       ` Paul E. McKenney
2004-08-30 16:13                         ` Paul E. McKenney
2004-08-31  4:33                         ` Kaigai Kohei
2004-08-31  4:33                           ` Kaigai Kohei
2004-08-31 16:20                           ` Paul E. McKenney
2004-08-31 16:20                             ` Paul E. McKenney
2004-08-31 15:33                     ` James Morris
2004-08-31 15:33                       ` James Morris
2004-08-24 23:02         ` RCU issue with SELinux (Re: SELINUX performance issues) Paul E. McKenney
2004-08-24 23:02           ` Paul E. McKenney
2004-08-25  9:51           ` Kaigai Kohei [this message]
2004-08-25  9:51             ` Kaigai Kohei
2004-08-25 17:34             ` Paul E. McKenney
2004-08-25 17:34               ` Paul E. McKenney

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='024b01c48a89$26765b60$f97d220a@linux.bs1.fc.nec.co.jp' \
    --to=kaigai@ak.jp.nec.com \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@us.ibm.com \
    --cc=sds@epoch.ncsc.mil \
    --cc=selinux@tycho.nsa.gov \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.