From: Soheil Hassas Yeganeh <soheil.kdev@gmail.com>
To: torvalds@linux-foundation.org, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
dave@stgolabs.net, edumazet@google.com, willemb@google.com,
khazhy@google.com, guantaol@google.com,
Soheil Hassas Yeganeh <soheil@google.com>
Subject: [PATCH 3/8] epoll: pull fatal signal checks into ep_send_events()
Date: Fri, 6 Nov 2020 18:16:30 -0500 [thread overview]
Message-ID: <20201106231635.3528496-4-soheil.kdev@gmail.com> (raw)
In-Reply-To: <20201106231635.3528496-1-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil@google.com>
To simplify the code, pull in checking the fatal signals into
ep_send_events(). ep_send_events() is called only from ep_poll().
Note that, previously, we were always checking fatal events, but
it is checked only if eavail is true. This should be fine because
the goal of that check is to quickly return from epoll_wait() when
there is a pending fatal signal.
Suggested-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Khazhismel Kumykov <khazhy@google.com>
---
fs/eventpoll.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 80c560dad6a3..ed9deeab2488 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1780,6 +1780,14 @@ static int ep_send_events(struct eventpoll *ep,
{
struct ep_send_events_data esed;
+ /*
+ * Always short-circuit for fatal signals to allow threads to make a
+ * timely exit without the chance of finding more events available and
+ * fetching repeatedly.
+ */
+ if (fatal_signal_pending(current))
+ return -EINTR;
+
esed.maxevents = maxevents;
esed.events = events;
@@ -1931,15 +1939,6 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
}
send_events:
- if (fatal_signal_pending(current)) {
- /*
- * Always short-circuit for fatal signals to allow
- * threads to make a timely exit without the chance of
- * finding more events available and fetching
- * repeatedly.
- */
- return -EINTR;
- }
/*
* Try to transfer events to user space. In case we get 0 events and
* there's still timeout left over, we go trying again in search of
--
2.29.1.341.ge80a0c044ae-goog
next prev parent reply other threads:[~2020-11-06 23:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 23:16 [PATCH 0/8] simplify ep_poll Soheil Hassas Yeganeh
2020-11-06 23:16 ` [PATCH 1/8] epoll: check for events when removing a timed out thread from the wait queue Soheil Hassas Yeganeh
2020-11-10 6:05 ` Davidlohr Bueso
2020-11-06 23:16 ` [PATCH 2/8] epoll: simplify signal handling Soheil Hassas Yeganeh
2020-11-06 23:16 ` Soheil Hassas Yeganeh [this message]
2020-11-06 23:16 ` [PATCH 4/8] epoll: move eavail next to the list_empty_careful check Soheil Hassas Yeganeh
2020-11-06 23:16 ` [PATCH 5/8] epoll: simplify and optimize busy loop logic Soheil Hassas Yeganeh
2020-11-06 23:16 ` [PATCH 6/8] epoll: pull all code between fetch_events and send_event into the loop Soheil Hassas Yeganeh
2020-11-06 23:16 ` [PATCH 7/8] epoll: replace gotos with a proper loop Soheil Hassas Yeganeh
2020-11-06 23:16 ` [PATCH 8/8] epoll: eliminate unnecessary lock for zero timeout Soheil Hassas Yeganeh
2020-11-06 23:35 ` [PATCH 0/8] simplify ep_poll Linus Torvalds
2020-11-08 1:43 ` Andrew Morton
2020-11-08 4:45 ` Soheil Hassas Yeganeh
2020-11-09 18:59 ` Davidlohr Bueso
2020-11-09 19:28 ` Soheil Hassas Yeganeh
2020-11-10 22:05 ` Andrew Morton
2020-11-11 3:37 ` Soheil Hassas Yeganeh
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=20201106231635.3528496-4-soheil.kdev@gmail.com \
--to=soheil.kdev@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=edumazet@google.com \
--cc=guantaol@google.com \
--cc=khazhy@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=soheil@google.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willemb@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).