[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0f5cd36f-0b03-d8ae-eeea-98d68bfd3b7b@virtuozzo.com>
Date: Fri, 3 Jun 2016 13:03:23 +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>,
<xemul@...tuozzo.com>, <khorenko@...tuozzo.com>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH 2/6] x86/vdso: introduce do_map_vdso() and vdso_type enum
On 06/03/2016 12:50 PM, Cyrill Gorcunov wrote:
> On Wed, Jun 01, 2016 at 04:11:33PM +0300, Dmitry Safonov wrote:
>> Make in-kernel API to map vDSO blobs on x86.
>>
>> Cc: Andy Lutomirski <luto@...nel.org>
>> Cc: Ingo Molnar <mingo@...hat.com>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: "H. Peter Anvin" <hpa@...or.com>
>> Signed-off-by: Dmitry Safonov <dsafonov@...tuozzo.com>
>
> Hi! Sorry for delay in reply. Dima, here is a moment I somehow missing:
> when do_map_vdso is called it is implied that old vdso is unmapped already,
> or both can be present in the system?
>
Both can be present. There are some limitations: if first vDSO was
32-bit, syscalls through it wouldn't work, only on the last mapped.
It's because of mm->context.vdso pointer, which for 32-bit vDSO
should point on it. (and this code make it point to a new mapped vDSO)
On RFC I did patch that unmaps previous vDSO, but I have though
it's better to simplify this code and drop unmapping.
Powered by blists - more mailing lists