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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110405215003.636e950b@mfleming-mobl1.ger.corp.intel.com>
Date:	Tue, 5 Apr 2011 21:50:03 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Oleg Nesterov <oleg@...hat.com>
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 Tue, 5 Apr 2011 22:19:58 +0200
Oleg Nesterov <oleg@...hat.com> wrote:

> Hi Matt,
> 
> I'll try to study this series, but not before Friday, sorry.

No problem!

> Only one thing,
> 
> On 04/05, Matt Fleming wrote:
> > 
> > Because SIGCONT and SIGSTOP affect an entire thread group,
> 
> Yes, the effect is global, but
> 
> > we can
> > place them on the 'shared_pending' queue.
> 
> I don't think we can.
> 
>  -	pending = group ? &t->signal->shared_pending : &t->pending;
> > +	/*
> > +	 * We always enqueue SIGSTOP or SIGCONT signals on the
> > shared
> > +	 * queue. This means that a SIGSTOP or SIGCONT signal
> > _cannot_
> > +	 * be present on a thread's private pending queue.
> > +	 *
> > +	 * This makes prepare_signal() more optimal as we do not
> > have
> > +	 * to remove signals from each thread's pending queue and
> > so
> > +	 * can avoid iterating over all threads in the thread group
> > +	 * (and therefore avoid the locking that would be
> > necessary to
> > +	 * do that safely).
> > +	 */
> > +	if (group || sig_kernel_stop(sig) || sig == SIGCONT)
> > +		pending = &t->signal->shared_pending;
> > +	else
> > +		pending = &t->pending;
> 
> How so? Suppose the process has a handler for SIGCONT. Suppose this
> process is not stopped. tkill(SIGCONT) should deliver the signal to
> the right thread.

D'oh, yes. I think I got confused here. You're right, this won't work.
 
> 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?

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

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/