public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: linux-kernel@vger.kernel.org, avi@redhat.com,
	kvm@vger.kernel.org, ghaskins@novell.com, rusty@rustcorp.com.au,
	bcrl@kvack.org
Subject: Re: [patch] eventfd - revised interface and cleanups (2nd rev)
Date: Tue, 23 Jun 2009 12:48:07 -0700	[thread overview]
Message-ID: <20090623124807.eb9042a5.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.1.10.0906231219450.17001@makko.or.mcafeemobile.com>

On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi <davidel@xmailserver.org> wrote:

> The following patch changes the eventfd interface to de-couple the eventfd 
> memory context, from the file pointer instance.
> Without such change, there is no clean way to racely free handle the 
> POLLHUP event sent when the last instance of the file* goes away.
> Also, now the internal eventfd APIs are using the eventfd context instead 
> of the file*.
> Another cleanup this patch does, is making AIO select EVENTFD, instead of 
> adding a bunch of empty function stubs inside eventfd.h in order to 
> handle the (AIO && !EVENTFD) case.
> 

If we really want to squeeze this into 2.6.31 then it would be helpful
to have justification in the changelog, please.  I see that some KVM
feature needs it, but what and why and why now, etc?

The patch conflicts with similar changes int he KVM tree, but that'll
just ruin sfr's life for a day.


Your patch has:


> ...
>  static int eventfd_release(struct inode *inode, struct file *file)
>  {
> -	kfree(file->private_data);
> +	struct eventfd_ctx *ctx = file->private_data;
> +
> +	wake_up_poll(&ctx->wqh, POLLHUP);
> +	eventfd_ctx_put(ctx);
>  	return 0;
>  }

but the patch in linux-next has

static int eventfd_release(struct inode *inode, struct file *file)
{
	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;
}

which looks quite different (and has a nice comment!)

What's going on here?

  reply	other threads:[~2009-06-23 19:48 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-23 16:47 [patch] eventfd - revised interface and cleanups Davide Libenzi
2009-06-23 16:59 ` Randy Dunlap
2009-06-23 17:04   ` Davide Libenzi
2009-06-23 17:03 ` Avi Kivity
2009-06-23 17:04   ` Davide Libenzi
2009-06-23 17:51 ` Gregory Haskins
2009-06-23 17:51   ` Davide Libenzi
2009-06-23 19:25 ` [patch] eventfd - revised interface and cleanups (2nd rev) Davide Libenzi
2009-06-23 19:48   ` Andrew Morton [this message]
2009-06-23 19:49     ` Davide Libenzi
2009-06-23 20:12   ` Andrew Morton
2009-06-23 20:59     ` Davide Libenzi
2009-06-23 21:25       ` Andrew Morton
2009-06-23 21:25         ` Davide Libenzi
2009-06-23 21:44           ` Andrew Morton
2009-06-23 22:49             ` Davide Libenzi
2009-06-23 23:18               ` Andrew Morton
2009-06-24 22:47                 ` Davide Libenzi
2009-06-24 23:12                   ` Andrew Morton
2009-06-24 23:52                     ` Davide Libenzi
2009-06-25  0:33                       ` Andrew Morton
2009-06-23 20:18   ` Andrew Morton
2009-06-23 21:03     ` Davide Libenzi
2009-06-23 21:29       ` Andrew Morton
2009-06-23 21:28         ` Davide Libenzi
2009-06-23 21:34         ` Davide Libenzi
2009-06-23 21:46           ` Andrew Morton
2009-06-23 21:48             ` Davide Libenzi
2009-06-23 22:07               ` Andrew Morton
2009-06-23 22:46   ` [patch] eventfd - revised interface and cleanups (3rd rev) Davide Libenzi
2009-06-24 23:57     ` [patch] eventfd - revised interface and cleanups (4th rev) Davide Libenzi

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=20090623124807.eb9042a5.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=avi@redhat.com \
    --cc=bcrl@kvack.org \
    --cc=davidel@xmailserver.org \
    --cc=ghaskins@novell.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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