All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Tony Luck <tony.luck@intel.com>
Subject: [RFC] making HAVE_SYSCALL_WRAPPERS universal (Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit)
Date: Mon, 21 Jan 2013 22:55:17 +0000	[thread overview]
Message-ID: <20130121225517.GV4939@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20130121023010.GR4939@ZenIV.linux.org.uk>

[linux-arch Cc'd]
On Mon, Jan 21, 2013 at 02:30:11AM +0000, Al Viro wrote:

> Neither do I, to be honest.  It might be saving us a few cycles on
> some architectures, but I'd like to see examples of that.  amd64
> doesn't seem to be one, at least...

*grumble*

OK, there is one problem - SYSCALL_ALIAS() is as arch-dependent as
cond_syscall().  As far as I can tell, with cond_syscall() we have
the following variants:
	1) alpha, mips
.weak foo
foo = sys_ni_syscall
	2) itanic, ppc
asmlinkage long x (void) __attribute__((weak,alias("sys_ni_syscall")))
	3) very common - most of the architectures
.weak foo
.set foo sys_ni_syscall
	3a) blackfin, h8300 - same as (3), except that asm symbols get
underscore prepended.
.weak _foo
.set _foo _sys_ni_syscall

For SYSCALL_ALIAS(foo,bar):
	1) alpha, mips
foo = bar
.globl foo
	2) ppc64
.globl foo
.set foo bar
.globl .foo
.set .foo .bar
[note that ppc64 cond_syscall ends up generating similar pair, only with
.globl replaced with .weak]
	3) s390, sparc, tile
.globl foo
.set foo bar

I suspect that (3) here should cover the same things as (3,3a) for
cond_syscalls(), with the same "prepend _" variation on blackfin/h8300.
I really wonder what's going on with ppc64, though - as far as I can
tell, .foo is the real function there, while foo is a OPD entry refering
to it.  Do we have anything similar on other architectures?  And what
about itanic?  After looking at the assembler generated by cond_syscall
there, I suspect that
foo# = bar#
.globl foo#
would be the right answer there, but I'd really like somebody familiar with
ia64 to confirm that...

Another question: what's the following comment from spu_callbacks.c about?
 * 4. They are optional and we can't rely on them being
 *    linked into the kernel. Unfortunately, the cond_syscall
 *    helper does not work here as it does not add the necessary
 *    opd symbols:
 *      mbind, mq_open, ipc, ...
What isn't added?  sys_ni_syscall is an OPD entry and weak aliases for it
*are* created.  That comment predates the conversion of cond_syscall()
definition to the current one; it used to be
.weak .foo
.set .foo .sys_ni_syscall
and that wouldn't have created the second alias; is it simply obsolete?
Note that mbind and friends still are not available to SPU; should that
be changed now that we can do that?

I've tried to sanitize cond_syscall/SYSCALL_ALIAS situation; the tree is in
git.kernel.org/pub/scm/linux/kernel/git/viro/signal experimental-syscalls
NOTE: this is absolutely untested and might very well blow up
on any number of architectures.

Review and comments would be very welcome.

  parent reply	other threads:[~2013-01-21 22:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-14  9:42 Issues with "x86, um: switch to generic fork/vfork/clone" commit Nicolas Dichtel
2013-01-19  6:38 ` Al Viro
2013-01-20  3:12   ` Al Viro
2013-01-20 20:53     ` Linus Torvalds
2013-01-20 21:28       ` Al Viro
2013-01-21  1:22       ` Al Viro
2013-01-21  1:40         ` Linus Torvalds
2013-01-21  2:30           ` Al Viro
2013-01-21  2:39             ` Linus Torvalds
2013-01-21  6:02               ` Al Viro
2013-01-21 22:55             ` Al Viro [this message]
2013-01-22 12:47               ` [RFC] making HAVE_SYSCALL_WRAPPERS universal (Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit) James Hogan
2013-01-22 12:47                 ` James Hogan
2013-01-22 14:23                 ` Al Viro
2013-01-22 13:16               ` Arnd Bergmann
2013-01-22 15:33               ` Arnd Bergmann
2013-01-21  9:00     ` Issues with "x86, um: switch to generic fork/vfork/clone" commit Nicolas Dichtel

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=20130121225517.GV4939@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=arnd@arndb.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.