Skip to contentSkip to conversation

set EXEC_PAGESIZE to PAGE_SIZE

PATCH In review Greg Edwards 3 participants 4 messages May 11, 2004

lore
Share & tools
lore

Greg Edwards

author
#0 lore raw

PATCH 1/1 set EXEC_PAGESIZE to PAGE_SIZE

The number of pages allocated for the gid_t * blocks[] array in the group_info struct is calculated from EXEC_PAGESIZE. This is used when the number of groups goes above 32. On ia64, this is currently hard-coded at 65536, which results in only a 1/4 of the required pages being allocated on a 16k page size kernel. A setgroups() call with a gidsetsize of 65536 will end up tromping on memory. Patch below sets EXEC_PAGESIZE to PAGE_SIZE.

=== include/asm-ia64/param.h 1.6 vs edited ==--- 1.6/include/asm-ia64/param.h Wed Feb 18 21:42:38 2004
+++ edited/include/asm-ia64/param.h Tue May 11 09:04:13 2004
@@ -10,7 +10,7 @@
* David Mosberger-Tang <[email protected]>, Hewlett-Packard Co
*/

-#define EXEC_PAGESIZE 65536
+#define EXEC_PAGESIZE PAGE_SIZE

#ifndef NOGROUP

 # define NOGROUP	(-1)
#1 lore raw
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Tue, 11 May 2004 09:59:23 -0500, [email protected] (Greg Edwards) said:

Greg> The number of pages allocated for the gid_t * blocks[] array Greg> in the group_info struct is calculated from EXEC_PAGESIZE.

Sounds like a bug in the large-groups patch then, no?

	--david
#2 lore raw
In reply to Greg Edwards
Quoted 7 lines · [email protected] (Greg Edwards) writes:

The number of pages allocated for the gid_t * blocks[] array in the group_info struct is calculated from EXEC_PAGESIZE. This is used when the number of groups goes above 32. On ia64, this is currently hard-coded at 65536, which results in only a 1/4 of the required pages being allocated on a 16k page size kernel. A setgroups() call with a gidsetsize of 65536 will end up tromping on memory. Patch below sets EXEC_PAGESIZE to PAGE_SIZE.

IMHO the real bug is that EXEC_PAGESIZE is used in the first place. EXEC_PAGESIZE is supposed to be the biggest page size supported by any executable, thus is should always be the max of all possible page sizes. It has no relation to the actual page size of the running kernel.

Andreas.

Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
author
#3 lore raw
In reply to Greg Edwards

On Tue, May 11, 2004 at 06:24:22PM +0200, Andreas Schwab wrote:

| [email protected] (Greg Edwards) writes:
| 
| > The number of pages allocated for the gid_t * blocks[] array in the
| > group_info struct is calculated from EXEC_PAGESIZE.  This is used when
| > the number of groups goes above 32.  On ia64, this is currently
| > hard-coded at 65536, which results in only a 1/4 of the required pages
| > being allocated on a 16k page size kernel.  A setgroups() call with a
| > gidsetsize of 65536 will end up tromping on memory.  Patch below sets
| > EXEC_PAGESIZE to PAGE_SIZE.
| 
| IMHO the real bug is that EXEC_PAGESIZE is used in the first place.
| EXEC_PAGESIZE is supposed to be the biggest page size supported by any
| executable, thus is should always be the max of all possible page sizes.
| It has no relation to the actual page size of the running kernel.

Thanks for pointing that out, Andreas. I'll take a look and see if any arches have a problem with calculating NGROUPS_PER_BLOCK from PAGE_SIZE instead of EXEC_PAGESIZE, then I'll send something to lkml.

Greg