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  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' <>
CC:     'Linus Torvalds' <>,
        Andrew Morton <>,
        Deepa Dinamani <>,
        "Linux List Kernel Mailing" <>,
        Arnd Bergmann <>,
        Davidlohr Bueso <>, Jens Axboe <>,
        Davidlohr Bueso <>,
        "" <>, Jason Baron <>,
        linux-fsdevel <>,
        "" <>,
        "" <>,
        Thomas Gleixner <>,
        stable <>,
        Al Viro <>,
        "Eric W. Biederman" <>
Subject: RE: [PATCH] signal: remove the wrong signal_pending() check in

From: Oleg Nesterov []
> 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.


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

Powered by blists - more mailing lists