> Sorry for late response.
>
> In function int Pipe::connect(), pipe_lock is released first.
>
> int Pipe::connect()
> {
> bool got_bad_auth = false;
>
> ldout(msgr->cct,10) << "connect " << connect_seq << dendl;
> assert(pipe_lock.is_locked());
>
> __u32 cseq = connect_seq;
> __u32 gseq = msgr->get_global_seq();
>
> // stop reader thread
> join_reader();
>
> pipe_lock.Unlock();
>
> .....
>
> some tcp_read and do_sendmsg after this for protocol processing
> In between unlock and lock, pipe may be getting replaced due to network errors.
> and moved to STATE_CLOSED in accept routine while this pipe is waiting for lock
> below.
> ......
>
> pipe_lock.Lock();
>
> ....
> After this there is code like below which override Pipe state.
> There is a danger of overwriting STATE_CLOSED state?
>
> if (reply.tag == CEPH_MSGR_TAG_WAIT) {
> ldout(msgr->cct,3) << "connect got WAIT (connection race)" << dendl;
> state = STATE_WAIT;
> goto stop_locked;
> }
>
> Please see if there is any issue in above code.
Hi Greg, kindly see if there is a bug here.
We are not able to reproduce the issue in our tests.
Thanks,
Padmanabh
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
