locks: reverse order of posix_locks_conflict() arguments
The first argument to posix_locks_conflict() is meant to be a lock request,
and the second a lock from an inode's lock request. It doesn't really
make a difference which order you call them in, since the only
asymmetric test in posix_lock_conflict() is the check whether the second
argument is a posix lock--and every caller already does that check for
some reason.
But may as well fix posix_test_lock() to call posix_locks_conflict()
with the arguments in the same order as everywhere else.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
1 file changed