From: Andreas Schwab <schwab@suse.de>
To: Phil Howard <phil-linux-kernel@ipal.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: EINTR vs ERESTARTSYS, ERESTARTSYS not defined
Date: 22 Nov 2001 16:15:40 +0100 [thread overview]
Message-ID: <jeherm7s6b.fsf@sykes.suse.de> (raw)
In-Reply-To: <20011122083623.A18057@vega.ipal.net>
In-Reply-To: <20011122083623.A18057@vega.ipal.net> (Phil Howard's message of "Thu, 22 Nov 2001 08:36:23 -0600")
Phil Howard <phil-linux-kernel@ipal.net> writes:
|> The accept() call does indeed return errno==ERESTARTSYS to user space
|> when coming back from signal handling, even though other things like
|> poll() return errno==EINTR. This would not really be a problem except
|> for this in include/linux/errno.h starting at line 6:
|>
|> +=============================================================================
|> | #ifdef __KERNEL__
|> |
|> | /* Should never be seen by user programs */
|> | #define ERESTARTSYS 512
|> | #define ERESTARTNOINTR 513
|> | #define ERESTARTNOHAND 514 /* restart if no handler.. */
|> | #define ENOIOCTLCMD 515 /* No ioctl command */
|> +=============================================================================
|>
|> So which way is it _supposed_ to be (so someone can patch things up
|> to make it consistent):
|>
|> 1. User space should never see ERESTARTSYS from any system call
Yes. The kernel either transforms it to EINTR, or restarts the syscall
when the signal handler returns.
|> 2. ERESTARTSYS can be seen from system call and is defined somewhere
|>
|> In user space I have to define __KERNEL__ to get programs to compile
|> when coded to know about all possible (valid?) values of errno from
|> system calls. As seen from strace:
strace is special here, because it gets more information than the traced
program would get.
|> +=============================================================================
|> | [pid 6453] accept(5, 0xbffff908, [16]) = ? ERESTARTSYS (To be restarted)
At this point the accept syscall hasn't actually finished yet, but rather
suspended to let the program execute the signal handler. As soon as the
signal handler returns the syscall will be restarted.
Andreas.
--
Andreas Schwab "And now for something
Andreas.Schwab@suse.de completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
next prev parent reply other threads:[~2001-11-22 15:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-22 14:36 EINTR vs ERESTARTSYS, ERESTARTSYS not defined Phil Howard
2001-11-22 15:15 ` Andreas Schwab [this message]
2001-11-22 18:05 ` Phil Howard
2001-11-26 19:59 ` Alan Cox
[not found] <20011122083623.A18057@vega.ipal.net.suse.lists.linux.kernel>
2001-11-22 15:28 ` Andi Kleen
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=jeherm7s6b.fsf@sykes.suse.de \
--to=schwab@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=phil-linux-kernel@ipal.net \
/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