linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "'Eric W. Biederman'" <ebiederm@xmission.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: Thu, 13 Jun 2019 14:43:48 +0200	[thread overview]
Message-ID: <20190613124347.GB12506@redhat.com> (raw)
In-Reply-To: <66311ce9762849f7988c16bc752ea5a9@AcuMS.aculab.com>

On 06/13, David Laight wrote:
>
> > And you interpret this as if a pending signal should be delivered in any case,
> > even if pselect succeeds. Again, perhaps you are right, but to me this is simply
> > undocumented.
>
> This text (from http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html) is moderately clear:
>     ... if all threads within the process block delivery of the signal, the signal shall
>     remain pending on the process until a thread calls a sigwait() function selecting that
>     signal, a thread unblocks delivery of the signal, or the action associated with the signal
>     is set to ignore the signal.
>
> So when pselect() 'replaces the signal mask' any pending signals should be delivered.

I fail to understand this logic.


> > However, linux never did this. Until the commit 854a6ed56839 ("signal: Add
> > restore_user_sigmask()"). This commit caused regression. We had to revert it.
>
> That change wasn't expected to change the behaviour...

Yes.

And the changed behaviour matched your understanding of standard. We had to
change it back.

So what do you want from me? ;)

Oleg.

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "'Eric W. Biederman'" <ebiederm@xmission.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: Thu, 13 Jun 2019 14:43:48 +0200	[thread overview]
Message-ID: <20190613124347.GB12506@redhat.com> (raw)
Message-ID: <20190613124348.gAaGNsh6Hy-WrZjQ3rIZiQOFnp_m4u0fbVoWopMU77Q@z> (raw)
In-Reply-To: <66311ce9762849f7988c16bc752ea5a9@AcuMS.aculab.com>

On 06/13, David Laight wrote:
>
> > And you interpret this as if a pending signal should be delivered in any case,
> > even if pselect succeeds. Again, perhaps you are right, but to me this is simply
> > undocumented.
>
> This text (from http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html) is moderately clear:
>     ... if all threads within the process block delivery of the signal, the signal shall
>     remain pending on the process until a thread calls a sigwait() function selecting that
>     signal, a thread unblocks delivery of the signal, or the action associated with the signal
>     is set to ignore the signal.
>
> So when pselect() 'replaces the signal mask' any pending signals should be delivered.

I fail to understand this logic.


> > However, linux never did this. Until the commit 854a6ed56839 ("signal: Add
> > restore_user_sigmask()"). This commit caused regression. We had to revert it.
>
> That change wasn't expected to change the behaviour...

Yes.

And the changed behaviour matched your understanding of standard. We had to
change it back.

So what do you want from me? ;)

Oleg.

  parent reply	other threads:[~2019-06-13 12:43 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190522032144.10995-1-deepa.kernel@gmail.com>
     [not found] ` <20190529161157.GA27659@redhat.com>
     [not found]   ` <20190604134117.GA29963@redhat.com>
     [not found]     ` <20190606140814.GA13440@redhat.com>
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 22:07           ` Linus Torvalds
2019-06-07 22:07             ` Linus Torvalds
2019-06-10 16:22           ` Oleg Nesterov
2019-06-10 16:22             ` Oleg Nesterov
2019-06-10 21:20             ` Eric W. Biederman
2019-06-10 21:20               ` Eric W. Biederman
2019-06-11  9:52               ` David Laight
2019-06-11  9:52                 ` David Laight
2019-06-11 11:14                 ` 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 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 13:45                 ` Oleg Nesterov
2019-06-12 13:45                   ` Oleg Nesterov
2019-06-12 14:18                   ` David Laight
2019-06-12 14:18                     ` David Laight
2019-06-12 15:11                     ` Eric W. Biederman
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 [this message]
2019-06-13 12:43                             ` Oleg Nesterov
2019-06-11 18:55               ` 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  8:39                   ` David Laight
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: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:43         ` [RFC PATCH 4/5] signal: Remove saved_sigmask 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-11 18:58         ` [RFC PATCH 0/5]: Removing saved_sigmask Oleg Nesterov
2019-06-11 18:58           ` 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=20190613124347.GB12506@redhat.com \
    --to=oleg@redhat.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=ebiederm@xmission.com \
    --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=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: 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;
as well as URLs for NNTP newsgroup(s).