* 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
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)
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)
* 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
> > > 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"
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.
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 |
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
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.
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
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;
> > +
@@ -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) {
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
> > 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
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
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
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
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
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
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
@@ -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) {
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 =
> 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
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
24 matches
Mail list logo
