On 08/13, Tom Tromey wrote:
Roland However, I think the test you probably want is !S_ISCHR.
Thanks. I wasn't sure.
Roland Actually, better yet, just make it !isatty (fd).
Ok.
Good. IIUC, this also allows to remove the ugly return 0
to pretend TCGETS/TCSETS/TCFLSH works from -ioctl().
I
No changes in the compiled code. Just make the code parsable by humans.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
--- kstub/kernel/utrace.c~1_use_cleanup_exit_state_checks 2010-08-14
04:28
but allows
set, the latter case should be forbidden too.
If utrace_set_events(UTRACE_EVENT(REAP)) succeeds, the caller
has all rights to expect -report_reap() will be caller later.
If you take this patch, then please consider the next one.
Signed-off-by: Oleg Nesterov o
On 08/11, Tom Tromey wrote:
Oleg == Oleg Nesterov o...@redhat.com writes:
Oleg So, the patch below fixes the problem, and gdb + /proc/ugdb seems
Oleg to work.
Oleg Indeed, gdb sees that this fd is not pipe/tcp and uses the hardwire
Oleg serial_ops, but hardwire_readchar() doesn't play
Please see the attached ugdb.c.
It supports multiple inferiors/threads, stop/cont, clone/exit.
It doesn't report W/X when the process exits yet, but this is
only because I'd like to discuss the current problems with the
exited leader first, then implement this as a separate change.
Any code
On 08/03, Kevin Buettner wrote:
On Tue, 3 Aug 2010 15:14:36 +0200
Oleg Nesterov o...@redhat.com wrote:
To avoid the unnecessary details, consider the oversimplified example,
$ sleep 1
[1] 2923
$ cat SLEEP
set target-async on
set non-stop
target
On 08/03, Jan Kratochvil wrote:
On Wed, 28 Jul 2010 20:17:02 +0200, Oleg Nesterov wrote:
Btw, gdb crashes very often right after
(gdb) set target-async on
(gdb) set non-stop
(gdb) file mt-program
(gdb) target extended-remote :port
(gdb) attach its_pid
I
Forgot to mention,
On 08/03, Oleg Nesterov wrote:
So I assumed it is always safe to resend the notification unless gdb already
sent vStopped. Since it is not clear to me when it makes sense to resend it,
currently gdbstub does re-send every time /proc/ugdb reports the new event
(T00
On 07/28, Oleg Nesterov wrote:
- currently it only supports attach, stop, cont, detach
and exit.
OK, I am a bit stuck.
I am trying to implement attach-to-the-thread-group, and I'd like
to invent something simple without O(n**2) and semaphores in
-report_clone(). There are other
On 07/29, Frank Ch. Eigler wrote:
Oleg Nesterov o...@redhat.com writes:
[...]
- ugdb.c
The kernel module which implements the basic
user-space API on top of utrace. Of course,
this API should be discussed.
- gdbstub
On 07/26, Oleg Nesterov wrote:
I decided to take a bit different approach, we will see if it
makes sense in the longer term.
Please see the attached files,
- ugdb.c
The kernel module which implements the basic
user-space API on top of utrace. Of course
On 07/16, Roland McGrath wrote:
Note that currently I am not even trying to do something meaningful
with utrace. My only goal for now is to implement the very basic things
like attach/detach/stop/cont/exit correctly from the remote protocol
pov. And I want to do this rightly, then we will
On 07/13, Oleg Nesterov wrote:
And now I am going to rewrite this code without adding the new
functionality (this shouldn't take much time, hopefully today).
Next iteration. Misc changes, but still in the initial stage. The
only visible change is that cont/ctrl-c pretends to work.
Note
On 07/13, Ananth N Mavinakayanahalli wrote:
Given these requirements, and given that the 'new' uprobes is close to
-tip, would it be more useful to pursue an alternate syscall approach
rather than gdbstub?
Roland has already answered, and I agree.
The problem is that we do not have the new
On 07/12, Roland McGrath wrote:
Please see the attachment. Don't take this code seriously, this is
the early prototype and everything should be rewritten. It barely
uses utrace, only to stop the target.
You've got to start somewhere!
Yes ;)
And now I am going to rewrite this code
Hello.
Please see the attachment. Don't take this code seriously, this is
the early prototype and everything should be rewritten. It barely
uses utrace, only to stop the target.
(gdb) file /path/to/binary
(gdb) target extended-remote /proc/ugdb
(gdb) attach PID
Introduce ENGINE_LSM_TRACE and ENGINE_LSM_TRACE_CAP bits for
utrace_unsafe_exec(). These bit should be set when we attach the
new engine by user request.
Note: we use engine-flags and task-utrace_flags, this doesn't
really matter. The only important point is: somehow utrace_engine
should have the
The only patch which probably makes sense anyway.
Currently utrace assumes that task-utrace_flags can have only one
special bit, ENGINE_STOP. But it make sense to add more special bits.
For example, ptrace-utrace. It still uses task-ptrace for PT_PTRACE_CAP
and PT_UTRACED (the latter one is only
Convert ptrace to use utrace_set_caps(). ptrace_report_clone() uses
utrace_get_caps() and PT_UTRACED instead of parent-ptrace.
Henceforth task_struct-ptrace is only used for PT_UTRACED, and this
bit can be moved into ENGINE_EXTRA_FLAGS.
utrace_unsafe_exec() doesn't need to play with task-ptrace
Introduce utrace_unsafe_exec() used by tracehook_unsafe_exec().
Currently the new helper just copies the old -ptrace logic.
Whatever we do, we need something like this patch. Once we implement
anything which can be used by unprivileged user we should handle the
security problems, in particular we
On 07/07, Roland McGrath wrote:
For exec transitions (set-id, file caps, selinux), I'd originally figured
an engine's report_exec could check for changes and decide to detach itself
if appropriate.
No, it can't. At this point S_ISUID/S_ISGID exid's were already dropped,
or exec can fail
On 06/22, Roland McGrath wrote:
OTOH, I am wondering if we can give more power to utrace_control(STOP).
Currently debugger can't stop the tracee unless it cooperates. However, if
the tracee doesn't have UTRACE_EVENT(QUIESCE), then utrace_control(STOP)
works. This is strange.
Why is it
On 06/21, Roland McGrath wrote:
I am wondering if there is another way to handle such a race...
Suppose we
- add UTRACE_STOP_XXX
- modify utrace_control(UTRACE_STOP_XXX) to do
mark_engine_wants_stop() and nothing more.
utrace_control(current,,UTRACE_STOP) doesn't
On 06/17, Alpár Török wrote:
The producer is a utrace monitored task. At any time there is an
arbitrary number of producers. On sys_entry and sys_exit the producers
do :
slot = book_message_in_buffer(buf);
if (slot 0) {
/* no slot can be alocated, producer must sleep */
On 01/26, Linus Torvalds wrote:
The problem is that anything that is based on reparenting and signals is
fundamentally a one parent only kind of interface. See?
Indeed. signals + do_wait() is the horrible model.
So the reason I think using an fd is a good idea is _not_ because gdb
already
On 01/26, Andi Kleen wrote:
But when I did that i couldn't come up with a good scenario
where multiple debuggers actually make sense. In a sense
being a debugger is really a very intimate thing for process. Do you
really want to have multiple of them messing with each other?
If yes how
On 01/26, Andi Kleen wrote:
Simple example. Try to debug/strace strace ot gdb itself. Not trivial,
you can't attach to strace's tracees. Recently I spent 2 days trying to
understand why strace -f hangs. I was able to attach to strace, but
I wasn't able to see what its tracees do.
But
On 01/21, Linus Torvalds wrote:
On Thu, 21 Jan 2010, Andrew Morton wrote:
ptrace is a nasty, complex part of the kernel which has a long history
of problems, but it's all been pretty quiet in there for the the past few
years.
More importantly, we're not ever going to get rid of it.
On 01/21, Linus Torvalds wrote:
I realize that my argument is very anti-thetical to the normal CS teaching
of general-purpose is good. I often feel that very specific code with
very clearly defined (and limited) applicability is a good thing - I'd
rather have just a very specific ptrace layer
On 01/07, Roland McGrath wrote:
I am confused as well. Yes, I thought about regs-psw.mask change too,
but I don't understand why it helps..
[...]
But. Acoording to the testing I did (unless I did something wrong
again) this patch doesn't make any difference in this particular
case.
Martin, sorry for delay,
On 01/07, Martin Schwidefsky wrote:
On Wed, 6 Jan 2010 13:13:29 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
However, with or without CONFIG_UTRACE,
6580807da14c423f0d0a708108e6df6ebc8bc83d
is needed on s390 too, otherwise the child gets unnecessary
On 01/07, Martin Schwidefsky wrote:
On Wed, 6 Jan 2010 13:08:12 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
That's what tracehook_signal_handler is for. You're both doing it yourself
in the arch code (by setting TIF_SINGLE_STEP), and then telling the generic
code to do it (by
On 01/06, caiq...@redhat.com wrote:
Cai, any chance you can help? Using /usr/bin/console I can't choose
anotherkernel at the 00: Please choose (default will boot in 15 seconds):
stage, how can I do this???
As Heiko mentioned, I did manage to enter,
#cp vi vmsg 2
if only I new about
On 01/05, Oleg Nesterov wrote:
On 01/05, Oleg Nesterov wrote:
On 01/05, Oleg Nesterov wrote:
I'll add clear_bit(TIF_SINGLE_STEP) into do_fork() path and re-test.
Hmm. This patch
--- kernel/fork.c~ 2009-12-22 10:41:53.188084961 -0500
+++ kernel/fork.c 2010
On 01/05, Martin Schwidefsky wrote:
On Mon, 4 Jan 2010 13:11:47 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
This probably means that copy_process()-user_disable_single_step()
is not enough to clear the this task wants single-stepping copied
from parent.
I would suspect
On 01/05, Martin Schwidefsky wrote:
On Mon, 4 Jan 2010 13:11:47 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
This probably means that copy_process()-user_disable_single_step()
is not enough to clear the this task wants single-stepping copied
from parent.
I would suspect
On 01/05, Oleg Nesterov wrote:
Anyway. I modified the debugging patch a bit:
--- K/arch/s390/kernel/traps.c~ 2009-12-22 10:41:52.909174198 -0500
+++ K/arch/s390/kernel/traps.c2010-01-05 09:49:19.541792379 -0500
@@ -384,6 +384,8 @@ void __kprobes do_single_step(struct pt_
On 01/05, Martin Schwidefsky wrote:
On Tue, 5 Jan 2010 16:36:33 +0100
Oleg Nesterov o...@redhat.com wrote:
For example, why do_signal() sets TIF_SINGLE_STEP? Why can't we do
--- a/arch/s390/kernel/signal.c
+++ b/arch/s390/kernel/signal.c
@@ -500,18 +500,10 @@ void
On 01/04, Oleg Nesterov wrote:
IOW. I think this problem is minor and probably can be ignored,
Or may be not...
Even if the child is not killed by SIGTRAP, it can get a lot of
unnecessary traps.
To verify, I did another trivial patch (below), and the test
case from
On 12/22, Andrew Morton wrote:
On Fri, 18 Dec 2009 02:11:16 +0100
Oleg Nesterov o...@redhat.com wrote:
It allows for multiple separate tracing engines to work
in parallel without interfering with each other. Higher-level tracing
facilities can be implemented as loadable kernel modules
-ptrace or PT_PTRACED
directly, change arch/s390/kernel/traps.c to use the helper.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath rol...@redhat.com
---
arch/s390/kernel/traps.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- V1/arch/s390/kernel/traps.c
On 12/22, Oleg Nesterov wrote:
On 12/22, caiq...@redhat.com wrote:
and a different syscall number when syscall-from-clone failed.
This is not clear to me, will take a look.
Should I say I know nothing about s390 and can't read its asm?
First of all, I think syscall-from-clone is wrong
On 12/22, Oleg Nesterov wrote:
On 12/22, Oleg Nesterov wrote:
and I don't know whether it is OK or not that syscall-from-clone
sees different -orig_gpr2 after return from fork() on s390
-unexpected syscall 0x5ee9 without utrace
+unexpected syscall 0
On 12/21, Jan Kiszka wrote:
Oleg Nesterov wrote:
Hmm. Now I see how wrong I was when I said this code is obviously wrong ;)
Yes, it is easy to blame the code you don't understand.
My apologies to all.
I'll add the debugging printk's and report the output. Sorry for delay,
can't do
On 12/18, Frederic Weisbecker wrote:
On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
Hi.
do_debug() is obviously wrong wrt PTRACE_SINGLESTEP/TIF_SINGLESTEP, no?
Afaics this was broken by
hw-breakpoints: modifying generic debug exception to use
thread-specific
On 12/18, K.Prasad wrote:
On Fri, Dec 18, 2009 at 06:27:47PM +0100, Oleg Nesterov wrote:
On 12/18, Frederic Weisbecker wrote:
On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
Hi.
snipped
Single stepping works well for me, after a quick check on
gdb. How did you
On 12/18, Roland McGrath wrote:
Please find the trivial test-case below. It hangs, because
PTRACE_SINGLESTEP doesn't trigger the trap.
2.6.33-rc1 x86-64 works for me with either -m64 or -m32 version of that test.
(not sure this matters, but I did the testing under kvm)
Apparently it
It was always supposed to be mb(), not rmb().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- UTRACE_PTRACE/include/linux/tracehook.h~1_NOTIFY_RESUME_MB 2009-12-17
17:00:31.0 +0100
Somehow I placed CONFIG_UTRACE between AUDIT and AUDITSYSCALL,
move it down after AUDITSYSCALL.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
init/Kconfig | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
--- UTRACE_PTRACE/init/Kconfig~2_CONFIG_UTRACE_AUDIT2009
Hi.
do_debug() is obviously wrong wrt PTRACE_SINGLESTEP/TIF_SINGLESTEP, no?
Afaics this was broken by
hw-breakpoints: modifying generic debug exception to use
thread-specific debug registers
commit 08d68323d1f0c34452e614263b212ca556dae47f
To verify, the patch below fixes the
is implemented on top of utrace, eventually this code will be removed
completely.
Signed-off-by: Roland McGrath rol...@redhat.com
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/signal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- V1/kernel/signal.c~3_PTRACE_SIGNAL_CK_PTRACED
Export __ptrace_detach() and do_notify_parent_cldstop() for
ptrace-utrace.
Signed-off-by: Roland McGrath rol...@redhat.com
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/ptrace.h |1 +
include/linux/sched.h |1 +
kernel/ptrace.c|2 +-
kernel/signal.c
No functional changes, preparation for the next patch.
Move the code which can be shared with ptrace-utrace up, before
__ptrace_link(). This way ptrace-utrace needs a single #ifdef in
ptrace.c.
Signed-off-by: Roland McGrath rol...@redhat.com
Signed-off-by: Oleg Nesterov o...@redhat.com
change to userland when CONFIG_UTRACE is enabled.
Signed-off-by: Roland McGrath rol...@redhat.com
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/ptrace.h |2
kernel/Makefile|1
kernel/ptrace.c|2
kernel/ptrace-utrace.c | 1080
On 12/17, Roland McGrath wrote:
Comparing to the old (2.6.32) logic, I think it might be this (untested).
I also note this is the sole use of get_si_code, seems like it should
just be rolled in here.
Well, it is too late for me to even try to read this patch ;)
but...
@@ -569,14 +568,15 @@
On 12/13, Roland McGrath wrote:
Its not entirely clear why we can check pending_attach outside of the
utrace-lock and not be racy.
I think it can be racy sometimes but that does not matter.
Maybe Oleg can verify my logic here. If it's right, he can
add some comments to make it more
On 12/14, Peter Zijlstra wrote:
Quite gross this.. can't we key off the
tracehoook_report_clone_complete() and use a wakeup there?
Yes, we intended to clean this up at some point later. But doing that
is just a distraction and complication right now so we put it off. For
this
On 12/14, Oleg Nesterov wrote:
IOW, we must ensure that if ever clear TIF_NOTIFY_RESUME we must not
miss -pending_attach, correct? and for this case we have mb() after
clear_thread_flag(). Perhaps instead we should add mb__after_clear_bit()
into arch/ hooks, but this needs a lot of arch
On 12/14, Roland McGrath wrote:
In the stopped cases, there are lots of locks and barriers and things
after resuming. (Oleg?)
Every time the tracee resumes after TASK_TRACED it uses utrace-lock
to synchronize with utrace_control/etc, it must see any changes.
And TASK_STOPPED?
the change in flags.
utrace_set_events() does not set _UTRACE_DEATH_EVENTS if -exit_state
was already set by exit_notify(), and after we set -exit_state under
write_lock(tasklist) we must see the change in -utrace_flags.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |9
Due to typo, utrace_attach_delay() always succeeds if the caller
is not traced. The creator must have the valid -utrace != NULL
and utrace-cloning should be target.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c | 20
1 file changed, 12 insertions(+), 8
My attempt to make the comment more explicit.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- UTRACE-PTRACE/include/linux/tracehook.h~3_NOTIFY_RESUME_MB_COMMENT
2009-12-12 16:32:39.0 +0100
Move the comment from utrace_task_alloc() to utrace_add_engine()
and try to make it a bit more clear.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/utrace.h |4 ++--
kernel/utrace.c| 11 +--
2 files changed, 7 insertions(+), 8 deletions(-)
--- UTRACE
On 12/11, K.Prasad wrote:
On Thu, Dec 10, 2009 at 08:24:36PM +0100, Oleg Nesterov wrote:
Oh well. I spent this day grepping arch/powerpc to understand how
PTRACE_SET_DEBUGREG works and what is the problem. But I am afraid
this time I need a help from someone who understands the hardware
On 12/11, Oleg Nesterov wrote:
For those who didn't read the whole thread, the test-case:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/watchpoint.c?cvsroot=systemtap
or you can look at
https://www.redhat.com/archives/utrace-devel/2009-December
On 12/10, Oleg Nesterov wrote:
On 12/09, CAI Qian wrote:
- Oleg Nesterov o...@redhat.com wrote:
Thanks, but it doesn't fail for me on this machine...
Hmm, it failed for me.
# cd /root/ptrace-tests
# make check
...
FAIL: watchpoint
OMG. Yet another test-case fails
On 12/08, Ananth N Mavinakayanahalli wrote:
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
On 12/08, caiq...@redhat.com wrote:
This is seen with and without CONFIG_UTRACE.
Good, at least we shouldn't worry about 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
(add cc's)
On 12/03, Roland McGrath wrote:
Not sure what should we do right now, s390 needs more attention.
Also, it uses PT_PTRACED bit, I am afraid this is not what we wan
with utrace.
This looks simple. Its one use can just be
tracehook_consider_fatal_signal(SIGTRAP) instead. I
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 12/07, caiq...@redhat.com 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
machine?
Funny enough. The above failure only
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 to the thunk (I do not know the correct English term)
ppc64 calls it function descriptor (GDB
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 to the thunk (I do not know the correct English term)
ppc64 calls
On 12/05, caiq...@redhat.com wrote:
Yes, it looks good so far. Ptrace tests also does not show any
regression.
I said this too early. Looks like step-jump-count started to fail now.
step-jump-cont: step-jump-cont.c:244: main: Assertion `0' failed.
/bin/sh: line 5: 28212 Aborted
You are right, thanks, suppress_sigtrap() is no longer needed.
Surprisingly, it even has the comment which explains why it was needed before,
and since the recent changes SIGTRAP from tracehook_report_syscall_exit()
pathes is just not possible with utrace.
This should also fix the compilation on
Fix __must_check warnings. The change in ptrace_wake_up() just fools
the compiler, we really don't care if utrace_control() fails or returns
something like -EINPROGRESS. But we could add a clever WARN_ON(err..)
perhaps.
---
kernel/ptrace-utrace.c |8 +---
1 file changed, 5
Jan, this fixes step-fork.c on powerpc.
Without this patch it just hangs, see
http://marc.info/?t=12592474861
On 12/01, Veaceslav Falico wrote:
Instead of using fork(), call syscall(__NR_fork) in step-fork.c
to avoid looping on powerpc arch in libc.
Signed-off-by: Veaceslav
On 12/05, caiq...@redhat.com wrote:
Yes, it looks good so far. Ptrace tests also does not show any
regression.
I said this too early. Looks like step-jump-count started to fail now.
step-jump-cont: step-jump-cont.c:244: main: Assertion `0' failed.
/bin/sh: line 5: 28212 Aborted
-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- UTRACE-PTRACE/kernel/utrace.c~DONT_CHANGE_OPS_LOCKLESS 2009-11-24
17:20:33.0 +0100
+++ UTRACE-PTRACE/kernel/utrace.c 2009-12-04 17:10:37.0 +0100
the promised patch which kills supress_sigtrap() tomorrow,
it needs testing/checking.
On 12/04, Oleg Nesterov wrote:
On 12/04, Roland McGrath wrote:
I think the problem is clear now.
Ok. We should probably move this discussion to utrace-devel.
Yes, I didn't notice we discuss
On 12/01, Peter Zijlstra wrote:
+static inline __must_check int utrace_control_pid(
+ struct pid *pid, struct utrace_engine *engine,
+ enum utrace_resume_action action)
+{
+ /*
+* We don't bother with rcu_read_lock() here to protect the
+* task_struct pointer, because
On 11/30, Oleg Nesterov wrote:
On 11/29, Roland McGrath wrote:
Please file this test case on bugzilla.redhat.com for Fedora 12 glibc.
https://bugzilla.redhat.com/show_bug.cgi?id=542731
It was closed as NOTABUG, Andreas Schwab wrote:
If you call clone directly you are responsible
On 12/01, Peter Zijlstra wrote:
On Tue, 2009-11-24 at 21:02 +0100, Oleg Nesterov wrote:
+ para
+There is nothing a kernel module can do to keep a structnamestruct
+task_struct/structname alive outside of
+functionrcu_read_lock/function.
Sure there is, get_task_struct
On 11/29, Roland McGrath wrote:
Please file this test case on bugzilla.redhat.com for Fedora 12 glibc.
https://bugzilla.redhat.com/show_bug.cgi?id=542731
Oleg.
On 11/30, Benjamin Herrenschmidt wrote:
On Mon, 2009-11-30 at 10:15 +1100, Benjamin Herrenschmidt wrote:
Yes, the asm should be changed. I suppose we could check if the result
of do_syscall_trace_enter is negative, and if it is, branch to the exit
path using r3 as the error code. Would
On 11/30, Benjamin Herrenschmidt wrote:
On Sun, 2009-11-29 at 22:07 +0100, Oleg Nesterov wrote:
If I change the test-case to use NEWVAL == 1000 (or any other value
greater than NR_syscalls), then the tracee sees ENOSYS and this is
correct too.
But I do not see how it is possible
(add cc's)
On 11/27, caiq...@redhat.com wrote:
I have consistently reproduced the failure with clone-multi-ptrace
with both the patched and unpatched F13 kernels.
# ./clone-multi-ptrace
clone-multi-ptrace: clone-multi-ptrace.c:205: try_to_reproduce: Assertion
`__extension__ (((union {
On 11/27, Christoph Hellwig wrote:
On Thu, Nov 26, 2009 at 01:24:41PM +0100, Ingo Molnar wrote:
FYI, it's been in -mm, that's where it's maintained.
None of the recent mm snapshots has anything utrace related in there,
Well, not that I think this is important, but...
Two weeks ago we
On 11/27, Veaceslav Falico wrote:
On Wed, Nov 25, 2009 at 01:17:15PM -0800, Roland McGrath wrote:
That's certainly good to hear. If you are pretty confident about that,
then I am quite happy to consider nonregression on all of ptrace-tests the
sole gating test for kernel changes. We
On 11/27, Ananth N Mavinakayanahalli wrote:
On Thu, Nov 26, 2009 at 03:50:51PM +0100, Oleg Nesterov wrote:
Ananth, could you please run the test-case from the changelog
below ? I do not really expect this can help, but just in case.
Right, it doesn't help :-(
GDB shows that the parent
On 11/26, Christoph Hellwig wrote:
What the patches in the current form do is to introduce two different
ptrace implementations, with one used on the architectures getting most
testing and another secondary one for left over embedded or dead
architectures with horrible results.
Yes, nobody
Veaceslav doesn't have the time to continue, but he gave me
access to rhts machine ;)
The kernel is 2.6.31.6 btw.
On 11/26, Veaceslav Falico wrote:
Just noticed the test-case fails in handler_fail(). Most probably
this means it is killed by SIGALRM because either parent or child
hang in
On 11/26, Oleg Nesterov wrote:
Then it loops inside __GI__IO_list_lock
0xfeacd24
0xfeacd28
0xfeacd2c
0xfeacd30
0xfeacd34
...
and so on forever,
Dump of assembler code for function __GI__IO_list_lock:
0x0feacce0 __GI__IO_list_lock+0
(status))
break;
assert(ptrace(PTRACE_SINGLESTEP, pid, 0,0) == 0);
}
assert(WEXITSTATUS(status) == 43);
return 0;
}
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath
First of all, thanks Ananth and Cai for help!
Jan, I need your help ;)
looking at different reports I can't understand how to interpret them.
To the point, I do not understand if the overall results are good or bad.
The first question, are these tests supposed to be stable?
For example,
Move CONFIG_UTRACE from the topmost menu into General setup,
near Auditing support.
(this matches the patch we sent for review)
Signed-off-by: Oleg Nesterov o...@redhat.com
---
init/Kconfig | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
--- UTRACE-PTRACE/init
On 11/25, Christoph Hellwig wrote:
On Tue, Nov 24, 2009 at 09:01:27PM +0100, Oleg Nesterov wrote:
Hello.
This is the new iteration of Roland's utrace patch, this time
with rewrite-ptrace-via-utrace + cleanups in utrace core.
1-7 are already in -mm tree, I am sending them to simplify
Hello.
This is the new iteration of Roland's utrace patch, this time
with rewrite-ptrace-via-utrace + cleanups in utrace core.
1-7 are already in -mm tree, I am sending them to simplify the
review.
8-12 don not change the behaviour, simple preparations.
13-14 add utrace-ptrace and utrace
ptrace_link().
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath rol...@redhat.com
---
include/linux/ptrace.h | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
--- V1/include/linux/ptrace.h~1_PTRACE_INIT_TASK2009-11-24
19:46:51.0 +0100
+++ V1
101 - 200 of 551 matches
Mail list logo
