Commit Graph

13 Commits

Author SHA1 Message Date
Paolo 'Blaisorblade' Giarrusso
47c51dff4a [PATCH] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted
Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c
and forced by binary compatibility.  UML/32bit breaks because of this -
since it is wise enough to use PTRACE_OLDSETOPTIONS to be binary compatible
with 2.4 host kernels.

Until 2.6.17 (commit f0f2d6536e) we had:

       default:
                return sys_ptrace(request, pid, addr, data);

Instead here we have:
        case PTRACE_GET_THREAD_AREA:
	case ...:
                return sys_ptrace(request, pid, addr, data);

        default:
                return -EINVAL;

This change was a style change - when a case is added, it must be
explicitly tested this way.  In this case, not enough testing was done.

Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-08 07:38:21 -08:00
Andi Kleen
14679eb3c5 [PATCH] x86-64: Fix PTRACE_[SG]ET_THREAD_AREA regression with ia32 emulation.
ptrace(PTRACE_[SG]ET_THREAD_AREA) calls from ia32 code
should be passed onto the x86_64 implementation.

The default case in sys32_ptrace used to call to sys_ptrace(), but is
now EINVAL.  This patch fixes a regression caused by that changed.

Signed-off-by: Mike McCormack <mike@codeweavers.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-11-14 16:57:46 +01:00
Al Viro
86f9333654 [PATCH] ptrace32 trivial __user annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-10 15:37:23 -07:00
Andi Kleen
95912008ba [PATCH] Add __must_check to copy_*_user
Following i386.

And also fix the two occurrences that caused warnings in arch/x86_64/*

Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26 10:52:39 +02:00
Stephane Eranian
d3a4f48d48 [PATCH] x86-64 TIF flags for debug regs and io bitmap in ctxsw
Hello,

Following my discussion with Andi. Here is a patch that introduces
two new TIF flags to simplify the context switch code in __switch_to().
The idea is to minimize the number of cache lines accessed in the common
case, i.e., when neither the debug registers nor the I/O bitmap are used.

This patch covers the x86-64 modifications. A patch for i386 follows.

Changelog:
	- add TIF_DEBUG to track when debug registers are active
	- add TIF_IO_BITMAP to track when I/O bitmap is used
	- modify __switch_to() to use the new TIF flags

<signed-off-by>: eranian@hpl.hp.com

Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26 10:52:28 +02:00
Andi Kleen
2c87e2cd0b [PATCH] x86_64: Fix access check in ptrace compat
We can't safely directly access an compat_alloc_user_space() pointer
with the siginfo copy functions. Bounce it through the stack.

Noticed by Al Viro using sparse

[ This was only added post 2.6.17, not in any released kernel ]

Cc: Al Viro <viro@ftp.linux.org.uk>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-10 15:12:33 -07:00
Andi Kleen
5c0f80fab3 [PATCH] x86_64: Remove long obsolete CVS
Early development of x86-64 Linux was in CVS, but that hasn't been
the case for a long time now. Remove the obsolete $Id$s.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 10:48:16 -07:00
Andi Kleen
f0f2d6536e [PATCH] x86_64: Implement compat functions for PTRACE_SETSIGINFO/GETSIGINFO
Previously we would just silently provide 64 bit services
for this to 32bit processes.

I also added all the other cases explicitely to the ptrace
compat wrapper to make sure this doesn't happen again.

And removed one bogus check in the wrapper.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 10:48:15 -07:00
Al Viro
bb049232fa [PATCH] amd64: task_pt_regs()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-12 09:08:51 -08:00
Chuck Ebbert
60923df35e [PATCH] x86_64: allow setting RF in EFLAGS
Setting RF (resume flag) allows a debugger to resume execution after a code
breakpoint without tripping the breakpoint again.  It is reset by the CPU
after executing one instruction.

Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-11 19:05:00 -08:00
Christoph Hellwig
6b9c7ed848 [PATCH] use ptrace_get_task_struct in various places
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 <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 20:13:51 -08:00
Daniel Jacobowitz
e8ed11b9dc [PATCH] x86_64: fix 32-bit thread debugging
The IA32 ptrace emulation currently returns the wrong registers for fs/gs;
it's returning what x86_64 calls gs_base.  We need regs.gsindex in order
for GDB to correctly locate the TLS area.  Without this patch, the 32-bit
GDB testsuite bombs on a 64-bit kernel.  With it, results look about like
I'd expect, although there are still a handful of kernel-related failures
(vsyscall related?).

Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-04 16:28:27 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00