Re: [patch 0/3] no MAX_ARG_PAGES -v2
* Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > This patch-set aims at removing the current limit on argv+env space > > aka. MAX_ARG_PAGES. > > Thanks a lot for solving this properly. I have been upping current > limits to some insane ammounts to work around this. seconded! I have tried the patchset and it works great for me. This limitation of Linux has bothered me almost since i started using Linux more than a decade ago (i remember having run into it when running a script on an overly large directory), and it's perhaps the oldest still existing userspace-visible limitations of Linux. It was also a really hard nut to crack. Kudos Peter! I really cant wait to see this in 2.6.23 :-) Acked-by: Ingo Molnar <[EMAIL PROTECTED]> 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
Hi! > This patch-set aims at removing the current limit on argv+env space aka. > MAX_ARG_PAGES. Thanks a lot for solving this properly. I have been upping current limits to some insane ammounts to work around this. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
Hi! This patch-set aims at removing the current limit on argv+env space aka. MAX_ARG_PAGES. Thanks a lot for solving this properly. I have been upping current limits to some insane ammounts to work around this. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
* Pavel Machek [EMAIL PROTECTED] wrote: Hi! This patch-set aims at removing the current limit on argv+env space aka. MAX_ARG_PAGES. Thanks a lot for solving this properly. I have been upping current limits to some insane ammounts to work around this. seconded! I have tried the patchset and it works great for me. This limitation of Linux has bothered me almost since i started using Linux more than a decade ago (i remember having run into it when running a script on an overly large directory), and it's perhaps the oldest still existing userspace-visible limitations of Linux. It was also a really hard nut to crack. Kudos Peter! I really cant wait to see this in 2.6.23 :-) Acked-by: Ingo Molnar [EMAIL PROTECTED] 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/
RE: [patch 0/3] no MAX_ARG_PAGES -v2
> > > A good heuristic, though, might be to limit > > > argument size to a percentage (say 25%) of maximum stack size and > > > validate this inside copy_strings(). > > > > This seems to do: > > Looks good. Me too. As I increase the number of arguments, I now have a smooth cutover from "works" to "Arg list too long", without the in between zone where the process is killed. The IA-32 compatability exec path is now working too (I didn't stress it too hard, but I did try argument lists up to a megabyte). Acked-by: Tony Luck <[EMAIL PROTECTED]> - 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On 6/15/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote: > A good heuristic, though, might be to limit > argument size to a percentage (say 25%) of maximum stack size and > validate this inside copy_strings(). This seems to do: Looks good. Ollie - 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote:
> A good heuristic, though, might be to limit
> argument size to a percentage (say 25%) of maximum stack size and
> validate this inside copy_strings().
This seems to do:
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
fs/exec.c | 17 +
1 file changed, 17 insertions(+)
Index: linux-2.6-2/fs/exec.c
===
--- linux-2.6-2.orig/fs/exec.c 2007-06-15 11:05:09.0 +0200
+++ linux-2.6-2/fs/exec.c 2007-06-15 11:05:18.0 +0200
@@ -199,6 +199,23 @@ static struct page *get_arg_page(struct
if (ret <= 0)
return NULL;
+ if (write) {
+ struct rlimit *rlim = current->signal->rlim;
+ unsigned long size = bprm->vma->vm_end - bprm->vma->vm_start;
+
+ /*
+* 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.
+*/
+ if (size > rlim[RLIMIT_STACK].rlim_cur / 4) {
+ put_page(page);
+ return NULL;
+ }
+ }
+
return page;
}
-
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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote:
A good heuristic, though, might be to limit
argument size to a percentage (say 25%) of maximum stack size and
validate this inside copy_strings().
This seems to do:
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
fs/exec.c | 17 +
1 file changed, 17 insertions(+)
Index: linux-2.6-2/fs/exec.c
===
--- linux-2.6-2.orig/fs/exec.c 2007-06-15 11:05:09.0 +0200
+++ linux-2.6-2/fs/exec.c 2007-06-15 11:05:18.0 +0200
@@ -199,6 +199,23 @@ static struct page *get_arg_page(struct
if (ret = 0)
return NULL;
+ if (write) {
+ struct rlimit *rlim = current-signal-rlim;
+ unsigned long size = bprm-vma-vm_end - bprm-vma-vm_start;
+
+ /*
+* 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.
+*/
+ if (size rlim[RLIMIT_STACK].rlim_cur / 4) {
+ put_page(page);
+ return NULL;
+ }
+ }
+
return page;
}
-
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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On 6/15/07, Peter Zijlstra [EMAIL PROTECTED] wrote: On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote: A good heuristic, though, might be to limit argument size to a percentage (say 25%) of maximum stack size and validate this inside copy_strings(). This seems to do: Looks good. Ollie - 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/
RE: [patch 0/3] no MAX_ARG_PAGES -v2
A good heuristic, though, might be to limit argument size to a percentage (say 25%) of maximum stack size and validate this inside copy_strings(). This seems to do: Looks good. Me too. As I increase the number of arguments, I now have a smooth cutover from works to Arg list too long, without the in between zone where the process is killed. The IA-32 compatability exec path is now working too (I didn't stress it too hard, but I did try argument lists up to a megabyte). Acked-by: Tony Luck [EMAIL PROTECTED] - 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote:
> > @@ -1385,6 +1401,10 @@ int do_execve(char * filename,
> > goto out;
> > bprm->argv_len = env_p - bprm->p;
> >
> > + retval = expand_arg_vma(bprm);
> > + if (retval < 0)
> > + goto out;
> > +
> > retval = search_binary_handler(bprm,regs);
> > if (retval >= 0) {
> > /* execve success */
>
> At this point bprm->argc hasn't been finalized yet. For example, the
> script binfmt reads the script header and adds additional arguments.
> The flush_old_exec() function is a better place to call this.
Sure, but at this time most of it is there, so when there are many, this
allocates the most of it.
> I'm not 100% sure this is the right way to handle this, though. The
> problem isn't as simple as ensuring the stack doesn't overflow during
> argument allocation. We also need to ensure the program has
> sufficient stack space to run subsequently. Otherwise, the observable
> behavior is identical.
Well, not identical, but similar indeed.
> Since we can't realistically predict
> acceptable stack availability requirements, some amount of uncertainty
> is always going to exist.
> A good heuristic, though, might be to limit
> argument size to a percentage (say 25%) of maximum stack size and
> validate this inside copy_strings().
Right, this seems a much simpler approach. I like it.
-
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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
@@ -1385,6 +1401,10 @@ int do_execve(char * filename,
goto out;
bprm->argv_len = env_p - bprm->p;
+ retval = expand_arg_vma(bprm);
+ if (retval < 0)
+ goto out;
+
retval = search_binary_handler(bprm,regs);
if (retval >= 0) {
/* execve success */
At this point bprm->argc hasn't been finalized yet. For example, the
script binfmt reads the script header and adds additional arguments.
The flush_old_exec() function is a better place to call this.
I'm not 100% sure this is the right way to handle this, though. The
problem isn't as simple as ensuring the stack doesn't overflow during
argument allocation. We also need to ensure the program has
sufficient stack space to run subsequently. Otherwise, the observable
behavior is identical. Since we can't realistically predict
acceptable stack availability requirements, some amount of uncertainty
is always going to exist. A good heuristic, though, might be to limit
argument size to a percentage (say 25%) of maximum stack size and
validate this inside copy_strings().
Ollie
-
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/
RE: [patch 0/3] no MAX_ARG_PAGES -v2
On Thu, 2007-06-14 at 11:22 -0700, Luck, Tony wrote: > > > Interesting. If you're exceeding your stack ulimit, you should be > > > seeing either an "argument list too long" message or getting a > > > SIGSEGV. Have you tried bypassing wc and piping the output straight > > > to a file? > > > > I think it sends SIGKILL on failure paths. > > Setting stack limit to unlimited I managed to exec with 10MB, and > "wc" produced the correct output when it (finally) ran, so no > odd limits being hit in there. Ah, good :-) > Ah ... running the 34*100K case direct from my shell prompt, I > do see a "Killed" that must get lost when I run this in the > shell script loop. Yes, so it seems we just trip the stack limit after we cross the point of no return. I started looking into growing the stack beforehand and perhaps shrinking the stack after we're done. That would get most if not all these failures before the point of no return. - 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/
RE: [patch 0/3] no MAX_ARG_PAGES -v2
> > Interesting. If you're exceeding your stack ulimit, you should be > > seeing either an "argument list too long" message or getting a > > SIGSEGV. Have you tried bypassing wc and piping the output straight > > to a file? > > I think it sends SIGKILL on failure paths. Setting stack limit to unlimited I managed to exec with 10MB, and "wc" produced the correct output when it (finally) ran, so no odd limits being hit in there. Setting a lower (4MB) stack limit, and then increasing the amount of args in 100K steps I saw this: Up to an including 32 * 100K => works fine. 33:40 * 100K => no errors from the script, but wc reports "0 0 0" >40 * 100K => "/bin/echo: Argument list too long". All this might be connected to ia64's confusing implementation of stack limit (since we have *two* stacks ... the regular one and the upward growing one for the h/w register stack engine). Ah ... running the 34*100K case direct from my shell prompt, I do see a "Killed" that must get lost when I run this in the shell script loop. -Tony - 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On Wed, 2007-06-13 at 23:23 -0700, Ollie Wild wrote:
> On 6/13/07, Luck, Tony <[EMAIL PROTECTED]> wrote:
> > Above 5Mbytes, I started seeing problems. The line/word/char
> > counts from "wc" started being "0 0 0". Not sure if this is
> > a problem in "wc" dealing with a single line >5MBytes, or some
> > other problem (possibly I was exceeding the per-process stack
> > limit which is only 8MB on that machine).
>
> Interesting. If you're exceeding your stack ulimit, you should be
> seeing either an "argument list too long" message or getting a
> SIGSEGV. Have you tried bypassing wc and piping the output straight
> to a file?
I think it sends SIGKILL on failure paths.
I've been thinking of moving this large stack alloc in
create_elf_tables() before the point of no return.
something like this, it should do the largest part of the alloc
beforehand. Just have to see if all binfmts need this much, and if not,
what the ramifications are of overgrowing the stack (perhaps we need to
shrink it again to wherever bprm->p ends up?)
Index: linux-2.6-2/fs/exec.c
===
--- linux-2.6-2.orig/fs/exec.c 2007-06-14 10:29:22.0 +0200
+++ linux-2.6-2/fs/exec.c 2007-06-14 10:28:45.0 +0200
@@ -272,6 +272,17 @@ static bool valid_arg_len(struct linux_b
return len <= MAX_ARG_STRLEN;
}
+static int expand_arg_vma(struct linux_binprm *bprm)
+{
+ long size = (bprm->argc + bprm->envc + 2) * sizeof(void *);
+
+#ifdef CONFIG_STACK_GROWSUP
+#error I broke it
+#else
+ return expand_stack(bprm->vma, bprm->p - size);
+#endif
+}
+
#else
static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
@@ -326,6 +337,11 @@ static bool valid_arg_len(struct linux_b
return len <= bprm->p;
}
+static int expand_arg_vma(struct linux_binprm *bprm)
+{
+ return 0;
+}
+
#endif /* CONFIG_MMU */
/*
@@ -1385,6 +1401,10 @@ int do_execve(char * filename,
goto out;
bprm->argv_len = env_p - bprm->p;
+ retval = expand_arg_vma(bprm);
+ if (retval < 0)
+ goto out;
+
retval = search_binary_handler(bprm,regs);
if (retval >= 0) {
/* execve success */
-
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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On 6/13/07, Luck, Tony <[EMAIL PROTECTED]> wrote: Above 5Mbytes, I started seeing problems. The line/word/char counts from "wc" started being "0 0 0". Not sure if this is a problem in "wc" dealing with a single line >5MBytes, or some other problem (possibly I was exceeding the per-process stack limit which is only 8MB on that machine). Interesting. If you're exceeding your stack ulimit, you should be seeing either an "argument list too long" message or getting a SIGSEGV. Have you tried bypassing wc and piping the output straight to a file? Ollie - 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On 6/13/07, Luck, Tony [EMAIL PROTECTED] wrote: Above 5Mbytes, I started seeing problems. The line/word/char counts from wc started being 0 0 0. Not sure if this is a problem in wc dealing with a single line 5MBytes, or some other problem (possibly I was exceeding the per-process stack limit which is only 8MB on that machine). Interesting. If you're exceeding your stack ulimit, you should be seeing either an argument list too long message or getting a SIGSEGV. Have you tried bypassing wc and piping the output straight to a file? Ollie - 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On Wed, 2007-06-13 at 23:23 -0700, Ollie Wild wrote:
On 6/13/07, Luck, Tony [EMAIL PROTECTED] wrote:
Above 5Mbytes, I started seeing problems. The line/word/char
counts from wc started being 0 0 0. Not sure if this is
a problem in wc dealing with a single line 5MBytes, or some
other problem (possibly I was exceeding the per-process stack
limit which is only 8MB on that machine).
Interesting. If you're exceeding your stack ulimit, you should be
seeing either an argument list too long message or getting a
SIGSEGV. Have you tried bypassing wc and piping the output straight
to a file?
I think it sends SIGKILL on failure paths.
I've been thinking of moving this large stack alloc in
create_elf_tables() before the point of no return.
something like this, it should do the largest part of the alloc
beforehand. Just have to see if all binfmts need this much, and if not,
what the ramifications are of overgrowing the stack (perhaps we need to
shrink it again to wherever bprm-p ends up?)
Index: linux-2.6-2/fs/exec.c
===
--- linux-2.6-2.orig/fs/exec.c 2007-06-14 10:29:22.0 +0200
+++ linux-2.6-2/fs/exec.c 2007-06-14 10:28:45.0 +0200
@@ -272,6 +272,17 @@ static bool valid_arg_len(struct linux_b
return len = MAX_ARG_STRLEN;
}
+static int expand_arg_vma(struct linux_binprm *bprm)
+{
+ long size = (bprm-argc + bprm-envc + 2) * sizeof(void *);
+
+#ifdef CONFIG_STACK_GROWSUP
+#error I broke it
+#else
+ return expand_stack(bprm-vma, bprm-p - size);
+#endif
+}
+
#else
static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
@@ -326,6 +337,11 @@ static bool valid_arg_len(struct linux_b
return len = bprm-p;
}
+static int expand_arg_vma(struct linux_binprm *bprm)
+{
+ return 0;
+}
+
#endif /* CONFIG_MMU */
/*
@@ -1385,6 +1401,10 @@ int do_execve(char * filename,
goto out;
bprm-argv_len = env_p - bprm-p;
+ retval = expand_arg_vma(bprm);
+ if (retval 0)
+ goto out;
+
retval = search_binary_handler(bprm,regs);
if (retval = 0) {
/* execve success */
-
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/
RE: [patch 0/3] no MAX_ARG_PAGES -v2
Interesting. If you're exceeding your stack ulimit, you should be seeing either an argument list too long message or getting a SIGSEGV. Have you tried bypassing wc and piping the output straight to a file? I think it sends SIGKILL on failure paths. Setting stack limit to unlimited I managed to exec with 10MB, and wc produced the correct output when it (finally) ran, so no odd limits being hit in there. Setting a lower (4MB) stack limit, and then increasing the amount of args in 100K steps I saw this: Up to an including 32 * 100K = works fine. 33:40 * 100K = no errors from the script, but wc reports 0 0 0 40 * 100K = /bin/echo: Argument list too long. All this might be connected to ia64's confusing implementation of stack limit (since we have *two* stacks ... the regular one and the upward growing one for the h/w register stack engine). Ah ... running the 34*100K case direct from my shell prompt, I do see a Killed that must get lost when I run this in the shell script loop. -Tony - 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/
RE: [patch 0/3] no MAX_ARG_PAGES -v2
On Thu, 2007-06-14 at 11:22 -0700, Luck, Tony wrote: Interesting. If you're exceeding your stack ulimit, you should be seeing either an argument list too long message or getting a SIGSEGV. Have you tried bypassing wc and piping the output straight to a file? I think it sends SIGKILL on failure paths. Setting stack limit to unlimited I managed to exec with 10MB, and wc produced the correct output when it (finally) ran, so no odd limits being hit in there. Ah, good :-) Ah ... running the 34*100K case direct from my shell prompt, I do see a Killed that must get lost when I run this in the shell script loop. Yes, so it seems we just trip the stack limit after we cross the point of no return. I started looking into growing the stack beforehand and perhaps shrinking the stack after we're done. That would get most if not all these failures before the point of no return. - 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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
@@ -1385,6 +1401,10 @@ int do_execve(char * filename,
goto out;
bprm-argv_len = env_p - bprm-p;
+ retval = expand_arg_vma(bprm);
+ if (retval 0)
+ goto out;
+
retval = search_binary_handler(bprm,regs);
if (retval = 0) {
/* execve success */
At this point bprm-argc hasn't been finalized yet. For example, the
script binfmt reads the script header and adds additional arguments.
The flush_old_exec() function is a better place to call this.
I'm not 100% sure this is the right way to handle this, though. The
problem isn't as simple as ensuring the stack doesn't overflow during
argument allocation. We also need to ensure the program has
sufficient stack space to run subsequently. Otherwise, the observable
behavior is identical. Since we can't realistically predict
acceptable stack availability requirements, some amount of uncertainty
is always going to exist. A good heuristic, though, might be to limit
argument size to a percentage (say 25%) of maximum stack size and
validate this inside copy_strings().
Ollie
-
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/
Re: [patch 0/3] no MAX_ARG_PAGES -v2
On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote:
@@ -1385,6 +1401,10 @@ int do_execve(char * filename,
goto out;
bprm-argv_len = env_p - bprm-p;
+ retval = expand_arg_vma(bprm);
+ if (retval 0)
+ goto out;
+
retval = search_binary_handler(bprm,regs);
if (retval = 0) {
/* execve success */
At this point bprm-argc hasn't been finalized yet. For example, the
script binfmt reads the script header and adds additional arguments.
The flush_old_exec() function is a better place to call this.
Sure, but at this time most of it is there, so when there are many, this
allocates the most of it.
I'm not 100% sure this is the right way to handle this, though. The
problem isn't as simple as ensuring the stack doesn't overflow during
argument allocation. We also need to ensure the program has
sufficient stack space to run subsequently. Otherwise, the observable
behavior is identical.
Well, not identical, but similar indeed.
Since we can't realistically predict
acceptable stack availability requirements, some amount of uncertainty
is always going to exist.
A good heuristic, though, might be to limit
argument size to a percentage (say 25%) of maximum stack size and
validate this inside copy_strings().
Right, this seems a much simpler approach. I like it.
-
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/
RE: [patch 0/3] no MAX_ARG_PAGES -v2
> This patch-set aims at removing the current limit on argv+env space aka. > MAX_ARG_PAGES. Running with this patch shows that /bin/bash has some unpleasant O(n^2) performance issues with long argument lists. I made a 1Mbyte file full of pathnames, then timed the execution of: $ /bin/echo `cat megabyte` | wc $ /bin/echo `cat megabyte megabyte` | wc etc. ... System time was pretty much linear as the arglist grew (and only got up to 0.144 seconds at 5Mbytes). But user time ~= real time (in seconds) looks like: 1 5.318 2 18.871 3 40.620 4 70.819 5 108.911 Above 5Mbytes, I started seeing problems. The line/word/char counts from "wc" started being "0 0 0". Not sure if this is a problem in "wc" dealing with a single line >5MBytes, or some other problem (possibly I was exceeding the per-process stack limit which is only 8MB on that machine). -Tony - 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/
RE: [patch 0/3] no MAX_ARG_PAGES -v2
This patch-set aims at removing the current limit on argv+env space aka. MAX_ARG_PAGES. Running with this patch shows that /bin/bash has some unpleasant O(n^2) performance issues with long argument lists. I made a 1Mbyte file full of pathnames, then timed the execution of: $ /bin/echo `cat megabyte` | wc $ /bin/echo `cat megabyte megabyte` | wc etc. ... System time was pretty much linear as the arglist grew (and only got up to 0.144 seconds at 5Mbytes). But user time ~= real time (in seconds) looks like: 1 5.318 2 18.871 3 40.620 4 70.819 5 108.911 Above 5Mbytes, I started seeing problems. The line/word/char counts from wc started being 0 0 0. Not sure if this is a problem in wc dealing with a single line 5MBytes, or some other problem (possibly I was exceeding the per-process stack limit which is only 8MB on that machine). -Tony - 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/
