From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756030Ab2LNCUX (ORCPT ); Thu, 13 Dec 2012 21:20:23 -0500 Received: from mail-lb0-f174.google.com ([209.85.217.174]:55839 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755689Ab2LNCUW (ORCPT ); Thu, 13 Dec 2012 21:20:22 -0500 MIME-Version: 1.0 In-Reply-To: <8c3585bc-fc7d-4826-913c-f4581494d91d@email.android.com> References: <1355343572-23074-1-git-send-email-stefani@seibold.net> <50C9148C.4040308@zytor.com> <1355378005.24283.11.camel@wall-e> <1d3061cb-76d0-4e42-9b75-a975b05384ec@email.android.com> <1355379433.24701.1.camel@wall-e> <1355383038.18653.2.camel@wall-e> <50CA6E4C.6000305@zytor.com> <50CA81A4.9040702@zytor.com> <50CA85BD.7070502@zytor.com> <8c3585bc-fc7d-4826-913c-f4581494d91d@email.android.com> From: Andy Lutomirski Date: Thu, 13 Dec 2012 18:20:00 -0800 Message-ID: Subject: Re: [PATCH] Add VDSO time function support for x86 32-bit kernel To: "H. Peter Anvin" Cc: criu@openvz.org, Stefani Seibold , linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, ak@linux.intel.com, aarcange@redhat.com, john.stultz@linaro.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote: > Wouldn't the vdso get mapped already and could be mremap()'d. If we really need more control I'd almost push for a device/filesystem node that could be mmapped the usual way. Hmm. That may work, but it'll still break ABI. I'm not sure that criu is stable enough yet that we should care. Criu people? (In brief summary: how annoying would it be if the vdso was no longer just a bunch of constant bytes that lived somewhere?) --Andy > > Andy Lutomirski wrote: > >>On Thu, Dec 13, 2012 at 5:49 PM, H. Peter Anvin wrote: >>> On 12/13/2012 05:42 PM, Andy Lutomirski wrote: >>>> >>>> The 64-bit/x32 case is currently very simple and fast because it >>uses >>>> absolute addressing. Admittedly, pcrel references are free, so >>>> changing this wouldn't cost much. For native, it'll be slower, but >>>> maybe no one cares. I seem to care about this more than anyone >>else, >>>> and I don't use 32 bit code. :) >>>> >>> >>> pcrel is actually cheaper than absolute addressing in 64-bit mode. >>> >>>> The benefit of switching is that the vdso code could be the same in >>>> all three cases. (Actually, it's even better than that. All of the >>>> VVAR magic could be the same in the vdso and the kernel -- the >>kernel >>>> linker script would just have to have an appropriate symbol to see >>the >>>> appropriate mapping.) >>>> >>>> >>>> This: >>>> >>>> __attribute__((visibility("hidden"))) int foo; >>>> >>>> int get_foo(void) >>>> { >>>> return foo; >>>> } >>>> >>>> generates a rip-relative access on 64 bits and GOTOFF on 32 bits. >>>> >>>> The only reason I didn't use a real symbol in the first place is >>>> because I couldn't figure out how to get gcc to emit an absolute >>>> relocation in pic code. >>> >>> Well, then, we wouldn't need to do that... this is starting to sound >>> like a significant win. >> >>How will this avoid breaking checkpoint/restore in userspace? If the >>vdso is not just plain old code, criu presumably needs to know about >>it. Should there be an arch_prctl(ARCH_MAP_VDSO, addr) to create a >>vdso mapping somewhere? >> >>--Andy > > -- > Sent from my mobile phone. Please excuse brevity and lack of formatting. -- Andy Lutomirski AMA Capital Management, LLC