On Tue, 15 Jul 2014 10:17:52 -0700 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Tue, Jul 15, 2014 at 06:37:45AM -0400, Jeff Layton wrote: > > Once we remove the client_mutex, we'll have a potential race between > > setting a lease on a file and breaking the delegation. We may set the > > lease, but by the time we go to hash it, it may have already been > > broken. Currently, we know that this won't happen as the nfs4_laundromat > > takes the client_mutex, but we want to remove that. > > > > As part of that fix, add a function that can tell us whether a > > particular file has a lease set on it. In a later nfsd patch, we'll use > > that to close the potential race window. > > > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxxxxxxx> > > Looks reasonable, I don't really understand why we can drop out of the > loop when finding the first non-lease, but other code in locks.c also > does this, so I assume it is intentional. > It is intentional. The i_flock list is ordered. See the comments over the struct file_lock definition. Took me a while to understand that too (which is why I added the comment a few months ago). > The only real question I have is why this is in locks.c, while > check_for_locks that does the equivalent for real file locks is > implemented in the nfsd code. But I think it's better to have these > sorts of interfaces in locks.c and check_for_locks should move there > eventually. > Agreed, though I'll defer that until after this series is merged. > Reviewed-by: Christoph Hellwig <hch@xxxxxx> Thanks! -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
