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: <cfd18e0f0809161724w646b1e21s466afe74579f12e0@mail.gmail.com>
Date:	Wed, 17 Sep 2008 02:24:32 +0200
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	"Ulrich Drepper" <drepper@...hat.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>,
	"Evgeniy Polyakov" <johnpol@....mipt.ru>
Subject: Re: sys_paccept: disable paccept() until API design is resolved

On Wed, Sep 17, 2008 at 1:17 AM, Ulrich Drepper <drepper@...hat.com> wrote:
> -----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.

What is "it"?  What "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.

I'm assuming that you mean this text from another thread:

[[
> accept, like select/poll, is used often as a function to dealy
> operation.  Unlike read, recv, etc, which are handled using O_NONBLOCK
> and select/poll.  pselect/ppoll do not really have a sigset parameter
> to handle signals in general.  You use it to enable special handling
> in case of blocking.  Example: if you want to implement userlevel
> context switching, you dedicate a signal to wake up any blocked
> thread.  Since accept falls more into the same category than poll,
> this means the sigset parameter is justified.  In theory we could add
> it to all functions but there is no reason to do this without any
> other reason to change the interface.
]]

I find this very difficult to understand -- what makes it difficult is
the wording of the explanation.  Could you please take some time to
(much) more clearly explain the above, and especially to very clearly
explain why paccept() serves needs that can't be dealt with by
pseelect/ppoll/epoll_pwait + accept().

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

I already clearly stated it was my opinion, and pointed out that
Roland had a diffferent opinion.  Really, what is your point?

> 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

[CC=+ Evgeniy Polyakov <johnpol@....mipt.ru>]

But, what are you trying to say in pointing out that this wasn't your idea?

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

No.  You still have given no clear explanation.  Please give one.

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/