linux-kernel - Re: [PATCHSET] ptrace,signal: Improve ptrace and job control interaction

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: <20110328152158.GA6736@htj.dyndns.org>
Date:	Mon, 28 Mar 2011 17:21:58 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	jan.kratochvil@...hat.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu, roland@...k.frob.com
Subject: Re: [PATCHSET] ptrace,signal: Improve ptrace and job control
 interaction

Hi,

On Mon, Mar 28, 2011 at 02:14:01PM +0200, Oleg Nesterov wrote:
> > Hmmm... setting TIF_SIGPENDING and kicking the task to enter signal
> > delivery path doesn't have any side effect when it's running in
> > userland,
> 
> Yes. We should avoid the spurious TIF_SIGPENDING, if possible. But in
> this case we don't care.
> 
> But, unless the thread is ptraced, it can't be running in userland,
> why should we set TIF_SIGPENDING?

It goes both ways.  If we need it for ptrace path, the overhead for
!ptrace case is negligible && it makes the code less finicky, why not?

It's much cleaner to say "it sets notification condition and
guarantees that tasks travel signal delivery path" than "if !ptraced,
at least one task should already be in signal delivery path for such
and such reasons; however, while ptraced, because of the interaction
with PTRACE_CONT, there's a case we need to call in the task
explicitly."  The code becomes less prone to subtle bugs when the
surrounding code changes too.

> > We set SIGNAL_CLD_STOPPED if group_stop_count wasn't zero, ie. if
> > group stop has initiated, which will be delivered as soon as any task
> > enters signal delivery path.
> 
> Yes. And that task T has already called do_signal_stop() and it is
> TASK_STOPPED.

Ah, right, this is where I got confused.  signal_stop_count wouldn't
be set unless at least one task is already in signal delivery path.

> No?

You're right.  I was confused.  But if we're gonna call in a task,
let's do it regardless of ptrace.  It's not like splitting that
condition will buy us anything.

Thanks.

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