Re: [bug] very high non-preempt latency in context_struct_compute_av()

On Monday 04 June 2007 5:39:00 pm Stephen Smalley wrote:
On Mon, 2007-06-04 at 17:11 -0400, Paul Moore wrote:
I'm not an expert on the SELinux security server guts like the other
people on the To/CC line of this thread, but here are my two cents on the
issue above.

From what I can tell the nasty loop that is taking so long is the actual
access vector lookup which determines if the subject has access to the
object (i.e. can user/application X access resource Y on the system).
While it may be possible to optimize this code I wonder if a
quicker/easier solution would be to refactor the lock. At present
SELinux uses a read/write spinlock to protect the policy stored in the
kernel with macros to take and release the lock, POLICY_{RD,WR}LOCK and
POLICY_{RD,WR}UNLOCK. From personal observations as well as a quick
check of the code, it appears that most of the time we only want to read
lock the policy and not write lock the policy - a spinlock, even a
read/write spinlock, seems a bit expensive here.

If we were to convert from a read/write spinlock to a RCU locking
mechanism would this solve the preemption problem (I'm not a lock expert
either)? If so, can anyone think of any reasons why converting the
policy lock to RCU is a bad idea (James, Stephen, the other James)?

rcu_read_lock disables preemption in mainline (see rcupdate.h).
Conversion to RCU is also complicated by conditional policy support
(changing of policy boolean states via selinuxfs). However, there were
experimental patches to do that a while ago by KaiGai Kohei.

Okay, for some reason I thought someone had found a way to make
RCU "preemptable" through the real-time work, maybe I'm just confused
again :) Regardless, it looks like there are better solutions possible.

Thanks.

--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages
Loading