On Mon, Dec 07, 2009 at 01:43:27PM +0100, Oleg Nesterov wrote:
On 12/06, CAI Qian wrote:
Ananth, could you please confirm once again that step-jump-cont (from
ptrace-tests testsuite) not fail on your machine? If yes, please tell
me the version of glibc/gcc. Is PTRACE_GETREGS defined on your
On Mon, Dec 07, 2009 at 07:05:40PM +0100, Oleg Nesterov wrote:
On 12/07, Oleg Nesterov wrote:
On 12/07, Jan Kratochvil wrote:
On Mon, 07 Dec 2009 15:24:51 +0100, Oleg Nesterov wrote:
But. raise_sigusr2 is not equal to the actual address of
raise_sigusr2(),
this value points
This is seen with and without CONFIG_UTRACE.
FAIL: watchpoint
ppc-dabr-race: ./../tests/ppc-dabr-race.c:141: handler_fail: Assertion `0'
failed.
/bin/sh: line 5: 31750 Aborted ${dir}$tst
FAIL: ppc-dabr-race
Are those known issues?
Thanks,
CAI Qian
Title: Nouvelle campagne
Si
vous n'arrivez pas consulter correctement ce message,
rendez-vous ici
On Tue, 2009-12-08 at 16:04 +0100, Oleg Nesterov wrote:
The
problem is, this code was developed out-of-tree. That is why we would
like to merge it asap, then do other changes which could be easily
reviewed.
Now, do you really mean we should throw out the working code, rewrite
it avoiding
On 12/08, Peter Zijlstra wrote:
On Tue, 2009-12-08 at 16:04 +0100, Oleg Nesterov wrote:
Well, this is subjective, but I don't agree that
get_task_struct(task);
task-utrace_flags = flags;
spin_unlock(utrace-lock);
put_task_struct(task);
looks
On 12/08, Peter Zijlstra wrote:
On Tue, 2009-12-08 at 16:04 +0100, Oleg Nesterov wrote:
The
problem is, this code was developed out-of-tree. That is why we would
like to merge it asap, then do other changes which could be easily
reviewed.
Now, do you really mean we should throw out
On Tue, 2009-12-08 at 17:31 +0100, Oleg Nesterov wrote:
If you take a task ref you can write the much saner:
utrace_control()
{
...
spin_lock(utrace-lock);
...
if (reset)
utrace_reset(utrace);
spin_unlock(utrace-lock);
}
No, get_task_struct() in
Hi -
Help me out here: by kgdb extension do you imagine something new
that an unprivileged user can use to debug his own process? Or do
you imagine a new userspace facility that single-steps the kernel?
Is this a trick question? Single-stepping the kernel on the same system
