linux-kernel - Re: epoll design problems with common fork/exec patterns

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: <472311B8.5080408@cosmosbay.com>
Date:	Sat, 27 Oct 2007 12:23:52 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Marc Lehmann <linux-kernel@....eu>
CC:	linux-kernel@...r.kernel.org,
	Davide Libenzi <davidel@...ilserver.org>
Subject: Re: epoll design problems with common fork/exec patterns

Marc Lehmann a écrit :
> On Sat, Oct 27, 2007 at 11:22:25AM +0200, Eric Dumazet <dada1@...mosbay.com> wrote:
> 
>> If such a bug exists on your kernel, please fill a complete bug report, 
>> giving details.
> 
> As this behaviour is clearly documented in the epoll manpage, why do you
> think it is a bug? I think its fairly bad, but at least tis documented as
> the behaviour it should be:
> 
>     Q6     Will the close of an fd cause it to be removed from all epoll sets automatically?
>     A6     Yes.

Answer : epoll documentation cannot explain the full semantic of file 
descriptors, or difference between user side (file descriptors) and kernel 
side (files and fds)
Or should, since you had problems. But then, if the epoll documentation has to 
document the full Unix/Linux files semantic, nobody will read it.

The 'close' of a file is not close(fd) :)
But : the last close() so that underlying file refcount is 0

example 1)

fd = open("somefile", ...)
fd1 = dup(fd);
epoll_add_in_my_set(fd1);/* setup epoll work on fd1 */
{do_something;}
close(fd1); /* this is not the last close and will NOT close 'somefile' */
             /* It wont be removed from epoll sets NOW */


close(fd); /* oh yes, this one is the real 'file close', now we perform epoll 
cleanups */

epoll has to deal with files, but documentation is a User side documentation, 
so has to use 'file descriptors'. So everything that plays with the file 
descriptor table can make the thing complex to understand/document. 
(fork()/dup()/close()/exit()/exec()....)

example 2)

int pfd[2];
pipe(pfd);
epoll_add_in_my_set(pfd[0]);/* setup epoll work on pfd[0] for example */
pid = fork();
if (pid == 0) {


    close(pfd[0]); /* this is not the last close and will NOT close pipe */
	/* epoll has NO WAY to perform some cleanup at this stage */

    close(pfd[1]); /* this not the last close and will NOT close the pipe*/
    _exit(0);
    }
close(pfd[1]);
wait(NULL);
{do_something_epoll_related;}
close(pfd[0]); /* finally we close the pipe, and epoll can do its cleanup */

fork() is acting sort of dup() , as it increases all file refcounts.

You have problems about close()/dup()/fork()/... file descriptors semantic, 
which is handled by a layer independent from epoll stuff.


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