Re: [RFC/PATCH 2/5] revoke: core code

[Al Viro <viro@ftp.linux.org.uk>]

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.