linux-kernel - Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such

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]

Message-ID: <20120425133238.GG6871@ZenIV.linux.org.uk>
Date:	Wed, 25 Apr 2012 14:32:38 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	Russell King <linux@....linux.org.uk>,
	Tejun Heo <tj@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Roland McGrath <roland@...k.frob.com>
Subject: Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such

On Wed, Apr 25, 2012 at 03:03:29PM +0200, Oleg Nesterov wrote:
> Yes, and it sets TIF_SIGPENDING, but unless I missed something this doesn't
> matter.
> 
> > So no,
> > it might have been blocked prior to sigsuspend().
> 
> If it was not blocked, then the next do_signal()->get_signal_to_deliver()
> returns 0 and clears TIF_SIGPENDING. After that we finally re-enter
> sys_sigsuspend() and (assuming it unblocks this sig) notice this pending
> signal again and return -EINTR eventually.

Point...  Still, since we are talking about an arbitrary wide window (the
damn thing is waiting for signals to arrive, after all) this doesn't
sound good; sure, we might have been hit by SIGSTOP just before entering
that sigsuspend() with SIGCONT arriving only when the signal in question
had, ending up with handler running before sigsuspend(), but...  IMO it's
a QoI problem at the very least.

As for SA_RESTART/!SA_RESTART mixes, if SA_RESTART comes first we should
just take that restart and pretend that the second signal has arrived at
the very beginning of handler, I think.  Assuming I understood you correctly,
that is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/