public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Piel <Eric.Piel@Bull.Net>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Bug: Blocking of RT signals in a pause()
Date: Fri, 21 Feb 2003 16:38:24 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590709805904@msgid-missing> (raw)

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

Hello,

I'm still very newby to kernel hacking, however while trying to port the
hrtimer-posix patch (which is now in the main tree) to ia64 I think I
came to find a bug.

Basically the problem is that while my program is in a pause() I can not
receive any signal > 32 (RT signals) even if I've just unblocked them.
In addition if I unblock signal 32 then all the RT signals are
unblocked. This strange behaviour is not reproductible during a sleep().
No idea came to my mind to test other system calls so I can't say more.

Attached to this email, there is a small program to highlight this
behaviour. The bug was reproductible under 2.4ia64 and 2.5ia64 but never
with an ia32 arch. To run it on your computer you compile it:
cc -Wall -DPAUSE -g bug_signal_rt.c -o bug_signal_rt

*and then run it as a background process (so you can send it some
signals):
>./bug_signal_rt &
[3] 15424
Testing SIGNAL1=33 with signal 32 unblocked.

*you send it a signal 33:
>kill -33 15424
The signal 33 was received.
Testing SIGNAL1=33 with signal 33 unblocked.

*send the signal 33:
>kill -33 15424
###nothing happens

So you can see the bug when it received the signal 33 while unblocking
only the signal 32!
If it's not so clear you can have a look at usage_bug_signal_rt.txt to
read a bit more.

Whatever, I tried to correct the bug but after reading
arch/ia64/kernel/signal.c I could find anything to help. My knowledge of
the kernel is still quite poor. So if someone could confirm the bug and
also give me some hints about where I should hunt this bug I would be
very grateful...

Cheers
Eric

[-- Attachment #2: bug_signal_rt.c --]
[-- Type: text/plain, Size: 1228 bytes --]

/* to enable the signal 33 you have to unblock signal 32 instead of 33!*/

#include <sys/types.h>
#include <signal.h>
#include <stdio.h>
#include <unistd.h>

#define SIGNAL1	33 /* SIGRTMIN */

int sig_received;

void sigminrt_handler(int signo, siginfo_t * info, void * ptr)
{
	sig_received = 1;	/* we passed the handler */
}

int do_test(int sig)
{
	sig_received = 0;
#ifdef PAUSE
	pause();		/* wait a lot */
#else
	sleep(10);		/* wait a little bit */
#endif
	if (sig_received) printf("The signal %d was received.\n", sig);
	else printf("The signal %d was NOT received.\n", sig);

	return (sig_received);
}

int main()
{
	struct sigaction sigact;
 	sigset_t new_mask;

        sigact.sa_sigaction =sigminrt_handler;
        sigact.sa_flags = SA_SIGINFO;
        sigemptyset(&sigact.sa_mask);
	sigaction(SIGNAL1, &sigact, NULL);

	sigfillset(&new_mask);
	sigdelset(&new_mask, 32);
	sigprocmask(SIG_SETMASK, &new_mask, NULL);
	printf("Testing SIGNAL1=%d with signal %d unblocked.\n", SIGNAL1, 32);
	do_test(SIGNAL1);

	sigfillset(&new_mask);
	sigdelset(&new_mask, SIGNAL1);
	sigprocmask(SIG_SETMASK, &new_mask, NULL);
	printf("Testing SIGNAL1=%d with signal %d unblocked.\n", SIGNAL1, SIGNAL1);
	do_test(SIGNAL1);

	return 0;
}


[-- Attachment #3: usage_bug_signal_rt.txt --]
[-- Type: text/plain, Size: 1085 bytes --]

How to compile and use bug_signal_rt

Compile it with:
cc -Wall -g bug_signal_rt.c -o bug_signal_rt
to provide a sleep() mechanism

or:
cc -Wall -DPAUSE -g bug_signal_rt.c -o bug_signal_rt
to provide a pause() mechanism

Usage:
*run the program in background and note the PID:
./bug_signal_rt &
[3] 15424
Testing SIGNAL1=33 with signal 32 unblocked.

*send it a signal 33:
kill -33 15424
The signal 33 was received.
Testing SIGNAL1=33 with signal 33 unblocked.

*redo it:
kill -33 15424

*if nothing happens you can kill it:
kill -KILL 15424

What it should demonstrate:
In pause() the RT signals blocking methods are not working as specified/expected.
All signals >= 32 are blocked if the flag for signal 32 is set. Flags > 32 are taken into account. This problem doesn't happens in a sleep().

The program blocks all blockable signals execpted one and set an signal handler for signal 33. Then it call a sleep() or a pause() and when going out checks if the signal handler was called.
It does this procedure twice, first with signal 32 unblocked, second with signal 33 unblocked.




                 reply	other threads:[~2003-02-21 16:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=marc-linux-ia64-105590709805904@msgid-missing \
    --to=eric.piel@bull.net \
    --cc=linux-ia64@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox