getrlimit give unexpected results

[Jeff Currier_1]

On a 64 bit system, when I run a 32-bit program I am seeing that getrlimit is being restricted by maxdsiz_64bit which doesn't make sense. This happens when maxdsiz_64bit is less than maxdsiz. Does this make sense to anyone? Is this a bug in getrlimit?

I wrote the following simple program to test. When maxdsiz_64bit is less than 2gb and less than madxsiz, then my test program, compiled at a 32-bit program, resports the size as what is set by maxdsiz_64bit, not the value of maxdsiz as I expected. Can you explain this?

______________START____________________
/* jeff Currier
File: test.c
cc +DD32 -o test10 test10.c
*/
#include
#include
#include
int i=-1;
int uid;
int found=0;
struct rlimit rlp;

main (argc,argv)
int argc;
char *argv[];
{
printf ("start\n");
i =getrlimit(RLIMIT_DATA,&rlp);
printf ("RLIMITerr %d \n",i);
printf ("RLIMITcur %ld \n",rlp.rlim_cur);
printf ("RLIMITmax %ld \n",rlp.rlim_max);
printf ("end\n");
}
__________________________END____________
This always shows that if maxdsiz_64bit is less than maxdsiz, then RLIMIT is equal to maxdiz_64bit.
See the following output (a page equals 4kb), I expected to see 2GB at the result, not 1gb.

currierj-hp01:/home/currierj/mem> /etc/sysdef | grep maxd
maxdsiz 503866 - 0-503866 Pages -
maxdsiz_64bit 262144 - 1024-1073479679 Pages -
hp01:/home/currierj/mem> ./test10
start
RLIMITerr 0
RLIMITcur 1073741824
RLIMITmax 1073741824
end

[Dietmar Konermann]

Hi!

Indeed, I was able to verify your symptom on our 11.11 system. In fact you even don't need your test program...


### kernel configuration:

# kmtune |grep maxdsiz
maxdsiz 1000000000 - 1000000000
maxdsiz_64bit 500000000 - 500000000


### after bootup:

# ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 488280
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 2048

So we have the maxdsiz_64bit limit active for our 32 bit shell.

But we are able to increase the limit beyond the smaller 64 bit limit, since we are 32 bit:

# ulimit -d 900000
# ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 900000
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 2048

So the interesting thing is that we default to the 64 bit limit and I think this is designed this way, because:

The typical configuration is maxdsiz_64bit >= maxdsiz. And the shell is e.g. 32bit. I we would default to the 32bit limit then all started 64bit procs would inherit the smaller limit. And that would be an undesired behaviour, I beleive.

So, in summary:
The 64 bit limit is the default, but you can increase your limit manually for 32 bit procs if your 32bit limit is larger.

Best regards...
Dietmar.