Re: RCU issue with SELinux (Re: SELINUX performance issues)

[Kaigai Kohei]

Hi Stephen, thanks for your comments.

> > By this method, the decision-making is available irrespective of
> > the result of kmalloc(). Is it robustless?
> > The original implementation has too many lock contensitons in Big-SMP
> > environment. It is more positive to consider the method using RCU.
> 
> Yes, that would address my concern.  However, I'm still unclear as to
> why using RCU mandates that we migrate from preallocated nodes to
> dynamic allocation.  I certainly agree that the existing global spinlock
> doesn't scale.  

When avc_reclaim_node() is called, one or some nodes are reclaimed
in both approachs(spinlock/RCU).

But we can't use the reclaimed nodes immediately in RCU-approach,
because it can't guarantee that nobody refers the nodes.
(These nodes are released actually after non-deterministic period.)
The success of avc_reclaim_node() does not mean that we can hold
an avc_node object immediately!
Therefore, we need to allocate a new avc_node object by kmalloc().

In original spinlock implementation, the reclaimed node is chained
to the 'avc_node_freelist' under the spinlock. Thus, we can use
the reclaimed node immediately.

Indeed, I had considered the RCU-approach with pre-allocation,
but I faced to the above difficult problem, and gave up.
Then, I make it with kmalloc() alternatively, so fine.

> > Please wait for a patch, thanks.
> 
> Thanks for working on this.  Could you also supply updated performance
> data when you have a newer patch?  Thanks.

OK, the benchmark results will also be updated.
Thanks.
--------
Kai Gai <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/