From: Oleg Nesterov <oleg@tv-sign.ru>
To: Roland McGrath <roland@redhat.com>
Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [BUG] signal: multithread program returns with wrong errno on receiving SIGSTOP
Date: Tue, 29 May 2007 23:22:43 +0400 [thread overview]
Message-ID: <20070529192243.GA189@tv-sign.ru> (raw)
In-Reply-To: <20070529073354.729431F8511@magilla.localdomain>
On 05/29, Roland McGrath wrote:
>
> Your fix seems like the only way to go. From skimming all the ERESTART*
> uses, I think that in all cases (except for n_tty.c:job_control before your
> patch), TIF_SIGPENDING is indeed set when a thread returns -ERESTART*.
>
> But it makes me realize that there is a danger of leaking a -ERESTART*
> return code to userland when TIF_SIGPENDING gets cleared by another thread
> doing a recalc_sigpending_tsk. Because of -ERESTART* I think we must make
> it a rule that no thread can clear another thread's TIF_SIGPENDING, only
> set it (unless it's known to be stopped in the signal code or something).
> >From our recent work on it, I think that do_sigaction is in fact the only
> place this can happen. So that says we should err in the other direction
> from what I said before in do_sigaction, and not have it do recalc at all.
I think you are right.
But please note that cancel_freezing(p) is special. It is also called when
try_to_freeze_tasks() fails. So it should clear TIF_SIGPENDING if "p" is a
kernel thread, otherwise p may run with signal_pending() forever.
Unfortunately, it is not easy to detect the kernel thread, is_user_space()
is not reliable. Probably we should ignore this minor problem and do not
change cancel_freezing().
Oleg.
next prev parent reply other threads:[~2007-05-29 19:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-28 7:07 [BUG] signal: multithread program returns with wrong errno on receiving SIGSTOP Oleg Nesterov
2007-05-28 9:58 ` Satoru Takeuchi
2007-05-28 10:13 ` Oleg Nesterov
2007-05-29 7:33 ` Roland McGrath
2007-05-29 19:22 ` Oleg Nesterov [this message]
2007-05-29 19:28 ` Roland McGrath
-- strict thread matches above, loose matches on Subject: below --
2007-05-28 2:32 Satoru Takeuchi
2007-05-29 8:03 ` Andrew Morton
2007-05-29 8:04 ` Roland McGrath
2007-05-29 8:09 ` Satoru Takeuchi
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=20070529192243.GA189@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--cc=roland@redhat.com \
--cc=takeuchi_satoru@jp.fujitsu.com \
/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.