[PATCH] epoll: clear the tfile_check_list on -ELOOP

[PATCH] epoll: clear the tfile_check_list on -ELOOP

[Jason Baron]

An epoll_ctl(,EPOLL_CTL_ADD,,) operation can return '-ELOOP' to prevent
circular epoll dependencies from being created. However, in that case
we do not properly clear the 'tfile_check_list'. Thus, add a call to
clear_tfile_check_list() for the -ELOOP case.

Reported-by: Yurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru>
Tested-by: Alexandra N. Kossovsky <Alexandra.Kossovsky@oktetlabs.ru>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
 fs/eventpoll.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 739b098..c0b3c70 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1663,8 +1663,10 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
 	if (op == EPOLL_CTL_ADD) {
 		if (is_file_epoll(tfile)) {
 			error = -ELOOP;
-			if (ep_loop_check(ep, tfile) != 0)
+			if (ep_loop_check(ep, tfile) != 0) {
+				clear_tfile_check_list();
 				goto error_tgt_fput;
+			}
 		} else
 			list_add(&tfile->f_tfile_llink, &tfile_check_list);
 	}
-- 
1.7.7.6

Re: [PATCH] epoll: clear the tfile_check_list on -ELOOP

[Andrew Morton]

On Tue, 17 Apr 2012 10:34:52 -0400
Jason Baron <jbaron@redhat.com> wrote:

> An epoll_ctl(,EPOLL_CTL_ADD,,) operation can return '-ELOOP' to prevent
> circular epoll dependencies from being created. However, in that case
> we do not properly clear the 'tfile_check_list'. Thus, add a call to
> clear_tfile_check_list() for the -ELOOP case.

So here I am wondering what effect this bug has upon our users, so I
can decide which kernel versions should be fixed.  Jason didn't tell me
so I went to read the description of clear_tfile_check_list().  After a
brief chuckle, I stopped.

I then found Yurij's original report, so I know what's going on.  But I
still can't write your changelog because I don't know whether this is a
regression and if it is, which patch caused the regression.

Wanna help out here please?

Re: [PATCH] epoll: clear the tfile_check_list on -ELOOP

[Alexandra N. Kossovsky]

On Tue, Apr 17, 2012 at 02:13:15PM -0700, Andrew Morton wrote:
> On Tue, 17 Apr 2012 10:34:52 -0400
> Jason Baron <jbaron@redhat.com> wrote:
> 
> > An epoll_ctl(,EPOLL_CTL_ADD,,) operation can return '-ELOOP' to prevent
> > circular epoll dependencies from being created. However, in that case
> > we do not properly clear the 'tfile_check_list'. Thus, add a call to
> > clear_tfile_check_list() for the -ELOOP case.
> 
> So here I am wondering what effect this bug has upon our users, so I
> can decide which kernel versions should be fixed.  Jason didn't tell me
> so I went to read the description of clear_tfile_check_list().  After a
> brief chuckle, I stopped.
> 
> I then found Yurij's original report, so I know what's going on.  But I
> still can't write your changelog because I don't know whether this is a
> regression and if it is, which patch caused the regression.

It is a regression, somewhere between 3.2.6 and 3.2.9.
Yurij and me blame
commit 203aa5260edca2ab1872ad8b08386d874f7132f3
Author: Jason Baron <jbaron@redhat.com>
Date:   Thu Jan 12 17:17:43 2012 -0800
but we have not tested it.

-- 
Alexandra N. Kossovsky
OKTET Labs (http://www.oktetlabs.ru/)

Re: [PATCH] epoll: clear the tfile_check_list on -ELOOP

[Jason Baron]

On Wed, Apr 18, 2012 at 08:56:15AM +0400, Alexandra N. Kossovsky wrote:
> On Tue, Apr 17, 2012 at 02:13:15PM -0700, Andrew Morton wrote:
> > On Tue, 17 Apr 2012 10:34:52 -0400
> > Jason Baron <jbaron@redhat.com> wrote:
> > 
> > > An epoll_ctl(,EPOLL_CTL_ADD,,) operation can return '-ELOOP' to prevent
> > > circular epoll dependencies from being created. However, in that case
> > > we do not properly clear the 'tfile_check_list'. Thus, add a call to
> > > clear_tfile_check_list() for the -ELOOP case.
> > 
> > So here I am wondering what effect this bug has upon our users, so I
> > can decide which kernel versions should be fixed.  Jason didn't tell me
> > so I went to read the description of clear_tfile_check_list().  After a
> > brief chuckle, I stopped.
> > 
> > I then found Yurij's original report, so I know what's going on.  But I
> > still can't write your changelog because I don't know whether this is a
> > regression and if it is, which patch caused the regression.
> 
> It is a regression, somewhere between 3.2.6 and 3.2.9.
> Yurij and me blame
> commit 203aa5260edca2ab1872ad8b08386d874f7132f3
> Author: Jason Baron <jbaron@redhat.com>
> Date:   Thu Jan 12 17:17:43 2012 -0800
> but we have not tested it.
> 

Right, I introduced this with the upstream commit:

commit 28d82dc1c4edbc352129f97f4ca22624d1fe61de
Author: Jason Baron <jbaron@redhat.com>
Date:   Thu Jan 12 17:17:43 2012 -0800

    epoll: limit paths

So yes, this is a newly introduced regression.

Thanks,

-Jason