aboutsummaryrefslogtreecommitdiffstats
path: root/security/selinux/avc.c
diff options
context:
space:
mode:
Diffstat (limited to 'security/selinux/avc.c')
-rw-r--r--security/selinux/avc.c19
1 files changed, 15 insertions, 4 deletions
diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index 1ed0f076aadc..b4b5da1c0a42 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -868,8 +868,19 @@ u32 avc_policy_seqno(void)
868 868
869void avc_disable(void) 869void avc_disable(void)
870{ 870{
871 avc_flush(); 871 /*
872 synchronize_rcu(); 872 * If you are looking at this because you have realized that we are
873 if (avc_node_cachep) 873 * not destroying the avc_node_cachep it might be easy to fix, but
874 kmem_cache_destroy(avc_node_cachep); 874 * I don't know the memory barrier semantics well enough to know. It's
875 * possible that some other task dereferenced security_ops when
876 * it still pointed to selinux operations. If that is the case it's
877 * possible that it is about to use the avc and is about to need the
878 * avc_node_cachep. I know I could wrap the security.c security_ops call
879 * in an rcu_lock, but seriously, it's not worth it. Instead I just flush
880 * the cache and get that memory back.
881 */
882 if (avc_node_cachep) {
883 avc_flush();
884 /* kmem_cache_destroy(avc_node_cachep); */
885 }
875} 886}