On Sun, Aug 03, 2014 at 07:35:37AM -0400, Jeffrey Layton wrote: > Agreed. That's a significant bit of nastiness, and I think you're > correct that the client_mutex removal will exacerbate the problem. The > only way I can see to properly fix that would be to make it so that > the conflock holds a reference to the lockowner, and then put it when > the conflock is freed. > > That will require some new fl_ops or fl_lmops. It would also be good > to clean up conflock generation a bit, and turn it into a more > explicit process. __locks_copy_lock doesn't really fully describe > what's going on there, IMO... Or do the work of nfs4_set_lock_denied under the i_lock in some sort of callback from the locking code? --b. -- 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
