linux-kernel - Re: [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190613124347.GB12506@redhat.com>
Date:   Thu, 13 Jun 2019 14:43:48 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     "'Eric W. Biederman'" <ebiederm@...ssion.com>,
        'Andrew Morton' <akpm@...ux-foundation.org>,
        'Deepa Dinamani' <deepa.kernel@...il.com>,
        "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
        "'arnd@...db.de'" <arnd@...db.de>,
        "'dbueso@...e.de'" <dbueso@...e.de>,
        "'axboe@...nel.dk'" <axboe@...nel.dk>,
        "'dave@...olabs.net'" <dave@...olabs.net>,
        "'e@...24.org'" <e@...24.org>,
        "'jbaron@...mai.com'" <jbaron@...mai.com>,
        "'linux-fsdevel@...r.kernel.org'" <linux-fsdevel@...r.kernel.org>,
        "'linux-aio@...ck.org'" <linux-aio@...ck.org>,
        "'omar.kilani@...il.com'" <omar.kilani@...il.com>,
        "'tglx@...utronix.de'" <tglx@...utronix.de>,
        'Al Viro' <viro@...IV.linux.org.uk>,
        'Linus Torvalds' <torvalds@...ux-foundation.org>,
        "'linux-arch@...r.kernel.org'" <linux-arch@...r.kernel.org>
Subject: Re: [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user_sigmask

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.