From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC/PATCH 2/5] revoke: core code Date: Wed, 11 Jul 2007 10:42:51 +0100 Message-ID: <20070711094251.GV21668@ftp.linux.org.uk> References: <20070711093732.GU21668@ftp.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Pekka J Enberg Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:35353 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760192AbXGKJmw (ORCPT ); Wed, 11 Jul 2007 05:42:52 -0400 Content-Disposition: inline In-Reply-To: <20070711093732.GU21668@ftp.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Jul 11, 2007 at 10:37:33AM +0100, Al Viro wrote: > On Wed, Jul 11, 2007 at 12:01:06PM +0300, Pekka J Enberg wrote: > > From: Pekka Enberg > > > > 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... 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.