All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@tv-sign.ru>
To: Simon Holm Th?gersen <odie@cs.aau.dk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Davide Libenzi <davidel@xmailserver.org>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] fix the long standing exec vs kill race
Date: Sun, 2 Dec 2007 21:52:37 +0300	[thread overview]
Message-ID: <20071202185237.GA88@tv-sign.ru> (raw)
In-Reply-To: <1196618901.5698.23.camel@odie.local>

On 12/02, Simon Holm Th?gersen wrote:
>
> s??n, 02 12 2007 kl. 20:18 +0300, skrev Oleg Nesterov:
> > On 12/02, Simon Holm Th?gersen wrote:
> > > 
> > > I have an issue that sounds related, but I might be completely off. I
> > > would expect the simple attached program to keep receiving the same
> > > signal, i.e. respond to
> > > 	killall signal-exec -s SIGHUP
> > > 
> > > I tried your patches, but they didn't help.
> > > 
> > > Any ideas?
> > > 
> > > 
> > > Simon Holm Th??gersen
> > 
> > > #include <signal.h>
> > > #include <stdio.h>
> > > #include <unistd.h>
> > > 
> > > static char **argv_;
> > > 
> > > static void handler(int signal)
> > > {
> > > 	printf("got signal %d\n", signal);
> > > 	execv(argv_[0], argv_);
> > > }
> > > 
> > > int main(int argc, char *argv[])
> > > {
> > > 	printf("spawned\n");
> > > 	argv_ = argv;
> > > 	if (signal(SIGTERM, handler) == SIG_ERR)
> > > 		err(1, "could not set signal handler for SIGTERM");
> > > 	if (signal(SIGHUP, handler) == SIG_ERR)
> > > 		err(1, "could not set signal handler for SIGTERM");
> > > 	sleep(60);
> > > 	return 0;
> > > }
> > > 
> > 
> > I think this is another issue which should be solved (?).
> > 
> > exec() from the signal handler doesn't do sys_sigreturn(), so we don't unblock
> > the signal, and it remains blocked after exec().
> > 
> > Hmm. Is this linux bug, or application bug?
> 
> Good question. I haven't been able to find something in the
> documentation for execve(2) and signal(2) saying it shouldn't be
> possible, and it works on Solaris 10, so I'd say it is a Linux bug.

Well, as I said, I don't know what would be the right behaviour,

> Actually, having another look at the documentation, signal(7) mentions
> that POSIX.1-2003 requires that execve is safe to call from inside a
> signal handler.

... but this doesn't look very clear to me.

- Linux can perfectly exec from inside a signal handler

- the application should know that the signal is blocked when the handler runs

- exec should preserve the ->blocked mask

So, is this really buggy? Do we break the "execve should be signal-safe" rule?
I don't know, but our CC: list is good ;)

Oleg.


  reply	other threads:[~2007-12-02 18:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-02 15:14 [PATCH 0/2] fix the long standing exec vs kill race Oleg Nesterov
2007-12-02 17:06 ` Simon Holm Thøgersen
2007-12-02 17:18   ` Oleg Nesterov
2007-12-02 18:08     ` Simon Holm Thøgersen
2007-12-02 18:52       ` Oleg Nesterov [this message]
2007-12-02 20:26     ` Linus Torvalds
2007-12-03 16:37 ` Linus Torvalds
2007-12-03 17:41   ` Oleg Nesterov

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=20071202185237.GA88@tv-sign.ru \
    --to=oleg@tv-sign.ru \
    --cc=akpm@linux-foundation.org \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=odie@cs.aau.dk \
    --cc=roland@redhat.com \
    --cc=torvalds@linux-foundation.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.