linux-kernel - Rationale for paccept() sigset argument?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Aug 2008 18:50:12 +0200
From:	Michael Kerrisk <mtk.manpages@...glemail.com>
To:	Ulrich Drepper <drepper@...hat.com>
CC:	Davide Libenzi <davidel@...ilserver.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jakub Jelinek <jakub@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Rationale for paccept() sigset argument?

Ulrich,

I'll need to cover this point in the man pages, and the rationale still isn't
clear to me, so I'll check it with you...

2.6.27-rc has paccept():

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

paccept() blocks until either a connection is received on fd, or a signal is
sigmask() is caught.

What is the rationale for the sigset argument of paccept()?

For pselect()/ppoll()/epoll_pwait(), the sigset argument allows us to deal
with a not uncommon situation: waiting for both signals and (multiple) file
descriptors.  (The alternative is the self-pipe trick, which requires more
programming effort.)

However, do we really need this argument for paccept()?  I ask this for the
following reasons:

* This seems to be special casing for accept().  But there are other system
calls (e.g., open(), connect(), recvfrom()) that are similar, in the sense
that they may wait on a file descriptor, for which there is no [perceived
need for a] sigset argument.

* It seems to me that any case where we might want to use paccept() could be
equivalently dealt with using the existing pselect()/ppoll()/epoll_pwait()
followed by a conventional accept() if the listening file descriptor
indicates as ready.  (But perhaps I missed something?)

Can you please explain why we need this special case for [p]accept()?

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/