All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Lianwei Wang <lianwei.wang@gmail.com>,
	linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: PATCH: freezer: add fake signal clearing back when thaw task
Date: Tue, 26 Feb 2013 15:54:12 +0100	[thread overview]
Message-ID: <20130226145412.GA31943@redhat.com> (raw)
In-Reply-To: <20130226141456.GB28940@redhat.com>

Damn.

Tejun, et all, sorry for confusion.

Somehow I misunderstood your email completely! as if you argue with
my "freezer: do not send a fake signal to a PF_DUMPCORE thread"
change http://marc.info/?l=linux-kernel&m=136173112604220

As for "add fake signal clearing back when thaw task", I do not
understand why do we need this change too, so I agree with you.

On 02/26, Oleg Nesterov wrote:
>
> On 02/25, Tejun Heo wrote:
> >
> > (cc'ing Rafael and Oleg and quoting whole body)
> >
> > On Thu, Feb 21, 2013 at 02:19:21PM +0800, Lianwei Wang wrote:
> > > Hi Tejun Heo and all,
> > >
> > > The commit of "34b087e freezer: kill unused
> > > set_freezable_with_signal()" remove recalc_sigpending*() calls in
> > > freezer, so the user tasks get TIF_SIGPENDING fake signal that is set
> > > when freezing userspace process. It left the fake signal to userspcae
> > > which cause the userspace task that wait_event_freezable and friends
> > > return a wrong ERESTARTSYS. This is not good because it waste cpu time
> > > to handle the fake signal.
> >
> > Is this even measureable?  Freeze / thaw isn't exactly a hot path and
> > I'm having difficult time believing -ERESTARTSYS would have a
> > noticeable impact on anything.  Can you please explain why this is a
> > problem?
>
> For example, wait_for_dump_helpers() can fail because it checks
> signal_pending(). And we can sleep in TASK_KILLABLE because pipe_release()
> does wake_up_interruptible(). But this is minor, wait_for_dump_helpers()
> could be fixed without this change.
>
> The real problem is dump_write-like code. Say, pipe_write() can fail if
> signal_pending() == T. I am not saying this is unsolvable, in fact I was
> going to add the freeze + recalc_sigpending + retry logic initially, but
> this looks soooo ugly.
>
> Also. Rightly or not, but I came to conclusion that this change is right
> even if we forget about killable/freezable problems in coredump. The
> coredumping thread is no longer a "real" user-space process. It can never
> handle the signals, it doesn't return to user-mode, but it does a lot of
> work in kernel space. So I think it should look as PF_KTHREAD to freezer.
> 
> > > Can we just call the recalc_sigpending to clear the fake signal for
> > > userspace tasks? as below patch do:
> > >
> > > +static void fake_signal_clear(struct task_struct *p)
> > > +{
> > > + unsigned long flags;
> > > +
> > > + if (lock_task_sighand(p, &flags)) {
> > > +     recalc_sigpending();
> > > +     unlock_task_sighand(p, &flags);
> > > + }
> 
> You know, _perhaps_ we have another reason for this change. Otherwise
> wait_event_freezable() doesn't look right. Or we should clarify that
> it is only for PF_KTHREAD but than we can simplify wait_event_freezable().
> And in this case I do not think we should reintroduce recalc_sigpending()
> removed by 34b087e48 "freezer: kill unused set_freezable_with_signal()".
> 
> I'll write another email about this, nobody actually need
> wait_event_freezable().
> 
> But. The change above can't help the coredumping thread. It still
> needs to do
> 
> 	spin_lock_irq(current->siglock);
> 	if (!__fatal_signal_pending(current))
> 		clear_thread_flag(TIF_SIGPENDING);
> 	spin_unlock_irq(current->siglock);
> 
> or we should change recalc_sigpending() to check PF_KTHREAD.
> 
> Oleg.


  reply	other threads:[~2013-02-26 14:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-21  6:19 PATCH: freezer: add fake signal clearing back when thaw task Lianwei Wang
2013-02-25 23:53 ` Tejun Heo
2013-02-26 14:14   ` Oleg Nesterov
2013-02-26 14:54     ` Oleg Nesterov [this message]
2013-02-26 14:28   ` Oleg Nesterov
2013-03-04  3:24   ` Lianwei Wang
2013-03-04 17:01     ` Tejun Heo
2013-03-04 17:32     ` 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=20130226145412.GA31943@redhat.com \
    --to=oleg@redhat.com \
    --cc=lianwei.wang@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.