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: <20071027085125.GC12326@schmorp.de>
Date:	Sat, 27 Oct 2007 10:51:25 +0200
From:	Marc Lehmann <linux-kernel@....eu>
To:	Eric Dumazet <dada1@...mosbay.com>
Cc:	linux-kernel@...r.kernel.org,
	Davide Libenzi <davidel@...ilserver.org>
Subject: Re: epoll design problems with common fork/exec patterns

On Sat, Oct 27, 2007 at 10:23:17AM +0200, Eric Dumazet <dada1@...mosbay.com> wrote:
> >  In this case, the parent process works fine until the child closes fds,
> >  after which the fds become unarmed in the parent too. This works as
> 
> I have no idea what exact problem you have. 

Well, I explained it rather succinctly, I think. If you tell me whats unclear
I can explain...

> But if the child closes some 
> file descriptor that were 'cloned' at fork() time, this only decrements a 
> refcount, and definitely should not close it for the 'parent'.

It doesn't. It removes it from the epoll set, though, so the parent will not
receive events for that fd anymore.

> I have some apps that are happily using epoll() and fork()/exec() and have 

The problem I described is fork/close/exec. close being the explicit
syscall.

> no problem at all. I usually use O_CLOEXEC so that all close() are done at 
> exec() time without having to do it in a loop. epoll continues to work as 
> expected in the parent process.

This is because epoll doesn't behave like documented: It removes the fd
from the parents epoll set only on an explicit close() syscall, not on an
implicit close from exec.

> >fd sets. This would explain the behaviour above. Unfortunately (or
> >fortunately?) this is not what happens: when the fds are being closed by
> >exec or exit, the fds do not get removed from the epoll set.
> 
> at exec() (granted CLOEXEC is asserted) or exit() time, only the refcount 
> of each file is decremented. Only if their refcount becomes NULL, files are 
> then removed from epoll set.

Yes. But thats obviously not the only way to close fds.

> >Is epoll really designed to be so incompatible with the most commno fork
> >patterns? Shouldn't epoll do refcounting, as is commonly done under
> >Unix? As the fd space is not shared between rpocesses, why does epoll
> >try? Shouldn't the epoll information be copied just like the fd table
> >itself, memory, and other resources?
> 
> Too many questions here, showing lack of understanding.

You already said you don't the problem. No need to get insulting :(

> epoll definitly is not useless. It is used on major and critical apps.
> You certainly missed something.

Well, it behaves like documented, which is the problem. You admit you
don't understand the problem or the documentation, so again, no need to
insult me.

> Please provide some code to illustrate one exact problem you have.

   // assume there is an open epoll set that listens for events on fd 5
   if (fork () = 0)
     {
       close (5);
       // fd 5 is now removed from the epoll set of the parent.
       _exit (0);
     }

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg@...f.com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE
-
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/