public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Jan Kara <jack@suse.cz>, Wu Fengguang <fengguang.wu@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Unkillable R-state process stuck in sendfile
Date: Mon, 17 Feb 2014 16:51:37 +0400	[thread overview]
Message-ID: <530205D9.1010908@parallels.com> (raw)

Hi,

While running trinity syscall fuzzer I noticed that sometimes it does
not get killed immediately, even by SIGKILL - it takes several minutes
before it exits. What is interesting it "hangs" in R-state consuming
100% of CPU time. Analyzing its trace I found that it loops in
sendfile(2) with the out fd pointing to an evenfd object, i.e. it does
something like this:

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/eventfd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <limits.h>
#include <err.h>

#define SIZE            INT_MAX

int main()
{
        int in_fd, out_fd;
        ssize_t ret;

        in_fd = open("tmpfile", O_RDWR|O_CREAT, 0666);
        if (in_fd < 0)
                err(1, "open");
        if (ftruncate64(in_fd, SIZE) < 0)
                err(1, "ftruncate");
        out_fd = eventfd(0, 0);
        if (out_fd < 0)
                err(1, "eventfd");
        ret = sendfile64(out_fd, in_fd, NULL, SIZE);
        if (ret < 0)
                err(1, "sendfile");
}

This program will ignore SIGKILL for 2-5 minutes depending on how fast
the host processor is. This happens, because eventfd_write does not
check for pending signals when making progress (not waiting), neither
does file read.

I'm not sure if this is actually bad and should be fixed, but perhaps
it's worth making do_generic_file_read() check for fatal signals pending
and break the read loop if so?

FWIW, generic_perform_write() isn't prone to this problem, because
recently it was made interruptible by a fatal signal - see commit
a50527b19c62c ("fs: Make write(2) interruptible by a fatal signal").

Thanks.

             reply	other threads:[~2014-02-17 12:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-17 12:51 Vladimir Davydov [this message]
2014-02-18 19:13 ` Unkillable R-state process stuck in sendfile Valdis.Kletnieks
2014-02-19  6:38   ` Vladimir Davydov

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=530205D9.1010908@parallels.com \
    --to=vdavydov@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    /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