public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ulrich Drepper <drepper@redhat.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: john stultz <johnstul@us.ibm.com>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch
Date: Thu, 29 Jan 2004 21:09:39 -0800	[thread overview]
Message-ID: <4019E713.1010107@redhat.com> (raw)
In-Reply-To: <20040130041708.GA2816@mail.shareable.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jamie Lokier wrote:

> Because I am sure you don't agree :) this is how to implement it:

You are right, nothing like this is in the least acceptable.  Text
relocations are completely off-limits.  Depending on prelinking being
available is not acceptable.

Your entire scheme is based on this and therefore not worth the bits
used to store it.  Your understanding of how and where syscalls are made
and how ELF works is flawed.  There is no "group the syscalls nicely
together", they are all over the place, inlined in many places.  There
is no concept of weak aliases in dynamic linking.  Finding all the
"aliases" requires lookups by name for now more than 200 syscall names
and growing.  Prelinking can help if it is wanted, but if the vDSO
address is changed or randomized (this is crucial I'd say) or the vDSO
is not setup up for a process, the full price has to be paid.  With
every kernel change the whole prelinking has to be redone.  We kept the
dependencies with the vDSO minimal exactly because it is not a normal DSO.


This proposed method is many times more expensive for all processes
which do not call the same syscalls many many times over.  Every single
name lookup costs dearly, the larger the application the more expensive.
 The startup times will probably increase ten-fold or moreif prelinking
isn't available or disabled because one or more of the linked in objects
changed.  You cannot say that it's OK the system becomes unusable if
prelinking isn't used.  There are always programs which are not
prelinked because they cannot be prelinked, they are newly
installed/updated, or because prelinking isn't done at all to increase
security.  No method must perform measurably worse than normal,
non-prelinked code does now.


And I am not in the least convinced that this one direct jump from a
tainted page is faster then the indirect jump from read-only memory.
You increase the memory usage of the system.  You'd need a couple of
additional pages in each process' glibc which are not shared.


If gettimeofday() is the only optimized syscall, just add a simple

  cmp $__NR_gettimeofday, %eax
  je  __vsyscall_gettimeofday

to the __kernel_vsyscall code.  With correct static branch prediction
you'll not be able to measure the effect.  The correct way is IMO to
completely hide the optimizations since otherwise the increased
dependencies between kernel and libc only create more friction and cost
and loss of speed.


- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAGecT2ijCOnn/RHQRAkBwAJ9f4gKLdVeUpA4kbfxwb1Y4oiJmdQCghg7e
JK8NvNy1GyEJXtE5pGJB1IU=
=D0yc
-----END PGP SIGNATURE-----

  reply	other threads:[~2004-01-30  5:10 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-29  2:46 [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch john stultz
2004-01-29  5:06 ` Ulrich Drepper
2004-01-29 13:26   ` Jamie Lokier
2004-01-29 18:05     ` Ulrich Drepper
2004-01-29 19:15       ` Jamie Lokier
2004-01-29 23:59         ` john stultz
2004-01-30  0:40           ` Ulrich Drepper
2004-01-30  0:31         ` Ulrich Drepper
2004-01-30  4:17           ` Jamie Lokier
2004-01-30  5:09             ` Ulrich Drepper [this message]
2004-01-30  9:29               ` Ingo Molnar
2004-02-03  4:38                 ` Ulrich Drepper
2004-01-30 17:34               ` Jamie Lokier
2004-01-30  8:33             ` Jakub Jelinek
2004-01-30 17:21               ` Jamie Lokier
2004-01-31  0:10     ` Eric W. Biederman
2004-01-31  2:41       ` Jamie Lokier
2004-01-31  5:54         ` Eric W. Biederman
2004-02-01  1:28   ` Andrea Arcangeli
2004-02-03  4:35     ` Ulrich Drepper
2004-02-03  5:34       ` Andrea Arcangeli
2004-02-03  8:52       ` Jamie Lokier
2004-02-03 16:25         ` Andrea Arcangeli
2004-02-03 17:37           ` Jamie Lokier
2004-02-03 18:10             ` Andrea Arcangeli
2004-02-03 18:23               ` Jamie Lokier
2004-02-03 18:34                 ` Andrea Arcangeli
2004-01-31  0:17 ` Eric W. Biederman
2004-01-31  2:20   ` john stultz
     [not found] <1075344395.1592.87.camel@cog.beaverton.ibm.com.suse.lists.linux.kernel>
     [not found] ` <401894DA.7000609@redhat.com.suse.lists.linux.kernel>
     [not found]   ` <20040201012803.GN26076@dualathlon.random.suse.lists.linux.kernel>
     [not found]     ` <401F251C.2090300@redhat.com.suse.lists.linux.kernel>
     [not found]       ` <20040203085224.GA15738@mail.shareable.org.suse.lists.linux.kernel>
     [not found]         ` <20040203162515.GY26076@dualathlon.random.suse.lists.linux.kernel>
     [not found]           ` <20040203173716.GC17895@mail.shareable.org.suse.lists.linux.kernel>
     [not found]             ` <20040203181001.GA26076@dualathlon.random.suse.lists.linux.kernel>
     [not found]               ` <20040203182310.GA18326@mail.shareable.org.suse.lists.linux.kernel>
2004-02-04  2:27                 ` Andi Kleen
2004-02-04  2:40                   ` Andrea Arcangeli
2004-02-04  4:21                   ` Jamie Lokier
2004-02-05 21:43                     ` Andrea Arcangeli
2004-02-06  4:15                       ` Rik van Riel
2004-02-06  4:28                         ` Andrea Arcangeli
2004-02-06  9:23                           ` Ulrich Drepper
2004-02-06 15:49                             ` Andrea Arcangeli
2004-02-07  0:37                               ` Ulrich Drepper
2004-02-07  2:19                                 ` Andrea Arcangeli
2004-02-07  3:37                                   ` Daniel Jacobowitz
2004-02-07  4:36                                     ` Andrea Arcangeli
2004-02-07  4:53                                       ` Jamie Lokier

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=4019E713.1010107@redhat.com \
    --to=drepper@redhat.com \
    --cc=jamie@shareable.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /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