mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-kernel@vger.kernel.org, Jan Kara <jack@suse.cz>,
	Davide Libenzi <davidel@xmailserver.org>
Subject: Re: [patch] fs, epoll: short circuit fetching events if thread has been killed
Date: Tue, 9 May 2017 17:08:17 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1705091707340.112797@chino.kir.corp.google.com> (raw)
In-Reply-To: <20170509160520.a394a93544419eb53d2d0879@linux-foundation.org>

On Tue, 9 May 2017, Andrew Morton wrote:

> > We've encountered zombies that are waiting for a thread to exit that are
> > looping in ep_poll() almost endlessly although there is a pending SIGKILL
> > as a result of a group exit.
> > 
> > This happens because we always find ep_events_available() and fetch more
> > events and never are able to check for signal_pending() that would break
> > from the loop and return -EINTR.
> > 
> > Special case fatal signals and break immediately to guarantee that we
> > loop to fetch more events and delay making a timely exit.
> > 
> > It would also be possible to simply move the check for signal_pending()
> > higher than checking for ep_events_available(), but there have been no
> > reports of delayed signal handling other than SIGKILL preventing zombies
> > from exiting that would be fixed by this.
> 
> Any thoughts on the priority of this?  -stable?  If so, why?
> 

It fixes an issue for us where we have witnessed zombies sticking around 
for at least O(minutes), but considering the code has been like this 
forever and nobody else has complained that I have found, I would simply 
queue it up for 4.12.

  reply	other threads:[~2017-05-10  0:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04  0:22 David Rientjes
2017-05-09 23:05 ` Andrew Morton
2017-05-10  0:08   ` David Rientjes [this message]
2017-05-10 13:07 ` Michal Hocko

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=alpine.DEB.2.10.1705091707340.112797@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=davidel@xmailserver.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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

all inboxes | Powered by JetHome®