This code predates <linux/bsearch.h>. Now that the bsearch function
exists there we can use it to reduce code duplication.

Signed-off-by: Collin Funk <collin.funk1@gmail.com>
---
 kernel/groups.c | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/kernel/groups.c b/kernel/groups.c
index 9b43da22647d..4294a97e4ea8 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -2,6 +2,7 @@
 /*
  * Supplementary group IDs
  */
+#include <linux/bsearch.h>
 #include <linux/cred.h>
 #include <linux/export.h>
 #include <linux/slab.h>
@@ -91,23 +92,13 @@ EXPORT_SYMBOL(groups_sort);
 /* a simple bsearch */
 int groups_search(const struct group_info *group_info, kgid_t grp)
 {
-	unsigned int left, right;
+	void *result;
 
 	if (!group_info)
 		return 0;
-
-	left = 0;
-	right = group_info->ngroups;
-	while (left < right) {
-		unsigned int mid = (left+right)/2;
-		if (gid_gt(grp, group_info->gid[mid]))
-			left = mid + 1;
-		else if (gid_lt(grp, group_info->gid[mid]))
-			right = mid;
-		else
-			return 1;
-	}
-	return 0;
+	result = bsearch(&grp, group_info->gid, group_info->ngroups,
+			 sizeof(*group_info->gid), gid_cmp);
+	return !!result;
 }
 
 /**
-- 
2.49.0

On Sun, May 25, 2025 at 05:17:46PM -0700, Collin Funk wrote:
> This code predates <linux/bsearch.h>. Now that the bsearch function
> exists there we can use it to reduce code duplication.

Careful - that really needs profiling with setups where processes have
a bunch of supplementary groups.

It *is* on hot paths, and while the current version will be inlined,
yours will do a bunch of indirect calls.  These days that can be
costly.

Reducing code duplication is a good thing, but not when it creates
measurable regressions...

Hi Al,

Al Viro <viro@zeniv.linux.org.uk> writes:

> Careful - that really needs profiling with setups where processes have
> a bunch of supplementary groups.
>
> It *is* on hot paths, and while the current version will be inlined,
> yours will do a bunch of indirect calls.  These days that can be
> costly.

Sure, makes sense.

I would assume that gid_cmp/gid_lt/gid_gt all get inlined no matter
what, but I am not sure if the conversion to 'grp' to a void pointer for
the generic bsearch prevents some optimizations.

> Reducing code duplication is a good thing, but not when it creates
> measurable regressions...

Yes, that makes sense.

There is '__inline_bsearch', but I'll have to do some expirementing to
make sure that gets optimized well.

Thanks,
Collin