From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregory Haskins Subject: Re: [KVM PATCH v5 3/4] KVM: Fix races in irqfd using new eventfd_kref_get interface Date: Sun, 28 Jun 2009 08:53:22 -0400 Message-ID: <4A4767C2.3010503@novell.com> References: <20090625132441.26748.641.stgit@dev.haskins.net> <20090625132826.26748.15607.stgit@dev.haskins.net> <20090628114846.GA11764@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09B4E4D4152CE8CAC89D4198" Cc: kvm@vger.kernel.org, avi@redhat.com To: "Michael S. Tsirkin" Return-path: Received: from victor.provo.novell.com ([137.65.250.26]:34492 "EHLO victor.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751450AbZF1Mx3 (ORCPT ); Sun, 28 Jun 2009 08:53:29 -0400 In-Reply-To: <20090628114846.GA11764@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09B4E4D4152CE8CAC89D4198 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael S. Tsirkin wrote: > On Thu, Jun 25, 2009 at 09:28:27AM -0400, Gregory Haskins wrote: > =20 >> eventfd currently emits a POLLHUP wakeup on f_ops->release() to genera= te a >> "release" callback. This lets eventfd clients know if the eventfd is = about >> to go away and is very useful particularly for in-kernel clients. How= ever, >> until recently it is not possible to use this feature of eventfd in a >> race-free way. This patch utilizes a new eventfd interface to rectify= >> the problem. >> >> Note that one final race is known to exist: the slow-work thread may r= ace >> with module removal. We are currently working with slow-work upstream= >> to fix this issue as well. Since the code prior to this patch also >> races with module_put(), we are not making anything worse, but rather >> shifting the cause of the race. Once the slow-work code is patched we= >> will be fixing the last remaining issue. >> =20 > > By the way, why are we using slow-work here? Wouldn't a regular > workqueue do just as well, with less code, and avoid the race? > > =20 I believe it will cause a problem if you do a "flush_work()" from inside a work-item. I could be wrong, of course, but it looks like a recipe to deadlock. -Greg --------------enig09B4E4D4152CE8CAC89D4198 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpHZ8IACgkQlOSOBdgZUxl3QACeMsy+o9SPzFeEotQuM7mAiUL7 4tkAoI4S8Bqb24nHUkRg0a67DQmKRbeR =kLMA -----END PGP SIGNATURE----- --------------enig09B4E4D4152CE8CAC89D4198--