summaryrefslogtreecommitdiff
path: root/fs/ceph
diff options
context:
space:
mode:
authorIlya Dryomov <idryomov@gmail.com>2019-01-14 21:13:10 +0100
committerIlya Dryomov <idryomov@gmail.com>2019-01-21 14:53:12 +0100
commit4aac9228d16458cedcfd90c7fb37211cf3653ac3 (patch)
treea2f4197002b85d760be304d2d91d28734a2d046f /fs/ceph
parentd95e674c01cfb5461e8b9fdeebf6d878c9b80b2f (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/ceph')
0 files changed, 0 insertions, 0 deletions