From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH v2 08/14] KVM: x86: remove notifiers from PIT discard policy Date: Fri, 19 Feb 2016 16:06:10 +0100 Message-ID: <56C72F62.5060307@redhat.com> References: <1455736496-374-1-git-send-email-rkrcmar@redhat.com> <1455736496-374-9-git-send-email-rkrcmar@redhat.com> <56C6088A.5080207@redhat.com> <20160219150434.GA25910@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Yuki Shibuya To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: In-Reply-To: <20160219150434.GA25910@potion.brq.redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 19/02/2016 16:04, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> >=20 >> > ... so in patch 7 concurrent _writes_ of reinject are protected by= the >> > lock, but reads are done outside it (in pit_timer_fn). WDYT about >> > making reinject an atomic_t? > There was/is no harm in having reinject non-atomic. This patch added > notifiers, which is the reason for re-introducing a mutex. >=20 > Userspace can (and SHOULDN'T) call this function multiple times, > concurrently, so the mutex prevents a situations where, e.g. only one > notifier is registered in the end. Yes, I understand why you added the mutex here; good catch indeed. The atomic_t is just to show that it's okay to read it outside the lock. It's just for a bit of extra documentation. Paolo