[lkml]   [2006]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] binfmt: turn MAX_ARG_PAGES into a sysctl tunable

    * Linus Torvalds <> 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 :-|

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-27 01:04    [W:0.028 / U:11.824 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site