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. 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. Reviewed-by: Christoph Hellwig <hch@xxxxxx> -- 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
