linux-toradex.git/include/linux/ptrace.h, branch v2.6.23.12

PTRACE_POKEDATA consolidation

2007-07-17T17:23:03+00:00

Identical implementations of PTRACE_POKEDATA go into generic_ptrace_pokedata()
function.

AFAICS, fix bug on xtensa where successful PTRACE_POKEDATA will nevertheless
return EPERM.

Signed-off-by: Alexey Dobriyan 
Cc: Christoph Hellwig 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

PTRACE_PEEKDATA consolidation

2007-07-17T17:23:03+00:00

Identical implementations of PTRACE_PEEKDATA go into generic_ptrace_peekdata()
function.

Signed-off-by: Alexey Dobriyan 
Cc: Christoph Hellwig 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Use decimal for PTRACE_ATTACH and PTRACE_DETACH.

2006-09-29T16:18:16+00:00

It is sure confusing that linux/ptrace.h has:
	#define PTRACE_SINGLESTEP	   9
	#define PTRACE_ATTACH		0x10
	#define PTRACE_DETACH		0x11
	#define PTRACE_SYSCALL		  24
All the low-numbered constants are in decimal, but the last two in hex.
It sure makes it likely that someone will look at this and think that
9, 10, 11 are used, and that 16 and 17 are not used.

How about we use the same notation for all the numbers [0,24] in the
same short list?

Signed-off-by: Roland McGrath 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] coredump: kill ptrace related stuff

2006-06-26T16:58:27+00:00

With this patch zap_process() sets SIGNAL_GROUP_EXIT while sending SIGKILL to
the thread group.  This means that a TASK_TRACED task

	1. Will be awakened by signal_wake_up(1)

	2. Can't sleep again via ptrace_notify()

	3. Can't go to do_signal_stop() after return
	   from ptrace_stop() in get_signal_to_deliver()

So we can remove all ptrace related stuff from coredump path.

Signed-off-by: Oleg Nesterov 
Cc: "Eric W. Biederman" 
Cc: Roland McGrath 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ptrace: document the locking rules

2006-06-23T14:43:03+00:00

After a lot of reading the code and thinking about how it behaves I have
managed to figure out what the current ptrace locking rules are.  The
current code is in much better that it appears at first glance.  The
troublesome code paths are actually the code paths that violate the current
rules.

ptrace uses simple exclusive access as it's locking.  You can only touch
task->ptrace if the task is stopped and you are the ptracer, or if the task
is running and are the task itself.

Very simple, very easy to maintain.  It just needs to be documented so
people know not to touch ptrace from elsewhere.

Currently we do have a few pieces of code that are in violation of this
rule.  Particularly the core dump code, and ptrace_attach.  But so far the
code looks fixable.

Signed-off-by: Eric W. Biederman 
Cc: Oleg Nesterov 
Cc: Roland McGrath 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] fix zap_thread's ptrace related problems

2006-02-15T19:05:43+00:00

1. The tracee can go from ptrace_stop() to do_signal_stop()
   after __ptrace_unlink(p).

2. It is unsafe to __ptrace_unlink(p) while p->parent may wait
   for tasklist_lock in ptrace_detach().

Signed-off-by: Oleg Nesterov 
Cc: Roland McGrath 
Cc: Ingo Molnar 
Cc: Christoph Hellwig 
Cc: Eric W. Biederman 
Signed-off-by: Linus Torvalds

[PATCH] PTRACE_SYSEMU is only for i386 and clashes with other ptrace codes of other archs

2006-01-09T04:14:04+00:00

PTRACE_SYSEMU{,_SINGLESTEP} is actually arch specific, for now, and the
current allocated number clashes with a ptrace code of frv, i.e.
PTRACE_GETFDPIC.  I should have submitted this much earlier, anyway we get no
breakage for this.

CC: Daniel Jacobowitz 
Signed-off-by: Paolo 'Blaisorblade' Giarrusso 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] use ptrace_get_task_struct in various places

2006-01-09T04:13:51+00:00

The ptrace_get_task_struct() helper that I added as part of the ptrace
consolidation is useful in variety of places that currently opencode it.
Switch them to the common helpers.

Add a ptrace_traceme() helper that needs to be explicitly called, and simplify
the ptrace_get_task_struct() interface.  We don't need the request argument
now, and we return the task_struct directly, using ERR_PTR() for error
returns.  It's a bit more code in the callers, but we have two sane routines
that do one thing well now.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] consolidate sys_ptrace()

2005-11-07T15:53:42+00:00

The sys_ptrace boilerplate code (everything outside the big switch
statement for the arch-specific requests) is shared by most architectures.
This patch moves it to kernel/ptrace.c and leaves the arch-specific code as
arch_ptrace.

Some architectures have a too different ptrace so we have to exclude them.
They continue to keep their implementations.  For sh64 I had to add a
sh64_ptrace wrapper because it does some initialization on the first call.
For um I removed an ifdefed SUBARCH_PTRACE_SPECIAL block, but
SUBARCH_PTRACE_SPECIAL isn't defined anywhere in the tree.

Signed-off-by: Christoph Hellwig 
Acked-by: Paul Mackerras 
Acked-by: Ralf Baechle 
Acked-By: David Howells 
Acked-by: Russell King 
Acked-by: Paul Mundt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] remove duplicated code from proc and ptrace

2005-09-07T23:57:43+00:00

Extract common code used by ptrace_attach() and may_ptrace_attach()
into a separate function.

Signed-off-by: Miklos Szeredi 
Cc: 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds