rlim patch
PATCH 1/1 rlim patch
Quoted 7 lines
Howdy --
Regarding http://reality.sgi.com/kanoj_engr/rlim.patch :
Thanks for the patch!
I've also had to do similar things myself because I'm using over 2G virtual.
Linus/Alan, could you guys please look at the (2.2.10) patch at
http://reality.sgi.com/kanoj_engr/rlim.patch
for inclusion into 2.2 and 2.3. It is absolutely essential for processes which want to fill up their 3Gb user space completely.
Quoted 14 lines
Do you know what the chance is of getting this patch into the kernel? It's definitely useful and IMHO it should be considered a bugfix. (Was this posted to some list?)
Quoted 7 lines
This patch tries to fix some problems in the 2.2.10 kernel in regards to limit checks on vm resources. Specifically, the
RLIMIT_ASandRLIMIT_MEMLOCKresource checking does not have a concept of "unlimited", ieRLIM_INFINITY, this patch introduces that. Note that limits are defined as "long" quantities, and none of the limit values can be set to negative quantities via setrlimit. Hence,LONG_MAXis the maximum value of any limit, and this is the same asRLIM_INFINITY.
Quoted 6 lines
An additional way of dealing with this problem is to make all those longs be unsigned, and make INFINITY be ~0UL. This offers the advantage that you can also set resource limits to be between 2G and the maximum the kernel allows (e.g., 3G by default), instead of having all that be "infinity." I realize only the very perverse would want to set some resource limit between 2G and 3G :), but this would seem to be The Right Thing anyway.
You will see that in a bunch of places, the kernel tries to cast the "long" limits into "unsigned long" before doing the checks. Unfortunately, setrlimit() does not let you set "long" -ve values, so this is of limited use by itself.
Quoted 4 lines
To gain that advantage we'd need to have libc use and surface unsigned types too (which I've done on my system), which is actually claimed to be what the spec calls for in the first place.
Here in lies the dilemma of the concept of independent software modules. It would be a very nice thing to be able to isolate kernel changes and libc (or command) changes, and not have them depend on each other. In cases like this though, that poses problems, because you probably want old and new kernels working properly on old and new libc's.
Quoted 3 lines
What do you think?
Note that most limits are already set to LONG_MAX, which is also RLIM_INFINITY. Couldn't we isolate the fix to just the kernel, and basically treat LONG_MAX as RLIM_INFINITY, without wanting finer resolution?
Kanoj
Quoted 3 lines
thx,
grg
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/