From c185e86466268975937b12af35425f0269eebbe9 Mon Sep 17 00:00:00 2001 From: Eric Paris Date: Sun, 20 Sep 2009 21:21:10 -0400 Subject: [PATCH] --- yaml --- r: 165533 b: refs/heads/master c: 5224ee086321fec78970e2f2805892d2b34e8957 h: refs/heads/master i: 165531: 870209b66b98a75fdfcb06e5dcd5df29c066db3d v: v3 --- [refs] | 2 +- trunk/security/selinux/avc.c | 19 +++++++++++++++---- 2 files changed, 16 insertions(+), 5 deletions(-) diff --git a/[refs] b/[refs] index 4d4c577a3e4e..77a94db0e3c2 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 606531c316d30e9639473a6da09ee917125ab467 +refs/heads/master: 5224ee086321fec78970e2f2805892d2b34e8957 diff --git a/trunk/security/selinux/avc.c b/trunk/security/selinux/avc.c index 1ed0f076aadc..b4b5da1c0a42 100644 --- a/trunk/security/selinux/avc.c +++ b/trunk/security/selinux/avc.c @@ -868,8 +868,19 @@ u32 avc_policy_seqno(void) void avc_disable(void) { - avc_flush(); - synchronize_rcu(); - if (avc_node_cachep) - kmem_cache_destroy(avc_node_cachep); + /* + * If you are looking at this because you have realized that we are + * not destroying the avc_node_cachep it might be easy to fix, but + * I don't know the memory barrier semantics well enough to know. It's + * possible that some other task dereferenced security_ops when + * it still pointed to selinux operations. If that is the case it's + * possible that it is about to use the avc and is about to need the + * avc_node_cachep. I know I could wrap the security.c security_ops call + * in an rcu_lock, but seriously, it's not worth it. Instead I just flush + * the cache and get that memory back. + */ + if (avc_node_cachep) { + avc_flush(); + /* kmem_cache_destroy(avc_node_cachep); */ + } }