From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [KVM PATCH v5 3/4] KVM: Fix races in irqfd using new eventfd_kref_get interface Date: Sun, 28 Jun 2009 14:48:46 +0300 Message-ID: <20090628114846.GA11764@redhat.com> References: <20090625132441.26748.641.stgit@dev.haskins.net> <20090625132826.26748.15607.stgit@dev.haskins.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, avi@redhat.com To: Gregory Haskins Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36220 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752294AbZF1LtP (ORCPT ); Sun, 28 Jun 2009 07:49:15 -0400 Content-Disposition: inline In-Reply-To: <20090625132826.26748.15607.stgit@dev.haskins.net> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jun 25, 2009 at 09:28:27AM -0400, Gregory Haskins wrote: > eventfd currently emits a POLLHUP wakeup on f_ops->release() to generate 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. However, > 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 race > 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. 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? -- MST