LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jiri Kosina <jkosina@suse.cz>
To: Roland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>,
Davide Libenzi <davidel@xmailserver.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RFC] fix missed SIGCONT cases
Date: Wed, 27 Feb 2008 23:04:38 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.64.0802272258150.3391@jikos.suse.cz> (raw)
In-Reply-To: <20080227210038.93AFC2700FD@magilla.localdomain>
On Wed, 27 Feb 2008, Roland McGrath wrote:
> Have you observed an actual problem? I don't think the "race" you seem
> to be concerned about is a problem at all.
> The comment refers to the necessary atomicity of posting the signal along
> with doing the wakeups. Those are done together with the siglock held.
> It does not matter that the siglock was dropped and reacquired before
> there.
What happens here is that the proces that was woken-up is spinning on the
siglock even before the actual SIGCONT has been queued. When this lock is
released, the process continues executing, and its SIGCONT handler doesn't
run, even though it executes _just because_ it was woken up by SIGCONT.
Let's take this as an example:
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
volatile int sigcont_received = 0;
static void sigcont_handler(int signo)
{
sigcont_received = 1;
}
int main(int argc, char **argv)
{
struct sigaction action;
memset(&action, 0, sizeof(action));
action.sa_handler = sigcont_handler;
sigemptyset(&action.sa_mask);
if (sigaction(SIGCONT, &action, NULL) != 0) {
fprintf(stderr, "sigaction() failed\n");
return 1;
}
while (1) {
if (kill(getpid(), SIGSTOP) != 0) {
printf("could not send SIGSTOP to self\n");
return 1;
}
if (sigcont_received)
printf("finished (SIGCONT received)\n");
else
printf("finished (without SIGCONT)\n");
sigcont_received = 0;
}
return 0;
}
Do you agree that when you run this program, and once it gets stopped
(sends SIGSTOP to itself), send SIGCONT to it. It should always print
finished (SIGCONT received)
right? Without my patch, sometimes
finished (without SIGCONT)
can be observed (for some reason, it seems to trigger more often on ia64
machines than on any x86 hardware).
Thanks,
--
Jiri Kosina
SUSE Labs
next prev parent reply other threads:[~2008-02-27 22:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-27 15:22 Jiri Kosina
2008-02-27 21:00 ` Roland McGrath
2008-02-27 22:04 ` Jiri Kosina [this message]
2008-02-28 10:26 ` Roland McGrath
2008-02-28 11:42 ` Jiri Kosina
2008-02-28 15:32 ` Oleg Nesterov
2008-02-28 15:32 ` Jiri Kosina
2008-02-28 15:30 ` Oleg Nesterov
2008-02-28 15:40 ` Jiri Kosina
2008-02-28 16:08 ` Oleg Nesterov
2008-02-28 16:13 ` Jiri Kosina
2008-02-28 16:45 ` [PATCH] handle_stop_signal: don't wake up the stopped task until it sees SIGCONT Oleg Nesterov
2008-02-28 16:56 ` Jiri Kosina
2008-02-29 2:39 ` [PATCH] [RFC] fix missed SIGCONT cases Roland McGrath
2008-02-29 12:01 ` Oleg Nesterov
2008-02-29 13:20 ` Oleg Nesterov
2008-03-01 1:59 ` Roland McGrath
2008-03-01 16:41 ` Oleg Nesterov
2008-03-03 13:25 ` Oleg Nesterov
2008-03-06 10:50 ` Roland McGrath
2008-03-06 9:05 ` Roland McGrath
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=Pine.LNX.4.64.0802272258150.3391@jikos.suse.cz \
--to=jkosina@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=roland@redhat.com \
--subject='Re: [PATCH] [RFC] fix missed SIGCONT cases' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).