LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: davids@webmaster.com
Cc: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: Re: epoll design problems with common fork/exec patterns
Date: Sun, 28 Oct 2007 10:33:56 +0100	[thread overview]
Message-ID: <47245784.10209@cosmosbay.com> (raw)
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKIEEDHNAC.davids@webmaster.com>

David Schwartz a écrit :
>> 6) Epoll removes the file from the set, when the *kernel* object gets
>>    closed (internal use-count goes to zero)
>>
>> With that in mind, how can the code snippet above trigger a removal from
>> the epoll set?
> 
> 	I don't see how that can be. Suppose I add fd 8 to an epoll set. Suppose fd
> 5 is a dup of fd 8. Now, I close fd 8. How can fd 8 remain in my epoll set,
> since there no longer is an fd 8? Events on files registered for epoll
> notification are reported by descriptor, so the set membership has to be
> associated (as reflected into userspace) with the descriptor, not the file.

Events are not necessarly reported "by descriptors". epoll uses an opaque 
field provided by the user.

It's up to the user to properly chose a tag that will makes sense if the user 
app is playing dup()/close() games for example.

typedef union epoll_data
{
   void *ptr;
   int fd;
   uint32_t u32;
   uint64_t u64;
} epoll_data_t;


It's true some applications are using 'fd' field from epoll_data_t, but in 
this case they should not play dup()/close() games that could change the 
meaning of their 'epoll tags'. They would better use 'ptr/u64' for example to 
map the event to an application object. In this object they might find the 
correct handle (fd) to communicate with the kernel for a given 'file'. This 
handle could then be remapped to another handle using dup()/fcntl()/close()...


> 
> 	For example, consider:
> 
> 	1) Process creates an epoll set, the set gets fd 4.
> 
> 	2) Process creates a socket, it gets fd 5.
> 
> 	3) The process adds fd 5 to set 4.
> 
> 	4) The process forks.
> 
> 	5) The child inherits the epoll set but not the socket.
> 
> 	Here the kernel cannot quite do the right thing. Ideally, the parent would
> still have fd 5 in its version of the epoll set. After all, it has not
> closed fd 5. However, the child *cannot* see fd 5 in its version of the
> epoll set since it has no fd 5. An event reported for fd 5 would be
> nonsense.

Yes, it would be nonsense that the child still tries to get events from the 
epoll set while he cannot possibly use the socket. If you use 'ptr' field to 
retrieve an object, this object probably would have no meaning in the child 
anyway, especially after an exec() syscall.

That kind of user error can also happens with select()/poll(), if you do for 
example :

FD_ZERO(&fdset);
FD_SET(fd, &fdset);
select(fd+1,&fdset, NULL, NULL, NULL);
newfd = dup(fd);
close(fd);
for (i = 0 ; i < maxfd ; i++)
if (FD_ISSET(i, &fdset))
     read(i, ...)



  reply	other threads:[~2007-10-28  9:34 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-27  6:22 Marc Lehmann
2007-10-27  8:23 ` Eric Dumazet
2007-10-27  8:51   ` Marc Lehmann
2007-10-27  9:22     ` Eric Dumazet
2007-10-27  9:34       ` Marc Lehmann
2007-10-27 10:23         ` Eric Dumazet
2007-10-27 10:46           ` Marc Lehmann
2007-10-27 16:59     ` Davide Libenzi
2007-10-27 17:38       ` Willy Tarreau
2007-10-27 18:01         ` Davide Libenzi
2007-10-29 22:36         ` Mark Lord
2007-10-28  4:47       ` David Schwartz
2007-10-28  9:33         ` Eric Dumazet [this message]
2007-10-28 21:04           ` David Schwartz
2007-10-29 18:55             ` Davide Libenzi
2008-02-26 15:13               ` Michael Kerrisk
2008-02-26 18:51                 ` Davide Libenzi
2008-02-27  1:30                   ` Chris "ク" Heath
2008-02-27 19:35                     ` Davide Libenzi
2008-02-28 13:12                       ` Michael Kerrisk
2008-02-28 13:23                         ` Michael Kerrisk
2008-02-28 19:34                           ` Davide Libenzi
2008-02-28 19:23                         ` Davide Libenzi
2008-02-29 15:46                           ` Michael Kerrisk
2008-02-29 19:19                             ` Davide Libenzi
2008-02-29 19:54                               ` Michael Kerrisk
2008-03-02 15:11                                 ` Sam Varshavchik
2008-03-02 21:44                                   ` Davide Libenzi
2007-10-28 18:48         ` Davide Libenzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47245784.10209@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: epoll design problems with common fork/exec patterns' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).