Re: [Nmh-workers] rmmproc Not Used for Lots of Messages; refile Copies.

[Valdis . Kletnieks]

On Mon, 26 Nov 2012 17:46:42 -0500, Paul Fox said:

> so, i've stumbled over rmmproc's limit in the past (and, like others,
> have quietly, manually, done it in chunks instead), but i don't think
> i've ever seen a similar limit with "rm".  and now i'm wondering, why
> not?  certainly this works just fine:
>
>     $ mkdir /tmp/many
>     $ cd /tmp/many
>     $ touch $(seq 1 100000)
>     $ ls | wc -l
>     100000

If you tried this on a Linux kernel that's newer than August 2007,
you probably will have to try harder to hit the argv[] limit.
The code in fs/exec.c now says:

                /*
                 * Limit to 1/4-th the stack size for the argv+env strings.
                 * This ensures that:
                 *  - the remaining binfmt code will not run out of stack space,
                 *  - the program will have a reasonable amount of stack left
                 *    to work from.
                 */
                rlim = current->signal->rlim;
                if (size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur) / 4) {
                        put_page(page);
                        return NULL;
                }

So if your default stack limit is 8M, you can exec() with up to 2M of
argv[] strings. If we're talking mh files, that means you can fit about
250K filenames into that 2M.

"250K filenames should be enough for anybody" -- Bill Gates, badly misquoted.

pgp4n77BmaYUb.pgp
Description: PGP signature