LKML Archive on
help / color / mirror / Atom feed
From: Stephen Smalley <>
To: peter enderborg <>,
	Paul Moore <>,
	Eric Paris <>,
	James Morris <>,
	Daniel Jurgens <>,
	Doug Ledford <>,,,,
	"Serge E . Hallyn" <>,
	"Paul E . McKenney" <>
Subject: Re: [PATCH V3 0/5] selinux:Significant reduce of preempt_disable holds
Date: Thu, 31 May 2018 08:42:06 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 05/31/2018 05:04 AM, peter enderborg wrote:
> On 05/30/2018 10:34 PM, Stephen Smalley wrote:
>> On 05/30/2018 10:10 AM, Peter Enderborg wrote:
>>> The boolean change becomes a lot more heavy with this patch,
>>> but it is a very rare usage in compare with read only operations.
>>> The lock held during a policydb_copy is about 1ms on a XEON.
>> This has a very substantial performance impact on setsebool, e.g. time setsebool httpd_can_sendmail=1.
>> That's because you are doing a full vmalloc();policydb_write();policydb_read();vfree() sequence on it.
>> In comparison, KaiGai's old attempt to replace the policy rwlock with RCU only duplicated the conditional policydb state (via a cond_policydb_dup) that he introduced.  Is there a reason you couldn't use that approach?
> That one did not make it, so I went for a other path. Make it simple, using the same serialisation that exist. That also make it easier to maintain.
> We do not  use the booleans in android since they are not allowed so im not aware of any use case where this administrative function are
> used in such frequent manner that it would have an impact. And it must be some other large overhead with interprocess communication and
> a multiple writes to sysfs during a boolean settings?  However my concern is/was memory pressure, setting booleans will generate pressure
> with lot of atomic allocation and large vmallocs.

Yes, that is also a concern.  I would prefer to only duplicate the conditional policydb state as in KaiGai's patch.
Keeping temporary setting of booleans lightweight is desirable for other use cases than Android.

I'm also concerned by the implications of switching all of the allocations to atomic.  KaiGai's patch did not take that approach either, and it obviously could make policy reload more prone to transient failures.

 But my goal is the fast path for real time critical functions such as audio, and it will be a cost for
> administrative tasks. On the xeon it takes about ~98 ms to run the security_set_bools compared to about ~8 ms without the overhead
> of copying the policydb.  About ~6 ms is rcu sync and ~8 ms is the same as the original update of selinux statuses, and about ~25 ms
> is policydb_destroy() of the old copy.

  reply	other threads:[~2018-05-31 12:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-30 14:10 Peter Enderborg
2018-05-30 14:11 ` [PATCH V3 1/5 selinux-next] selinux: Make allocation atomic in policydb objects functions Peter Enderborg
2018-05-30 14:11 ` [PATCH V3 2/5 selinux-next] selinux: Introduce selinux_ruleset struct Peter Enderborg
2018-05-30 21:15   ` J Freyensee
2018-06-01 13:48   ` kbuild test robot
2018-06-01 13:56   ` kbuild test robot
2018-05-30 14:11 ` [PATCH V3 3/5 selinux-next] selinux: sidtab_clone switch to use rwlock Peter Enderborg
2018-05-30 21:22   ` J Freyensee
2018-05-31  5:35     ` peter enderborg
2018-05-30 14:11 ` [PATCH V3 4/5 selinux-next] selinux: seqno separation Peter Enderborg
2018-05-30 14:11 ` [PATCH V3 5/5 selinux-next] selinux: Switch to rcu read locks for avc_compute Peter Enderborg
2018-05-30 20:34 ` [PATCH V3 0/5] selinux:Significant reduce of preempt_disable holds Stephen Smalley
2018-05-31  9:04   ` peter enderborg
2018-05-31 12:42     ` Stephen Smalley [this message]
2018-05-31 14:12       ` peter enderborg
2018-05-31 14:21         ` Stephen Smalley
2018-05-31 16:40           ` Stephen Smalley
2018-06-01 11:18       ` peter enderborg

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH V3 0/5] selinux:Significant reduce of preempt_disable holds' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).