Vous avez reçu un Fax
Title: Fax Reception Si ce message ne s'affiche pas correctement, cliquez ici conomique Plus besoin de ligne tlphonique ddie, ni de tlcopieur. Fini les problmes d'encre, de papier et de sonnerie. Simplicit En quelques minutes, vous choisissez votre nouveau numro de fax, et votre ligne est active et oprationnelle instantanment. Confidentialit Vous disposez d'un numro de fax personnel ainsi que d'un accs scuris. Mobilit Grce l'accs web, vous pouvez consulter vos fax mme lorsque vous tes en dplacement. Compatible PDA Ds souscription au service FaxReception, vous recevez aussi vos fax directement sur votre PDA. cologique En utilisant FaxReception pour recevoir vos fax, vous rduisez votre consommation de papier. Pour envoyer vos fax Envoyez directement vos Fax partir de votre PC : www.safefax.fr 2009 ALLIANCE MCA Cliquez ici pour ne plus recevoir notre newsletter. A rception, celui-ci sera pris en compte conformment la loi n 78-17 du 06-01-1978 relative linformatique, aux fichiers et aux liberts modifie par la loi n2004-801 du 06-08-2004
Re: utrace_report_syscall_entry() finish_report()
On 11/11, Roland McGrath wrote: I saw you have utrace-syscall-resumed branch but never looked at it. For those not concerned with its purpose, there is one thing you must know. Every report_syscall_entry callback must do: if (utrace_syscall_action(action) == UTRACE_SYSCALL_RESUMED) return UTRACE_RESUME; to avoid being confused by the new extra callbacks. OK, thanks. Then I fix utrace-ptrace. I _think_ this will be easy too. ptrace_report_syscall_exit() can notice ctx-resume == UTRACE_SINGLESTEP and send the trap if utrace_control() doesn't set TIF_SINGLESTEP synchronously. (And this means with utrace tracehook_report_syscall_exit() can do nothing except utrace_report_syscall_exit()). Today we don't call into utrace unless UTRACE_EVENT(SYSCALL_EXIT) is set. So if nothing changes in the utrace layer, this means that ptrace will enable UTRACE_EVENT(SYSCALL_EXIT) (i.e. TIF_SYSCALL) for PTRACE_SINGLE*. Is that what you had in mind? Yes, exactly. There are two possible issues with doing it that way. The first is purely from a ptrace perspective. Today PTRACE_SINGLE* does not set TIF_SYSCALL. On x86 this doesn't really make a difference in the underlying code, because TIF_SINGLESTEP takes the same path. So probably this is fine. But on other machines I'm not entirely sure that TIF_SYSCALL won't take a slower path than single-step alone caused already for syscall entries. This surely pales in comparison to the overhead of the ptrace stop and context switch and all, but still, it could be a change. On x86 I'm not sure there's any reason not to optimize that better in the future, I see. The other issue comes from the utrace API perspective. Here it just seems entirely wrong to require the engine (ptrace or any other) to do any syscall-exit magic of its own to make UTRACE_SINGLESTEP work on a syscall insn like it does on other insns. The utrace layer should make that trap appear transparently like the normal traps seen for UTRACE_SINGLESTEP. So, we could have tracehook_report_syscall_exit send the signal as it does now upstream. But probably better is to do it all in the utrace layer, Indeed! i.e. pass the step flag to utrace_report_syscall_exit. The problem is, we can't use step flag. step == TIF_SINGLESTEP, and it can be unset despite the fact ptrace (or other engine) did utrace_control(UTRACE_SINGLESTEP) to resume. Simple example. The tracee stopped in syscall-entry. the tracer does PTRACE_SINGLESTEP. With the recent changes in utrace-cleanup utrace_control() doesn't set TIF_SINGLESTEP, and the tracee passes syscall_trace_leave() without TIF_SINGLESTEP. But I guess utrace_report_syscall_exit() can look at utrace-resume and notice UTRACE_SINGLESTEP ? That approximates the check that yesterday's x86 code does: if (test_thread_flag(TIF_SINGLESTEP) tracehook_consider_fatal_signal(current, SIGTRAP)) send_sigtrap(current, regs, 0, TRAP_BRKPT); But still we are queuing a real signal here. That is no different from the real hardware trap case, so perhaps that is the right thing to do for now. (Eventually we want to have a way for all these traps to avoid becoming real signals at all, but that is a subject for another day.) Like a real signal, that has the problem of still being queued if the tracer detaches immediately thereafter (so it gets delivered to the user). We could avoid that for this fake signal by just setting some flag that tells utrace_get_signal to synthesize it before dequeuing real signals. It's probably not worth bothering with that complexity now. Yes, I think we have more important problems ;) Oleg.
Re: [PATCH 0/1] Was: utrace-cleanup branch
I did some tweaks that I think address the several things you've raised. But I didn't try to reply point by point. I've merged everything up now, so the utrace-cleanup branch is gone. Please review the current code and post about anything we still need to fix. I merged into utrace-ptrace and did the trivial hack to handle UTRACE_SYSCALL_RESUMED. Later we probably want to change this to some smarter handling so that ptrace doesn't report until other engines have finished their fiddling and let the thread resume. That way we can have e.g. strace vs kmview show something consistent. But we can refine this later. I think what I did is sufficient to maintain the status quo in your code. You can fix it up as needed. Thanks, Roland
Re: [PATCH 127] move ptrace_resume()-send_sigtrap() logic into ptrace_report_signal()
On 11/02, Roland McGrath wrote: - unlike send_sigtrap()-force_sig_info() we don't unblock SIGTRAP or reset the handler This is nicer for debugger things actually, but we don't have such niceness for real traps and won't soon. IMHO it is best to start with doing exactly what the old x86 code does, which is force_sig_info--which is also making all machines uniformly do what a real single-step trap does and is thus consistent in this PTRACE_SINGLESTEP case matching all others, which we have been saying is a sensible principle. these changes looks good (but see the next patch). However, any user-visible change is dangerous. Let's not roll it in. As well as it just being bad form to roll that into implementation detail changes, it makes things less consistent rather than more (on x86, anyway, and arguably across the board). OK. So, we should revert this change and send the trap from ptrace_resume(), - instead of send_sigtrap() we should use user_single_step_siginfo() + force_sig_info() - PTRACE_EVENT_SYSCALL_EXIT shouldn't send the trap, this was x86 specific behaviour, and this is fixed in upstream by [PATCH v2 5/5] ptrace: x86: change syscall_trace_leave() to rely on tracehook when stepping we recently sent. (btw, I wrongly thought x86 is right and other machines should be fixed). Correct? If yes: - force_sig_info() needs tasklist_lock. we can change force_sig_info() to use lock_task_sighand(), but perhaps we should not worry about this now - what should we do with PTRACE_EVENT_SIGTRAP ? So, get rid of PTRACE_EVENT_SIGTRAP. Instead for the case of UTRACE_SIGNAL_HANDLER when stepping, initialize *info to look like a vanilla SIGTRAP and then fall into the default case for real signals. should UTRACE_SIGNAL_HANDLER use force_sig_info() too or it can just deliver this *info as you initially suggested ? Or we can forget about this change for now? I agree in advance with everything you prefer, you definetely know better. Anything else I missed? Oleg.
Re: [PATCH 122] ptrace_request(PTRACE_KILL) should not(?) return -ESRCH
Just noticed I didn't reply to this message, On 10/30, Roland McGrath wrote: If the tracee was STOPPED/TRACED, then it is equivalent to PTRACE_CONT,SIGKILL. Otherwise it has no effect except it can race with exit() and spoil -exit_code, and wake_up_process() is not good if course. (I am talking about upstream). Correct. In job control stop (including one already turned into TASK_TRACED by a prior ptrace call), the resumption signal is ignored. So the only reliable effect at all is when it's in a proper ptrace stop that doesn't otherwise swallow signals (i.e. exactly PTRACE_CONT,SIGKILL that ignores liveness/stoppedness errors). In every other case it has no effect at best, so fixing that to no effect at all is just fine. Please tell me what do you think, then I'll do other changes you suggested. In the old code, PTRACE_KILL can never fail once the initial attachedness test has passed. So: (void) ptrace_resume(child, engine, request, SIGKILL); ret = 0; /* Historical compatibility. */ is probably fine. Yes, but utrace-ptrace does a lot more in ptrace_resume() compared to upstream. If the tracee is not stopped, then ptrace_resume() can race with the tracee in many ways. This is mostly harmless, I think, but still I did if (task_is_traced(child)) ptrace_resume(PTRACE_CONT, SIGKILL); ret = 0; Oleg.
Re: utrace_report_syscall_entry() finish_report()
Simple example. The tracee stopped in syscall-entry. the tracer does PTRACE_SINGLESTEP. With the recent changes in utrace-cleanup utrace_control() doesn't set TIF_SINGLESTEP, and the tracee passes syscall_trace_leave() without TIF_SINGLESTEP. Ah, yes. Well, the point of the arch/tracehook tweaks was that the utrace layer has all the information and can decide what to do. But I guess utrace_report_syscall_exit() can look at utrace-resume and notice UTRACE_SINGLESTEP ? Yes. Unlike ptrace, at the utrace layer we can have both syscall-exit and single-step going on at the same time (even by unrelated engines). If some engine doesn't care about syscall-exit, it will still get report_quiesce there and should reassert UTRACE_SINGLESTEP with its return value. But that makes it a bit unclear whether a UTRACE_SINGLESTEP return from report_syscall_exit wants a fresh step after the next insn, or wants a synthetic trap immediately after the syscall insn. So I wonder if what might be right is to have utrace_report_syscall_exit look at -resume before its reporting. If it's single/block-step it can synthesize the trap there, so the signal is queued before the syscall-exit report is made. Thanks, Roland
Re: [PATCH 0/1] Was: utrace-cleanup branch
On 11/12, Roland McGrath wrote: I did some tweaks that I think address the several things you've raised. But I didn't try to reply point by point. I've merged everything up now, so the utrace-cleanup branch is gone. Please review the current code and post about anything we still need to fix. Great, thanks. I will definitely read the changes in utrace.c, if nothing else this is interesting to me. But for now, until utrace-ptrace is updated/finished, I will assume it is correct and doesn't need any further changes. Oleg.
Re: [PATCH 127] move ptrace_resume()-send_sigtrap() logic into ptrace_report_signal()
So, we should revert this change and send the trap from ptrace_resume(), What's wrong with ptrace_report_signal doing it? - instead of send_sigtrap() we should use user_single_step_siginfo() + force_sig_info() Right. - PTRACE_EVENT_SYSCALL_EXIT shouldn't send the trap, this was x86 specific behaviour, and this is fixed in upstream by Right. (btw, I wrongly thought x86 is right and other machines should be fixed). In these corner cases it is always debatable what right is. I didn't really think and decide about it until recently when we decided about the upstream change. - force_sig_info() needs tasklist_lock. we can change force_sig_info() to use lock_task_sighand(), but perhaps we should not worry about this now It would be much better if we can leave the signals code alone. (It can always use more cleanups, but let those happen later on their own.) I think ideally we should try to invoke it the way it's invoked now, i.e. force_sig_info() is called on current. - what should we do with PTRACE_EVENT_SIGTRAP ? So, get rid of PTRACE_EVENT_SIGTRAP. Instead for the case of UTRACE_SIGNAL_HANDLER when stepping, initialize *info to look like a vanilla SIGTRAP and then fall into the default case for real signals. should UTRACE_SIGNAL_HANDLER use force_sig_info() too or it can just deliver this *info as you initially suggested ? Or we can forget about this change for now? We need to make it consistent with the upstream ptrace behavior, so we can't forget about anything that's needed for that. Today tracehook_signal_handler() uses ptrace_notify(). So that is more like an implicit fake signal report than a real queued SIGTRAP. (Still we won't ignore the resume signal any more, but that is a desireable change.) Conversely, we could make an upstream change along the lines of the tracehook_report_syscall_exit() change, so that this uses a real SIGTRAP instead of ptrace_notify(). That has some logic to it. But today this case is consistent across machines, so we could consider that behavior change separately after utrace merges. I agree in advance with everything you prefer, you definetely know better. :-) Perhaps I do when I have it all in mind at the same moment. But my brain capacity is feeling a bit low this week. Anything else I missed? I hope not! This area is not really fresh in my mind right now. Thanks, Roland
