From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCQrm-0005jV-94 for qemu-devel@nongnu.org; Thu, 22 Aug 2013 05:07:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCQrf-0000B6-3y for qemu-devel@nongnu.org; Thu, 22 Aug 2013 05:07:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCQre-0000Ap-Sj for qemu-devel@nongnu.org; Thu, 22 Aug 2013 05:07:35 -0400 Message-ID: <5215D4A7.60501@redhat.com> Date: Thu, 22 Aug 2013 11:06:47 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1377050567-19122-1-git-send-email-asias@redhat.com> <20130821152440.GB18303@stefanha-thinkpad.redhat.com> <5214DF5B.50203@redhat.com> <20130822055947.GB24870@in.ibm.com> <20130822074846.GC10412@stefanha-thinkpad.redhat.com> In-Reply-To: <20130822074846.GC10412@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block: Fix race in gluster_finish_aiocb List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Vijay Bellur , Stefan Hajnoczi , qemu-devel@nongnu.org, Bharata B Rao , Asias He , MORITA Kazutaka Il 22/08/2013 09:48, Stefan Hajnoczi ha scritto: >> > gluster_finish_aiocb gets called from gluster thread, is it safe to create >> > and schedule a bh from such a thread ? >> > >> > In my first implementation (http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg01748.html), I was using a BH from qemu read side thread (the thread >> > that would respond to pipe write from gluster callback thread). That >> > implementation was based on rbd and I later dropped the BH part since it >> > looked like a round about way of completing the aio when we are already using >> > the pipe mechanism for aio completion. > Recent patches made creating and scheduling a BH thread-safe. I thought scheduling BHs was always thread safe? > I think Paolo's idea is better than mine. Both are fine, they are just different. Mine is simpler because it leaves list management to the BH code. But since we are at it, we should simplify the code and uniformly use a bottom half for both successful and erroneous completions. This applies to both ideas. Maybe an even simpler patch would be to just abort if the GLUSTER_FD_WRITE write fails. Under what circumstances could it happen? Paolo