linux-kernel - Re: [RFC PATCH 7/X] ptrace: mv task->parent ptrace_task->pt

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: <20090527235936.GB12216@redhat.com>
Date:	Thu, 28 May 2009 01:59:36 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Roland McGrath <roland@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 7/X] ptrace: mv task->parent ptrace_task->pt_tracer

On 05/27, Roland McGrath wrote:
>
> > 		if (!exit_code)
> > 			child->exit_code = exit_code;
>
> The condition is wrong.  It's unconditional except in the "already killed"
> case that ptrace_detach() is checking for.  It never depends on the value.
> (You probably meant the inverse of this test.  But that's wrong too.
> PTRACE_CONT,0 must clear the old signal and not deliver any signal.)

This is optimization. If exit_code == 0 we do not need to fixup
->last_siginfo. Note that we have another "child->exit_code = exit_code"
below in the slow path.

> > 		if (child->exit_code == exit_code)
> > 			return;
>
> This makes no sense unless it's before setting it.

This also covers the "exit_code == 0" case. If exit_code = 0 we have
already set child->exit_code, we can return.

> > The disadvantage is, ptrace_notify() does not need this, we add the
> > little pessimization...
>
> It can check for !child->last_siginfo before lock_task_sighand().

ptrace_stop() always sets ->last_siginfo != NULL.

> > And. This change adds another dependency with arches which implement
> > their own resume.
>
> The current draft series is meant to assume arch issues are already dealt
> with before this merges.  If we need to sequence this part of it later than
> most of it, we can revisit that later before really preparing to merge it.
>
> > So. Do you think this cleanup should be done before/with this series
> > or we can do it later?
>
> Whatever you think fits best.  Right now I just want to get the rough draft
> of the series all the way to the end of the most substantive work.  Do that
> however seems most efficacious now.  We can juggle the order again later to
> ease the eventual merging.

OK, lets do this change later ;)

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/