Received-SPF: pass (google.com: domain of linux-kernel+bounces-96499-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Imran Khan <imran.f.khan@oracle.com>
To: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH] eventpoll: record task that adds to monitor list.
Date: Fri,  8 Mar 2024 15:21:36 +1100
Message-Id: <20240308042136.2739321-1-imran.f.khan@oracle.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

While debugging latency issues for task waiting on epoll_wait, sometimes
it becomes necessary to see if the lower layer is invoking ep_poll_callback
timely for a given pid or not.

Recording task_struct in involved eppoll_entry's wait_queue_entry, allows us
to check this using a probe (say dtrace) at this function.
We could also achieve this by checking wait_queue_entry on eventpoll's
wait_queue_head itself, but that would involve more indirections.

Signed-off-by: Imran Khan <imran.f.khan@oracle.com>
---

Since it just helps in debugging, I have kept the patch RFC.

 fs/eventpoll.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 3534d36a1474..3d4faf0a2d25 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1287,6 +1287,8 @@ static void ep_ptable_queue_proc(struct file *file, wait_queue_head_t *whead,
 	init_waitqueue_func_entry(&pwq->wait, ep_poll_callback);
 	pwq->whead = whead;
 	pwq->base = epi;
+	pwq->wait.private = current;
+
 	if (epi->event.events & EPOLLEXCLUSIVE)
 		add_wait_queue_exclusive(whead, &pwq->wait);
 	else
-- 
2.34.1