From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752959AbdEJNHy (ORCPT ); Wed, 10 May 2017 09:07:54 -0400 Received: from mx2.suse.de ([195.135.220.15]:37432 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752881AbdEJNHv (ORCPT ); Wed, 10 May 2017 09:07:51 -0400 Date: Wed, 10 May 2017 15:07:49 +0200 From: Michal Hocko To: David Rientjes Cc: Andrew Morton , Alexander Viro , linux-kernel@vger.kernel.org Subject: Re: [patch] fs, epoll: short circuit fetching events if thread has been killed Message-ID: <20170510130749.GA31471@dhcp22.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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