Message-ID: <49A44FEB.6000803@cosmosbay.com>
Date:	Tue, 24 Feb 2009 20:52:11 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Tony Battersby <tonyb@...ernetics.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Davide Libenzi <davidel@...ilserver.org>,
	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] [2.6.29] epoll: fix for epoll_wait sometimes returning
 events on closed fds

Tony Battersby a écrit :
> Eric Dumazet wrote:
>> Your patch may solve part of the problem. In your programs, maybe you
>> have one thread doing all epoll_wait() and close() syscalls, but what
>> of other programs ?
>>
>> What prevents a thread doing close(fd) right after an other thread
>> got this fd from epoll_wait() ?
>> Nothing, and application may strangely react.
>>
>> The moment you have several threads doing read()/write()/close() syscalls
>> on the same fd at the same time, you obviously get problems, not
>> only with epoll.
>>
>> In a typical epoll driven application, with a pool of N worker threads all doing :
>>
>> while (1) {
>> 	fd = epoll_wait(epoll_fd);
>> 	work_on_fd(fd); /* possibly calling close(fd); */
>> }
>>
>> Then, you must be prepared to get a *false* event, ie an fd that another worker
>> already closed (and eventually reopened)
>>
>>
>>
>>   
> Yes, I agree that userspace threads do need synchronization to prevent
> one thread from stomping on another thread's data.  If userspace can't
> prove that close() returned before the call to epoll_wait(), then
> epoll_wait() may legitimately return an event on a closed fd.  That's
> why my test program did close() and then epoll_wait() from the same
> thread - to prove that they were serialized.
> 
> I am not actually using epoll in any of my programs right now; I was
> just investigating a bug reported to me by another programmer at my
> company.  So my test program isn't intented to reflect anything other
> than a way to reproduce the problem reliably.  However, I can imagine
> that a network program might want to spawn separate rx/tx threads on the
> same socket, in which case it might make sense to have separate threads
> accessing the same file descriptor.  As you say, the two threads would
> have to use proper locking, but that is purely a userspace issue that
> kernel developers need not worry about.  So I am only concerned with the
> case that userspace can prove that close() and epoll_wait() were
> properly serialized, and epoll_wait() still returned an event on the
> closed fd.

I believe Davide already said that close() meant the real close, not
the file descriptor freeing. 

And current documentations clearly states it, maybe your man page is too old ?

---

Q6  Will closing a file descriptor cause it to be removed from all epoll sets automatically?

A6  Yes,  but  be  aware  of  the  following  point.   A  file descriptor is a reference to an open file description (see
    open(2)).  Whenever a descriptor is duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, or fork(2), a new file descriptor  referring  to  the same open file description is created.  An open file description continues to exist until all
    file descriptors referring to it have been closed.  A file descriptor is removed from an epoll set only after all the
    file  descriptors  referring to the underlying open file description have been closed (or before if the descriptor is
    explicitly removed using epoll_ctl() EPOLL_CTL_DEL).  This means that even after a file descriptor that is part of an
    epoll set has been closed, events may be reported for that file descriptor if other file descriptors referring to the
    same underlying file description remain open.



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

Powered by blists - more mailing lists