On 03.03.2008 [16:50:11 -0600], Andrew Hastings wrote:
> Nish,
>
> Nishanth Aravamudan wrote:
> > Another quick thought: we recently changed elflink.c to fork() to do the
> > hugetlbfs copying. Would such a change be useful in the stack remapping
> > code? That would avoid some of the address spac
Nish,
Nishanth Aravamudan wrote:
> Another quick thought: we recently changed elflink.c to fork() to do the
> hugetlbfs copying. Would such a change be useful in the stack remapping
> code? That would avoid some of the address space pollution issues, I'd
> think, but not sure if it's fully applica
On 22.02.2008 [17:42:58 -0600], Andrew Hastings wrote:
> Nish,
>
> Nishanth Aravamudan wrote:
> 2. Must have address space randomization turned on for i386 and x86_64.
If this is the case, shouldn't you be checking the sysctl in stack.c?
Then we just make the feature depend on the sys
Nish,
Nishanth Aravamudan wrote:
2. Must have address space randomization turned on for i386 and x86_64.
>>> If this is the case, shouldn't you be checking the sysctl in stack.c?
>>> Then we just make the feature depend on the sysctl's value.
>> I'd prefer not to do this -- if my kernel patch
On 22.02.2008 [14:20:13 -0600], Andrew Hastings wrote:
> Nish,
>
> Thanks for the review!
No problem, thanks for working on this code, I think it's a useful
feature.
> Nishanth Aravamudan wrote:
>> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
>>> Remap stack on hugepages if HUGETLB_STAC
On 22.02.2008 [14:20:13 -0600], Andrew Hastings wrote:
> Nish,
>
> Thanks for the review!
Another quick thought: we recently changed elflink.c to fork() to do the
hugetlbfs copying. Would such a change be useful in the stack remapping
code? That would avoid some of the address space pollution iss
Nish,
Thanks for the review!
Nishanth Aravamudan wrote:
> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
>> Remap stack on hugepages if HUGETLB_STACK is set in the environment.
>>
>> Caveats:
>> 1. Hugepage stack does not grow or shrink.
>
> Ok, this may not be a problem we need to addre
On Fri, Feb 08, 2008 at 09:46:09AM -0600, Andrew Hastings wrote:
> David Gibson wrote:
> > On Tue, Feb 05, 2008 at 02:54:03PM -0800, Nishanth Aravamudan wrote:
> >> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
> >>> Remap stack on hugepages if HUGETLB_STACK is set in the environment.
> >>
David Gibson wrote:
> On Tue, Feb 05, 2008 at 02:54:03PM -0800, Nishanth Aravamudan wrote:
>> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
>>> Remap stack on hugepages if HUGETLB_STACK is set in the environment.
>>>
>>> Caveats:
>>> 1. Hugepage stack does not grow or shrink.
>> Ok, this m
On Tue, Feb 05, 2008 at 02:54:03PM -0800, Nishanth Aravamudan wrote:
> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
> > Remap stack on hugepages if HUGETLB_STACK is set in the environment.
> >
> > Caveats:
> > 1. Hugepage stack does not grow or shrink.
>
> Ok, this may not be a problem
On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
> Remap stack on hugepages if HUGETLB_STACK is set in the environment.
>
> Caveats:
> 1. Hugepage stack does not grow or shrink.
Ok, this may not be a problem we need to address in the short term,
we'll see what users say :)
> 2. Must have a
Remap stack on hugepages if HUGETLB_STACK is set in the environment.
Caveats:
1. Hugepage stack does not grow or shrink.
2. Must have address space randomization turned on for i386 and x86_64.
For i386 and x86_64, the default stack location is at TASK_SIZE and is
not aligned to 2M. The kernel w
12 matches
Mail list logo
