[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8bcf014e-f2a6-dcde-e37e-194be3537784@virtuozzo.com>
Date: Mon, 29 Aug 2016 12:18:08 +0300
From: Dmitry Safonov <dsafonov@...tuozzo.com>
To: Cyrill Gorcunov <gorcunov@...il.com>
CC: <linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
<luto@...capital.net>, <tglx@...utronix.de>, <hpa@...or.com>,
<x86@...nel.org>, <0x7f454c46@...il.com>, <oleg@...hat.com>,
<rostedt@...dmis.org>, <viro@...iv.linux.org.uk>
Subject: Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping
On 08/28/2016 11:14 PM, Cyrill Gorcunov wrote:
> On Thu, Aug 25, 2016 at 06:21:08PM +0300, Dmitry Safonov wrote:
>> I added here a new in-kernel fs with ramfs-like options.
>> Created vdso file in this fs (yet for testing, only 64-bit vdso).
>> Mapped this file to process's mm on setup_additional_pages.
>> Just for testing purpose it's done only for specific UID.
>>
>> Signed-off-by: Dmitry Safonov <dsafonov@...tuozzo.com>
>
Hi Cyrill,
> Dmitry, could you clarify please, why "old way" remains in the code?
> Even if RFC is not the new approach is supposing to completely remove
> old one? Or I miss something obvious?
Well, I left it for RFC, I think on post-RFC we can leave it as
cmd-param (alike vdso{64,32}_enabled) so it could be easily disabled if
it brokes something in userspace. I guess, that's preferred way to
introduce something like that.
--
Dmitry
Powered by blists - more mailing lists