Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1638805

Re: [patch] fs, epoll: short circuit fetching events if thread has been killed

Show all headers | View raw

On Wed 03-05-17 17:22:53, David Rientjes wrote:
[...]
> @@ -1748,6 +1748,16 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
>  			 * to TASK_INTERRUPTIBLE before doing the checks.
>  			 */
>  			set_current_state(TASK_INTERRUPTIBLE);
> +			/*
> +			 * 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)) {
> +				res = -EINTR;
> +				break;
> +			}
>  			if (ep_events_available(ep) || timed_out)
>  				break;
>  			if (signal_pending(current)) {

I am wondering. Is there any specific reason why we do not break out of
the loop before checking ep_events_available on any pending signal? Is
there any advantage to preempt signal handling by too many events?

I've tried to dig it out from the full history git tree but it goes all
the way down to "[PATCH] epoll update r3".

-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[patch] fs, epoll: short circuit fetching events if thread has been  killed David Rientjes <rientjes@google.com> - 2017-05-04 02:30 +0200
  Re: [patch] fs, epoll: short circuit fetching events if thread has  been killed Andrew Morton <akpm@linux-foundation.org> - 2017-05-10 01:10 +0200
    Re: [patch] fs, epoll: short circuit fetching events if thread has  been killed David Rientjes <rientjes@google.com> - 2017-05-10 02:10 +0200
  Re: [patch] fs, epoll: short circuit fetching events if thread has  been killed Michal Hocko <mhocko@kernel.org> - 2017-05-10 15:10 +0200

csiph-web