public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gregory Haskins <ghaskins@novell.com>
To: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, avi@redhat.com,
	davidel@xmailserver.org, mst@redhat.com,
	paulmck@linux.vnet.ibm.com
Subject: [KVM-RFC PATCH 1/2] eventfd: send POLLHUP on f_ops->release
Date: Tue, 02 Jun 2009 11:15:33 -0400	[thread overview]
Message-ID: <20090602151533.29746.1533.stgit@dev.haskins.net> (raw)
In-Reply-To: <20090602151135.29746.91320.stgit@dev.haskins.net>

From: Davide Libenzi <davidel@xmailserver.org>

Return-path: <davidel@xmailserver.org>
Received: from novell.com ([::ffff:130.57.1.153])
	by soto.provo.novell.com with ESMTP; Wed, 27 May 2009 13:35:04 -0600
Received: from x35.xmailserver.org not authenticated [64.71.152.41]
	by novell.com with M+ Extreme Email Engine 2008.3.release
	via secured & encrypted transport (TLS);
	Wed, 27 May 2009 13:35:04 -0600
X-MailFrom: davidel@xmailserver.org
X-AuthUser: davidel@xmailserver.org
Received: from makko.or.mcafeemobile.com
	by x35.xmailserver.org with [XMail 1.26 ESMTP Server]
	id <S2EBEB0> for <ghaskins@novell.com> from <davidel@xmailserver.org>;
	Wed, 27 May 2009 15:34:01 -0400
Date: Wed, 27 May 2009 12:28:57 -0700 (PDT)
From: Davide Libenzi <davidel@xmailserver.org>
X-X-Sender: davide@makko.or.mcafeemobile.com
To: "Michael S. Tsirkin" <mst@redhat.com>
cc: Gregory Haskins <ghaskins@novell.com>, kvm@vger.kernel.org,
    Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, avi@redhat.com,
    mtosatti@redhat.com
Subject: Re: [KVM PATCH v10] kvm: add support for irqfd
In-Reply-To: <20090527184106.GA18463@redhat.com>
Message-ID: <alpine.DEB.1.10.0905271222590.20243@makko.or.mcafeemobile.com>
References: <20090520142234.22285.72274.stgit@dev.haskins.net> <20090527130447.GA11643@redhat.com> <4A1D48FA.9080403@novell.com> <20090527184106.GA18463@redhat.com>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640  56FE 0974 BF23 270F 474E
X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 27 May 2009, Michael S. Tsirkin wrote:

> On Wed, May 27, 2009 at 10:06:50AM -0400, Gregory Haskins wrote:
> > Michael S. Tsirkin wrote:
> > > On Wed, May 20, 2009 at 10:30:49AM -0400, Gregory Haskins wrote:
> > >
> > >> +static int
> > >> +kvm_assign_irqfd(struct kvm *kvm, int fd, int gsi)
> > >> +{
> > >> +	struct _irqfd *irqfd;
> > >> +	struct file *file = NULL;
> > >> +	int ret;
> > >> +
> > >> +	irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL);
> > >> +	if (!irqfd)
> > >> +		return -ENOMEM;
> > >> +
> > >> +	irqfd->kvm = kvm;
> > >> +	irqfd->gsi = gsi;
> > >> +	INIT_LIST_HEAD(&irqfd->list);
> > >> +	INIT_WORK(&irqfd->work, irqfd_inject);
> > >> +
> > >> +	/*
> > >> +	 * Embed the file* lifetime in the irqfd.
> > >> +	 */
> > >> +	file = fget(fd);
> > >> +	if (IS_ERR(file)) {
> > >> +		ret = PTR_ERR(file);
> > >> +		goto fail;
> > >> +	}
> > >>
> > >
> > > So we get a reference to a file, and unless the user is nice to us, it
> > > will only be dropped when kvm char device file is closed?
> > > I think this will deadlock if the fd in question is the open kvm char device.
> > >
> > >
> > >
> > Hmm...I hadn't considered this possibility, though I am not sure if it
> > would cause a deadlock in the pattern you suggest.  It seems more like
> > it would result in, at worst, an extra reference to itself (and thus a
> > leak) rather than a deadlock...
> >
> > I digress.  In either case, perhaps I should s/fget/eventfd_fget to at
> > least limit the type of fd to eventfd.  I was trying to be "slick" by
> > not needing the eventfd_fget() exported, but I am going to need to
> > export it later anyway for iosignalfd, so its probably a moot point.
> >
> > Thanks Michael,
> > -Greg
> >
>
> This only works as long as eventfd does not do fget on some fd as well.
> Which it does not do now, and may never do - but we create a fragile
> system this way.
>
> I think it's really wrong, fundamentally, to keep a reference to a
> file until another file is closed, unless you are code under fs/.
> We will get nasty circular references sooner or later.
>
> Isn't the real reason we use fd to be able to support the same interface
> on top of both kvm and lguest?
> And if so, wouldn't some kind of bus be a better solution?

Another solution, that I proposed in the past, is having irqfd hold no
references to the eventfd. It's just register (holding an eventfd-get())
for events (in the way that currently does), notice the POLLHUP, unchain
from it, and propagate the eventfd-close event to whatever the irqfd logic
is supposed to.



- Davide

Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---

 fs/eventfd.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/fs/eventfd.c b/fs/eventfd.c
index 3f0e197..72f5f8d 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -61,7 +61,15 @@ EXPORT_SYMBOL_GPL(eventfd_signal);
 
 static int eventfd_release(struct inode *inode, struct file *file)
 {
-	kfree(file->private_data);
+	struct eventfd_ctx *ctx = file->private_data;
+
+	/*
+	 * No need to hold the lock here, since we are on the file cleanup
+	 * path and the ones still attached to the wait queue will be
+	 * serialized by wake_up_locked_poll().
+	 */
+	wake_up_locked_poll(&ctx->wqh, POLLHUP);
+	kfree(ctx);
 	return 0;
 }
 


  reply	other threads:[~2009-06-02 15:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02 15:15 [KVM-RFC PATCH 0/2] irqfd: use POLLHUP notification for close() Gregory Haskins
2009-06-02 15:15 ` Gregory Haskins [this message]
2009-06-02 15:15 ` [KVM-RFC PATCH 2/2] kvm: use POLLHUP to close an irqfd instead of an explicit ioctl Gregory Haskins
2009-06-02 17:16   ` Davide Libenzi
2009-06-02 17:42     ` Gregory Haskins
2009-06-02 18:02   ` Paul E. McKenney
2009-06-02 18:23     ` Gregory Haskins
2009-06-02 22:01       ` Paul E. McKenney
2009-06-03  1:53         ` Gregory Haskins
2009-06-03 15:04           ` Paul E. McKenney
2009-06-03 17:27             ` Gregory Haskins
2009-06-03 17:24               ` Davide Libenzi
2009-06-02 16:04 ` [KVM-RFC PATCH 0/2] irqfd: use POLLHUP notification for close() Michael S. Tsirkin
2009-06-02 16:14   ` Gregory Haskins
2009-06-02 16:20     ` Michael S. Tsirkin
2009-06-02 16:34       ` Gregory Haskins
2009-06-02 16:59         ` Michael S. Tsirkin
2009-06-02 17:02           ` Michael S. Tsirkin
2009-06-02 17:41           ` Gregory Haskins
2009-06-03  6:39             ` Michael S. Tsirkin
2009-06-03 11:34               ` Gregory Haskins
2009-06-04 10:25               ` Avi Kivity
2009-06-04 11:43                 ` Gregory Haskins
2009-06-04 11:50                   ` Avi Kivity
2009-06-04 11:52                     ` Gregory Haskins
2009-06-04 12:02                       ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090602151533.29746.1533.stgit@dev.haskins.net \
    --to=ghaskins@novell.com \
    --cc=avi@redhat.com \
    --cc=davidel@xmailserver.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox