Vous avez reçu un Fax
Si ce message ne s'affiche pas correctement, visualisez la version en ligne http://campaigns.media-sender.net/HM?a=A9X7CkJQ0FqQsOZ4gORr9E_i6w FAXRÉCEPTION - RECEVEZ VOS FAX PAR E-MAIL (site : http://campaigns.media-sender.net/HS?a=A9X7CkJQ0FqQsOZ4gORrIszhJg ) Pourquoi ne pas recevoir vos fax par e-mail (6,50€ / mois) ? Démonstration de notre service : http://campaigns.media-sender.net/HS?a=A9X7CkJQ0FqQsOZ4gORrIs3hJw Test de la réception de fax par email : http://campaigns.media-sender.net/HS?a=A9X7CkJQ0FqQsOZ4gORrIsLhWA ÉCONOMIQUE Plus besoin de ligne téléphonique dédiée, ni de télécopieur. Fini les problèmes d'encre, de papier et de sonnerie. SIMPLICITÉ En quelques minutes, vous choisissez votre nouveau numéro de fax, et votre ligne est activée et opérationnelle instantanément. CONFIDENTIALITÉ Vous disposez d'un numéro de fax personnel ainsi que d'un accès sécurisé. MOBILITÉ Grâce à l'accès web, vous pouvez consulter vos fax même lorsque vous êtes en déplacement. COMPATIBLE PDA Dès souscription au service FaxReception, vous recevez aussi vos fax directement sur votre PDA. ÉCOLOGIQUE En utilisant FaxReception pour recevoir vos fax, vous réduisez votre consommation de papier. Pour envoyer vos fax Envoyez directement vos Fax à partir de votre PC : www.safefax.fr Ce courriel commercial est conforme à la législation en vigueur et aux délibérations de la CNIL des 22 et 30 mars 2005 sur la prospection par courrier électronique dans le cadre professionnel. Conformément à l'article 34 de la loi 78-17 du 6 janvier mille neuf cent soixante dix huit, relative à l'informatique, aux fichiers et aux libertés, vous disposez d'un droit d'accès, de rectification des données nominatives vous concernant. Si vous ne souhaitez plus recevoir de messages commerciaux de notre société par e-mail, Désactiver votre souscription : http://campaigns.media-sender.net/HP?a=A9X7CkJQ0FqQsOZ4gORrZZbhIQ . Le présent message est en parfait respect avec la déontologie et les bonnes pratiques de la communication par marketing direct électronique. Conformément à la législation en vigueur et des différents rectificatifs légaux, vous disposez d'un plein droit d'accès, de modifications ou de suppression des données personnelles vous concernant. Vous pouvez à tout moment exercer ce droit via le formulaire prévu à cet effet. Conformément à la loi Informatique et libertés, vous pouvez désactiver votre souscription à tout moment. Loi n° 78-17 du 6 Janvier mille neuf cent soixante dix huit, relative à l'informatique, aux fichiers et aux libertés : Toute personne physique a le droit de s'opposer, pour des motifs légitimes, à ce que des données à caractère personnel la concernant fassent l'objet d'un traitement. Elle a le droit de s'opposer, sans frais, à ce que les données la concernant soient utilisées à des fins de prospection, notamment commerciale, par le responsable actuel du traitement ou celui d'un traitement ultérieur. Les dispositions du premier alinéa ne s'appliquent pas lorsque le traitement répond à une nécessité légale ou lorsque l'application de ces dispositions a été écartée par une disposition expresse de l'acte autorisant le traitement de la publicité par voie électronique. Art 38 : Toute personne physique a le droit de s'opposer, pour des motifs légitimes, à ce que des données à caractère personnel la concernant fassent l'objet d'un traitement. Elle a le droit de s'opposer, sans frais, à ce que les données la concernant soient utilisées à des fins de prospection, notamment commerciale, par le responsable actuel du traitement ou celui d'un traitement ultérieur. Les dispositions du premier alinéa ne s'appliquent pas lorsque le traitement répond à une obligation légale ou lorsque l'application de ces dispositions a été écartée par une disposition expresse de l'acte autorisant le traitement. Si vous ne souhaitez plus recevoir de propositions commerciales de notre part, il vous suffit de remplir cette demande : http://campaigns.media-sender.net/HP?a=A9X7CkJQ0FqQsOZ4gORrZZfhIg .
Re: Stopped detach/attach status
On Mon, 05 Oct 2009 04:32:08 +0200, Oleg Nesterov wrote: On 10/01, Jan Kratochvil wrote: the ptrace-testsuite http://sourceware.org/systemtap/wiki/utrace/tests currently FAILs (also) on Fedora 12 kernel-2.6.31.1-48.fc12.x86_64 for: FAIL: detach-stopped FAIL: stopped-attach-transparency [...] As for user-space, I don't really understand the second test-case, this again means I don't understand the supposed behaviour. The high level goal is described at its top. Users expect that if they run `gstack PID' or `gcore PID' the target PID will be absolutely in the same state as before gstack/gcore. That means it will keep both whether it was / was not stopped and also any possible existing / non-existing pending signal for a possible future waitpid() from its real (non-ptrace) parent PID. Another question whether technically what it does is right but this high level goal is hopefully valid. Except, stopped-attach-transparency prints Excessive waiting SIGSTOP after the second attach/detach afaics the test-case is not right here. attach_detach() leaves the traced threads in STOPPED state, why pid_notifying_sigstop() should fail? [ Not replying this part, have not built a kernel with this patch now. ] In this case, I don't understand why stopped-attach-transparency sends SIGSTOP to every sub-thread. If the tracer wants to stop the thread group after detach, it can do ptrace(PTRACE_DETACH, anythread, SIGSTOP); for_each_other_thread(pid) ptrace(PTRACE_DETACH, anythread, 0); or just kill(SIGSTOP); for_each_thread(pid) ptrace(PTRACE_DETACH, anythread, 0); OK, it this is the recommended way I can fix the testcase this way. The all-threads-being-sent-SIGSTOP way IIRC worked on linux-2.6.9 but I do not think this part of the compatibility must be kept. Thanks, Jan
[PATCH 66] introduce syscall_code(context) helper
Trivial, move the annoying PTRACE_O_TRACESYSGOOD check into the new helper,
syscall_code().
---
kernel/ptrace.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
--- PU/kernel/ptrace.c~66_SYSGOOD_HELPER2009-10-06 00:50:01.0
+0200
+++ PU/kernel/ptrace.c 2009-10-06 01:11:40.0 +0200
@@ -207,6 +207,12 @@ static u32 ptrace_report_clone(enum utra
return ret;
}
+static inline int syscall_code(struct ptrace_context *context)
+{
+ return (context-options PTRACE_O_TRACESYSGOOD) ?
+ (SIGTRAP | 0x80) : SIGTRAP;
+}
+
static u32 ptrace_report_syscall_entry(u32 action,
struct utrace_engine *engine,
struct task_struct *task,
@@ -217,8 +223,8 @@ static u32 ptrace_report_syscall_entry(u
WARN_ON(ev_pending(context));
context-ev_name = PTRACE_EVENT_SYSCALL_ENTRY;
- context-ev_code = (context-options PTRACE_O_TRACESYSGOOD) ?
- (SIGTRAP | 0x80) : SIGTRAP;
+ context-ev_code = syscall_code(context);
+
return UTRACE_SYSCALL_RUN | UTRACE_STOP;
}
@@ -233,8 +239,8 @@ static u32 ptrace_report_syscall_exit(en
return UTRACE_STOP;
context-ev_name = PTRACE_EVENT_SYSCALL_EXIT;
- context-ev_code = (context-options PTRACE_O_TRACESYSGOOD) ?
- (SIGTRAP | 0x80) : SIGTRAP;
+ context-ev_code = syscall_code(context);
+
return UTRACE_STOP;
}
@@ -931,8 +937,8 @@ static void do_ptrace_resume(struct utra
case PTRACE_EVENT_CLONE:
case PTRACE_EVENT_VFORK_DONE:
context-ev_name = PTRACE_EVENT_SYSCALL_EXIT;
- context-ev_code = (context-options
PTRACE_O_TRACESYSGOOD) ?
- (SIGTRAP | 0x80) : SIGTRAP;
+ context-ev_code = syscall_code(context);
+
do_ptrace_notify_stop(context, tracee);
return;
}
[PATCH 67] introduce get_stop_code(context) helper
Trivial, to simplify the review of the next patches.
-ev_name is used as rvalue in ptrace_resume(), add the trivial helper
to read this member.
---
kernel/ptrace.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
--- PU/kernel/ptrace.c~67_GET_STOP_CODE_HELPER 2009-10-06 01:11:40.0
+0200
+++ PU/kernel/ptrace.c 2009-10-06 01:23:21.0 +0200
@@ -47,6 +47,11 @@ static inline bool ev_pending(struct ptr
return context-ev_name != 0;
}
+static inline int get_stop_code(struct ptrace_context *context)
+{
+ return context-ev_name;
+}
+
static inline struct ptrace_context *
ptrace_context(struct utrace_engine *engine)
{
@@ -916,7 +921,7 @@ static void do_ptrace_resume(struct utra
{
struct ptrace_context *context = ptrace_context(engine);
- switch (context-ev_name) {
+ switch (get_stop_code(context)) {
case 0:
// XXX: JCTL stop
break;
@@ -931,7 +936,7 @@ static void do_ptrace_resume(struct utra
}
if (request == PTRACE_SYSCALL) {
- switch (context-ev_name) {
+ switch (get_stop_code(context)) {
case PTRACE_EVENT_EXEC:
case PTRACE_EVENT_FORK:
case PTRACE_EVENT_CLONE:
@@ -945,7 +950,7 @@ static void do_ptrace_resume(struct utra
}
if (action != UTRACE_RESUME) {
- switch (context-ev_name) {
+ switch (get_stop_code(context)) {
case PTRACE_EVENT_EXEC:
case PTRACE_EVENT_FORK:
case PTRACE_EVENT_CLONE:
[PATCH 69] kill context-ev_name
Kill context-ev_name, it is always eq to (ev_code 8) since the
previous patch.
I think it makes sense to add another helper for (event 8) | signr,
but I failed to invent the name.
We can also kill context-signr, we can use (ev_code 0xFF) byte instead.
---
kernel/ptrace.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
--- PU/kernel/ptrace.c~69_KILL_EV_NAME 2009-10-06 02:00:51.0 +0200
+++ PU/kernel/ptrace.c 2009-10-06 02:04:07.0 +0200
@@ -30,7 +30,6 @@ struct ptrace_context {
int signr;
siginfo_t *siginfo;
- int ev_name;
int ev_code;
unsigned long ev_mesg;
@@ -46,12 +45,12 @@ struct ptrace_context {
static inline bool ev_pending(struct ptrace_context *context)
{
- return context-ev_name != 0;
+ return context-ev_code != 0;
}
static inline int get_stop_code(struct ptrace_context *context)
{
- return context-ev_name;
+ return context-ev_code 8;
}
static inline struct ptrace_context *
@@ -124,7 +123,6 @@ static u32 ptrace_report_exit(enum utrac
WARN_ON(ev_pending(context));
- context-ev_name = PTRACE_EVENT_EXIT;
context-ev_code = (PTRACE_EVENT_EXIT 8) | SIGTRAP;
context-ev_mesg = *code;
@@ -197,14 +195,12 @@ static u32 ptrace_report_clone(enum utra
// XXX: child-pid is wrong! use tracer's pid_ns
if (event) {
- context-ev_name = event;
context-ev_code = (event 8) | SIGTRAP;
context-ev_mesg = child-pid;
ret = UTRACE_STOP;
} else if ((clone_flags CLONE_VFORK)
(context-options PTRACE_O_TRACEVFORKDONE)) {
- context-ev_name = PTRACE_EVENT_VFORK_DONE;
context-ev_code = (PTRACE_EVENT_VFORK_DONE 8) | SIGTRAP;
context-ev_mesg = child-pid;
@@ -229,7 +225,6 @@ static u32 ptrace_report_syscall_entry(u
WARN_ON(ev_pending(context));
- context-ev_name = PTRACE_EVENT_SYSCALL_ENTRY;
context-ev_code = (PTRACE_EVENT_SYSCALL_ENTRY 8) |
syscall_code(context);
@@ -246,7 +241,6 @@ static u32 ptrace_report_syscall_exit(en
if (ev_pending(context))
return UTRACE_STOP;
- context-ev_name = PTRACE_EVENT_SYSCALL_EXIT;
context-ev_code = (PTRACE_EVENT_SYSCALL_EXIT 8) |
syscall_code(context);
@@ -272,7 +266,6 @@ static u32 ptrace_report_exec(enum utrac
return UTRACE_RESUME;
}
- context-ev_name = PTRACE_EVENT_EXEC;
context-ev_code = (PTRACE_EVENT_EXEC 8) | SIGTRAP;
return UTRACE_STOP;
@@ -334,7 +327,6 @@ static u32 ptrace_report_signal(u32 acti
context-siginfo = NULL;
if (resume != UTRACE_RESUME) {
- context-ev_name = PTRACE_EVENT_SIGTRAP;
context-ev_code = (PTRACE_EVENT_SIGTRAP 8) |
SIGTRAP;
return UTRACE_STOP | UTRACE_SIGNAL_IGN;
@@ -360,7 +352,6 @@ static u32 ptrace_report_signal(u32 acti
*/
utrace_control(task, engine, UTRACE_INTERRUPT);
- context-ev_name = PTRACE_EVENT_SIGNAL;
context-ev_code = (PTRACE_EVENT_SIGNAL 8) | info-si_signo;
context-signr = info-si_signo;
@@ -945,7 +936,6 @@ static void do_ptrace_resume(struct utra
case PTRACE_EVENT_FORK:
case PTRACE_EVENT_CLONE:
case PTRACE_EVENT_VFORK_DONE:
- context-ev_name = PTRACE_EVENT_SYSCALL_EXIT;
context-ev_code = (PTRACE_EVENT_SYSCALL_EXIT 8) |
syscall_code(context);
do_ptrace_notify_stop(context, tracee);
@@ -969,7 +959,7 @@ static void do_ptrace_resume(struct utra
}
}
- context-ev_name = 0;
+ context-ev_code = 0;
context-resume = action;
ptrace_wake_up(engine, tracee, action);
}
Re: utrace-ptrace detach with signal semantics
On 10/05, Oleg Nesterov wrote: On 10/05, Jan Kratochvil wrote: On Mon, 05 Oct 2009 04:51:32 +0200, Oleg Nesterov wrote: It is not trivial to implement, and I don't understand why it is important to keep this behaviour. But we have the test case which checks this: attach-into-signal. This testcase is in fact PASSing even when non-SIGSTOP signal is sent as the first one after PTRACE_ATTACH. It has specific handling of such cases. This test-case also does: /* detach with SIGPIPE/attach. This should kill tracee */ ptrace (PTRACE_DETACH, child, (void *) 1, (void *) SIGPIPE); ptrace (PTRACE_ATTACH, child, (void *) 0, (void *) 0); waitpid (child, status, 0); assert (WIFSIGNALED (status) WTERMSIG (status) == SIGPIPE); It fails if the second PTRACE_ATTACH sees SIGPIPE. This is what I can't understand. Just in case... If I change the test-case --- a/ptrace-tests/tests/attach-into-signal.c 2009-01-31 13:11:40.0 -0800 +++ b/ptrace-tests/tests/attach-into-signal.c 2009-09-20 13:32:30.0 -0700 @@ -225,9 +225,9 @@ static void reproduce (void) return; } assert (WIFSTOPPED (status)); - assert (WSTOPSIG (status) == SIGSTOP); + assert (WSTOPSIG (status) == SIGPIPE); /* let tracee run. it must be killed very soon by SIGPIPE */ - ptrace (PTRACE_CONT, child, (void *) 1, (void *) 0); + ptrace (PTRACE_CONT, child, (void *) 1, (void *) SIGPIPE); assert_perror (errno); pid = waitpid (child, status, 0); assert (pid == child); then it doesn't fail. OK. Currently, ptrace(DETACH, SIGXXX) means: - untrace - the tracee will get this SIGXXX and handle this signal - BUT! if the new tracer attaches right now, before the tracee handles the signal, this signal will not be reported to the new tracer. With the current utrace-ptrace implementation: if the second attach happens before the tracee dequeues SIGXXX, this signal will be reported to the new tracer too. So... Jan, do you think this behaviour change can break gdb? Oleg.
