Re: avr32: handle_signal() bug?

[Matt Fleming]

On Sun, 2011-08-07 at 10:20 -0700, HÃvard Skinnemoen wrote:
> Hi Matt,
> 
> On Wed, Aug 3, 2011 at 2:04 AM, Matt Fleming <matt@xxxxxxxxxxxxxxxxx> wrote:
> > That doesn't look correct to me. Now, if we were unsuccessful in setting
> > up a signal frame, say, ret == -EFAULT, do we really want to block the
> > signal or any of the signals in the handler mask?
> 
> I'm assuming this is a rhetorical question :-)

Sort of. I phrased it as a question so that someone could point out
whether my analysis was correct or not ;-)

> Looks good to me. I'm not sure how to test it though...I can try to
> build a kernel, run it on my board and see if it explodes, but I
> suspect this bug is a lot more subtle than that.

I suspect the best test would be one that makes use of SA_NODEFER.
Something like this,

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

void handler(int signum)
{
	sigset_t mask;

	sigprocmask(SIG_BLOCK, NULL, &mask);
	printf("SIGUSR2: %s\n",
	       sigismember(&mask, SIGUSR2) ? "blocked" : "not blocked");
	printf("SIGTERM: %s\n",
	       sigismember(&mask, SIGTERM) ? "blocked" : "not blocked");
}

int main(int argc, char **argv)
{
	pid_t pid;

	pid = fork();
	if (pid == -1) {
		perror("fork");
		exit(EXIT_FAILURE);
	} else if (!pid) {
		struct sigaction act;

		memset(&act, 0, sizeof(act));
		act.sa_handler = handler;
		act.sa_flags = SA_NODEFER;

		sigaddset(&act.sa_mask, SIGUSR2);
		sigaddset(&act.sa_mask, SIGTERM);

		sigaction(SIGUSR1, &act, NULL);

		pause();
	} else {
		int status;

		sleep(3);
		kill(pid, SIGUSR1);
		waitpid(pid, &status, 0);
	}

	return 0;
}

Without the patch applied I would expect this testcase to run the signal
handler without SIGUSR2 or SIGTERM blocked. With the patch I'd hope you
would see the following,

[matt@mfleming-mobl1 signal-tests]$ ./nodefer
SIGUSR2: blocked
SIGTERM: blocked

-- 
Matt Fleming, Intel Open Source Technology Center

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/