Re: [PATCH] binfmt: turn MAX_ARG_PAGES into a sysctl tunable

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxx> wrote:

> I totally re-organized how execve() allocates the new mm at an execve 
> several years ago (it used to re-use the old MM if it could), and that 
> was so that we count just remove the brpm->page array, and just 
> install the pages directly into the destination.
> 
> That was in 2002. I never actually got around to doing it ;(.

i thought about your "map execve pages directly into target" (since the 
source gets destroyed anyway) suggestion back then, and unfortunately it 
gets quite complex.

Firstly, if setenv is done and the array of strings gets larger, glibc 
realloc()s it and the layout of the environment gets 'fragmented'. 
Ulrich was uneasy about passing a fragmented environment to the target 
task - it's not sure that no app would break. Secondly, for security 
reasons we have to memset all the memory around fragmented strings. So 
we might end up doing _alot_ of memsetting in some cases, if the string 
space happens to be fragmented. So while the current method is slow and 
uses persistent memory, it at least "compresses" the layout of the 
environment (and arguments) at every exec() time and thus avoids these 
sorts of problems.

And this is a real problem for real applications and is being complained 
about alot by shops that do alot of development and have scrips around 
large filesystem hierarchies. (and who got used to their scripts working 
on other unices just fine)

Lets at least give root the chance to increase this limit and go with 
the dumb and easy patch i posted years ago. It worked just fine - and 
it's not like root cannot cause lots of persistent memory to be 
allocated by processes: for example by setting the per-socket wmem limit 
to 10MB. Please? I personally run into this stupid limit every couple of 
days during development while working with the kernel tree, just do a 
simple thing like in the kernel tree's top directory:

 $ ls -lS `find .`
 -bash: /bin/ls: Argument list too long

The phrase "that ridiculous 128K limit" often comes to my mind :-|

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/