From: ebiederm@xmission.com (Eric W. Biederman) To: David Laight <David.Laight@ACULAB.COM> Cc: 'Oleg Nesterov' <oleg@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, Deepa Dinamani <deepa.kernel@gmail.com>, "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>, "arnd\@arndb.de" <arnd@arndb.de>, "dbueso\@suse.de" <dbueso@suse.de>, "axboe\@kernel.dk" <axboe@kernel.dk>, "dave\@stgolabs.net" <dave@stgolabs.net>, "e\@80x24.org" <e@80x24.org>, "jbaron\@akamai.com" <jbaron@akamai.com>, "linux-fsdevel\@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-aio\@kvack.org" <linux-aio@kvack.org>, "omar.kilani\@gmail.com" <omar.kilani@gmail.com>, "tglx\@linutronix.de" <tglx@linutronix.de>, Al Viro <viro@ZenIV.linux.org.uk>, Linus Torvalds <torvalds@linux-foundation.org>, "linux-arch\@vger.kernel.org" <linux-arch@vger.kernel.org> Subject: Re: [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user_sigmask Date: Wed, 12 Jun 2019 10:11:28 -0500 [thread overview] Message-ID: <87v9xayh27.fsf@xmission.com> (raw) In-Reply-To: <6f748b26bef748208e2a74174c0c0bfc@AcuMS.aculab.com> (David Laight's message of "Wed, 12 Jun 2019 14:18:28 +0000") David Laight <David.Laight@ACULAB.COM> writes: > From: Oleg Nesterov >> Sent: 12 June 2019 14:46 >> On 06/11, David Laight wrote: >> > >> > If I have an application that has a loop with a pselect call that >> > enables SIGINT (without a handler) and, for whatever reason, >> > one of the fd is always 'ready' then I'd expect a SIGINT >> > (from ^C) to terminate the program. I think this gets into a quality of implementation. I suspect that set_user_sigmask should do: if (signal_pending()) return -ERESTARNOSIGHAND; /* -EINTR that restarts if nothing was pending */ Which should be safe as nothing has blocked yet to consume any of the timeouts, and it should ensure that none of the routines miss a signal. >> This was never true. >> >> Before Eric's patches SIGINT can kill a process or not, depending on timing. >> In particular, if SIGINT was already pending before pselect() and it finds >> an already ready fd, the program won't terminate. > > Which matches what I see on a very old Linux system. > >> After the Eric's patches SIGINT will only kill the program if pselect() does >> not find a ready fd. >> >> And this is much more consistent. Now we can simply say that the signal will >> be delivered only if pselect() fails and returns -EINTR. If it doesn't have >> a handler the process will be killed, otherwise the handler will be called. > > But is it what the standards mandate? > Can anyone check how Solaris and any of the BSDs behave? > I don't have access to any solaris systems (I doubt I'll get the disk to > spin on the one in my garage). > I can check NetBSD when I get home. > > The ToG page for pselect() http://pubs.opengroup.org/onlinepubs/9699919799/functions/pselect.html says: > "If sigmask is not a null pointer, then the pselect() function shall replace > the signal mask of the caller by the set of signals pointed to by sigmask > before examining the descriptors, and shall restore the signal mask of the > calling thread before returning." > Note that it says 'before examining the descriptors' not 'before blocking'. > Under the general description about signals it also says that the signal handler > will be called (or other action happen) when a pending signal is unblocked. > So unblocking SIGINT (set to SIG_DFL) prior to examining the descriptors > should be enough to cause the process to exit. > The fact that signal handlers are not called until 'return to user' > is really an implementation choice - but (IMHO) it should appear as if they > were called at the time they became unmasked. > > If nothing else the man pages need a note about the standards and portability. I think the entire point is so that signals can be added to an event loop in a race free way. *cough* signalfd *cough*. I think if you are setting SIGINT to SIG_DFL you would leave SIGINT unblocked so it can happen anywhere. I can see more utility in having a SIGINT handler and you block SIGINT except in your polling loop so you can do something deterministic when SIGINT comes in. Which makes it independent of my patches, but still worth fixing. Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman) To: David Laight <David.Laight@ACULAB.COM> Cc: 'Oleg Nesterov' <oleg@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, Deepa Dinamani <deepa.kernel@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "arnd@arndb.de" <arnd@arndb.de>, "dbueso@suse.de" <dbueso@suse.de>, "axboe@kernel.dk" <axboe@kernel.dk>, "dave@stgolabs.net" <dave@stgolabs.net>, "e@80x24.org" <e@80x24.org>, "jbaron@akamai.com" <jbaron@akamai.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-aio@kvack.org" <linux-aio@kvack.org>, "omar.kilani@gmail.com" <omar.kilani@gmail.com>, "tglx@linutronix.de" <tglx@linutronix.de>, Al Viro <viro@ZenIV.linux.org.uk>, Linus Torvalds <torvalds@linux-foundation.org>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org> Subject: Re: [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user_sigmask Date: Wed, 12 Jun 2019 10:11:28 -0500 [thread overview] Message-ID: <87v9xayh27.fsf@xmission.com> (raw) In-Reply-To: <6f748b26bef748208e2a74174c0c0bfc@AcuMS.aculab.com> (David Laight's message of "Wed, 12 Jun 2019 14:18:28 +0000") David Laight <David.Laight@ACULAB.COM> writes: > From: Oleg Nesterov >> Sent: 12 June 2019 14:46 >> On 06/11, David Laight wrote: >> > >> > If I have an application that has a loop with a pselect call that >> > enables SIGINT (without a handler) and, for whatever reason, >> > one of the fd is always 'ready' then I'd expect a SIGINT >> > (from ^C) to terminate the program. I think this gets into a quality of implementation. I suspect that set_user_sigmask should do: if (signal_pending()) return -ERESTARNOSIGHAND; /* -EINTR that restarts if nothing was pending */ Which should be safe as nothing has blocked yet to consume any of the timeouts, and it should ensure that none of the routines miss a signal. >> This was never true. >> >> Before Eric's patches SIGINT can kill a process or not, depending on timing. >> In particular, if SIGINT was already pending before pselect() and it finds >> an already ready fd, the program won't terminate. > > Which matches what I see on a very old Linux system. > >> After the Eric's patches SIGINT will only kill the program if pselect() does >> not find a ready fd. >> >> And this is much more consistent. Now we can simply say that the signal will >> be delivered only if pselect() fails and returns -EINTR. If it doesn't have >> a handler the process will be killed, otherwise the handler will be called. > > But is it what the standards mandate? > Can anyone check how Solaris and any of the BSDs behave? > I don't have access to any solaris systems (I doubt I'll get the disk to > spin on the one in my garage). > I can check NetBSD when I get home. > > The ToG page for pselect() http://pubs.opengroup.org/onlinepubs/9699919799/functions/pselect.html says: > "If sigmask is not a null pointer, then the pselect() function shall replace > the signal mask of the caller by the set of signals pointed to by sigmask > before examining the descriptors, and shall restore the signal mask of the > calling thread before returning." > Note that it says 'before examining the descriptors' not 'before blocking'. > Under the general description about signals it also says that the signal handler > will be called (or other action happen) when a pending signal is unblocked. > So unblocking SIGINT (set to SIG_DFL) prior to examining the descriptors > should be enough to cause the process to exit. > The fact that signal handlers are not called until 'return to user' > is really an implementation choice - but (IMHO) it should appear as if they > were called at the time they became unmasked. > > If nothing else the man pages need a note about the standards and portability. I think the entire point is so that signals can be added to an event loop in a race free way. *cough* signalfd *cough*. I think if you are setting SIGINT to SIG_DFL you would leave SIGINT unblocked so it can happen anywhere. I can see more utility in having a SIGINT handler and you block SIGINT except in your polling loop so you can do something deterministic when SIGINT comes in. Which makes it independent of my patches, but still worth fixing. Eric
next prev parent reply other threads:[~2019-06-12 15:11 UTC|newest] Thread overview: 155+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-22 3:21 [PATCH v2] signal: Adjust error codes according to restore_user_sigmask() Deepa Dinamani 2019-05-22 15:05 ` Oleg Nesterov 2019-05-22 15:55 ` Deepa Dinamani 2019-05-22 16:14 ` Oleg Nesterov 2019-05-22 16:33 ` Deepa Dinamani 2019-05-23 9:03 ` David Laight 2019-05-23 14:59 ` Oleg Nesterov 2019-05-23 16:18 ` David Laight 2019-05-23 16:36 ` Oleg Nesterov 2019-05-23 16:56 ` David Laight 2019-05-23 18:06 ` Deepa Dinamani 2019-05-23 20:41 ` Deepa Dinamani 2019-05-23 21:06 ` Deepa Dinamani 2019-05-24 9:58 ` David Laight 2019-05-24 14:10 ` Oleg Nesterov 2019-05-24 15:16 ` Deepa Dinamani 2019-05-24 16:33 ` Oleg Nesterov 2019-05-24 17:01 ` Deepa Dinamani 2019-05-27 15:04 ` Oleg Nesterov 2019-05-28 20:47 ` Deepa Dinamani 2019-05-29 16:57 ` Oleg Nesterov 2019-05-29 18:42 ` Deepa Dinamani 2019-05-28 9:02 ` David Laight 2019-05-28 9:12 ` David Laight 2019-05-28 11:37 ` Deepa Dinamani 2019-05-28 12:04 ` David Laight 2019-05-24 14:19 ` Oleg Nesterov 2019-05-24 14:29 ` Deepa Dinamani 2019-05-24 14:51 ` Oleg Nesterov 2019-05-24 13:29 ` Oleg Nesterov 2019-05-24 14:59 ` David Laight 2019-05-24 15:09 ` David Laight 2019-05-24 15:46 ` Oleg Nesterov 2019-05-24 15:44 ` Oleg Nesterov 2019-05-24 16:40 ` David Laight 2019-05-23 14:33 ` Oleg Nesterov 2019-05-22 22:18 ` Chris Down 2019-05-22 22:52 ` Deepa Dinamani 2019-05-22 22:52 ` Deepa Dinamani 2019-05-29 16:11 ` pselect/etc semantics (Was: [PATCH v2] signal: Adjust error codes according to restore_user_sigmask()) Oleg Nesterov 2019-05-29 16:54 ` David Laight 2019-05-29 18:50 ` Eric Wong 2019-05-30 9:34 ` David Laight 2019-05-30 13:04 ` pselect/etc semantics Eric W. Biederman 2019-05-29 16:56 ` pselect/etc semantics (Was: [PATCH v2] signal: Adjust error codes according to restore_user_sigmask()) Deepa Dinamani 2019-05-29 18:26 ` Deepa Dinamani 2019-05-29 22:32 ` Arnd Bergmann 2019-05-30 1:54 ` pselect/etc semantics Eric W. Biederman 2019-05-30 18:28 ` Arnd Bergmann 2019-05-30 14:40 ` pselect/etc semantics (Was: [PATCH v2] signal: Adjust error codes according to restore_user_sigmask()) Oleg Nesterov 2019-05-30 18:37 ` Arnd Bergmann 2019-05-30 13:01 ` pselect/etc semantics Eric W. Biederman 2019-05-30 15:18 ` David Laight 2019-05-30 16:13 ` Oleg Nesterov 2019-05-30 15:38 ` Eric W. Biederman 2019-05-30 15:48 ` Deepa Dinamani 2019-05-30 16:59 ` Deepa Dinamani 2019-05-30 16:08 ` Oleg Nesterov 2019-05-30 17:20 ` Eric W. Biederman 2019-05-30 16:22 ` David Laight 2019-05-30 15:57 ` Oleg Nesterov 2019-05-30 21:03 ` Eric Wong 2019-06-04 13:41 ` [PATCH] signal: remove the wrong signal_pending() check in restore_user_sigmask() Oleg Nesterov 2019-06-04 15:31 ` Eric W. Biederman 2019-06-04 15:31 ` Eric W. Biederman 2019-06-04 15:57 ` David Laight 2019-06-04 15:57 ` David Laight 2019-06-04 16:37 ` Arnd Bergmann 2019-06-04 18:14 ` Deepa Dinamani 2019-06-04 18:35 ` Eric Wong 2019-06-04 21:26 ` Linus Torvalds 2019-06-04 22:24 ` Eric Wong 2019-06-04 23:51 ` Eric W. Biederman 2019-06-05 9:04 ` Oleg Nesterov 2019-06-05 8:56 ` Oleg Nesterov 2019-06-05 9:02 ` David Laight 2019-06-05 9:25 ` Oleg Nesterov 2019-06-05 9:58 ` David Laight 2019-06-05 15:58 ` [PATCH -mm 0/1] signal: simplify set_user_sigmask/restore_user_sigmask Oleg Nesterov 2019-06-05 15:58 ` [PATCH -mm 1/1] " Oleg Nesterov 2019-06-06 0:14 ` kbuild test robot 2019-06-06 1:06 ` kbuild test robot 2019-06-06 7:25 ` Oleg Nesterov 2019-06-06 7:30 ` Sedat Dilek 2019-06-05 17:24 ` [PATCH -mm 0/1] " Linus Torvalds 2019-06-06 9:05 ` David Laight 2019-06-06 11:05 ` Oleg Nesterov 2019-06-06 11:29 ` David Laight 2019-06-06 12:41 ` Oleg Nesterov 2019-06-06 13:23 ` David Laight 2019-06-06 10:22 ` Oleg Nesterov 2019-06-06 11:32 ` [PATCH -mm V2 1/1] " Oleg Nesterov 2019-06-06 14:08 ` [PATCH 0/2] select: simplify the usage of restore_saved_sigmask_unless() Oleg Nesterov 2019-06-06 14:08 ` [PATCH 1/2] select: change do_poll() to return -ERESTARTNOHAND rather than -EINTR Oleg Nesterov 2019-06-07 18:05 ` Linus Torvalds 2019-06-06 14:09 ` [PATCH 2/2] select: shift restore_saved_sigmask_unless() into poll_select_copy_remaining() Oleg Nesterov 2019-06-07 21:39 ` [RFC PATCH 0/5]: Removing saved_sigmask Eric W. Biederman 2019-06-07 21:39 ` Eric W. Biederman 2019-06-07 21:41 ` [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user_sigmask Eric W. Biederman 2019-06-07 21:41 ` Eric W. Biederman 2019-06-07 21:41 ` Eric W. Biederman 2019-06-07 22:07 ` Linus Torvalds 2019-06-07 22:07 ` Linus Torvalds 2019-06-10 16:22 ` Oleg Nesterov 2019-06-10 21:20 ` Eric W. Biederman 2019-06-11 9:52 ` David Laight 2019-06-11 11:14 ` David Laight 2019-06-12 12:55 ` Eric W. Biederman 2019-06-12 12:55 ` Eric W. Biederman 2019-06-12 12:55 ` Eric W. Biederman 2019-06-12 13:24 ` David Laight 2019-06-12 13:24 ` David Laight 2019-06-12 13:35 ` Oleg Nesterov 2019-06-12 13:35 ` Oleg Nesterov 2019-06-12 13:39 ` David Laight 2019-06-12 13:39 ` David Laight 2019-06-11 15:46 ` David Laight 2019-06-11 15:46 ` David Laight 2019-06-12 12:40 ` Eric W. Biederman 2019-06-12 12:40 ` Eric W. Biederman 2019-06-12 12:40 ` Eric W. Biederman 2019-06-12 13:45 ` Oleg Nesterov 2019-06-12 14:18 ` David Laight 2019-06-12 15:11 ` Eric W. Biederman [this message] 2019-06-12 15:11 ` Eric W. Biederman 2019-06-12 15:37 ` Oleg Nesterov 2019-06-12 15:37 ` Oleg Nesterov 2019-06-13 8:48 ` David Laight 2019-06-13 8:48 ` David Laight 2019-06-13 9:43 ` Oleg Nesterov 2019-06-13 9:43 ` Oleg Nesterov 2019-06-13 10:56 ` David Laight 2019-06-13 10:56 ` David Laight 2019-06-13 12:43 ` Oleg Nesterov 2019-06-13 12:43 ` Oleg Nesterov 2019-06-11 18:55 ` Oleg Nesterov 2019-06-11 19:02 ` Eric W. Biederman 2019-06-11 19:02 ` Eric W. Biederman 2019-06-12 8:39 ` David Laight 2019-06-12 13:09 ` Eric W. Biederman 2019-06-12 13:09 ` Eric W. Biederman 2019-06-12 13:09 ` Eric W. Biederman 2019-06-07 21:41 ` [RFC PATCH 2/5] signal/kvm: Stop using sigprocmask in kvm_sigset_(activate|deactivate) Eric W. Biederman 2019-06-07 21:41 ` Eric W. Biederman 2019-06-07 21:41 ` Eric W. Biederman 2019-06-07 21:42 ` [RFC PATCH 3/5] signal: Always keep real_blocked in sync with blocked Eric W. Biederman 2019-06-07 21:42 ` Eric W. Biederman 2019-06-07 21:42 ` Eric W. Biederman 2019-06-07 21:43 ` [RFC PATCH 4/5] signal: Remove saved_sigmask Eric W. Biederman 2019-06-07 21:43 ` Eric W. Biederman 2019-06-07 21:43 ` Eric W. Biederman 2019-06-07 21:44 ` [RFC PATCH 5/5] signal: Remove the unnecessary restore_sigmask flag Eric W. Biederman 2019-06-07 21:44 ` Eric W. Biederman 2019-06-07 21:44 ` Eric W. Biederman 2019-06-11 18:58 ` [RFC PATCH 0/5]: Removing saved_sigmask 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=87v9xayh27.fsf@xmission.com \ --to=ebiederm@xmission.com \ --cc=David.Laight@ACULAB.COM \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=axboe@kernel.dk \ --cc=dave@stgolabs.net \ --cc=dbueso@suse.de \ --cc=deepa.kernel@gmail.com \ --cc=e@80x24.org \ --cc=jbaron@akamai.com \ --cc=linux-aio@kvack.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=oleg@redhat.com \ --cc=omar.kilani@gmail.com \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=viro@ZenIV.linux.org.uk \ /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: linkBe 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.