In message <20100208145240.fb58.a69d9...@jp.fujitsu.com> you wrote:
> > > >
> > > > Hi,
> > > >
> > > > > Why do we need page size independent stack size? It seems to have
> > > > > compatibility breaking risk.
> > > >
> > > > I don't think so. The current behaviour is clearly wrong, we dont n
> On Mon, Feb 8, 2010 at 2:05 PM, KOSAKI Motohiro
> wrote:
> >> --- linux-2.6-ozlabs.orig/fs/exec.c
> >> +++ linux-2.6-ozlabs/fs/exec.c
> >> @@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
> >> goto out_unlock;
> >> }
> >>
> >> + stack_base = min(EXTRA
On Mon, Feb 8, 2010 at 2:05 PM, KOSAKI Motohiro
wrote:
>> --- linux-2.6-ozlabs.orig/fs/exec.c
>> +++ linux-2.6-ozlabs/fs/exec.c
>> @@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
>> goto out_unlock;
>> }
>>
>> + stack_base = min(EXTRA_STACK_VM_PAGES *
>
> Hi,
>
> > I didn't discuss which behavior is better. Michael said he want to apply
> > his patch to 2.6.32 & 2.6.33. stable tree never accept the breaking
> > compatibility patch.
> >
> > Your answer doesn't explain why can't we wait it until next merge window.
> >
> >
> > btw, personally,
> > >
> > > Hi,
> > >
> > > > Why do we need page size independent stack size? It seems to have
> > > > compatibility breaking risk.
> > >
> > > I don't think so. The current behaviour is clearly wrong, we dont need a
> > > 16x larger stack just because you went from a 4kB to a 64kB base page
>
> >
> > Hi,
> >
> > > Why do we need page size independent stack size? It seems to have
> > > compatibility breaking risk.
> >
> > I don't think so. The current behaviour is clearly wrong, we dont need a
> > 16x larger stack just because you went from a 4kB to a 64kB base page
> > size. The use
Hi
> apkm, linus: this or something like it needs to go into 2.6.33 (& 32) to
> fix 'ulimit -s'.
"fix ulimit -s" is too cool explanation ;-)
we are not ESPer. please consider to provide what bug is exist.
> Mikey
>
> [PATCH] Restrict stack space re
Hi,
> I didn't discuss which behavior is better. Michael said he want to apply
> his patch to 2.6.32 & 2.6.33. stable tree never accept the breaking
> compatibility patch.
>
> Your answer doesn't explain why can't we wait it until next merge window.
>
>
> btw, personally, I like page size inde
>
> Hi,
>
> > Why do we need page size independent stack size? It seems to have
> > compatibility breaking risk.
>
> I don't think so. The current behaviour is clearly wrong, we dont need a
> 16x larger stack just because you went from a 4kB to a 64kB base page
> size. The user application stac
Hi,
> Why do we need page size independent stack size? It seems to have
> compatibility breaking risk.
I don't think so. The current behaviour is clearly wrong, we dont need a
16x larger stack just because you went from a 4kB to a 64kB base page
size. The user application stack usage is the sam
When reserving stack space for a new process, make sure we're not
attempting to allocate more than rlimit allows.
Also, reserve the same stack size independent of page size.
This fixes a bug cause by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
"mm: variable length argument support" and unmasked by
apkm, linus: this or something like it needs to go into 2.6.33 (& 32) to
fix 'ulimit -s'.
Mikey
[PATCH] Restrict stack space reservation to rlimit
When reserving stack space for a new process, make sure we're not
attempting to allocate more than rlimit allows.
Also, res
12 matches
Mail list logo
