From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 09407452566 for ; Sat, 16 Nov 2019 14:54:22 +0300 (MSK) Received: by mail-lf1-f66.google.com with SMTP id z188so10021831lfa.11 for ; Sat, 16 Nov 2019 03:54:22 -0800 (PST) Date: Sat, 16 Nov 2019 14:54:21 +0300 From: Konstantin Osipov Message-ID: <20191116115421.GD14490@atlas> References: <0e1af790a8cbc380fcd3bb7c7295f5f5b80d98a3.1573862438.git.v.shpilevoy@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e1af790a8cbc380fcd3bb7c7295f5f5b80d98a3.1573862438.git.v.shpilevoy@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 1/1] iproto: don't destroy a session during disconnect List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org * Vladislav Shpilevoy [19/11/16 12:48]: > Binary session disconnect trigger yield could lead to use after > free of the session object. That happened because iproto thread > sent two requests to TX thread at disconnect: > > - Close the session and run its on disconnect triggers; > > - If all requests are handled, destroy the session. > > When a connection is idle, all requests are handled, so both these > requests are sent. If the first one yielded in TX thread, the > second one arrived and destroyed the session right under the feet > of the first one. > > This can be solved in two ways - in TX thread, and in iproto > thread. > > TX thread solution (which is chosen in the patch): add a flag > which says whether disconnect is processed by TX. When destroy > request arrives, it checks the flag. If disconnect is not done, > the destroy request waits on a condition variable until it is. > > The solution is simple, but adds new members to iproto_connection > struct, and requires lots of commenting. > > Iproto thread solution (alternative): just don't send destroy > request until disconnect returns back to iproto thread. I like this one more to be honest. -- Konstantin Osipov, Moscow, Russia