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

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

Message-Id: <20090527230700.11F2DFC2BD@magilla.sf.frob.com>
Date:	Wed, 27 May 2009 16:07:00 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...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

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

> 		if (child->exit_code == exit_code)
> 			return;

This makes no sense unless it's before setting it.

> 		if (lock_task_sighand(child, &flags)) {
> 			siginfo_t *info = child->last_siginfo;
[...]
> And ptrace_resume/ptrace_detach should use ptrace_set_exit_code()
> instead of child->exit_code = data.

Right.

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

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

Thanks,
Roland
--
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/