Re: [RFC PATCH 06/22] selinux: rename comparison functions for clarity

[Daniel Burgener <dburgener@linux.microsoft.com>]

On 11/15/2024 8:35 AM, Christian Göttsche wrote:
> From: Christian Göttsche <cgzones@googlemail.com>
> 
> The functions context_cmp() and mls_context_cmp() are not traditional
> C style compare functions returning -1, 0, and 1 for less than, equal,
> and greater than; they only return whether their arguments are equal.
> 
> Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
> ---
>   security/selinux/ss/context.c  |  2 +-
>   security/selinux/ss/context.h  | 10 +++++-----
>   security/selinux/ss/services.c |  2 +-
>   security/selinux/ss/sidtab.c   |  2 +-
>   4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/security/selinux/ss/context.c b/security/selinux/ss/context.c
> index e39990f494dd..a528b7f76280 100644
> --- a/security/selinux/ss/context.c
> +++ b/security/selinux/ss/context.c
> @@ -20,7 +20,7 @@ u32 context_compute_hash(const struct context *c)
>   	 * context struct with only the len & str set (and vice versa)
>   	 * under a given policy. Since context structs from different
>   	 * policies should never meet, it is safe to hash valid and
> -	 * invalid contexts differently. The context_cmp() function
> +	 * invalid contexts differently. The context_equal() function
>   	 * already operates under the same assumption.
>   	 */
>   	if (c->len)
> diff --git a/security/selinux/ss/context.h b/security/selinux/ss/context.h
> index 7ccab2e6965f..e1307f6f7f50 100644
> --- a/security/selinux/ss/context.h
> +++ b/security/selinux/ss/context.h
> @@ -132,8 +132,8 @@ static inline int mls_context_glblub(struct context *dst,
>   	return rc;
>   }
>   
> -static inline int mls_context_cmp(const struct context *c1,
> -				  const struct context *c2)
> +static inline bool mls_context_equal(const struct context *c1,
> +				     const struct context *c2)
>   {
>   	return ((c1->range.level[0].sens == c2->range.level[0].sens) &&
>   		ebitmap_cmp(&c1->range.level[0].cat, &c2->range.level[0].cat) &&

Should the same logic in this patch be applied to ebitmap_cmp as well?

-Daniel