On 22/05/2015 09:25, Jan Beulich wrote:
On 21.05.15 at 13:48, wrote:
> On 21.05.15 at 13:08, wrote:
>>> On 21/05/15 11:15, Jan Beulich wrote:
This is needed as stacks are going to become non-executable. Use
separate stub pages (shared among suitable CPUs on the same node)
>>> On 22.05.15 at 10:25, wrote:
On 21.05.15 at 13:48, wrote:
> On 21.05.15 at 13:08, wrote:
>>> It might be wise to have a BUILD_BUG_ON() which confirms that
>>> STUBS_PER_PAGE is a power of two, which is a requirement given the way
>>> it is used.
>>
>> Good idea.
>
> Sadly this can
>>> On 21.05.15 at 13:48, wrote:
On 21.05.15 at 13:08, wrote:
>> On 21/05/15 11:15, Jan Beulich wrote:
>>> This is needed as stacks are going to become non-executable. Use
>>> separate stub pages (shared among suitable CPUs on the same node)
>>> instead.
>>>
>>> Stub areas (currently 128 byt
On 21/05/15 12:48, Jan Beulich wrote:
On 21.05.15 at 13:08, wrote:
>> On 21/05/15 11:15, Jan Beulich wrote:
>>> This is needed as stacks are going to become non-executable. Use
>>> separate stub pages (shared among suitable CPUs on the same node)
>>> instead.
>>>
>>> Stub areas (currently 128
>>> On 21.05.15 at 13:08, wrote:
> On 21/05/15 11:15, Jan Beulich wrote:
>> This is needed as stacks are going to become non-executable. Use
>> separate stub pages (shared among suitable CPUs on the same node)
>> instead.
>>
>> Stub areas (currently 128 bytes each) are being split into two parts -
On 21/05/15 11:15, Jan Beulich wrote:
> This is needed as stacks are going to become non-executable. Use
> separate stub pages (shared among suitable CPUs on the same node)
> instead.
>
> Stub areas (currently 128 bytes each) are being split into two parts -
> a fixed usage one (the syscall ones) a
This is needed as stacks are going to become non-executable. Use
separate stub pages (shared among suitable CPUs on the same node)
instead.
Stub areas (currently 128 bytes each) are being split into two parts -
a fixed usage one (the syscall ones) and dynamically usable space,
which will be used b
