[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFx1+hFSCa4nX80C30BkEOugXRvBZ=7LA+u+KOq_qSaJsg@mail.gmail.com>
Date: Sun, 20 Jan 2013 12:21:14 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Dan Carpenter <dan.carpenter@...cle.com>,
Kernel Security <security@...nel.org>,
Michael Davidson <md@...gle.com>,
Suleiman Souhlal <suleiman@...gle.com>,
Julien Tinnes <jln@...gle.com>,
Aaron Durbin <adurbin@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Tejun Heo <tj@...nel.org>,
Roland McGrath <roland@...k.frob.com>,
Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 2/4] ptrace: ensure arch_ptrace/ptrace_request can never
race with SIGKILL
On Sun, Jan 20, 2013 at 11:25 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> +
> +static void ptrace_unfreeze_traced(struct task_struct *task)
> +{
> + if (task->state != __TASK_TRACED)
> + return;
> +
> + if (WARN_ON(!task->ptrace || task->parent != current))
> + return;
This WARN_ON() is bogus.
Because you added the warning, you then need to make the callers check
for the whole PTRACE_UNATTACH.
So I think you should just remove the WARN_ON(), and then just call
ptrace_unfreeze_traced() unconditionally after you've successfully
done a ptrace_check_attach(). Just to keep the code simpler.
Also, in your corrected version, you had
+ if (!wait_task_inactive(child, __TASK_TRACED)) {
+ /* This can only happen if may_ptrace_stop() fails */
+ WARN_ON(child->state == __TASK_TRACED);
+ ret = -ESRCH;
where I actually think that the comment is not really helpful. It
doesn't really explain what he child can do to get to ptrace_stop() in
the first place, and what that does to the child state...
Linus
--
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/
Powered by blists - more mailing lists