summaryrefslogtreecommitdiff
path: root/net/dccp/ipv4.c
diff options
context:
space:
mode:
authorDave Wysochanski <dwysocha@redhat.com>2019-10-23 12:02:33 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-11-10 13:21:10 +0300
commitad56882f0cbaa8af92d022d1958c8c3bee56e59c (patch)
treefdfe2ae3ad423e532e0233f37e6f4abe33abc554 /net/dccp/ipv4.c
parent771fd6cdb9f84d34a18a432e490cab88d0ba48cd (diff)
downloadlinux-ad56882f0cbaa8af92d022d1958c8c3bee56e59c.tar.xz
cifs: Fix cifsInodeInfo lock_sem deadlock when reconnect occurs
[ Upstream commit d46b0da7a33dd8c99d969834f682267a45444ab3 ] There's a deadlock that is possible and can easily be seen with a test where multiple readers open/read/close of the same file and a disruption occurs causing reconnect. The deadlock is due a reader thread inside cifs_strict_readv calling down_read and obtaining lock_sem, and then after reconnect inside cifs_reopen_file calling down_read a second time. If in between the two down_read calls, a down_write comes from another process, deadlock occurs. CPU0 CPU1 ---- ---- cifs_strict_readv() down_read(&cifsi->lock_sem); _cifsFileInfo_put OR cifs_new_fileinfo down_write(&cifsi->lock_sem); cifs_reopen_file() down_read(&cifsi->lock_sem); Fix the above by changing all down_write(lock_sem) calls to down_write_trylock(lock_sem)/msleep() loop, which in turn makes the second down_read call benign since it will never block behind the writer while holding lock_sem. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Suggested-by: Ronnie Sahlberg <lsahlber@redhat.com> Reviewed--by: Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'net/dccp/ipv4.c')
0 files changed, 0 insertions, 0 deletions