linux-kernel - Re: [PATCH 0.2/8] ptrace: Always put ptracee into appropriate execution state

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: <20110323080010.GV12003@htj.dyndns.org>
Date:	Wed, 23 Mar 2011 09:00:10 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	roland@...hat.com, jan.kratochvil@...hat.com,
	vda.linux@...glemail.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	indan@....nu
Subject: Re: [PATCH 0.2/8] ptrace: Always put ptracee into appropriate
 execution state

Hello,

On Tue, Mar 22, 2011 at 09:33:22PM +0100, Oleg Nesterov wrote:
> > +	/*
> > +	 * Reinstate GROUP_STOP_PENDING if group stop is in effect and
> > +	 * @child isn't dead.
> > +	 */
> > +	if (!(child->flags & PF_EXITING) &&
> > +	    (child->signal->flags & SIGNAL_STOP_STOPPED ||
> > +	     child->signal->group_stop_count))
> > +		child->group_stop |= GROUP_STOP_PENDING;
> 
> Why do we need to filter out PF_EXITING tasks? This doesn't look
> strictly necessary. And note that exit_signals() doesn't always
> take ->siglock, we can race anyway.

I don't think it's strictly necessary either but in the usual group
stop initiation path in do_signal_stop(), PF_EXITING is checked before
setting PENDING, so I think it's better to remain consistent with
that.

> > +	 * Note that @resume should be used iff @child
> > +	 * is in TASK_TRACED; otherwise, we might unduly disrupt
> > +	 * TASK_KILLABLE sleeps.
> 
> Yes. but, just in case,
> 
> > +	 */
> > +	if (child->group_stop & GROUP_STOP_PENDING || task_is_traced(child))
> > +		signal_wake_up(child, task_is_traced(child));
> 
> signal_wake_up() is not needed if task_is_traced(). Even if we added
> GROUP_STOP_PENDING, ptrace_stop() does recalc_sigpending_tsk() anyway
> before return.
> 
> So we could do
> 
> 	if (SIGNAL_STOP_STOPPED || group_stop_count) {
> 		child->group_stop |= GROUP_STOP_PENDING;
> 		signal_wake_up(child, 0);
> 	}
> 
> 	if (task_is_traced(child))
> 		wake_up_state(TASK_TRACED);
> 
> But probably a single wakeup looks more simple/clean, so I agree.

Yeah, I'd like to avoid mixing calls to wake_up_state() and
signal_wake_up().  It gets confusing and there's no reason for
micro-optimization here.

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/