[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110524120013.GD10334@htj.dyndns.org>
Date: Tue, 24 May 2011 14:00:13 +0200
From: Tejun Heo <tj@...nel.org>
To: Pedro Alves <pedro@...esourcery.com>
Cc: Denys Vlasenko <vda.linux@...glemail.com>, oleg@...hat.com,
jan.kratochvil@...hat.com, linux-kernel@...r.kernel.org,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
indan@....nu, bdonlan@...il.com
Subject: Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE
Hello,
On Tue, May 24, 2011 at 10:49:58AM +0100, Pedro Alves wrote:
> A couple interface questions that just crossed my mind:
>
> - on a fork/vfork/clone, if PTRACE_EVENT_FORK|VFORK|CLONE have been
> enabled, will the tracer still see the new child stop with a
> SIGSTOP, or will it see a PTRACE_EVENT_INTERRUPT?
This won't change, so SIGSTOP although we probably want to improve it
such that this can be distinguished from SIGTRAP from userland.
> - is PTRACE_INTERRUPT on PTRACE_TRACEME-traced-child planed to
> be allowed (for convenience)?
> A PTRACE_O_TRACEINTERRUPT, or some such PTRACE_SETOPTIONS
> option might be necessary to get PTRACE_EVENT_INTERRUPT instead
> of SIGSTOP in the point above.
I'm currently leaning toward deprecating PTRACE_TRACEME. If a task
can PTRACE_TRACEME, it may as well just do pause(2) and let the parent
SEIZE it.
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/
Powered by blists - more mailing lists