From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YROob-0007aw-Eq for qemu-devel@nongnu.org; Fri, 27 Feb 2015 12:35:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YROoa-00018z-LM for qemu-devel@nongnu.org; Fri, 27 Feb 2015 12:35:05 -0500 Message-ID: <54F0AAC2.6020202@weilnetz.de> Date: Fri, 27 Feb 2015 18:34:58 +0100 From: Stefan Weil MIME-Version: 1.0 References: <1425045947-9271-1-git-send-email-mreitz@redhat.com> <20150227165723.GB32542@stefanha-thinkpad.redhat.com> <54F0A86E.7000608@weilnetz.de> <54F0A957.5090906@redhat.com> In-Reply-To: <54F0A957.5090906@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] block/vdi: Add locking for parallel requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , Stefan Hajnoczi Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, qemu-block@nongnu.org, qemu-stable@nongnu.org Am 27.02.2015 um 18:28 schrieb Max Reitz: > On 2015-02-27 at 12:25, Stefan Weil wrote: >> block/vdi.c was never written for multi-threaded access, see my comment >> in the header of block/vdi.c: >> >> * The code is not thread safe (missing locks for changes in header and >> * block table, no problem with current QEMU). >> >> This was true in the past, but obviously later multi-threaded access was >> introduced for QEMU. Locking was added for qcow2 and other drivers in >> 2012 and 2013, but never for vdi. >> >> I must admit that I don't know which parts of the block filesystem >> drivers potentially run in parallel threads.Ideally there would be one >> or more test cases which test multi-threaded operations and which >> trigger a failure with the current vdi code. >> >> If I had a simple test scenario, I could have a look on the problem. > > I have one for you. See the attached ruby script. > > (If there are no "Pattern verification failed" messages, everything is > good) > >> The VMDK approach is fine as an intermediate work around, but please use >> conditional compilation to allow easy tests without coarse locks (and >> update the comments :-)). > > Will a macro defined in vdi.c be enough? Yes, that would be fine. vdi.c already has several locally defined CONFIG_VDI_... macros. Stefan