All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <lkml@rtr.ca>
To: Willy Tarreau <w@1wt.eu>
Cc: Davide Libenzi <davidel@xmailserver.org>,
	Marc Lehmann <linux-kernel@tst.eu>,
	Eric Dumazet <dada1@cosmosbay.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: epoll design problems with common fork/exec patterns
Date: Mon, 29 Oct 2007 18:36:20 -0400	[thread overview]
Message-ID: <47266064.9030306@rtr.ca> (raw)
In-Reply-To: <20071027173828.GY10199@1wt.eu>

Willy Tarreau wrote:
>> On Sat, 27 Oct 2007, Marc Lehmann wrote:
>>
>>>> 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);
>>>      }
..
> from what I understand, Marc is not asking for the code above to remove
> the fd from the epoll set, but he's in fact complaining that he *observed*
> that the fd was removed from the epoll set in the *parent* process when
> the child closes it, which is of course not expected at all. As strange
> as it looks like, this might need investigation. It is possible that there
> is some strange bug somewhere in some kernel versions.
> 
> Marc, I think that if you indicate the last kernel version on which you
> observed this and provide a very short and easy reproducer, it would
> help everyone investigating this. Basically something which reports "OK"
> or "KO".

That's how I read it, too.
So basically, a program like this, perhaps.
Except that, here running 2.6.23.1, it works just fine (no removal bug).

#include <sys/epoll.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/socket.h>

static int del_from_epoll_set (int efd, int fd, const char *msg)
{
	struct epoll_event e;

	memset(&e, 0, sizeof(e));
	e.data.fd = fd;
	if (epoll_ctl(efd, EPOLL_CTL_DEL, fd, &e) == -1) {
		int err = errno;
		fprintf(stderr, "epoll_ctl(DEL) failed (%s): %s\n", msg, strerror(err));
		return -1;
	}
	return 0;
}

static int add_to_epoll_set (int efd, int fd, __uint32_t events, const char *msg)
{
	struct epoll_event e;

	memset(&e, 0, sizeof(e));
	e.events = events;
	e.data.fd = fd;
	if (epoll_ctl(efd, EPOLL_CTL_ADD, fd, &e) == -1) {
		int err = errno;
		fprintf(stderr, "epoll_ctl(ADD) failed (%s): %s\n", msg, strerror(err));
		return -1;
	}
	return 0;
}

int main (int argc, char **argv)
{
	int	efd, sd, fds[2];
	pid_t	cpid;

	if (pipe(fds) == -1) {
		perror("pipe()");
		exit(1);
	}
	sd = socket(PF_INET, SOCK_STREAM, 0);
	if (sd == -1) {
		perror("socket");
		exit(1);
	}

	efd = epoll_create(5);
	if (efd == -1) {
		perror("epoll_create");
		exit(1);
	}

	if (add_to_epoll_set(efd, fileno(stdin), EPOLLIN, "stdin"))
		exit(1);
	if (add_to_epoll_set(efd, fileno(stdout), EPOLLOUT, "stdout"))
		exit(1);
	if (add_to_epoll_set(efd, fds[0], EPOLLIN, "pipe_read"))
		exit(1);
	if (add_to_epoll_set(efd, fds[1], EPOLLOUT, "pipe_write"))
		exit(1);
	if (add_to_epoll_set(efd, sd, EPOLLIN|EPOLLOUT, "socket"))
		exit(1);

	// assume there is an open epoll set that listens for events on fd 5
	cpid = fork();
	if (cpid == 0) {
		close(fileno(stdin));
		close(fileno(stdout));
		close(fds[0]);
		close(fds[1]);
		close(sd);
		exit(0);
	}
	waitpid(cpid, NULL, 0);

	// now test whether the fd's are still in the epoll set:
	add_to_epoll_set(efd, sd, EPOLLIN|EPOLLOUT, "sd");
	add_to_epoll_set(efd, fds[0], EPOLLIN,  "fds[0]");
	add_to_epoll_set(efd, fds[1], EPOLLOUT, "fds[1]");
	add_to_epoll_set(efd, fileno(stdin),  EPOLLIN,  "fileno(stdin)");
	add_to_epoll_set(efd, fileno(stdout), EPOLLOUT, "fileno(stdout)");

	del_from_epoll_set(efd, sd, "sd");
	del_from_epoll_set(efd, fds[0], "fds[0]");
	del_from_epoll_set(efd, fds[1], "fds[1]");
	del_from_epoll_set(efd, fileno(stdin), "fileno(stdin)");
	del_from_epoll_set(efd, fileno(stdout), "fileno(stdout)");

	printf("Done.\n");
	exit(0);
}


  parent reply	other threads:[~2007-10-29 22:36 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-27  6:22 epoll design problems with common fork/exec patterns 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 [this message]
2007-10-28  4:47       ` David Schwartz
2007-10-28  9:33         ` Eric Dumazet
2007-10-28 21:04           ` David Schwartz
2007-10-29 18:55             ` Davide Libenzi
     [not found]               ` <Pine.LNX.4.64.0710291147180.3387-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2008-02-26 15:13                 ` Michael Kerrisk
2008-02-26 15:13                   ` Michael Kerrisk
     [not found]                   ` <47C42CA7.4030607-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-02-26 18:51                     ` Davide Libenzi
2008-02-26 18:51                       ` Davide Libenzi
     [not found]                       ` <Pine.LNX.4.64.0802261049040.27243-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2008-02-27  1:30                         ` Chris "ク" Heath
2008-02-27  1:30                           ` Chris "ク" Heath
     [not found]                           ` <1204075804.5238.7.camel-DBi1IKlRe8YXiSwHZUBl+UgmxNRb6L7S@public.gmane.org>
2008-02-27 19:35                             ` Davide Libenzi
2008-02-27 19:35                               ` Davide Libenzi
     [not found]                               ` <Pine.LNX.4.64.0802271131180.377-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2008-02-28 13:12                                 ` Michael Kerrisk
2008-02-28 13:12                                   ` Michael Kerrisk
     [not found]                                   ` <cfd18e0f0802280512q43a457d0sc9a8dc83c51e8e1c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-28 13:23                                     ` Michael Kerrisk
2008-02-28 13:23                                       ` Michael Kerrisk
     [not found]                                       ` <cfd18e0f0802280523p1bdacfc5s274387f8280238c8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-28 19:34                                         ` Davide Libenzi
2008-02-28 19:34                                           ` Davide Libenzi
2008-02-28 19:23                                     ` Davide Libenzi
2008-02-28 19:23                                       ` Davide Libenzi
     [not found]                                       ` <Pine.LNX.4.64.0802281106050.7660-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2008-02-29 15:46                                         ` Michael Kerrisk
2008-02-29 15:46                                           ` Michael Kerrisk
     [not found]                                           ` <cfd18e0f0802290746p3cb7efc9j72394cd77ff37829-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-29 19:19                                             ` Davide Libenzi
2008-02-29 19:19                                               ` Davide Libenzi
2008-02-29 19:54                                               ` Michael Kerrisk
2008-03-02 15:11                                                 ` Sam Varshavchik
2008-03-02 15:11                                                   ` Sam Varshavchik
     [not found]                                                   ` <cone.1204470717.369031.30230.500-lO+bjgoT4TKm14v+eVDVcBDJ/jce7dRH@public.gmane.org>
2008-03-02 21:44                                                     ` Davide Libenzi
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=47266064.9030306@rtr.ca \
    --to=lkml@rtr.ca \
    --cc=dada1@cosmosbay.com \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@tst.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=w@1wt.eu \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.