diff mbox series

selinux: remove avc_disable() as it is no longer used

Message ID 20230505224934.645040-1-paul@paul-moore.com (mailing list archive)
State Rejected
Delegated to: Paul Moore
Headers show
Series selinux: remove avc_disable() as it is no longer used | expand

Commit Message

Paul Moore May 5, 2023, 10:49 p.m. UTC
With the removal of the runtime disable functionality we no longer
have any callers of the avc_disable() function, remove it.

Signed-off-by: Paul Moore <paul@paul-moore.com>
---
 security/selinux/avc.c         | 19 -------------------
 security/selinux/include/avc.h |  3 ---
 2 files changed, 22 deletions(-)

Comments

Ondrej Mosnacek May 6, 2023, 9:16 a.m. UTC | #1
On Sat, May 6, 2023 at 12:51 AM Paul Moore <paul@paul-moore.com> wrote:
>
> With the removal of the runtime disable functionality we no longer
> have any callers of the avc_disable() function, remove it.
>
> Signed-off-by: Paul Moore <paul@paul-moore.com>
> ---
>  security/selinux/avc.c         | 19 -------------------
>  security/selinux/include/avc.h |  3 ---
>  2 files changed, 22 deletions(-)
>
> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
> index eaed5c2da02b..6bc65830e1a9 100644
> --- a/security/selinux/avc.c
> +++ b/security/selinux/avc.c
> @@ -1203,22 +1203,3 @@ u32 avc_policy_seqno(void)
>  {
>         return selinux_avc.avc_cache.latest_notif;
>  }
> -
> -void avc_disable(void)
> -{
> -       /*
> -        * 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); */
> -       }
> -}
> diff --git a/security/selinux/include/avc.h b/security/selinux/include/avc.h
> index 9301222c8e55..9e055f74daf6 100644
> --- a/security/selinux/include/avc.h
> +++ b/security/selinux/include/avc.h
> @@ -168,9 +168,6 @@ int avc_get_hash_stats(char *page);
>  unsigned int avc_get_cache_threshold(void);
>  void avc_set_cache_threshold(unsigned int cache_threshold);
>
> -/* Attempt to free avc node cache */
> -void avc_disable(void);
> -
>  #ifdef CONFIG_SECURITY_SELINUX_AVC_STATS
>  DECLARE_PER_CPU(struct avc_cache_stats, avc_cache_stats);
>  #endif
> --
> 2.40.1
>

The same patch (modulo subject & description) has already been posted
by Christian:
https://lore.kernel.org/selinux/20230420150503.22227-3-cgzones@googlemail.com/
Paul Moore May 7, 2023, 7:54 p.m. UTC | #2
On Sat, May 6, 2023 at 5:16 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Sat, May 6, 2023 at 12:51 AM Paul Moore <paul@paul-moore.com> wrote:
> >
> > With the removal of the runtime disable functionality we no longer
> > have any callers of the avc_disable() function, remove it.
> >
> > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > ---
> >  security/selinux/avc.c         | 19 -------------------
> >  security/selinux/include/avc.h |  3 ---
> >  2 files changed, 22 deletions(-)

..

> The same patch (modulo subject & description) has already been posted
> by Christian:
> https://lore.kernel.org/selinux/20230420150503.22227-3-cgzones@googlemail.com/

Ah ... huh, odd.  It looks like the patchset from Christian was
incorrectly assigned (probably by me, oops) so I missed it.

Anyway, consider this patch dropped in favor of Christian's.
diff mbox series

Patch

diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index eaed5c2da02b..6bc65830e1a9 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -1203,22 +1203,3 @@  u32 avc_policy_seqno(void)
 {
 	return selinux_avc.avc_cache.latest_notif;
 }
-
-void avc_disable(void)
-{
-	/*
-	 * 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); */
-	}
-}
diff --git a/security/selinux/include/avc.h b/security/selinux/include/avc.h
index 9301222c8e55..9e055f74daf6 100644
--- a/security/selinux/include/avc.h
+++ b/security/selinux/include/avc.h
@@ -168,9 +168,6 @@  int avc_get_hash_stats(char *page);
 unsigned int avc_get_cache_threshold(void);
 void avc_set_cache_threshold(unsigned int cache_threshold);
 
-/* Attempt to free avc node cache */
-void avc_disable(void);
-
 #ifdef CONFIG_SECURITY_SELINUX_AVC_STATS
 DECLARE_PER_CPU(struct avc_cache_stats, avc_cache_stats);
 #endif