On Tue, Nov 28, 2017 at 02:17:19PM +0100, Frederic Lecaille wrote: > On 11/28/2017 02:13 PM, Willy Tarreau wrote: > > On Tue, Nov 28, 2017 at 01:43:52PM +0100, Frederic Lecaille wrote: > > > On 11/28/2017 01:29 PM, Frederic Lecaille wrote: > > > There is a "/* fall through */" between PEER_SESS_ST_CONNECT and > > > PEER_SESS_ST_GETSTATUS cases in peer I/O handler code, so with a lock > > > which > > > may be taken two times ;). > > > > From what I'm seeing it cannot take it twice because it only grabs the > > lock when curpeer switches from null to non-null. > > Yes. Wrong remark on my side. > > What if peer state switched from PEER_SESS_ST_CONNECT to > PEER_SESS_ST_GETPEER? > > This may happen if the peer has just sent a hello message and just after > received a hello message.
>From what I'm reading (but I could be wrong), this transition does not exist, as the only way to reach GETPEER is via the following sequence : (new) -> ACCEPT -> GETVERSION -> GETHOST -> GETPEER Anyway, a double lock is easy to spot, as the offending process would spin at 100% CPU. That's why I think we are facing a different issue here. Willy
