linux-kernel - Re: [RFC][PATCH 1/5] signals: Always place SIGCONT and SIGSTOP on 'shared

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 6 Apr 2011 14:57:57 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>,
	Matt Fleming <matt.fleming@...ux.intel.com>
Subject: Re: [RFC][PATCH 1/5] signals: Always place SIGCONT and SIGSTOP on
	'shared_pending'

On 04/05, Matt Fleming wrote:
>
> On Tue, 5 Apr 2011 22:19:58 +0200
>
> > SIGSTOP can't have the handler, still we shouldn't place it on the
> > shared list, debuggers won't be happy.
>
> Urgh, debuggers actually peek at shared_pending and pending?

Argh, sorry, I was not clear.

First of all, only SIGSTOP is never delivered to user-space, other
sig_kernel_stop() signals can have a handler and in this case, say,
SIGTTIN doesn't stop but acts like the normal signal. This means you
can't put it into shared_pending.

But even SIGSTOP should be routed properly. If the process is ptraced,
the tracee reports SIGSTOP to the debugger first. This means that
tkill(SIGSTOP) should be delivered to the right target.

> > Also. This code was changed very much, please do these changes on
> > top of
> > http://git.kernel.org/?p=linux/kernel/git/tj/misc.git;a=shortlog;h=refs/heads/ptrace
>
> My patches are already based on that tree.

Ah, good.

Oleg.

--
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/