RCU issue with SELinux (Re: SELINUX performance issues)

From: Kaigai Kohei
Date: Mon Aug 16 2004 - 04:38:46 EST


Hello, everyone.

Sat, 7 Aug 2004 22:57:08 -0400 (EDT)
James Morris <jmorris@xxxxxxxxxx> wrote:

> > The biggest problem is the global lock:
> >
> > avc_has_perm_noaudit:
> > spin_lock_irqsave(&avc_lock, flags);
> >
> > Any chance we can get rid of it? Maybe with RCU?
>
> Yes, known problem. I plan on trying RCU soon, Rik was looking at a
> seqlock approach.

I'm interested in the scalability of SELinux, and tried with
rwlock and RCU approaches.

I simply replaced spinlock_irq_save() by (read|write)_lock_irqsave() first,
but performance improvement was observed in the hackbench only,not in OSDL-REAIM.

Next, I tried with RCU approach. I came across the following problem.

Some AVC-Entries are referred directly by avc_entry_ref structure
in various resource objects (such as task_struct, inode and so on...).
Thus, referring to invalidated AVC-Entries may happen after detaching
an entry from the AVC hash list.
Since only list scanning of forward direction is expected in RCU-model,
direct reference to AVC-Entry is not appropriate.

In my opinion, direct reference to AVC-Entry should be removed
to avoid the problem for scalability of SELinux.
The purpose of this direct reference is performance improvement
in consecutive access control check about each related object.
Performance degradation may happen by this.
But I think it is not so significant, because the number of the hash
slot is 512 in spite of that the number of AVC-Entry is 410 fixed.
We can reach the target AVC-Entry by one or two steps in average.

Is removing direct reference to AVC-Entry approach acceptable?

I'll try to consider this issue further.
--------
Kai Gai, Linux Promotion Center, NEC
E-mail: kaigai@xxxxxxxxxxxxx

-
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/