linux-kernel - RE: [PATCH] signal: remove the wrong signal_pending() check in restore_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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 5 Jun 2019 09:58:25 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Oleg Nesterov' <oleg@...hat.com>
CC:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        "Linux List Kernel Mailing" <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Davidlohr Bueso <dbueso@...e.de>, Jens Axboe <axboe@...nel.dk>,
        Davidlohr Bueso <dave@...olabs.net>,
        "e@...24.org" <e@...24.org>, Jason Baron <jbaron@...mai.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        "linux-aio@...ck.org" <linux-aio@...ck.org>,
        "omar.kilani@...il.com" <omar.kilani@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        stable <stable@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Subject: RE: [PATCH] signal: remove the wrong signal_pending() check in
 restore_user_sigmask()

From: Oleg Nesterov [mailto:oleg@...hat.com]
> Sent: 05 June 2019 10:25
> On 06/05, David Laight wrote:
> >
> > epoll() would have:
> > 	if (restore_user_sigmask(xxx.sigmask, &sigsaved, !ret || ret == -EINTR))
> > 		ret = -EINTR;
> 
> I don't think so but lets discuss this later.

I certainly think there should be some comments at least
about when/whether signal handlers get called and that
being separate from the return value.

The system call restart stuff does seem strange.
ISTR that was originally added for SIG_SUSPEND (^Z) so that those
signals wouldn't be seen by the appication.
But that makes it a property of the signal, not the system call.

> > I also think it could be simplified if code that loaded the 'user sigmask'
> > saved the old one in 'current->saved_sigmask' (and saved that it had done it).
> > You'd not need 'sigsaved' nor pass the user sigmask address into
> > the restore function.
> 
> Heh. apparently you do not read my emails ;)
> 
> This is what I proposed in my very 1st email, and I even showed the patch
> and the code with the patch applied twice. Let me do this again.

I did read that one, I've even quoted it in the past :-)
It's just not been mentioned recently.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)