Re: epoll and closed file descriptors

[Bryan Donlan <bdonlan@gmail.com>]

On Wed, Sep 16, 2009 at 8:40 PM, Gilad Benjamini
<gilad@altornetworks.com> wrote:
> Davide wrote:
>> On Wed, 16 Sep 2009, Gilad Benjamini wrote:
>>
>> > I would, but epoll is preventing me from doing so.
>> > Early in sys_epoll_ctl there are these lines
>> >
>> >   file = fget(epfd);
>> >   if (!file)
>> >     goto error_return;
>> >
>> > Leaving me in a kind of dead lock
>>
>> The 'epfd' in there, is the _epoll fd_, which, if fget() fails, means
>> you
>> close it.
>> You see likely failing the 'tfile = fget(fd)' (of course, you closed
>> it),
>> so if someone else keeps the socket open and you have no chance in
>> telling
>> it to drop it (really?), you need to remove the socket from the set
>> before
>> closing it.
>>
>>
>>
>> - Davide
>
> My bad. I meant to quote the line that you mentioned.
> I agree that the right thing to do is to remove the fd from epoll before
> closing it.
> However, due to the way curl works, I cannot do that. Changing the curl code
> doesn't seem trivial.
>
> Regardless, I still don't see how the kernel got into this situation, and if
> this situation is valid, why it doesn't bail out of it.

epoll references the underlying file object; the fd is used _only_ to
obtain this file object, and then never used again. Determining when
the fd goes away then requires iterating over all fds, and since epoll
was designed to avoid doing exactly that, it isn't an acceptable
solution.

As I mentioned in the other email, by dup()ing the file descriptor,
you can get control over when the copy is closed without changing
curl. Then just make sure to remove it from the epoll set before
closing your copy.