On 2/4/25 19:46, Jens Axboe wrote:
If a wait_queue_entry is passed in to epoll_wait(), then utilize this
new helper for reaping events and/or adding to the epoll waitqueue
rather than calling the potentially sleeping ep_poll(). It works like
ep_poll(), except it doesn't block - it either returns the events that
are already available, or it adds the specified entry to the struct
eventpoll waitqueue to get a callback when events are triggered. It
returns -EIOCBQUEUED for that case.
Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
---
fs/eventpoll.c | 37 ++++++++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index ecaa5591f4be..a8be0c7110e4 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -2032,6 +2032,39 @@ static int ep_try_send_events(struct eventpoll *ep,
return res;
}
+static int ep_poll_queue(struct eventpoll *ep,
+ struct epoll_event __user *events, int maxevents,
+ struct wait_queue_entry *wait)
+{
+ int res, eavail;
+
+ /* See ep_poll() for commentary */
+ eavail = ep_events_available(ep);
+ while (1) {
+ if (eavail) {
+ res = ep_try_send_events(ep, events, maxevents);
+ if (res)
+ return res;
+ }
+
+ eavail = ep_busy_loop(ep, true);
I have doubts we want to busy loop here even if it's just one iteration /
nonblockinf. And there is already napi polling support in io_uring done
from the right for io_uring users spot.
--
Pavel Begunkov
