On Wed, Jul 27, 2011 at 12:45:25AM +0200, Tejun Heo wrote: > Hello, > > On Tue, Jul 26, 2011 at 11:11:28AM -0700, Matt Helsley wrote: > > No, you can't use the fd from the epoll item to look it up in the > > task's fd table. It may look trivially correct but it is not and that's > > why I mentioned it. > > > > This is an example of where the information we already have in /proc > > looks like it should be re-used but should not. > > > > EPOLL_CTL_ADD uses the fd to add it to the epoll items as an (fd,file) > > pair. Then another thread could change the fd table to close that fd. > > close does not update all the epoll sets the fd is a part of. So in order > > to remove the epoll item userspace must use the same "fd" it used during > > EPOLL_CTL_ADD -- even though that fd no longer refers to anything. > > That's why you can't just use the epoll item's fd to do a lookup in the > > fd table -- you'll get the wrong struct *file. Unfortunately, most of the > > time it will probably appear to work. You need a proper testcase to > > demonstrate it. > > > > At least that's what I recall of the code. > > Ummm... I'm a bit confused, are you saying that EPOLL_CTL_DEL may take > fd which is already closed? I can't see how that would be possible. > epoll uses fget() for fd -> file mapping like everyone else. If fd is Argh, you're right! I thought it just did an fget() on the epoll fd itself then looked up the target fd in the epoll set.. > closed, the mapping doesn't exist. > > I think what's confusing here is that, if multiple fd points to the > same file, epoll 'may' report events on an already closed or resued fd > because whole thing is anchored on struct file which doesn't go away > until the last fd is closed, but I don't think that's something we > need to worry about. It's dangling events on dead fds which is > explicitly described as 'may' happen in the documentation. Yup. Cheers, -Matt _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
