From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIKao-00025D-7c for qemu-devel@nongnu.org; Tue, 25 Feb 2014 11:10:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIKai-0004ha-8W for qemu-devel@nongnu.org; Tue, 25 Feb 2014 11:10:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIKah-0004h4-Hj for qemu-devel@nongnu.org; Tue, 25 Feb 2014 11:10:44 -0500 Message-ID: <530CC078.4080707@redhat.com> Date: Tue, 25 Feb 2014 17:10:32 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1392994280-9675-1-git-send-email-stefanha@redhat.com> <1392994280-9675-2-git-send-email-stefanha@redhat.com> <53076E46.3020109@redhat.com> <20140224155359.GH23185@stefanha-thinkpad.hitronhub.home> <530B77CD.9020502@redhat.com> <20140225154245.GC2374@stefanha-thinkpad.redhat.com> In-Reply-To: <20140225154245.GC2374@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] iothread: stash thread ID away List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Stefan Hajnoczi , "Shergill, Gurinder" , "Vinod, Chegu" , qemu-devel@nongnu.org, Luiz Capitulino Il 25/02/2014 16:42, Stefan Hajnoczi ha scritto: > I guess you're saying that while unlocking the mutex is atomic, that > doesn't guarantee pthread won't access the mutex internal state some > more after it has unlocked it. Therefore it's not safe for another > thread to destroy the mutex even after it has acquired it. Yes. > POSIX does say that: > > "It shall be safe to destroy an initialized mutex that is unlocked." The question is what "unlocked" means... :) > But maybe I am reading too much into that? > > After poking around glibc a little I think you are right. I can't say > for sure but it seems even after a futex call glibc might still mess > with internal state. But if anyone knows for certain, please speak up. I think other races are possible. Let's look at the simple lock in nptl/lowlevellock.h: /* Mutex lock counter: bit 31 clear means unlocked; bit 31 set means locked. All code that looks at bit 31 first increases the 'number of interested threads' usage counter, which is in bits 0-30. The comment is wrong, there is a fast path that does not do that; I'm not sure if this is why the problem can happen, I'm just pointing this out because it contradicts the code I'm posting now. The file uses C code, but it's simpler to look at it in assembly. Unlocking is very simple: lock; btcl $31, futex jz 2f ... do futex wake ... 2: Locking has a fast path followed by preparing the slow path, re-checking the fastpath condition, and waiting if it fails still: lock; btsl $31, futex jnc 9f lock; incl futex 1: lock; btsl $31, futex jnc 8f ... do futex wait ... jmp 1b 8: lock; decl futex 9: It's possible, if futex is locked by CPU 0 and CPU 1 tries to grab it, that the following happens: CPU 0 CPU 1 lock; btsl $31, futex (fails) lock; incl futex lock; btcl %0 (not zero) lock; btsl $31, futex (succeeds) lock; decl futex destroy lock free(lock) futex wake If you get an EFAULT from the futex wakeup, this could be a problem. Paolo