[libvirt] [PATCH v4 06/15] security_manager: Rework metadata locking

[John Ferlan]

On 11/14/18 7:44 AM, Michal Privoznik wrote:
> Trying to use virlockd to lock metadata turns out to be too big
> gun. Since we will always spawn a separate process for relabeling
> we are safe to use thread unsafe POSIX locks and take out
> virtlockd completely out of the picture.
> 

NB: This patch has a 1 second delay loop in the event the lock is
already taken by another thread. Since it's not expected that threads
holding the lock will need more than a second or two to process the
various file security operations, it was felt this was a good starting
point. The time taken to execute has two factors - the number of files
to be locked and the time the operation required by the security driver
to perform it's operation. Usage of virTimeBackOffStart may or may not
help. Similarly a configurable delay time or delay maximum time is also
possible, but was deemed unnecessary at this time.

[fair enough statement??  - pick and choose if you want to add all, any
part, or none of it... I think it's a fair representation for someone
coming along and looking at this commit to consider if they wanted to
make a change to help perceived performance if the delay loop becomes
that type of problem. It's not that it wasn't considered, it just wasn't
easily quantifiable].

> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  src/security/security_dac.c     |  12 +-
>  src/security/security_manager.c | 225 +++++++++++++++++---------------
>  src/security/security_manager.h |  17 ++-
>  src/security/security_selinux.c |  11 +-
>  4 files changed, 141 insertions(+), 124 deletions(-)
> 

Reviewed-by: John Ferlan <jferlan at redhat.com>

John