All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Mandeep Singh Baines <msb@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.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 v2 2/3] freezer: do not send a fake signal to a PF_DUMPCORE thread
Date: Wed, 27 Feb 2013 19:08:44 +0100	[thread overview]
Message-ID: <20130227180844.GA6015@redhat.com> (raw)
In-Reply-To: <CACBanvr5vbkH1J+waRHMBq8hRuKqJtF0sD0+95v6Qmnd=3Zd_w@mail.gmail.com>

On 02/26, Mandeep Singh Baines wrote:
>
> >> Change freeze_task() to check PF_DUMPCORE along with PF_KTHREAD. We
> >> need to recheck PF_DUMPCORE under ->siglock to avoid the race with
> >> zap_threads() which can set this flag right before we take the lock.
> >>
> >
> > Won't this prevent suspend?

Hmm. I guess you mean that pipe_write() can hang in pipe_wait() if the
user-space handler was already freezed... Damn, and I even mentioned
this race when we discussed this 2 weeks ago.

I need to think, but most probably you are right, and we need another
solution...

> You'd rather have reliable suspend than coredumps that aren't
> truncated so you need to set TIF_SIGPENDING to break waits in the
> dump_write path.

Oh, I agree. In this case the necessary changes look simple.

> static void wait_for_dump_helpers(struct file *file)
> {
>         struct pipe_inode_info *pipe;
>
>         pipe = file->f_path.dentry->d_inode->i_pipe;
>
>         pipe_lock(pipe);
>         pipe->readers++;
>         pipe->writers--;
>
>         while (pipe->readers > 1) {
>                 unsigned long flags;
>
>                 wake_up_interruptible_sync(&pipe->wait);
>                 kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
>                 pipe_wait(pipe);
>
>                 pipe_unlock(pipe);
>                 try_to_freeze();
>                 pipe_lock(pipe);
>
>                 if (fatal_signal_pending(current))
>                         break;
>
>                 /* Clear fake signal from freeze_task(). */
>                 spin_lock_irqsave(&current->sighand->siglock, flags);
>                 recalc_sigpending();
>                 spin_unlock_irqrestore(&current->sighand->siglock, flags);

IIRC, this is what you added into your tree. But note that
recalc_sigpending() is wrong, exactly because (say) SIGCHLD can
be pending if it was sent before we set SIGNAL_GROUP_COREDUMP.

So this code needs something like

	spin_lock_irq(siglock);
	if (!fatal_signal_pending)
		clear_thread_flag(TIF_SIGPENDING);
	spin_unlock_irq(siglock);

Or we need to change recalc_sigpending() to check SIGNAL_GROUP_COREDUMP
or PF_DUMPCORE. I'd like to avoid this, but perhaps we have to do this...

(Btw, this is offtopic, but whatever we do 3/3 still looks like a nice
 cleanup to me, although it probably needs more changes)

> What do you think? That would fix most cases. You'll still get a
> truncated core if you were to receive the signal during pipe_write or
> something.

Let me think a bit...

Right now I can only say that personally I do not really like the
idea to fix wait_for_dump_helpers() but not pipe_write(). I mean,
if pipe_write() can fail due to freezing(), then why should we care
about wait_for_dump_helpers() ? Let them all fail, suspend is not
that often.

Or we should try to make everything freezer-friendly. But if
freeze_task() sets TIF_SIGPENDING then we need the ugly "retry"
logic in dump_write()... Not good.

Thanks Mandeep. If you have other ideas please tell me ;)

Oleg.


  reply	other threads:[~2013-02-27 18:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-24 17:31 [PATCH -mm 0/3] coredump: make it freezable (almost) Oleg Nesterov
2013-02-24 17:32 ` [PATCH 1/3] coredump: factor out the setting of PF_DUMPCORE Oleg Nesterov
2013-02-24 17:32 ` [PATCH 2/3] freezer: do not send a fake signal to a PF_DUMPCORE thread Oleg Nesterov
2013-02-24 18:36   ` [PATCH v2 " Oleg Nesterov
2013-02-24 23:39     ` Rafael J. Wysocki
2013-02-26 16:37     ` Mandeep Singh Baines
2013-02-26 19:43       ` Mandeep Singh Baines
2013-02-27 18:08         ` Oleg Nesterov [this message]
2013-02-27 18:55           ` Oleg Nesterov
2013-02-28 15:39           ` Mandeep Singh Baines
2013-02-24 17:32 ` [PATCH 3/3] coredump: make wait_for_dump_helpers() freezable Oleg Nesterov
2013-02-28 20:19   ` Mandeep Singh Baines
2013-02-24 18:09 ` [PATCH -mm 0/3] coredump: make it freezable (almost) Oleg Nesterov
2013-02-25 23:05 ` Andrew Morton
2013-02-28 18:46   ` Oleg Nesterov

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=20130227180844.GA6015@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.