--Hugh Dickins <[email protected]> wrote (on Wednesday, August 31, 2005 14:42:38 +0100):
> On Wed, 31 Aug 2005, Arjan van de Ven wrote:
>> On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote:
>> > I was going to say, doesn't randomize_va_space take away the rest of
>> > the point? But no, it appears "randomize_va_space", as it currently
>> > appears in mainline anyway, is somewhat an exaggeration: it just shifts
>> > the stack a little, with no effect on the rest of the va space.
>>
>> it also randomizes mmaps
>
> Ah, via PF_RANDOMIZE, yes, thanks: so long as certain conditions are
> fulfilled - and my RLIM_INFINITY RLIMIT_STACK has been preventing it.
>
> And mmaps include shmats: so unless the process specifies non-NULL
> shmaddr to attach at, it'll choose a randomized address for that too
> (subject to those various conditions).
>
> Which is indeed a further disincentive against shared page tables.
Or shared pagetables a disincentive to randomizing the mmap space ;-)
They're incompatible, but you could be left to choose one or the other
via config option.
3% on "a certain industry-standard database benchmark" (cough) is huge,
and we expect the benefit for PPC64 will be larger as we can share the
underlying hardware PTEs without TLB flushing as well.
M.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |