[RFC][PATCH 0/7 + tools] Checkpoint/restore mostly in the userspace

[Matt Helsley]

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