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: <200809170950.58844.remi.denis-courmont@nokia.com>
Date:	Wed, 17 Sep 2008 09:50:58 +0300
From:	"Rémi Denis-Courmont" 
	<remi.denis-courmont@...ia.com>
To:	"ext Ulrich Drepper" <drepper@...hat.com>
Cc:	Michael Kerrisk <mtk.manpages@...glemail.com>,
	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

On Wednesday 17 September 2008 02:17:25 ext Ulrich Drepper, you wrote:
> 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.

Hmm. In a multithreaded program, it makes a lot of sense to use blocking I/O 
in general - not just blocking accept(). Of course, this assumes that there 
is only one file descriptor to wait on at a time. This is not necessarily 
true for I/O, nor is it for accept(). For instance, modern TCP servers should 
have an IPv4 and an IPv6 socket to accept() from...

If the code path is such that only one file descriptor is being waited on at a 
time, then using blocking I/O halves the number of syscalls, and thirds the 
number of context switch between hardware packet reception, and userland data 
deliver (3 to 1).

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

Right.

Then again... Why not recommend threaded programs to use sigwait() in a 
dedicated task and give up on the asynchronous signal handlers completely?

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
--
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/