On Fri, Jun 10, 2011 at 05:34:46PM -0400, J. Bruce Fields wrote: > On Fri, Jun 10, 2011 at 04:24:00PM -0400, Mimi Zohar wrote: > > On Thu, 2011-06-09 at 20:10 -0400, J. Bruce Fields wrote: > > > From: J. Bruce Fields <bfields@xxxxxxxxxx> > > > > > > Since break_lease is called before i_writecount is incremented, there's > > > a window between the two where a setlease call would have no way to know > > > that an open is about to happen. > > > > So unless the break_lease() call is moved from may_open() to after > > nameidata_to_filp(), I don't see any other options. > > Actually, offhand I can't see why that wouldn't be OK. > > Though I think we still end up needing something like i_blockleases to > handle unlink, link, rename, chown, and chmod. Well, I guess there's a bizarre alternative that wouldn't require a new inode field: What we care about is conflicts between read leases and operations that modify the metadata of the inode or the set of names pointing to it. As far as I can tell those operations all take the i_mutex either on the inode itself or on the parents of one of its aliases. So, you could prevent break_lease/setlease races by calling setlease under *all* of those i_mutexes: - take i_mutex on the inode - take i_lock to prevent the set of aliases from changing - take i_mutex for parent of each alias - set the lease - drop the parent i_mutexes, etc. where the i_mutexes would all be taken with mutex_trylock, and we'd just fail the whole setlease if any of them failed. ??? --b. -- 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
