On 11/15/18 7:38 PM, John Ferlan wrote: > > > 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. Darn, I forgot to undo the virTimeBackOffStart. You know what? To avoid sending v5 let me merge this version and investigate if using virTimeBackOff is any better. > > [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@xxxxxxxxxx> >> --- >> 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@xxxxxxxxxx> Thanks, Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
