From: Oleg Nesterov <oleg@redhat.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: caiqian@redhat.com, Heiko Carstens <heiko.carstens@de.ibm.com>,
Jan Kratochvil <jkratoch@redhat.com>,
Roland McGrath <roland@redhat.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
utrace-devel@redhat.com
Subject: Re: s390 && user_enable_single_step() (Was: odd utrace testing results on s390x)
Date: Mon, 4 Jan 2010 19:14:12 +0100 [thread overview]
Message-ID: <20100104181412.GA21146@redhat.com> (raw)
In-Reply-To: <20100104171626.22ea2d9c@mschwide.boeblingen.de.ibm.com>
On 01/04, Martin Schwidefsky wrote:
>
> On Mon, 4 Jan 2010 16:52:25 +0100
> Oleg Nesterov <oleg@redhat.com> wrote:
>
> > We have some strange problems with utrace on s390, and so far this _looks_
> > like a s390 problem.
> >
> > Looks like, on any CPU user_enable_single_step() does not "work" until at
> > least one thread with per_info.single_step = 1 does the context switch.
>
> The PER control registers only get reloaded on task switch. Can you test
> if this patch fixes your problem?
>
> --
> Subject: [PATCH] fix loading of PER control registers for utrace.
>
> From: Martin Schwidefsky <schwidefsky@de.ibm.com>
>
> If the current task enables / disables PER tracing for itself the
> PER control registers need to be loaded in FixPerRegisters.
>
> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
> ---
> arch/s390/kernel/ptrace.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> --- a/arch/s390/kernel/ptrace.c
> +++ b/arch/s390/kernel/ptrace.c
> @@ -98,6 +98,9 @@ FixPerRegisters(struct task_struct *task
> per_info->control_regs.bits.storage_alt_space_ctl = 1;
> else
> per_info->control_regs.bits.storage_alt_space_ctl = 0;
> +
> + if (task == current)
> + __ctl_load(per_info->control_regs.words, 9, 11);
> }
Yes it does fix the problem! Thanks a lot Martin.
However. Could you please look at 6580807da14c423f0d0a708108e6df6ebc8bc83d ?
I am worried, perhaps this commit is not enough for s390. OK, do_single_step()
tracehook_consider_fatal_signal(), this means the forked thread will not
be killed by SIGTRAP if it is not auto-attached, but still this may be
wrong.
IOW. I think this problem is minor and probably can be ignored, but if
I remove tracehook_consider_fatal_signal() check from do_single_step(),
--- a/arch/s390/kernel/traps.c
+++ b/arch/s390/kernel/traps.c
@@ -382,8 +382,7 @@ void __kprobes do_single_step(struct pt_
SIGTRAP) == NOTIFY_STOP){
return;
}
- if (tracehook_consider_fatal_signal(current, SIGTRAP))
- force_sig(SIGTRAP, current);
+ force_sig(SIGTRAP, current);
}
static void default_trap_handler(struct pt_regs * regs, long interruption_code)
-------------------------------------------------------------------
then the test-case from 6580807da14c423f0d0a708108e6df6ebc8bc83d
fails. This probably means that copy_process()->user_disable_single_step()
is not enough to clear the "this task wants single-stepping" copied
from parent.
Thanks!
Oleg.
next prev parent reply other threads:[~2010-01-04 18:14 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1503844142.2061111261478093776.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
[not found] ` <1257887498.2061171261478252049.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2010-01-04 15:52 ` s390 && user_enable_single_step() (Was: odd utrace testing results on s390x) Oleg Nesterov
2010-01-04 16:16 ` Martin Schwidefsky
2010-01-04 18:14 ` Oleg Nesterov [this message]
2010-01-04 19:30 ` Oleg Nesterov
2010-01-04 21:11 ` Roland McGrath
2010-01-05 9:50 ` Martin Schwidefsky
2010-01-05 15:36 ` Oleg Nesterov
2010-01-05 15:46 ` Martin Schwidefsky
2010-01-05 15:59 ` Oleg Nesterov
2010-01-05 17:03 ` Oleg Nesterov
2010-01-05 19:58 ` Oleg Nesterov
2010-01-06 14:59 ` Heiko Carstens
2010-01-06 20:17 ` Oleg Nesterov
2010-01-06 21:13 ` Roland McGrath
2010-01-07 9:18 ` Martin Schwidefsky
2010-01-07 17:54 ` Oleg Nesterov
2010-01-07 21:48 ` Roland McGrath
2010-01-21 20:51 ` Oleg Nesterov
2010-01-26 13:13 ` Martin Schwidefsky
2010-01-07 21:46 ` Roland McGrath
2010-01-08 8:30 ` Martin Schwidefsky
2010-01-08 10:25 ` Roland McGrath
2010-01-05 15:47 ` Oleg Nesterov
2010-01-05 15:50 ` Martin Schwidefsky
2010-01-06 21:08 ` Roland McGrath
2010-01-07 9:16 ` Martin Schwidefsky
2010-01-07 18:16 ` Oleg Nesterov
2010-01-07 21:44 ` Roland McGrath
2010-01-08 8:34 ` Martin Schwidefsky
2010-01-07 21:41 ` Roland McGrath
2010-01-07 18:11 ` Oleg Nesterov
2010-01-06 20:23 ` Oleg Nesterov
2010-01-06 20:56 ` Roland McGrath
2010-01-07 9:00 ` Martin Schwidefsky
2010-01-07 21:32 ` Roland McGrath
2010-01-21 20:32 ` Oleg Nesterov
2010-01-05 9:26 ` Martin Schwidefsky
2010-01-06 21:15 ` Roland McGrath
2010-01-04 20:46 ` Roland McGrath
[not found] <1158952983.251101262791902387.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2010-01-06 15:33 ` caiqian
2010-01-06 20:09 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100104181412.GA21146@redhat.com \
--to=oleg@redhat.com \
--cc=caiqian@redhat.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jkratoch@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=roland@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=utrace-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.