From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: "Kirill A. Shutemov" <kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Davide Libenzi <davidel-AhlLAIvw+VEjIGhXcJzhZg@public.gmane.org>,
Aaron Durbin <adurbin-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 1/4] eventfd: introduce eventfd_signal_hangup()
Date: Tue, 5 Feb 2013 11:40:50 +0800 [thread overview]
Message-ID: <51107F42.1090401@huawei.com> (raw)
In-Reply-To: <20130204101521.GA18322-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
On 2013/2/4 18:15, Kirill A. Shutemov wrote:
> On Sat, Feb 02, 2013 at 05:58:58PM +0200, Kirill A. Shutemov wrote:
>> On Sat, Feb 02, 2013 at 02:50:44PM +0800, Li Zefan wrote:
>>> When an eventfd is closed, a wakeup with POLLHUP will be issued,
>>> but cgroup wants to issue wakeup explicitly, so when a cgroup is
>>> removed userspace can be notified.
>>>
>>> Signed-off-by: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> Hm.. Looks like it will break eventfd semantics:
>
> 1. One eventfd can be used for deliver more then one notification from
> one or more cgroups. POLLHUP on removing one of cgroups is not valid.
>
> 2. It's valid to have eventfd opened only by one userspace application. We
> should not close it, just because cgroup is removed.
>
> I think problem with multiple threads waiting an event on eventfd should
> be handled in userspace.
>
I didn't realize this.. and if a cgroup is removed, the woken thread may not
be the thread that is waiting on this cgroup. How crappy.. I don't know how
userspace is going to deal with all these.
And another bug spotted. We can pass fd of memory.usage_in_bytes of cgroup A
to cgroup.event_control of cgroup B, and then we won't get memory usage
notification from A but B! What's worse, if A and B are in different mount
hierarchy, boom!
Signed-off-by: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
kernel/cgroup.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 3d21adf..e496359 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3825,6 +3825,7 @@ static int cgroup_write_event_control(struct cgroup *cgrp, struct cftype *cft,
const char *buffer)
{
struct cgroup_event *event = NULL;
+ struct cgroup *cgrp_cfile;
unsigned int efd, cfd;
struct file *efile = NULL;
struct file *cfile = NULL;
@@ -3880,6 +3881,16 @@ static int cgroup_write_event_control(struct cgroup *cgrp, struct cftype *cft,
goto fail;
}
+ /*
+ * The file to be monitored must be in the same cgroup as
+ * cgroup.event_control is.
+ */
+ cgrp_cfile = __d_cgrp(cfile->f_dentry->d_parent);
+ if (cgrp_cfile != cgrp) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
if (!event->cft->register_event || !event->cft->unregister_event) {
ret = -EINVAL;
goto fail;
--
1.8.0.2
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Tejun Heo <tj@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>,
Davide Libenzi <davidel@xmailserver.org>,
Aaron Durbin <adurbin@google.com>,
Greg Thelen <gthelen@google.com>
Subject: Re: [PATCH 1/4] eventfd: introduce eventfd_signal_hangup()
Date: Tue, 5 Feb 2013 11:40:50 +0800 [thread overview]
Message-ID: <51107F42.1090401@huawei.com> (raw)
In-Reply-To: <20130204101521.GA18322@shutemov.name>
On 2013/2/4 18:15, Kirill A. Shutemov wrote:
> On Sat, Feb 02, 2013 at 05:58:58PM +0200, Kirill A. Shutemov wrote:
>> On Sat, Feb 02, 2013 at 02:50:44PM +0800, Li Zefan wrote:
>>> When an eventfd is closed, a wakeup with POLLHUP will be issued,
>>> but cgroup wants to issue wakeup explicitly, so when a cgroup is
>>> removed userspace can be notified.
>>>
>>> Signed-off-by: Li Zefan <lizefan@huawei.com>
>
> Hm.. Looks like it will break eventfd semantics:
>
> 1. One eventfd can be used for deliver more then one notification from
> one or more cgroups. POLLHUP on removing one of cgroups is not valid.
>
> 2. It's valid to have eventfd opened only by one userspace application. We
> should not close it, just because cgroup is removed.
>
> I think problem with multiple threads waiting an event on eventfd should
> be handled in userspace.
>
I didn't realize this.. and if a cgroup is removed, the woken thread may not
be the thread that is waiting on this cgroup. How crappy.. I don't know how
userspace is going to deal with all these.
And another bug spotted. We can pass fd of memory.usage_in_bytes of cgroup A
to cgroup.event_control of cgroup B, and then we won't get memory usage
notification from A but B! What's worse, if A and B are in different mount
hierarchy, boom!
Signed-off-by: Li Zefan <lizefan@huawei.com>
---
kernel/cgroup.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 3d21adf..e496359 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3825,6 +3825,7 @@ static int cgroup_write_event_control(struct cgroup *cgrp, struct cftype *cft,
const char *buffer)
{
struct cgroup_event *event = NULL;
+ struct cgroup *cgrp_cfile;
unsigned int efd, cfd;
struct file *efile = NULL;
struct file *cfile = NULL;
@@ -3880,6 +3881,16 @@ static int cgroup_write_event_control(struct cgroup *cgrp, struct cftype *cft,
goto fail;
}
+ /*
+ * The file to be monitored must be in the same cgroup as
+ * cgroup.event_control is.
+ */
+ cgrp_cfile = __d_cgrp(cfile->f_dentry->d_parent);
+ if (cgrp_cfile != cgrp) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
if (!event->cft->register_event || !event->cft->unregister_event) {
ret = -EINVAL;
goto fail;
--
1.8.0.2
next prev parent reply other threads:[~2013-02-05 3:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-02 6:50 [PATCH 0/4] cgroup: bug fixes for eventfd Li Zefan
2013-02-02 6:50 ` Li Zefan
2013-02-02 6:51 ` [PATCH 2/4] cgroup: fix cgroup_rmdir() vs close(eventfd) race Li Zefan
[not found] ` <510CB763.3020700-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-02-02 15:59 ` Kirill A. Shutemov
2013-02-02 15:59 ` Kirill A. Shutemov
2013-02-02 6:51 ` [PATCH 3/4] eventfd: make operations on eventfd return -EIDRM if it's hung up Li Zefan
2013-02-02 16:12 ` Kirill A. Shutemov
[not found] ` <20130202161229.GB12939-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2013-02-04 3:15 ` Li Zefan
2013-02-04 3:15 ` Li Zefan
2013-02-02 6:51 ` [PATCH 4/4] cgroup: adapt to the new way of detecting cgroup removal Li Zefan
[not found] ` <510CB733.2080904-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-02-02 6:50 ` [PATCH 1/4] eventfd: introduce eventfd_signal_hangup() Li Zefan
2013-02-02 6:50 ` Li Zefan
[not found] ` <510CB744.7000300-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-02-02 15:58 ` Kirill A. Shutemov
2013-02-02 15:58 ` Kirill A. Shutemov
[not found] ` <20130202155858.GA13022-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2013-02-04 10:15 ` Kirill A. Shutemov
2013-02-04 10:15 ` Kirill A. Shutemov
[not found] ` <20130204101521.GA18322-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2013-02-05 3:40 ` Li Zefan [this message]
2013-02-05 3:40 ` Li Zefan
[not found] ` <51107F42.1090401-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-02-05 8:28 ` Kirill A. Shutemov
2013-02-05 8:28 ` Kirill A. Shutemov
2013-02-06 1:48 ` Li Zefan
[not found] ` <5111B664.5050606-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-02-06 14:53 ` Kirill A. Shutemov
2013-02-06 14:53 ` Kirill A. Shutemov
2013-02-02 6:59 ` [PATCH 0/4] cgroup: bug fixes for eventfd Li Zefan
2013-02-02 6:59 ` Li Zefan
2013-02-04 19:27 ` Tejun Heo
2013-02-04 19:27 ` Tejun Heo
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=51107F42.1090401@huawei.com \
--to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=adurbin-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=davidel-AhlLAIvw+VEjIGhXcJzhZg@public.gmane.org \
--cc=gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/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.