[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F19D43167@ORSMSX108.amr.corp.intel.com>
Date: Wed, 19 Sep 2012 20:50:51 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Andy Lutomirski <luto@...capital.net>,
John Stultz <john.stultz@...aro.org>
CC: Richard Cochran <richardcochran@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Paul Mackerras <paulus@...ba.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Paul Turner <pjt@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Prarit Bhargava <prarit@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: RE: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/rounding
issue in timekeeping core
> Does anything except the vDSO actually use the vDSO data page? It's
> mapped as part of the vDSO image (i.e. at a non-constant address), and
> it's not immediate obvious how userspace would locate that page.
Just for reference - on ia64 the address of the entry point for the magic
fast system call page is passed to each applications via the "auxv" structure
that exec(2) drops at the top of stack after args/env in the AT_SYSINFO
entry. Apps look for it to find out where to jump for fast system call entry
(if it isn't there, they fall back to regular slow syscall path).
Same method could be used to provide the address of a magic read-only
for users page that kernel fills with stuff for simple system calls.
-Tony
--
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