summaryrefslogtreecommitdiffstats
path: root/tools/time
diff options
context:
space:
mode:
authorBenjamin Coddington <bcodding@redhat.com>2017-01-05 10:20:16 -0500
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2017-12-09 22:01:51 +0100
commit9f800573a31b8993313a8c11eef4e0bd881c785a (patch)
treec2585b32fa7eb6e0798619109e932b7d8f39ea93 /tools/time
parentc682ae717759622c32d3bbd720a6acfbd54c9726 (diff)
downloadlinux-stable-9f800573a31b8993313a8c11eef4e0bd881c785a.tar.gz
linux-stable-9f800573a31b8993313a8c11eef4e0bd881c785a.tar.bz2
linux-stable-9f800573a31b8993313a8c11eef4e0bd881c785a.zip
nfs: Don't take a reference on fl->fl_file for LOCK operation
[ Upstream commit 4b09ec4b14a168bf2c687e1f598140c3c11e9222 ] I have reports of a crash that look like __fput() was called twice for a NFSv4.0 file. It seems possible that the state manager could try to reclaim a lock and take a reference on the fl->fl_file at the same time the file is being released if, during the close(), a signal interrupts the wait for outstanding IO while removing locks which then skips the removal of that lock. Since 83bfff23e9ed ("nfs4: have do_vfs_lock take an inode pointer") has removed the need to traverse fl->fl_file->f_inode in nfs4_lock_done(), taking that reference is no longer necessary. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/time')
0 files changed, 0 insertions, 0 deletions