Re: PATCH: report NGROUPS_MAX via a sysctl (read-only)
From: Glen Turner (glen.turner_at_aarnet.edu.au)
Date: 02/25/04
- Previous message: Darren Williams: "Re: [BUG] 2.6.3 Slab corruption: errors are triggered when memory exceeds 2.5GB (correction)"
- In reply to: Tim Hockin: "Re: PATCH: report NGROUPS_MAX via a sysctl (read-only)"
- Next in thread: Tim Hockin: "Re: PATCH: report NGROUPS_MAX via a sysctl (read-only)"
- Reply: Tim Hockin: "Re: PATCH: report NGROUPS_MAX via a sysctl (read-only)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Tim Hockin <thockin@hockin.org> Date: Wed, 25 Feb 2004 11:29:27 +1030
On Fri, 2004-02-20 at 17:40, Tim Hockin wrote:
> Well, really I don't see how apps would want to use it in any way that was
> correct.
The mere existence of the value means it can be used correctly
in application code for sanity checking.
eg:
assert(list_length(group_list) < ngroups_max());
list_append(&group_list, group);
An application might also use it to automatically
size data structure details, such as the parameters of
a hash function.
h = hash_create(ngroups_max());
Returning INT_MAX for NGROUPS_MAX isn't wrong, but you
then can't blame user space for making inefficient choices
if the kernel limit is actually smaller.
Cheers,
Glen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Darren Williams: "Re: [BUG] 2.6.3 Slab corruption: errors are triggered when memory exceeds 2.5GB (correction)"
- In reply to: Tim Hockin: "Re: PATCH: report NGROUPS_MAX via a sysctl (read-only)"
- Next in thread: Tim Hockin: "Re: PATCH: report NGROUPS_MAX via a sysctl (read-only)"
- Reply: Tim Hockin: "Re: PATCH: report NGROUPS_MAX via a sysctl (read-only)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
