Message-ID: <439DE488.7040703@BitWagon.com>
Date: Mon, 12 Dec 2005 12:58:48 -0800
From: John Reiser <jreiser@BitWagon.com>
Organization: -
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
MIME-Version: 1.0
To: Ingo Oeser <ioe-lkml@rameria.de>
CC: linux-kernel@vger.kernel.org
Subject: Re: control placement of vDSO page
References: <439D9767.2000208@BitWagon.com> <200512122039.29799.ioe-lkml@rameria.de>
In-Reply-To: <200512122039.29799.ioe-lkml@rameria.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1121
Lines: 27

Ingo Oeser wrote:
> On Monday 12 December 2005 16:29, John Reiser wrote:
> 
>>Possible solution: a new system call  move_vdso(old_addr, new_addr, flags).
>>Check that current vDSO was at old_addr, else error.  Change vDSO page
>>under control of flags like in mmap(): new_addr is hint (place to start
>>search) or required address if MAP_FIXED.  Return value is new vDSO address.
>>
> 
> 
> What about special casing the vDSO page in mremap() ?

Hmmm...  Where can the new address [hint] be given in the call to
mremap(old_address, old_size, new_size, flags) ?
Also: probably the size is constant, perhaps even unknown to the user.
It would be nice if the old page need not exist (could have been
mmap()ed over) at the time of the move, although the proposed
move_vdso() does ask for what the old_addr used to be, as a check
on validity.

-- 
John Reiser, jreiser@BitWagon.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/