• M
    sys_paccept: disable paccept() until API design is resolved · 2d4c8266
    Michael Kerrisk 提交于
    The reasons for disabling paccept() are as follows:
    
    * The API is more complex than needed.  There is AFAICS no demonstrated
      use case that the sigset argument of this syscall serves that couldn't
      equally be served by the use of pselect/ppoll/epoll_pwait + traditional
      accept().  Roland seems to concur with this opinion
      (http://thread.gmane.org/gmane.linux.kernel/723953/focus=732255).  I
      have (more than once) asked Ulrich to explain otherwise
      (http://thread.gmane.org/gmane.linux.kernel/723952/focus=731018), but he
      does not respond, so one is left to assume that he doesn't know of such
      a case.
    
    * The use of a sigset argument is not consistent with other I/O APIs
      that can block on a single file descriptor (e.g., read(), recv(),
      connect()).
    
    * The behavior of paccept() when interrupted by a signal is IMO strange:
      the kernel restarts the system call if SA_RESTART was set for the
      handler.  I think that it should not do this -- that it should behave
      consistently with paccept()/ppoll()/epoll_pwait(), which never restart,
      regardless of SA_RESTART.  The reasoning here is that the very purpose
      of paccept() is to wait for a connection or a signal, and that
      restarting in the latter case is probably never useful.  (Note: Roland
      disagrees on this point, believing that rather paccept() should be
      consistent with accept() in its behavior wrt EINTR
      (http://thread.gmane.org/gmane.linux.kernel/723953/focus=732255).)
    
    I believe that instead, a simpler API, consistent with Ulrich's other
    recent additions, is preferable:
    
    accept4(int fd, struct sockaddr *sa, socklen_t *salen, ind flags);
    
    (This simpler API was originally proposed by Ulrich:
    http://thread.gmane.org/gmane.linux.network/92072)
    
    If this simpler API is added, then if we later decide that the sigset
    argument really is required, then a suitable bit in 'flags' could be added
    to indicate the presence of the sigset argument.
    
    At this point, I am hoping we either will get a counter-argument from
    Ulrich about why we really do need paccept()'s sigset argument, or that he
    will resubmit the original accept4() patch.
    Signed-off-by: NMichael Kerrisk <mtk.manpages@gmail.com>
    Cc: David Miller <davem@davemloft.net>
    Cc: Davide Libenzi <davidel@xmailserver.org>
    Cc: Alan Cox <alan@redhat.com>
    Cc: Ulrich Drepper <drepper@redhat.com>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Roland McGrath <roland@redhat.com>
    Cc: Oleg Nesterov <oleg@tv-sign.ru>
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    2d4c8266
socket.c 58.7 KB