OK, so here's my (hacky) idea:
(1) Forget ptrace-via-utrace. Have utrace be a separate thing. This
way the recent ptrace changes won't matter.
(2) But, what about ptrace co-existing well with utrace? Make them
mutually exclusive - a ptraced-process can't be utraced and a
utraced-process
I will see if I can interest people in TI and Linaro. I will need a good
story... ;-)
It is kernel port modernization work that nearly every other platform has
done by now.
I've merged these patches to the utrace-ptrace branch, now merged up to
2.6.37-rc5, and also the 2.6.34 and 2.6.35 backport branches. The 2.6.33
backport branch is no longer being maintained. I didn't update the 2.6.36
backport branch and probably won't maintain it unless some Fedora release
Is a utrace engine with .report_jctl enabled suppose to handle
do_notify_parent_cldstop(current, notify) processing for the last
stopping task ? Or should it muck with task-ptrace to force
tracehook_notify_jctl() to return a non-zero value ?
I can't figure out exactly how to construe this as
Probably, I am not sure. I can't recall the previous discussions.
Me either (except hazily the one notion I mentioned), but that's why
we have mailing list archives.
Afaics, this was introduced by 26fefca955cc7c3c83014be2e10b773209d32eea
utrace: sticky resume action. Before that patch the
Yes. But, with this patch, in this case
utrace_barrier()-get_utrace_lock(attached = false) returns success
and then we check utrace-reporting == engine.
I guess that's OK if -reporting == engine is always set when any kind of
callback might be in progress.
(Hmm. Probably utrace-reap = T case
The 1st patch I sent initially:
--- kstub/kernel/utrace.c~10_utrace_reset_should_clear_ss
2010-09-20 03:55:12.0 +0200
+++ kstub/kernel/utrace.c 2010-09-20 21:33:47.0 +0200
@@ -709,6 +709,7 @@ static bool utrace_reset(struct task_str
Please feel free to ignore this if it's no longer relevant to your work.
I'm trying to catch up on the backlog of replies I owe you. I chose
this one as the arbitrary cut-off before which I think I have already
neglected things too long to still matter.
If engine is detached (has
But. Suppose we have to attached engines. The first engine gets
UTRACE_SIGNAL_REPORT and returns UTRACE_STOP | UTRACE_SIGNAL_IGN.
Right, that's what it would do. I see, you're saying that the
report.result passed on to the next engine would appear like it had
been a real signal that the
1. From what I've read in the DocBook pages I've figured out that I have
to have two report entries. One for syscall_entry and one for
syscall_exit. On syscall_entry I should use syscall_get_nr() and check
if this number is equal to __NR_socket and return UTRACE_SYSCALL_ABORT
in that case and
The ones I'm talking about are Z2/Z3 for (data) watchpoints.
Ah, OK, thanks. I'll try to understand how this works.
In theory these will map to uses of the hw_breakpoint interface.
Thanks,
Roland
I think it would be good to implement a feature that shows how this
approach is an improvement over the current state of gdb+ptrace or
gdb+gdbserver.
Exactly what feature this should be... I don't know :-)
I would imagine something performance-related.
My vague notion was that we'd get it
I think we should start with changing utrace_control(DETACH) anyway,
then try to improve. I'll ressend the one-liner I already showed.
Ok.
Hmm. I'll try to think more. Right now I don't really understand
how to do this correctly.
I wasn't immediately sure either.
OK,
Change utrace_reset() to do user_disable_single_step(). Alternatively
we could change ptrace layer, but I think this is not ptrace specific.
Yes, it's right to fix this in the utrace layer.
But I'm not sure that's the right place in the code to fix it.
The expectation is that either we'll
OK, so what should we do for now?
If we can't come to a straightforward answer for the general case
fairly quickly, then we can do the simple change to start with.
Without the multitracing utrace_resume()-user_disable_single_step()
fixes the problem. Otherwise we probably need
The problem is, utrace_control(UTRACE_RESUME) can't prevent the stop if
the tracee has already returned UTRACE_STOP, but utrace_stop() didn't
take utrace-lock yet.
So you are saying that utrace_barrier does not meet its documented API.
Right? It says effect ... has been applied. But that's
The traditional method is to restore the original instruction replaced by
the breakpoint in text, single-step over that instruction, then restore the
breakpoint in text, then continue. That method requires all-stop so that
while you are stepping the thread that just hit the breakpoint, you can't
Please note that last year's gdbstub prototype used kernel uprobes as
an optional gdb breakpoint implementation (i.e., a backend for the Z
packets). When/if the lkml uprobes patches actually get merged, ugdb
should also use them.
That's something for later, and it's not quite so simple. If
I am a bit confused... OK, ugdb is wrong wrt multitracing.
UTRACE_SIGNAL_REPORT case shouldn't return UTRACE_STOP | UTRACE_SIGNAL_IGN,
it should return UTRACE_STOP | UTRACE_SIGNAL_REPORT to keep report-result.
No, UTRACE_SIGNAL_REPORT is not meant for a return value. Its only use is
in the
But I meant another case, when the stopped tracee doesn't have siginfo.
Currently ugdb just sends this signal to tracee, and then it will be
reported to gdb. Not sure if this is right or not, I can change this.
(or perhap this doesn't matter, I dunno).
What do you mean by doesn't have
I misunderstood the UTRACE_INTERRUPT without UTRACE_EVENT(QUIESCE) above
as if you mean it is possible to get UTRACE_SIGNAL_REPORT without QUIESCE.
No, I meant the opposite: since you won't get UTRACE_SIGNAL_REPORT without
UTRACE_EVENT(QUIESCE), it might seem that UTRACE_INTERRUPT should not be
ugdb sets please stop flag and does utrace_control(INTERRUPT). However,
in unlikely case the tracee can stop before -report_signal() reporting
I don't think this is the right thing to do. When the intent is explicitly
to interrupt, there is no reason to stop before the interruption is
Currently GDB does not do anything special, that is if there is siginfo for
signal SIGUSR1 but one does $C0B (SIGSEGV) does ptrace reset the siginfo or is
left the SIGUSR1 siginfo for SIGSEGV?
The kernel considers this sloppy behavior on the debugger's part. If
you inject a different signal,
Hmm. I am not sure I understand. If -report_signal != NULL, then
you can't expect -report_quiesce() after utrace_control(INTERRUPT) ?
Sorry, I used report_quiesce as shorthand for either report_quiesce, or
report_signal with UTRACE_SIGNAL_REPORT.
So, it is technically kosher enough to use
But probably we need utrace_detached_ops-report_reap() anyway.
-report_death can return UTRACE_DETACH, and after that utrace_report_death()
can skip utrace_reset() and do -report_reap().
Yeah, that's a good point. There's no good reason to do a special case
check for detached_ops there rather
When the main thread exits, gdbserver still exposes it to gdb as
a running process. It is visible via info threads, you can switch
to this thread, $Tp or $Hx result in OK as if this thread is alive.
gdbserver even pretends that $vCont;x:DEAD_THEAD works, although
this thread obviously can
On 08/16, Roland McGrath wrote:
- It is possible that both -death and -reap are true. In this
case it is OK to clear UTRACE_EVENT(REAP), but set_events fails.
No, it's not OK to clear it. Once -reap is set, then the engine's
ops-report_reap might or might not have been called
This is the minimal temporary ugly fix for now, we should certainly
cleanup and simplify this logic. The barriers in mark_engine_detached()
and in start_callback() can't help and should be removed. If we ignore
utrace_get_signal() we do not even need utrace_detached_quiesce(),
utrace_resume(UTRACE_REPORT) always calls utrace_reset() because
start_callback() obviously can't clear report-spurious when
event == 0.
Change start_callback() to correctly clear -spurious in this case.
Ok.
Note: utrace_control(DETACH) does utrace_do_stop() and sets UTRACE_REPORT
if the
Note the second attachment, GDBCAT. It is just the simple perl
script which connects /proc/ugdb to tcp port. It can be used for
remote debugging via tcp, or with (unpatched) gdb which can't do
select() on /proc/ugdb.
bash$ nc -l 2000 /proc/ugdb
Actually, it is more convenient to use
it
Hmm. For unknown reason I do not see this 2/4 patch on utrace-devel,
strange.
So I am attaching it in case my email was really lost and you didn't
get it.
Indeed, it did not come through to me or the list.
Thanks,
Roland
utrace_set_events() checks the setting _UTRACE_DEATH_EVENTS case twice,
and it is not immediately obvious why the first check is needed, and why
it is not racy (we are checking exit_state without tasklist). The code is
correct, but looks confusing.
More comments are always good.
In short:
get_utrace_lock() must threat utrace-reap == T as engine-ops == NULL.
Yes, I think you're right. This requires some changes to the kerneldoc and
utrace.tmpl, because it now says that you get EALREADY if report_reap is
already running. Now it will be consistent with utrace_control, where you
The problem is, utrace_control(DETACH) does nothing and returns
-EALREADY if utrace-death is set, this is not right. We can and
should detach in this case, we only should skip utrace_reset() to
avoid the race with utrace_report_death()-REPORT_CALLBACKS().
This behavior is the original
Whatever we do, start_callback() can see the old engine-flags but
the new -ops = utrace_detached_ops. Just suppose that the caller
of UTRACE_DETACH is interrupted right after setting engine-ops.
* it can check the old flags before using the old ops, or check the old
* flags before using the
I don't know this area well, but considering that ser-unix.c is just
chock full of tty-related goo, I think it is probably important for
something. My impression is that this API is not just used for target
communication but also for manipulating gdb's own terminal.
Ah, I see.
I've
I seem to understand the problem(s). I am a bit surprized. Basically
I have the questions about almost every utrace_ function. I'll try
to recheck and summarize my concerns tomorrow with a fresh head, I
hope I missed something.
Ok. That stuff about pure kernel implementation issues doesn't
Indeed, gdb sees that this fd is not pipe/tcp and uses the hardwire
serial_ops, but hardwire_readchar() doesn't play well with select().
Please teach gdb to use poll/select ?
If it makes it easier, could use:
bash$ nc -l -U /tmp/socket /proc/ugdb
(gdb) target remote |nc -U
I don't really know the gdb code, but I'm surprised it really has multiple
different serial backends. I would have thought that after opening the
fd, you would treat them all about the same. If tcsetattr et al work on
it, then you set the baud rate and whatever, if they say ENOTTY then fine.
It
At first I tried to support both multiprocess and !multiprocess
modes, but this needs too many unnecessary code which I'd like
to avoid, at least now. So this version requires multiprocess+
in qSupported, otherwise target extended-remote fails.
Please
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 discuss utrace
issues.
Ok. I
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?
Feel free to pursue whatever you like. For our own time allocation, we
see an effort along those lines now as a distraction from
What is the reasoning for selecting /proc/ugdb instead of something like
/proc/pid/ugdb?
The protocol, and gdb, support dealing with many processes over one control
channel. For normal the debugger model to work where it can attach to a
process on demand, with your model it would have to open
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! Thanks, Oleg.
It's great to see this get underway.
This seems to work, but I had to
When I had posted a prototype of a gdbstub which Frank and I had
worked on. http://lkml.org/lkml/2009/11/30/173, Peter and Ingo
showed a preference for a combined gdbstub in kernel, i.e kgdb and the
newer stub should use only one stub in kernel. Do we have plans to
handle that?
Their actual
As to the unsafe_exec stuff, I'd long figured we would have something just
about like that. (You might recall that an earlier utrace API had an
unsafe_exec engine callback, which had its own unresolved complications.)
For exec transitions (set-id, file caps, selinux), I'd originally figured
an
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 before before
OK. But then perhaps UTRACE_STICKY_STOP makes sense even without the
races we discussed. It can simplify the cooperation in this case.
The only cooperation methods we should consider are those that cover all
their races.
Yes. Let's consider the concrete example. The tracee is going to
stop
utrace_control(current,,UTRACE_STOP) doesn't really do anything more.
It does utrace_do_stop() which sets UTRACE_REPORT/TIF_NOTIFY_RESUME.
Harmless, but makes sense to avoid.
Right. I was talking about the API perspective. Those internal details
are more or less invisible to a given
I think Roland is right. Let's forget about utrace for the moment,
this code looks like
if (!CONDITION) {
set_task_state(TASK_XXX);
schedule();
}
and it can obviously race with
CONDITION = true;
wake_up_xxx();
This is Linux
You should use linux/wait.h or similar facilities rather than calling
schedule() and wake_up_process() directly. This doesn't have anything to
do with utrace, it's just the clean practice for normal kinds of blocking
in the kernel, for a variety of reasons. That has to do with how your
control
Thanks for your interest in utrace.
It's correct that passing UTRACE_REPORT to utrace_control should
always ensure you get some report_* callback before the tracee returns
to user mode.
However, I think your use may be susceptible to a race between
resumption by utrace_control, and the
obj-m := crash_suspend.o
s/_/-/
But I'm happy to have tracked it down to the utrace-based ptrace
emulation, and was mostly just interested in knowing if preempt and
utrace are fundamentally incompatible on x86_64, or something like
that. I'll fight through the 2.6.18-164 issues instead, since the
ptrace problem doesn't seem
, please let me know.
Thanks,
Roland
---
[PATCH] MAINTAINERS: add utrace
This updates the ptrace entry to cover utrace too.
They are part of the same maintenance effort.
Also add the utrace mailing list.
Signed-off-by: Roland McGrath rol...@redhat.com
---
MAINTAINERS |7 +--
1 files
We don't have any particular plans to extend the ptrace interface.
I strongly doubt we would even try to do anything like that until the
utrace-based ptrace interface is merged into Linux and the old ptrace
implementation gone.
In general, we are not looking for extensions to the ptrace
Ok, I changed the wording slightly:
Clear the TIF_SINGLE_STEP bit in copy_thread. The new process did not get
a PER event of its own. It is wrong deliver a SIGTRAP that was meant for
the parent process.
Very good!
Thanks,
Roland
Right. That means we should leave the status quo of not clearing
TIF_SINGLE_STEP in user_disable_single_step.
Ok, although it seems a bit strange not to do it. Perhaps I should add a
comment about it.
It doesn't seem strange to me, but then I've just been through all this.
user_*_step is
Hmm, command for tracehook_signal_handler say this for stepping:
@stepping: nonzero if debugger single-step or block-step in
use
Are you saying you would like me to clarify that wording somehow? It's
meant to be implicit that the arch code is not doing any special fakery
about
Clear the TIF_SINGLE_STEP bit in copy_thread. If the new process is
not auto-attached by the tracer it is wrong to delivere SIGTRAP to
the new process.
The change is right, but this log entry is confusing. auto-attached has
nothing to do with it, nor does anything about tracing the new
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. 6580807da14c423f0d0a708108e6df6ebc8bc83d
However, with or without CONFIG_UTRACE,
6580807da14c423f0d0a708108e6df6ebc8bc83d
is needed on s390 too, otherwise the child gets unnecessary traps.
This confuses me. user_disable_single_step on non-current doesn't do
anything not already done by the memset in copy_thread. Ooh, except
The PER control registers only get reloaded on task switch. Can you test
if this patch fixes your problem?
Long ago when I first worked with David Wilder on s390 arch code,
I remember we made this change. It seems to have been forgotten
in the later rounds of reworking and merging.
Thanks,
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 s390's TIF_SINGLE_STEP flag here. That flag means a
single-step trap occurred. This is what causes do_single_step to be
called
Well. I had a lot of technical discussions with Roland about utrace,
but I never asked him why he created this thing ;) To me, utrace
looks like vfs. Currently we have the single and very poor filesystem,
ptrace. Until we add the appropriate layer, we can't expect the
further improvements is
Do you have an estimate or better numbers how the overhead of
seccomp-over-utrace compares to the current in-tree seccomp?
I never measured it. I would estimate that any difference one way or
another is in the noise. The point of seccomp is to run a process that
almost never makes any system
Damn, my fault. I forgot to cc you when I sent the fix for s390 (attached
below), and I forgot to remind you about this fix when we discussed the
testing on s390.
That change is upstream for 2.6.33 now. I'll cherry-picked it into
the 2.6.32/tracehook branch so it will be in the backport
Oh. I am still trying to parse arch/s390/kernel/entry.S to understand
how can we fix these test-cases. I think I need the help, will continue
tomorrow.
Martin Schwidefsky schwidef...@de.ibm.com is the s390 arch maintainer.
He is friendly and helpful. You can ask him for help both with
The utrace patch looks suspicious in utrace.h, which cause the compilation
failure without CONFIG_UTRACE. I have confirmed that the git tree looks sane.
+static inline void utrace_init_task(struct task_struct *child)
+{
+}
+{
+}
Oops! That snafu got fixed on the main branch but I
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 does. You should hack some printks into
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.
Thanks,
Roland
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 3339917..16a88f5 100644
---
+ dr6 = tsk-thread.debugreg6;
why? we have tsk-thread.debugreg6 = dr6 above
Yeah, it's a little superfluous. Except that the existing code uses
tsk-thread.debugreg6 and dr6 inconsistently. It only matters either way
if some notifier function might change thread.debugreg6, which I wasn't
C does implicit casts from enum to integer types, right? So always using
u32 here would not impose any extra typing on the user, or am I missing
something subtle here?
No, that's right. I had just been thinking of the documentation /
convenience issue. I figured with u32 people might tend to
Up until now, the utrace git trees were relative to 2.6.32. Now Linus has
merged several of Oleg's small patches that were prerequisites for utrace,
those populating my tracehook branch. So, I've now merged the latest
tree from Linus in, and split out 2.6.32/* branches.
We still have a
In http://kojipkgs.fedoraproject.org/packages/kernel/2.6.32.1/10.fc13/
right now you can find a Fedora kernel with the latest utrace up to the
minute. Coming soon to a rawhide near you (should be tomorrow).
This is a 2.6.32.1-based kernel with exactly the 2.6.32/* utrace patches as
you see them
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
Yes, I think this is correct. It is fine to miss -pending_attach == T,
and in any case the new attacher can come right after the check, even
if it was checked under utrace-lock.
Right.
It is important that the tracee can't miss, say, UTRACE_REPORT request
(as you already explained), and
Yes. I straced gdb to be sure it really does PTRACE_SET_DEBUGREF to
use the hardware watchpoint.
There is something strange though. gdb does PTRACE_SINGLESTEP and only
then PTRACE_CONT after watch xxx.
powerpc's data breakpoints are before-access, whereas x86's are
after-access. In
All that seems to do is call -release() and kmem_cache_free()s the
utrace_engine thing, why can't that be done with utrace-lock held?
Calling -release with a lock held is clearly insane, sorry. It is true
that any engine-writer who does anything like utrace_* calls inside their
release
I'm sorry for the delay. I'm picking up with responding to the parts of
your review that I did not include in my first reply. I appreciate very
much the discussion you've had with Oleg about the issues that I did not
address myself. I look forward to your replies to my comments in that
first
But... I tried to understand these check and failed. Why do we need them?
They look unneeded to me, but of course I know nothing about s390.
It's not specific to s390. Other arch's have equivalent logic. As
with all things ptrace, I strongly suspect that they just blindly
copied the logic
How about this?
--- step-into-handler.c 10 Dec 2008 04:42:43 -0800 1.8
+++ step-into-handler.c 05 Dec 2009 09:18:54 -0800
@@ -35,6 +35,7 @@
#include sys/time.h
#include string.h
#include stddef.h
+#include stdint.h
#if defined __x86_64__
#define REGISTER_IP regs.rip
@@ -113,11
I forgot that there is another issue (iirc a bit discussed too).
finish_callback_report() sets -ops = utrace_detached_ops lockless!
You'll have to remind me why this is a problem.
Re: [PATCH 85] ptrace_attach_task: rely on utrace_barrier(), don't
check -ops
We don't really intend to impose any new requirements on the arch behavior
here. It's up to the arch folks to decide. It does simplify life somewhat
on x86 that you can change the registers at the syscall-entry stop and then
after skipping the syscall, those registers will be unchanged from what
So. Any ptrace test which uses clone() is broken, at least on x86_64.
If you use clone() directly then you need to have the code run in that
child be purely under your control. You can't use miscellaneous libc
calls nor any libpthread calls, only ones you are sure do not require
any thread
Could we just drop the tracehook layer if this finally merged
and call the low level functions directly?
We can certainly do appropriate streamlining cleanups later, by all
means. The original purpose of the tracehook layer is simply this:
A person hacking on core kernel code or arch code
Note to all: I'm on the road this week (having had a holiday last week)
and will be somewhat slow in replying on these threads, but I will be
sure to get to them all.
Yes, nobody likes 2 implementations. I guess Roland and me hate
CONFIG_UTRACE much more than anybody else.
:-) We both hate
This above text seems inconsistent. First you say report_reap() is the
final callback and should be used for cleanup, then you say
report_death() is the penultimate callback but might not always happen
and people would normally use that as cleanup.
If we cannot rely on report_death() then I
In general everything where is a word thread has unstable results and
nonstop tests are also a bit unstable.
So where exactly is the problem in these cases? Are the tests overly
timing-sensitive where there is no actual behavior bug? Or is gdb overly
timing-sensitive where there is no actual
At this URL find built rpms (x86_64 and i686 only) that you can install on
a Fedora 12 (or rawhide, probably) system. These are the upstream kernel
du jour with the current utrace-ptrace branch code (see rpm changelog for
commit id). (I tried an f12-flavored build too, but it looks like the
On 11/18, Roland McGrath wrote:
In any case, what is the rationality?
The rationale is that if you see utrace_resume_action(action)==UTRACE_STOP
in your callback, then you know another engine asked for stop
Yes, but engine can't know if the next one is going to return
UTRACE_STOP
Is it possible to add si_code and si_addr info
info-si_code = TRAP_TRACE;
info-si_addr = instruction_pointer(regs);
This is exactly what arch-specific versions should do here.
The choice
The former is e.g. PTRACE_SINGLESTEP while an unrelated engine uses
UTRACE_EVENT(SYSCALL_ENTRY). The ptrace engine's report_quiesce returns
UTRACE_SINGLESTEP. finish_resume_report() calls user_enable_single_step().
That seems fine. Right?
In this case ptrace_report_quiesce(event)
I am not sure what is the best way to do these renames but I hope
this doesn't really matter, utrace-ptrace branch is only for us.
Sure, whatever you want to try is fine.
The goal is to make it testable with and without CONFIG_UTRACE.
Ok. We need to get upstream feedback on what they do or
Whatever we do, perhaps it makes sense to apply your patch
in https://www.redhat.com/archives/utrace-devel/2009-November/msg00109.html
first and then do further changes?
Ok. v2.6.32-rc8-245-g3d4f9cf has that. I'll shelve this 4-patch series
while we keep discussing (one more reply to come
Somehow I can't really understand this patch. I hope more or less
I can see what it does, but the resulting code looks even more
subtle to me.
Well, it was an untested draft and probably needed more comments.
With this patch, apply_resume_action() is always called after
utrace_stop(). Well,
Found the trivial but nasty problem.
Ah! Good catch.
I added tracehook_init_task() in my tree. I don't see much benefit in
sending any tracehook patch upstream for this. tracehook_init_task()
corresponds to tracehook_free_task(), which is only added by utrace
(and both would just be empty in
but now I think perhaps it would be better to send
ptrace-change-tracehook_report_syscall_exit-to-handle-stepping_fix
to akpm right now:
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -134,7 +134,7 @@ static inline __must_check int tracehook
Forgot to mention, your tree lacks these patches we sent upstream:
Right. I'll merge these into some requirements branch (or maybe just the
existing tracehook branch) and merge that into utrace.
Thanks,
Roland
Now, if we race with another task doing utrace_task_alloc() and see
-utrace != NULL, why should we see the correctly initialized *utrace?
utrace_task_alloc() needs wmb(), and the code like above
read_barrier_depends().
Ok. Please review what I put in (esp. commit c575558) and send patches
1 - 100 of 378 matches
Mail list logo
