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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 10 May 2017 15:07:49 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     David Rientjes <rientjes@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        linux-kernel@...r.kernel.org
Subject: Re: [patch] fs, epoll: short circuit fetching events if thread has
 been killed

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