[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110620203320.GC17157@redhat.com>
Date: Mon, 20 Jun 2011 22:33:20 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Tejun Heo <tj@...nel.org>
Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org, hch@...radead.org
Subject: Re: [PATCH 5/7] ptrace: kill clone/exec tracehooks
On 06/17, Tejun Heo wrote:
>
> At this point, tracehooks aren't useful to mainline kernel and mostly
> just add an extra layer of obfuscation.
Yes, this is true.
> @@ -1481,10 +1481,22 @@ long do_fork(unsigned long clone_flags,
> }
>
> /*
> - * When called from kernel_thread, don't do user tracing stuff.
> + * Determine whether and which event to report to ptracer. When
> + * called from kernel_thread or CLONE_UNTRACED is explicitly
> + * requested, no event is reported; otherwise, report if the event
> + * for the type of forking is enabled.
> */
> - if (likely(user_mode(regs)))
> - trace = tracehook_prepare_clone(clone_flags);
> + if (likely(user_mode(regs)) && !(clone_flags & CLONE_UNTRACED)) {
Off-topic, but I never understood this user_mode() check... OK, a
traced task can call kernel_thread() in kernel, but this used
CLONE_UNTRACED.
> + if (clone_flags & CLONE_VFORK)
> + trace = PTRACE_EVENT_VFORK;
> + else if ((clone_flags & CSIGNAL) != SIGCHLD)
> + trace = PTRACE_EVENT_CLONE;
> + else
> + trace = PTRACE_EVENT_FORK;
> +
> + if (likely(!ptrace_event_enabled(current, trace)))
> + trace = 0;
> + }
As I said am going to apply this all except 6/7, but imho this
deserves a trivial helper anyway.
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/
Powered by blists - more mailing lists