On 15-10-26 18:36:33, Mimi Zohar wrote:
> On Tue, 2015-10-27 at 00:03 +0200, Petko Manolov wrote:
> > On 15-10-26 22:39:28, Dmitry Kasatkin wrote:
>
> > > Can you please still explain when multiple policy writers can content? I
> > > 100% understand the role of mutex....
> >
> > Ignore the high level requirements for the moment. Every time you have a
> > contended resource you need to protect it from concurrent writers. IMA
> > policy is read way more frequently than it is been written. Just once in
> > the past, now a few times more.
>
> Right. We all agree that only one process can append new rules at a time.
> The open currently fails with -EBUSY. If the policy isn't being updated
> frequently and there isn't any contention for writing the policy, the
> question
> is why change the existing behavior (by defining a new mutex)?
There is just one reason - mutex plays nicer with user space. With the current
open() semantics the second writer will get an error, which the user's script
must check, do a delay and then make a new attempt.
All of the above is redundant when we use a mutex - the second writer get's
blocked for a short duration, automatically awaken and it's policy downloaded.
There's no need of error handling, bar the broken rule case.
The mutex is not on the hot code path so it does not affect performance in any
way. It is there for serializing the write() access. That said, i am not
religious about this semaphore. If you hate this approach i'll remove it. For
the kernel there is no big difference either way.
Petko
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
