All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mandeep Singh Baines <msb@chromium.org>,
	Neil Horman <nhorman@redhat.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] coredump: introduce dump_interrupted()
Date: Sat, 9 Mar 2013 20:16:43 +0100	[thread overview]
Message-ID: <20130309191643.GB778@redhat.com> (raw)
In-Reply-To: <20130308132046.02e2e6ac44a9fc4e63ed6604@linux-foundation.org>

On 03/08, Andrew Morton wrote:
>
> On Fri, 8 Mar 2013 18:59:15 +0100 Oleg Nesterov <oleg@redhat.com> wrote:
>
> > Change dump_write(), dump_seek() and do_coredump() to check
> > signal_pending() and abort if it is true.
>
> hm, why.

Firstly. we need these changes to ensure that the coredump won't delay
suspend, and to ensure it reacts to SIGKILL "quickly enough". A core
dump can take a lot of time.

> I think we're missing some context here - this is to support freezing,
> yes?

No. This is to document that

	- currently we do not support freezing

	- why we do not support, and what should we do to support
	  (the comments in dump_interrupted/wait_for_dump_helpers)

If do_coredump() "races" with suspend/etc we simply abort, hopefully
this is fine in practice. And even if we decide to change this later,
I hope this series can be counted as a preparation.

> An example of why this is needed: the dump_interrupted() check which
> was added to dump_seek() is just weird.  An lseek is instantaneous,
                                                       ^^^^^^^^^^^^^
Oh, I simply do not know, this can depend on the filesystem?

> And if the file doesn't support lseek (do such files exist?  should we
> be returning 0 instead of -ENOMEM?),

(can't comment, I do not know)

> we just sit there in a loop
> extending the file with write().  This can take *ages*, but this part
> of dump_seek() *didn't* get the signal check!

The loop does dump_write() which checks dump_interrupted() at the start.

> > Ideally it should do try_to_freeze() but then we need the unpleasant
> > changes in dump_write() and wait_for_dump_helpers(). So far we simply
> > accept the fact that the freezer can truncate a core-dump but at least
> > you can reliably suspend.
>
> OK, so there is some connection between this and suspending.  Details,
> please...

It is not trivial to change dump_write() to restart if f_op->write()
fails because of freezing(). We need to handle the short writes, we need
to clear TIF_SIGPENDING (and we can't rely on recalc_sigpending() unless
we change it to check PF_DUMPCORE), and somehow we need to avoid the
races with freeze_task + __thaw_task.

Everything looks possible but imho doesn't worth a trouble, a coredump
truncated by freezer is tolerable. I hope. And again, even if we decide
to "fix" this problem we can do this on top of these changes.

Oleg.


  reply	other threads:[~2013-03-09 19:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-08 17:58 [PATCH -mm 0/3] coredump: signal_pending() checks and cleanups Oleg Nesterov
2013-03-08 17:59 ` [PATCH 1/3] coredump: introduce dump_interrupted() Oleg Nesterov
2013-03-08 20:54   ` Mandeep Singh Baines
2013-03-09 18:48     ` Oleg Nesterov
2013-03-08 21:20   ` Andrew Morton
2013-03-09 19:16     ` Oleg Nesterov [this message]
2013-03-08 17:59 ` [PATCH 2/3] coredump: factor out the setting of PF_DUMPCORE Oleg Nesterov
2013-03-08 20:21   ` Mandeep Singh Baines
2013-03-08 17:59 ` [PATCH 3/3] coredump: change wait_for_dump_helpers() to use wait_event_interruptible() Oleg Nesterov
2013-03-08 20:22   ` Mandeep Singh Baines

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=20130309191643.GB778@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msb@chromium.org \
    --cc=nhorman@redhat.com \
    --cc=rjw@sisk.pl \
    --cc=tj@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.