Messages in this thread | | | From | "Gilad Benjamini" <> | Subject | RE: epoll and closed file descriptors | Date | Wed, 16 Sep 2009 17:53:05 -0700 |
| |
> Subject: Re: epoll and closed file descriptors > > 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.
Regarding bailing out of the situation, I see the logic in your answer. What about the first part ? Any ideas how the kernel actually got into that tight spot ? Looking into the code I can't find a path that can lead into this situation.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |