On 8 Jun 2022, at 9:36, J. Bruce Fields wrote: > On Wed, Jun 08, 2022 at 09:19:25AM -0400, Benjamin Coddington wrote: >> NLM sometimes gets burnt by implementations of f_op->lock for F_GETLK >> modifying the lock structure (swapping out fl_owner) when the return is >> F_UNLCK. >> >> Yes, NLM should be more defensive, but perhaps we should be checking for >> everyone, as per POSIX "If no lock is found that would prevent this lock >> from being created, then the structure shall be left unchanged >> except for >> the lock type which shall be set to F_UNLCK." > > Doesn't seem like changing fl_owner affects fcntl_getlk results in this > case, so I don't think posix applies? Though, OK, maybe it violates the > principle of least surprise for vfs_test_lock to behave differently. Oh yeah, good point. fl_owner is just internal. That's enough of a reason for me to drop this idea. Ben
