linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Jeff Dike <jdike@karaya.com>
Cc: Andi Kleen <ak@muc.de>, john stultz <johnstul@us.ibm.com>,
	Linus Torvalds <torvalds@transmeta.com>,
	lkml <linux-kernel@vger.kernel.org>,
	george anzinger <george@mvista.com>,
	Stephen Hemminger <shemminger@osdl.org>,
	Bill Davidsen <davidsen@tmr.com>
Subject: Re: [PATCH] linux-2.5.43_vsyscall_A0
Date: Sun, 20 Oct 2002 02:15:40 +0200	[thread overview]
Message-ID: <20021020001540.GR23930@dualathlon.random> (raw)
In-Reply-To: <200210192343.SAA03642@ccure.karaya.com>

On Sat, Oct 19, 2002 at 06:43:28PM -0500, Jeff Dike wrote:
> andrea@suse.de said:
> > the sysctl would replace the vsyscall fixmap fixmap entry for the
> > current cpu enterely at switch_to time, I certainly don't want to add
> > not necessary branches in the core vsyscall code.  Doing it globally
> > is zerocost but it would probably need privilegies as said, per-task
> > could be more dynamic without privilegies and it would be an unlikely
> > branch added in switch_to, still a very low cost so still acceptable. 
> 
> If I'm understanding this (and reading the code) correctly, this would
> allow UML to specify that, for a given process, it should have a page of
> its choosing mapped into the vsyscall area.  Correct?

What I suggested is an arch specific syscall to shutdown vsyscalls
enterely for the current task and its childs, the vsyscall will call
into the real syscall with sysenter, and you will be able to
revirtualize gettimeofday/time like you do on x86 with ptrace.

> If so, I can go along with this.  It makes vsyscalls virtualizable, and thus
> available to UML, which needs them more than the other arches :-)

what do you mean that uml needs the vsyscalls more than the other archs?
You can use the vsyscall in-kernel by executing such syscall to turn the
vsyscall on and then turning them off again before returning to
the uml userspace. Remapping the vsyscall address is messy, we would
need to define a fallback place where to put them and we'd need to deal
with mapping your userspace bytecode in the place of the kernel code
containing the vsyscalls, it's an overdesign mess and it breaks so many
things about the mm design. I much prefer you to keep trapping the
gettimeofday and time with ptrace after shutting down the vsyscalls for
the current task, it's so much cleaner. The overhead of ptrace cannot be
your point, if that overhead is a showstopper uml isn't an option in the
first place.

> The one suggestion I'd make is to make it per-mm rather than per-task and 
> put it in switch_mm rather than switch_to.

doesn't make sense to me, the time of the day has nothing specific to
the mm. The fact that turning off the vsyscall involves an invlpg
doesn't matter either since they're global and they need the explicit
flush anyways, furthmore the per-task info would be in the task struct
not in the mm_struct. I don't see any point in binding a time-of-day
information with the mm. It sounds quite natural to make it a per-task
information not per-mm (also think strace/ptrace, maybe strace/ptrace
could like to still handle gettimeofday, but there's no point to force
all other threads to use the syscall just because we're playing with one
task in the process group).

Andrea

  reply	other threads:[~2002-10-20  0:11 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-18 22:57 [PATCH] linux-2.5.43_vsyscall_A0 john stultz
2002-10-18 22:58 ` [EXAMPLE CODE] linux-2.5.43_vsyscall_A0 john stultz
2002-10-19  3:52 ` [PATCH] linux-2.5.43_vsyscall_A0 Jeff Dike
2002-10-19  3:10   ` Andi Kleen
2002-10-19  4:49     ` Jeff Dike
2002-10-19  4:02       ` Andi Kleen
2002-10-19  4:16         ` Andrea Arcangeli
2002-10-20  2:59           ` Andi Kleen
2002-10-20  6:44             ` Elladan
2002-10-20  9:27               ` [discuss] " Andi Kleen
2002-10-20 10:58                 ` Elladan
2002-10-20 11:20                   ` Andi Kleen
2002-10-20 14:51             ` Andrea Arcangeli
2002-10-21 16:49               ` george anzinger
2002-10-20 13:19         ` Andreas Jaeger
2002-10-20 14:59           ` Andrea Arcangeli
2002-10-19  4:10       ` Andrea Arcangeli
2002-10-19  4:45         ` Andi Kleen
2002-10-19  5:01           ` Andrea Arcangeli
2002-10-19 23:43             ` Jeff Dike
2002-10-20  0:15               ` Andrea Arcangeli [this message]
2002-10-20  2:03                 ` Jeff Dike
2002-10-20  2:33                   ` Andrea Arcangeli
2002-10-22  5:07                     ` Jeff Dike
2002-10-22  4:15                       ` Andi Kleen
2002-10-22  4:29                         ` Andrew Morton
2002-10-22  9:39                           ` Alan Cox
2002-10-22 16:12                             ` Andrew Morton
2002-10-22  5:08                         ` Andrea Arcangeli
2002-10-22  5:27                       ` Andrea Arcangeli
2002-10-22  7:24                         ` Elladan
2002-10-22  7:40                           ` Andrea Arcangeli
2002-10-23  5:12                             ` Elladan
2002-10-23  5:43                               ` Elladan
2002-10-23 17:51                               ` Gerrit Huizenga
2002-10-21 15:43             ` Stephen Hemminger
2002-10-21 16:26               ` Andi Kleen
2002-10-21 17:10           ` john stultz
2002-10-19 19:14         ` Bill Davidsen
2002-10-20  1:50       ` Rik van Riel
2002-10-20  2:56         ` Andi Kleen
2002-10-24 11:24       ` Pavel Machek
2002-10-24 11:24     ` Pavel Machek
2002-10-19 22:36   ` Ton Hospel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021020001540.GR23930@dualathlon.random \
    --to=andrea@suse.de \
    --cc=ak@muc.de \
    --cc=davidsen@tmr.com \
    --cc=george@mvista.com \
    --cc=jdike@karaya.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shemminger@osdl.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).