On Wed, Jul 11, 2007 at 12:01:06PM +0300, Pekka J Enberg wrote: > From: Pekka Enberg <penberg@xxxxxxxxxxxxxx> > > The revokeat(2) and frevoke(2) system calls invalidate open file descriptors > and shared mappings of an inode. After an successful revocation, operations > on file descriptors fail with the EBADF or ENXIO error code for regular and > device files, respectively. Attempting to read from or write to a revoked > mapping causes SIGBUS. > > The actual operation is done in two passes: > > 1. Revoke all file descriptors that point to the given inode. We do > this under tasklist_lock so that after this pass, we don't need > to worry about racing with close(2) or dup(2). How does that deal with the following: task A gets its descriptor table cleansed task B sends a descriptor to task A via SCM_RIGHTS datagram task B gets its descriptor table cleansed task A receives the datagram and gets the descriptor installed task A does any kind of IO on that descriptor ->f_mapping gets replaced in the most inconvenient time. Come to think of that, what do you do if I create a socketpair, stuff the descriptor into SCM_RIGHTS datagram and send it to myself? Then receive it a day after you've called revoke() and voila - I've got an almost undamaged struct file back... At the very least, it allows me to fchmod(). Or fchdir() if that had been a directory... BTW, read() or write() in progress might get rather unhappy if your live replacement of ->f_mapping races with them... - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
