From: Roland McGrath <roland@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
paul@mad-scientist.net, linux-kernel@vger.kernel.org,
stable@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH] coredump: Retry writes where appropriate
Date: Mon, 1 Jun 2009 16:02:10 -0700 (PDT) [thread overview]
Message-ID: <20090601230210.C0B15FC3C7@magilla.sf.frob.com> (raw)
In-Reply-To: Oleg Nesterov's message of Tuesday, 2 June 2009 00:32:41 +0200 <20090601223241.GA26788@redhat.com>
> I don't think ->real_blocked is a good choice, we have to add more checks
> to the signal sending path. Note that currenly it is only checked under
> sig_fatal() && !SIGNAL_GROUP_EXIT.
No, you're right. It's not a good idea.
> Perhaps it is easier to change dump_write() to clear TIF_SIGPENDING
> unless fatal_signal_pending(),
That is almost a separate subject, really. Having i/o calls' waits wrongly
interrupted and then clearing TIF_SIGPENDING just seems goofy to me. It
might not be just the ->write call, it might affect filp_open or dump_seek
or whatever. It makes no sense to me to take the approach of fiddling
after doing the wrong thing. Just don't do the wrong thing to begin with.
That means clear TIF_SIGPENDING and don't let it be set again by a signal
that is not meant to abort the core dump. Why do anything but that?
It's almost certain that recalc_sigpending_tsk won't be called once dumping
has started. But there is the possibility of recalc_sigpending_and_wake
via cancel_freezing, at least. Seems safer to make recalc_sigpending_tsk
robust in this case.
Thanks,
Roland
next prev parent reply other threads:[~2009-06-01 23:03 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-31 5:33 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
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 [this message]
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=20090601230210.C0B15FC3C7@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=paul@mad-scientist.net \
--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 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®