From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bn6eE-0001yj-Oy for qemu-devel@nongnu.org; Thu, 22 Sep 2016 12:14:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bn6e9-0007Xf-PT for qemu-devel@nongnu.org; Thu, 22 Sep 2016 12:14:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bn6e9-0007XY-JO for qemu-devel@nongnu.org; Thu, 22 Sep 2016 12:14:49 -0400 References: <20160922101316.13064-1-alex.bennee@linaro.org> <20160922101316.13064-5-alex.bennee@linaro.org> From: Paolo Bonzini Message-ID: Date: Thu, 22 Sep 2016 18:14:40 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 4/9] seqlock: use atomic writes for the sequence List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , =?UTF-8?Q?Alex_Benn=c3=a9e?= , qemu-devel@nongnu.org, cota@braap.org, stefanha@redhat.com, kwolf@redhat.com Cc: mttcg@greensocs.com, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, bobby.prani@gmail.com, nikunj@linux.vnet.ibm.com, mark.burton@greensocs.com, jan.kiszka@siemens.com, serge.fdrv@gmail.com, peter.maydell@linaro.org, claudio.fontana@huawei.com On 22/09/2016 17:38, Richard Henderson wrote: >> diff --git a/include/qemu/seqlock.h b/include/qemu/seqlock.h >> index 2e2be4c..8dee11d 100644 >> --- a/include/qemu/seqlock.h >> +++ b/include/qemu/seqlock.h >> @@ -31,7 +31,7 @@ static inline void seqlock_init(QemuSeqLock *sl) >> /* Lock out other writers and update the count. */ >> static inline void seqlock_write_begin(QemuSeqLock *sl) >> { >> - ++sl->sequence; >> + atomic_set(&sl->sequence, sl->sequence + 1); > > The read side isn't using a atomic_read right here. There cannot be concurrent writes, so this is okay (and actually helps catching seqlock write-side critical sections not protected by a mutex or something else). The rule is that there is a race if two accesses, one of them a write _and_ one of them not atomic, are concurrent. So reads not concurrent with any writes are fine (e.g. if all writes are under a mutex, reads under the mutex are fine too). Paolo