Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
locks: fix unlock when fcntl_setlk races with a close
commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 upstream. Dmitry reported that he was able to reproduce the WARN_ON_ONCE that fires in locks_free_lock_context when the flc_posix list isn't empty. The problem turns out to be that we're basically rebuilding the file_lock from scratch in fcntl_setlk when we discover that the setlk has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END, then we may end up with fl_start and fl_end values that differ from when the lock was initially set, if the file position or length of the file has changed in the interim. Fix this by just reusing the same lock request structure, and simply override fl_type value with F_UNLCK as appropriate. That ensures that we really are unlocking the lock that was initially set. While we're there, make sure that we do pop a WARN_ON_ONCE if the removal ever fails. Also return -EBADF in this event, since that's what we would have returned if the close had happened earlier. Cc: Alexander Viro <[email protected]> Fixes: c293621 (stale POSIX lock handling) Reported-by: Dmitry Vyukov <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Acked-by: "J. Bruce Fields" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
- Loading branch information