public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: Lennert Buytenhek <buytenh@math.leidenuniv.nl>,
	Davide Libenzi <davidel@xmailserver.org>,
	linux-kernel@vger.kernel.org
Subject: Re: {sys_,/dev/}epoll waiting timeout
Date: Tue, 28 Jan 2003 21:36:21 +0000	[thread overview]
Message-ID: <20030128213621.GA29036@bjl1.asuk.net> (raw)
In-Reply-To: <Pine.LNX.4.33L2.0301281139570.30636-100000@dragon.pdx.osdl.net>

Randy.Dunlap wrote:
> On Wed, 22 Jan 2003, Jamie Lokier wrote:
> 
> | ps.  sys_* system-call functions should never return "int".  They
> | should always return "long" or a pointer - even if the user-space
> | equivalent returns "int".  Take a look at sys_open() for an example.
> | Technical requirement of the system call return path on 64-bit targets.
> 
> Is this a blanket truism?  For all architectures?

I believe so, for all architecture-independent syscall functions.
(And architecture-dependent on those that need it -- see end of this
message).

Linus mentioned it in passing in the recent x86 vsyscall threads.  I
have never seen it mentioned before.  I always assumed that returned
longs were due to sloppy programming :)

If you look at the syscall return paths on the 64-bit architectures,
some of them always check the 64-bit return value register to see if
it is negative.  If so, they set an error flag, which is what
userspace uses to decide whether to return -1, rather than checking if
the return value is >= -4096 (or >= -125, architecture implementations vary).

This convoluted ABI allows those architectures to return full 64-bit
values as legitimate values, which is needed for... ptrace(), only on
those architecture of course.

The question is therefore are "int" values returned from C functions
sign-extended to 64 bits?  I don't know, maybe it varies between
architectures -- for all I know it happens to work on all the
supported 64-bit architectures -- but I believe this is the reason why
"long" (or equivalent, e.g. "ssize_t") and pointer types are
_supposed_ to be the only permitted return types from syscall
functions.

> Should current (older/all) syscalls be modified, or should only new ones
> (like epoll) be corrected?

All of them.

Here's a partial list of functions which return int from 2.5.49, based
on parsing Alpha, ARM, CRIS, IA64 and x86_64 trees:

	sys_set_tid_address
	sys_futex
	sys_sched_setaffinity
	sys_sched_getaffinity
	sys_remap_file_pages
	sys_epoll_create
	sys_epoll_ctl
	sys_epoll_wait
	sys_lookup_dcookie
	sys_pause

As far as I can guess from reading the GCC sources, 32-bit return
values aren't sign extended on x86_64 and IA64, but they are on all
the other Linux-supported 64-bit architectures (I could be mistaken
about this).  Of x86_64 and IA64, only the IA64 syscall return path
tests if the return value register is negative.

Which suggests that all the architectures are fine with all these
"int" returns, except IA64.

Curiously, IA64's own sys_perfmonctl() returns int.

-- Jamie

  reply	other threads:[~2003-01-28 21:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-22  6:55 {sys_,/dev/}epoll waiting timeout Lennert Buytenhek
2003-01-22  8:03 ` Jamie Lokier
2003-01-22 12:46   ` Ed Tomlinson
2003-01-22 13:20     ` Jamie Lokier
2003-01-22 19:14       ` Randy.Dunlap
2003-01-22 19:34         ` Jamie Lokier
2003-01-22 19:32           ` Randy.Dunlap
2003-01-23 14:07   ` Davide Libenzi
2003-01-23 15:43     ` Jamie Lokier
2003-01-23 17:27       ` Mark Mielke
2003-01-23 18:28         ` Jamie Lokier
2003-01-23 20:40           ` Mark Mielke
2003-01-23 22:18             ` Jamie Lokier
2003-01-24 14:41               ` Andreas Schwab
2003-01-25  1:08               ` Davide Libenzi
2003-01-27 21:27               ` bug in select() (was Re: {sys_,/dev/}epoll waiting timeout) Bill Rugolsky Jr.
2003-01-27 22:52                 ` Davide Libenzi
2003-01-28  9:45                   ` Jamie Lokier
2003-01-28 10:52                     ` Mark Mielke
2003-01-28 21:39                       ` Jamie Lokier
2003-01-28 22:15                     ` Davide Libenzi
2003-01-28 19:42   ` {sys_,/dev/}epoll waiting timeout Randy.Dunlap
2003-01-28 21:36     ` Jamie Lokier [this message]
2003-01-28 21:44       ` David Mosberger
     [not found] <20030122080322.GB3466@bjl1.asuk.net.suse.lists.linux.kernel>
     [not found] ` <Pine.LNX.4.33L2.0301281139570.30636-100000@dragon.pdx.osdl.net.suse.lists.linux.kernel>
     [not found]   ` <20030128213621.GA29036@bjl1.asuk.net.suse.lists.linux.kernel>
2003-01-28 21:55     ` Andi Kleen
2003-01-28 22:24       ` Davide Libenzi
2003-01-28 22:39         ` Andi Kleen
2003-01-28 23:00           ` Davide Libenzi

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=20030128213621.GA29036@bjl1.asuk.net \
    --to=jamie@shareable.org \
    --cc=buytenh@math.leidenuniv.nl \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.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