All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Lianwei Wang <lianwei.wang@gmail.com>
Cc: Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: PATCH: freezer: add fake signal clearing back when thaw task
Date: Mon, 4 Mar 2013 18:32:31 +0100	[thread overview]
Message-ID: <20130304173231.GA5442@redhat.com> (raw)
In-Reply-To: <CAJFUiJjy-7sS9xH76XMLs5SU6fUQ1Bk4Xn67jjHeZNQRjC54dg@mail.gmail.com>

On 03/04, Lianwei Wang wrote:
>
> Freeze/Thaw is a hot path for the Linux based mobile OS, e.g. Android.
> If we don't remove the pending fake signal, then the user space apps
> or the related kernel driver has to handle such error.

But if we add recalc_sigpending() we penalize the common case which
doesn't need this.

> And yes, the
> user can handle such case by checking the return value,

Yes.

> but it mislead
> the user and confuse to them that why wait_event_freezable and friends
> return a error on resume path every time? Can we avoid such useless
> error return?

Agreed, it looks strange. It is only for kthreads, I think. And we can
simplify wait_event_freezable() or even kill it.

But if we add new user-space users, I do not know... Fortunately I am
not maintainer ;)

> >> +static void fake_signal_clear(struct task_struct *p)
> >> +{
> >> + unsigned long flags;
> >> +
> >> + if (lock_task_sighand(p, &flags)) {
> >> +     recalc_sigpending();

This looks strange. p is always current, otherwise recalc_sigpending()
can't help.

And since it is current you do not need lock_task_sighand().

Oleg.


      parent reply	other threads:[~2013-03-04 17:34 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
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 [this message]

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=20130304173231.GA5442@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.