From: Andrew Morton <akpm@linux-foundation.org>
To: "Paton J. Lewis" <palewis@adobe.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Jason Baron <jbaron@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Paul Holland <pholland@adobe.com>,
Davide Libenzi <davidel@xmailserver.org>,
Michael Kerrisk <mtk.manpages@gmail.com>,
libc-alpha@sourceware.org, linux-api@vger.kernel.org,
paulmck@linux.vnet.ibm.com
Subject: Re: [PATCH v3] epoll: Support for disabling items, and a self-test app.
Date: Mon, 29 Oct 2012 13:42:23 -0700 [thread overview]
Message-ID: <20121029134223.81efcc00.akpm@linux-foundation.org> (raw)
In-Reply-To: <1351210112-23238-1-git-send-email-palewis@adobe.com>
On Thu, 25 Oct 2012 17:08:32 -0700
"Paton J. Lewis" <palewis@adobe.com> wrote:
> It is not currently possible to reliably delete epoll items when using the
> same epoll set from multiple threads. After calling epoll_ctl with
> EPOLL_CTL_DEL, another thread might still be executing code related to an
> event for that epoll item (in response to epoll_wait). Therefore the deleting
> thread does not know when it is safe to delete resources pertaining to the
> associated epoll item because another thread might be using those resources.
>
> The deleting thread could wait an arbitrary amount of time after calling
> epoll_ctl with EPOLL_CTL_DEL and before deleting the item, but this is
> inefficient and could result in the destruction of resources before another
> thread is done handling an event returned by epoll_wait.
>
> This patch enhances epoll_ctl to support EPOLL_CTL_DISABLE, which disables an
> epoll item. If epoll_ctl returns -EBUSY in this case, then another thread may
> handling a return from epoll_wait for this item. Otherwise if epoll_ctl
> returns 0, then it is safe to delete the epoll item. This allows multiple
> threads to use a mutex to determine when it is safe to delete an epoll item
> and its associated resources, which allows epoll items to be deleted both
> efficiently and without error in a multi-threaded environment. Note that
> EPOLL_CTL_DISABLE is only useful in conjunction with EPOLLONESHOT, and using
> EPOLL_CTL_DISABLE on an epoll item without EPOLLONESHOT returns -EINVAL.
>
> This patch also adds a new test_epoll self-test program to both demonstrate
> the need for this feature and test it.
Thanks. I queued this for testing and for consideration for 3.8. I
shall send the revert patches in to Linus to remove this interface
change from 3.7.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: "Paton J. Lewis" <palewis@adobe.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Jason Baron <jbaron@redhat.com>, <linux-fsdevel@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, Paul Holland <pholland@adobe.com>,
Davide Libenzi <davidel@xmailserver.org>,
Michael Kerrisk <mtk.manpages@gmail.com>,
<libc-alpha@sourceware.org>, <linux-api@vger.kernel.org>,
<paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH v3] epoll: Support for disabling items, and a self-test app.
Date: Mon, 29 Oct 2012 13:42:23 -0700 [thread overview]
Message-ID: <20121029134223.81efcc00.akpm@linux-foundation.org> (raw)
In-Reply-To: <1351210112-23238-1-git-send-email-palewis@adobe.com>
On Thu, 25 Oct 2012 17:08:32 -0700
"Paton J. Lewis" <palewis@adobe.com> wrote:
> It is not currently possible to reliably delete epoll items when using the
> same epoll set from multiple threads. After calling epoll_ctl with
> EPOLL_CTL_DEL, another thread might still be executing code related to an
> event for that epoll item (in response to epoll_wait). Therefore the deleting
> thread does not know when it is safe to delete resources pertaining to the
> associated epoll item because another thread might be using those resources.
>
> The deleting thread could wait an arbitrary amount of time after calling
> epoll_ctl with EPOLL_CTL_DEL and before deleting the item, but this is
> inefficient and could result in the destruction of resources before another
> thread is done handling an event returned by epoll_wait.
>
> This patch enhances epoll_ctl to support EPOLL_CTL_DISABLE, which disables an
> epoll item. If epoll_ctl returns -EBUSY in this case, then another thread may
> handling a return from epoll_wait for this item. Otherwise if epoll_ctl
> returns 0, then it is safe to delete the epoll item. This allows multiple
> threads to use a mutex to determine when it is safe to delete an epoll item
> and its associated resources, which allows epoll items to be deleted both
> efficiently and without error in a multi-threaded environment. Note that
> EPOLL_CTL_DISABLE is only useful in conjunction with EPOLLONESHOT, and using
> EPOLL_CTL_DISABLE on an epoll item without EPOLLONESHOT returns -EINVAL.
>
> This patch also adds a new test_epoll self-test program to both demonstrate
> the need for this feature and test it.
Thanks. I queued this for testing and for consideration for 3.8. I
shall send the revert patches in to Linus to remove this interface
change from 3.7.
next prev parent reply other threads:[~2012-10-29 20:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-26 0:08 [PATCH v3] epoll: Support for disabling items, and a self-test app Paton J. Lewis
2012-10-26 0:08 ` Paton J. Lewis
2012-10-29 20:42 ` Andrew Morton [this message]
2012-10-29 20:42 ` Andrew Morton
[not found] ` <1351210112-23238-1-git-send-email-palewis-dv/VyGpifdQAvxtiuMwx3w@public.gmane.org>
2012-10-31 6:32 ` Michael Wang
2012-10-31 6:32 ` Michael Wang
2012-10-31 18:57 ` Paton J. Lewis
[not found] ` <5091749B.4060605-dv/VyGpifdQAvxtiuMwx3w@public.gmane.org>
2012-11-01 0:43 ` Michael Wang
2012-11-01 0:43 ` Michael Wang
2012-11-01 18:47 ` Paton J. Lewis
[not found] ` <5092C3B9.2070909-dv/VyGpifdQAvxtiuMwx3w@public.gmane.org>
2012-11-02 2:26 ` Michael Wang
2012-11-02 2:26 ` Michael Wang
2012-11-02 4:13 ` [RFC/PATCH] epoll: replace EPOLL_CTL_DISABLE with EPOLL_CTL_POKE Eric Wong
2012-11-03 1:10 ` Christof Meerwald
2012-11-06 21:58 ` Eric Wong
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=20121029134223.81efcc00.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=jbaron@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=palewis@adobe.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pholland@adobe.com \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.