From: Oleg Nesterov <oleg@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: paul@mad-scientist.net, linux-kernel@vger.kernel.org,
stable@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>,
Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH] coredump: Retry writes where appropriate
Date: Mon, 1 Jun 2009 18:12:34 +0200 [thread overview]
Message-ID: <20090601161234.GA10486@redhat.com> (raw)
In-Reply-To: <20090531111851.07eb1df3@lxorguk.ukuu.org.uk>
On 05/31, Alan Cox wrote:
>
> On Sun, 31 May 2009 01:33:39 -0400
> Paul Smith <paul@mad-scientist.net> wrote:
>
> > coredump: Retry writes where appropriate
> >
> > Core dump write operations (especially to a pipe) can be incomplete due
> > to signal reception or possibly recoverable partial writes.
>
> NAK this
>
> > Previously any incomplete write in the ELF core dumper caused the core
> > dump to stop, giving short cores in these cases. Modify the core dumper
> > to retry the write where appropriate.
>
> The existing behaviour is an absolute godsend when you've something like
> a core dump stuck on an NFS mount or something trying to core dump to
> very slow media.
I agree, we should make the coredumping interruptible.
But I don't know which signal should intterrupt. At least SIGKILL should,
I think. As for other unhandled sig_fatal() signals, I am nor sure.
I can make a patch, but first I need to know what this patch should do.
Again, please look at:
killable/interruptible coredumps
http://marc.info/?l=linux-kernel&m=121665710711931
And we should not change dump_write(), we should create the new helper
which can be used by all fs/binfmt_*.c.
And of course, the coredumping thread should not play with ->blocked
or ->sighand->action. This is not even needed.
Oleg.
next prev parent reply other threads:[~2009-06-01 16:18 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-31 5:33 [PATCH] coredump: Retry writes where appropriate Paul Smith
2009-05-31 10:18 ` Alan Cox
2009-05-31 14:03 ` Olivier Galibert
2009-05-31 16:31 ` Alan Cox
2009-05-31 16:49 ` Olivier Galibert
2009-05-31 17:46 ` Paul Smith
2009-05-31 16:56 ` Paul Smith
2009-06-01 16:12 ` Oleg Nesterov [this message]
2009-06-01 16:41 ` Alan Cox
2009-06-01 17:11 ` Oleg Nesterov
2009-06-01 17:46 ` Alan Cox
2009-06-01 18:23 ` Oleg Nesterov
2009-06-01 20:38 ` Roland McGrath
2009-06-01 22:32 ` Oleg Nesterov
2009-06-01 23:02 ` Roland McGrath
2009-06-02 0:08 ` Oleg Nesterov
2009-06-03 7:09 ` Roland McGrath
2009-06-04 3:15 ` Oleg Nesterov
2009-06-04 17:14 ` Roland McGrath
2009-06-23 17:31 ` Paul Smith
2009-06-23 19:37 ` Oleg Nesterov
2009-07-07 19:37 ` Oleg Nesterov
2009-06-02 8:21 ` Alan Cox
2009-06-02 15:29 ` Oleg Nesterov
2009-06-03 7:15 ` Roland McGrath
2009-06-03 14:05 ` Paul Smith
2009-06-01 17:36 ` Paul Smith
2009-06-01 17:49 ` Alan Cox
2009-06-01 18:39 ` Paul Smith
2009-06-01 19:02 ` Alan Cox
2009-06-01 19:09 ` Andi Kleen
2009-06-01 19:06 ` Alan Cox
2009-06-01 19:14 ` Andi Kleen
2009-06-01 19:51 ` Paul Smith
2009-06-01 20:20 ` Oleg Nesterov
2009-06-01 21:34 ` Alan Cox
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=20090601161234.GA10486@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@mad-scientist.net \
--cc=roland@redhat.com \
--cc=stable@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.