On Wed, Jul 11, 2007 at 12:50:48PM +0300, Pekka J Enberg wrote: > Hi Al, > > On Wed, 11 Jul 2007, Al Viro wrote: > > Better: I have the only opened descriptor for foo. I send it to myself > > as described above. I close it. revoke() is called, finds no opened > > instances of foo in any descriptor tables and cheerfully does nothing. > > I call recvmsg() and I have completely undamaged opened file back. > > Uhm, nice. So, revoke() needs a proper inode -> struct files mapping > somewhere. Can we add a list of files to struct inode? Are there other > cases where a file can point to an inode but the file is not attached to > any file descriptor?
Umm... Any number, really - it might be in the middle of syscall while another task sharing descriptor table has closed the descriptor. Then there's quota, then there's process accounting, then there's execve() in progress, then there's knfsd working with that struct file, etc. The fundamental issue here is that even if you do find struct file, you can't blindly rip its ->f_mapping since it can be in the middle of ->read(), ->write(), pageout, etc. And even if you do manage that, you still have the ability to do fchmod() later. I don't see how the ability to find all instances in SCM_RIGHTS datagrams (for example) will help you with the race I've described first. Original state: task B has the only reference to file. revoke() is called, passes task A. B sends datagram to A and closes file. A receives datagram. Now the only reference is in A's table and you've already passed that. So you can't avoid processes keeping pointers to struct file. If you could find all struct file over given inode (which, I suspect, will lead to interesting locking), you could call something on that struct file, but you'd have zero exclusion with processes calling methods on it. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
