The branch main has been updated by olce:
URL:
https://cgit.FreeBSD.org/src/commit/?id=a61e7b5c98f840b4a7777d718218d0f63569c52a
commit a61e7b5c98f840b4a7777d718218d0f63569c52a
Author: Olivier Certner <o...@freebsd.org>
AuthorDate: 2025-08-27 13:50:59 +0000
Commit: Olivier Certner <o...@freebsd.org>
CommitDate: 2025-09-17 12:16:01 +0000
cred: 'kern.ngroups' tunable: Rework the comment on the initial value
Remove the parts about the effective GID being stored as the first
element of the groups array, as this is generally not the case now after
commit be1f7435ef21 ("kern: start tracking cr_gid outside of
cr_groups[]") (some credentials export structures still have the old
layout, and need to do the 'ngroups_max + 1' computation, but given the
computation needed to obtain a size in bytes, this detail is not really
important here).
Remove the part about 32-bit machines, avoiding another modification
when support for them is removed.
No functional change.
MFC after: 5 days
MFC to: stable/15
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52265
---
sys/kern/subr_param.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/sys/kern/subr_param.c b/sys/kern/subr_param.c
index 471640c290a7..a67e5fa6cbff 100644
--- a/sys/kern/subr_param.c
+++ b/sys/kern/subr_param.c
@@ -235,14 +235,11 @@ init_param1(void)
* specification for <limits.h>, paragraph "Runtime Increasable
* Values").
*
- * On the other hand, INT_MAX would result in an overflow for the common
- * 'ngroups_max + 1' computation (to obtain the size of the internal
- * groups array, its first element being reserved for the effective
- * GID). Also, the number of allocated bytes for the group array must
- * not overflow on 32-bit machines. For all these reasons, we limit the
- * number of supplementary groups to some very high number that we
- * expect will never be reached in all practical uses and ensures we
- * avoid the problems just exposed, even if 'gid_t' was to be enlarged
+ * On the other hand, a too high value would result in an overflow when
+ * computing the number of bytes to allocate for the groups array. We
+ * thus limit the number of supplementary groups to some very high
+ * number that we expect will never be reached in all practical uses,
+ * avoiding the problem just exposed even if 'gid_t' were to be enlarged
* by a magnitude.
*/
ngroups_max = NGROUPS_MAX;
