* Linus Torvalds <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
