[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVaKxY22=4S=mWhUgQ--H77kqnay5G8f847H=Cfper86w@mail.gmail.com>
Date: Thu, 30 Jan 2014 09:57:34 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Stefani Seibold <stefani@...bold.net>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Greg KH <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Andi Kleen <ak@...ux.intel.com>,
Andrea Arcangeli <aarcange@...hat.com>,
John Stultz <john.stultz@...aro.org>,
Pavel Emelyanov <xemul@...allels.com>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
andriy.shevchenko@...ux.intel.com, Martin.Runge@...de-schwarz.com,
Andreas.Brief@...de-schwarz.com
Subject: Re: [PATCH 0/4] Add 32 bit VDSO time function support
On Thu, Jan 30, 2014 at 7:52 AM, Stefani Seibold <stefani@...bold.net> wrote:
> Am Donnerstag, den 30.01.2014, 07:31 -0800 schrieb H. Peter Anvin:
>> On 01/30/2014 02:49 AM, stefani@...bold.net wrote:
>> > The VDSO page for a 32 bit resided now on 0xffffc000, followed by the VVAR and
>> > HPET page.
>>
>> Any reason to not move the vdso base page to the top, in order to avoid
>> breaking broken applications? It seems a fairly innocuous shuffle...
>> probably little gain, but very little cost.
>>
>> -hpa
>>
>
> The reason is that i get need than an additional VMA for HPET and VVAR.
>
> I seen no break of applications since the __FIXADDR_TOP is not on a fix
> place. Lguest, XEN, OPLC and the reservetop Kernel Parameter will change
> the VDSO Page Address.
By definition there aren't any broken users of the new functions,
because there aren't any users at all. So... should we start
randomizing this thing from the beginning?
Also, since the VVAR page has a real vma, should something be done to
prevent mprotect or ptrace from COWing it? Users will be rather
surprised if it suddenly stops updating.
Finally, this might be the time to kill off the userspace mapping of
the HPET. I suspect that there are few if any machines for which the
HPET is fast enough that avoiding a syscall matters at all. (On my
box at work, reading the HPET takes ~500 nanoseconds. I can do a lot
of syscalls in that amount of time.)
>
> - Stefani
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists