[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171028135854.mpdcngbkozssucrs@linux-n805>
Date: Sat, 28 Oct 2017 06:58:54 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Hou Tao <houtao1@...wei.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
viro@...iv.linux.org.uk, jbaron@...mai.com, oleg@...hat.com,
koct9i@...il.com
Subject: Re: [RFC][PATCH 1/8] epoll: remove epmutex from ep_free() &
eventpoll_release_file()
On Sat, 28 Oct 2017, Hou Tao wrote:
>Remove the global epmutex from ep_free() and eventpoll_release_file().
>In the later patches, we will add locks with a smaller granularity
>to serve the same purposes of epmutex.
>
>Signed-off-by: Hou Tao <houtao1@...wei.com>
>---
> fs/eventpoll.c | 4 ----
> 1 file changed, 4 deletions(-)
>
>diff --git a/fs/eventpoll.c b/fs/eventpoll.c
>index 2fabd19..26ab0c5 100644
>--- a/fs/eventpoll.c
>+++ b/fs/eventpoll.c
>@@ -835,7 +835,6 @@ static void ep_free(struct eventpoll *ep)
> * anymore. The only hit might come from eventpoll_release_file() but
> * holding "epmutex" is sufficient here.
> */
^^
What about this comment (and the equivalent one in eventpoll_release_file()?
>- mutex_lock(&epmutex);
...even if you fix it in a later patch, this patch breaks bisection. Now
we just race between ep_free() and eventpoll_release_file(). This patch
should be folded in, no?
Thanks,
Davidlohr
Powered by blists - more mailing lists