paccept() oddity

paccept() oddity

[Michael Kerrisk]

Ulrich,

[
2.6.27-rc has paccept():

int paccept(int fd, struct sockaddr *sockaddr, socklen_t *addrlen,
         const sigset_t *sigmask, int setsize, int flags)
]

While considering the sigset argument for paccept() (see my previous
message), and testing that system call, I realized that there is a certain
oddness in the implementation of paccept().

Like accept(), paccept() automatically restarts if interrupted by a signal
handler that was established with the SA_RESTART flag.

On the other hand, pselect(), ppoll(), and epoll_pwait() are never restarted
if interrupted by a handler, even if the handler was established with
SA_RESTART.  (This is the same as with select(), poll(), and epoll_wait().)

It seems to me that it makes little sense to restart paccept(), especially in
the case where it is interrupted by a handler for one of the signals that is
in sigmask, since the whole point of calling paccept() is to block until a
connection is received, or until one of the signals in sigmask is caught().

How about changing paccept() so that it is never automatically restarted if
interrupted by a signal handler, regardless of the SA_RESTART flag.  (In
other words, paccept() should be consistent with pselect(), ppoll(), and
epoll_pwait(), rather than being consistent with accept().)  What are your
thoughts?

Cheers,

Michael

Re: paccept() oddity

[Michael Kerrisk]

Ulrich -- Ping!

On Wed, Aug 20, 2008 at 6:50 PM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
> Ulrich,
>
> [
> 2.6.27-rc has paccept():
>
> int paccept(int fd, struct sockaddr *sockaddr, socklen_t *addrlen,
>        const sigset_t *sigmask, int setsize, int flags)
> ]
>
> While considering the sigset argument for paccept() (see my previous
> message), and testing that system call, I realized that there is a certain
> oddness in the implementation of paccept().
>
> Like accept(), paccept() automatically restarts if interrupted by a signal
> handler that was established with the SA_RESTART flag.
>
> On the other hand, pselect(), ppoll(), and epoll_pwait() are never restarted
> if interrupted by a handler, even if the handler was established with
> SA_RESTART.  (This is the same as with select(), poll(), and epoll_wait().)
>
> It seems to me that it makes little sense to restart paccept(), especially
> in
> the case where it is interrupted by a handler for one of the signals that is
> in sigmask, since the whole point of calling paccept() is to block until a
> connection is received, or until one of the signals in sigmask is caught().
>
> How about changing paccept() so that it is never automatically restarted if
> interrupted by a signal handler, regardless of the SA_RESTART flag.  (In
> other words, paccept() should be consistent with pselect(), ppoll(), and
> epoll_pwait(), rather than being consistent with accept().)  What are your
> thoughts?
>
> Cheers,
>
> Michael
>
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: paccept() oddity

[Michael Kerrisk]

Ulrich -- ping!

---------- Forwarded message ----------
From: Michael Kerrisk <mtk.manpages@googlemail.com>
Date: Aug 29, 2008 10:45 PM
Subject: Re: paccept() oddity
To: Ulrich Drepper <drepper@redhat.com>
Cc: Davide Libenzi <davidel@xmailserver.org>, Andrew Morton
<akpm@linux-foundation.org>, lkml <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>


Ulrich -- Ping!

On Wed, Aug 20, 2008 at 6:50 PM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
> Ulrich,
>
> [
> 2.6.27-rc has paccept():
>
> int paccept(int fd, struct sockaddr *sockaddr, socklen_t *addrlen,
>        const sigset_t *sigmask, int setsize, int flags)
> ]
>
> While considering the sigset argument for paccept() (see my previous
> message), and testing that system call, I realized that there is a certain
> oddness in the implementation of paccept().
>
> Like accept(), paccept() automatically restarts if interrupted by a signal
> handler that was established with the SA_RESTART flag.
>
> On the other hand, pselect(), ppoll(), and epoll_pwait() are never restarted
> if interrupted by a handler, even if the handler was established with
> SA_RESTART.  (This is the same as with select(), poll(), and epoll_wait().)
>
> It seems to me that it makes little sense to restart paccept(), especially
> in
> the case where it is interrupted by a handler for one of the signals that is
> in sigmask, since the whole point of calling paccept() is to block until a
> connection is received, or until one of the signals in sigmask is caught().
>
> How about changing paccept() so that it is never automatically restarted if
> interrupted by a signal handler, regardless of the SA_RESTART flag.  (In
> other words, paccept() should be consistent with pselect(), ppoll(), and
> epoll_pwait(), rather than being consistent with accept().)  What are your
> thoughts?
>
> Cheers,
>
> Michael
>
>



--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: paccept() oddity

[Andrew Morton]

On Wed, 20 Aug 2008 18:50:54 +0200 Michael Kerrisk <mtk.manpages@googlemail.com> wrote:

> Ulrich,
> 
> [
> 2.6.27-rc has paccept():
> 
> int paccept(int fd, struct sockaddr *sockaddr, socklen_t *addrlen,
>          const sigset_t *sigmask, int setsize, int flags)
> ]
> 
> While considering the sigset argument for paccept() (see my previous
> message), and testing that system call, I realized that there is a certain
> oddness in the implementation of paccept().
> 
> Like accept(), paccept() automatically restarts if interrupted by a signal
> handler that was established with the SA_RESTART flag.
> 
> On the other hand, pselect(), ppoll(), and epoll_pwait() are never restarted
> if interrupted by a handler, even if the handler was established with
> SA_RESTART.  (This is the same as with select(), poll(), and epoll_wait().)
> 
> It seems to me that it makes little sense to restart paccept(), especially in
> the case where it is interrupted by a handler for one of the signals that is
> in sigmask, since the whole point of calling paccept() is to block until a
> connection is received, or until one of the signals in sigmask is caught().
> 
> How about changing paccept() so that it is never automatically restarted if
> interrupted by a signal handler, regardless of the SA_RESTART flag.  (In
> other words, paccept() should be consistent with pselect(), ppoll(), and
> epoll_pwait(), rather than being consistent with accept().)  What are your
> thoughts?
> 

Oleg, Roland: would you have the time to ponder the above, please?

If we can't get this nailed down very soon I'd suggest that we disable
sys_paccept() for 2.6.27.  We don't want to be releasing a new system
call into 2.6.27 if there are doubts surrounding its userspace-visible
behaviour.

Thanks.

Re: paccept() oddity

[Roland McGrath]

I don't see any rationale for changing paccept to be an oddball special
case in its EINTR behavior.

select/poll are special cases historically, and that's why the principle of
least astonishment makes it best for pselect/ppoll to match their behavior.

The same principle makes it highly dubious to have paccept differ from
accept in such a subtlety.  I don't see any reason to want it, anyway.
An application that wants to see EINTR can just use sigaction to clear
SA_RESTART.

Frankly, I don't see the rationale for rolling the implicit sigprocmask
into paccept at all.  accept is analogous to read or other i/o calls,
not to select/poll.  It's not any normal plan to fiddle blocked signals
around a blocking i/o call.  Instead, programs use (p)select/poll (and
sometimes also O_NONBLOCK) to manage the blocking and waking up.  Then
when the program finally calls accept, it knows it won't block.  The
atomic signal machinery makes sense for pselect/ppoll to help manage the
corner cases of blocking/wakeup in event loops.  It makes no more sense
to roll blocked signal set changes into accept than it would to have
read, write, etc. all take a sigset_t and do that.


Thanks,
Roland

Re: paccept() oddity

[Michael Kerrisk]

Roland,

Thanks for having a look at this.

On 9/11/08, Roland McGrath <roland@redhat.com> wrote:
> I don't see any rationale for changing paccept to be an oddball special
> case in its EINTR behavior.
>
> select/poll are special cases historically, and that's why the principle of
> least astonishment makes it best for pselect/ppoll to match their behavior.

I agree on the idea of least astonishment.  I just differ on where
greater astonishment is considered to lie.  If I'm making a system
call one of whose arguments is a mask of signals that the system call
should wait for, then I expect the system call to return, rather than
restart, if that signal is delivered, regardless of SA_RESTART.  This
is the behaviour of pselect(), which seems perfectly reasonable, and
happens to coincide with historical select() EINTR behavior.

But, perhaps all of this is moot, given the point you raise below (and
which I already raised with Ulrich)...

> The same principle makes it highly dubious to have paccept differ from
> accept in such a subtlety.  I don't see any reason to want it, anyway.
> An application that wants to see EINTR can just use sigaction to clear
> SA_RESTART.
>
> Frankly, I don't see the rationale for rolling the implicit sigprocmask
> into paccept at all.  accept is analogous to read or other i/o calls,
> not to select/poll.

That is precisely the other point about paccept() that I've already
raised, which drew no response from Ulrich:

http://thread.gmane.org/gmane.linux.kernel/723952/focus=728786
(I'll add you to the CC on that thread.)

> It's not any normal plan to fiddle blocked signals
> around a blocking i/o call.  Instead, programs use (p)select/poll (and
> sometimes also O_NONBLOCK) to manage the blocking and waking up.  Then
> when the program finally calls accept, it knows it won't block.  The
> atomic signal machinery makes sense for pselect/ppoll to help manage the
> corner cases of blocking/wakeup in event loops.  It makes no more sense
> to roll blocked signal set changes into accept than it would to have
> read, write, etc. all take a sigset_t and do that.

Agreed.

Given that adding a sigset to accept():

* seems unnecessary (i.e., it provides no functionality that we can't
get otherwise), * is inconsistent with other I/O APIs that don't have
a sigset argument (e.g., read(), write(), redvfrom(), open(), etc.)
* currently (IMO) provides questionable semantics around EINTR

I'd argue in favour of eliminating this syscall in favour of a simpler:

accept4(int fd, struct sockaddr *sa, socklen_t *salen, ind flags);

and in the meantime disabling sys_paccept() in -rc.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html