linux-kernel - Re: sys_paccept: disable paccept() until API design is resolved

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48D03E85.9030808@redhat.com>
Date:	Tue, 16 Sep 2008 16:17:25 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	Michael Kerrisk <mtk.manpages@...glemail.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Davide Libenzi <davidel@...ilserver.org>,
	Alan Cox <alan@...hat.com>, Jakub Jelinek <jakub@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	netdev <netdev@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...sign.ru>, Christoph Hellwig <hch@....de>
Subject: Re: sys_paccept: disable paccept() until API design is resolved

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Kerrisk wrote:
> The patch below disables the new sys_paccept() for now.  Please
> apply for 2.6.27-rc, so that we do not release this API into
> the wild before a conclusion has been reached about its design.

There is no reason for that.


> 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 +

It would unnecessarily require programs to be changed.  I've explained
that programs cannot efficiently use accept() and poll() when multiple
threads are involved.  This means in these situations you'll find a
single thread handling only the accept() calls.


> * 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()).

This is because none of the other interfaces had (so far) be revised.
With this flawed argumentation you'd prevent any program ever to be made.


> * The behavior of paccept() when interrupted by a signal is IMO
>   strange:

You use your own opinion as the deciding factor?  The behavior differs
from other uses but is consistent with the accept() behavior.


> 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);

The signal set wasn't actually my idea.  See:

http://marc.info/?l=linux-kernel&m=120909788728078&w=2


> 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.

I have explained the need already. you just chose to ignore it.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjQPoQACgkQ2ijCOnn/RHTNZwCfaXdw5Yhy/chAUMqR2kZE8Rsm
wzUAnA7PtvODGyAMeahl44+mqasqGS1U
=Gh2E
-----END PGP SIGNATURE-----
--
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/