diff options
author | Ilya Dryomov <idryomov@gmail.com> | 2019-01-14 21:13:10 +0100 |
---|---|---|
committer | Ilya Dryomov <idryomov@gmail.com> | 2019-01-21 14:53:12 +0100 |
commit | 4aac9228d16458cedcfd90c7fb37211cf3653ac3 (patch) | |
tree | a2f4197002b85d760be304d2d91d28734a2d046f /fs | |
parent | d95e674c01cfb5461e8b9fdeebf6d878c9b80b2f (diff) |
libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive()
con_fault() can transition the connection into STANDBY right after
ceph_con_keepalive() clears STANDBY in clear_standby():
libceph user thread ceph-msgr worker
ceph_con_keepalive()
mutex_lock(&con->mutex)
clear_standby(con)
mutex_unlock(&con->mutex)
mutex_lock(&con->mutex)
con_fault()
...
if KEEPALIVE_PENDING isn't set
set state to STANDBY
...
mutex_unlock(&con->mutex)
set KEEPALIVE_PENDING
set WRITE_PENDING
This triggers warnings in clear_standby() when either ceph_con_send()
or ceph_con_keepalive() get to clearing STANDBY next time.
I don't see a reason to condition queue_con() call on the previous
value of KEEPALIVE_PENDING, so move the setting of KEEPALIVE_PENDING
into the critical section -- unlike WRITE_PENDING, KEEPALIVE_PENDING
could have been a non-atomic flag.
Reported-by: syzbot+acdeb633f6211ccdf886@syzkaller.appspotmail.com
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Tested-by: Myungho Jung <mhjungk@gmail.com>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions