From: Oleg Nesterov <oleg@redhat.com>
To: caiqian@redhat.com, Heiko Carstens <heiko.carstens@de.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: 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: s390 && user_enable_single_step() (Was: odd utrace testing results on s390x)
Date: Mon, 4 Jan 2010 16:52:25 +0100 [thread overview]
Message-ID: <20100104155225.GA16650@redhat.com> (raw)
In-Reply-To: <1257887498.2061171261478252049.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
Hi!
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.
This doesn't matter with the old ptrace implementation, but with utrace
the tracee itself does user_enable_single_step(current) and returns to
user-mode. Until it does at least one context switch the single-stepping
doesn't work, after that everything works fine till the next reboot.
To rule out the possible problems with ptrace or utrace, I did the trivial
patch:
--- K/kernel/sys.c~ 2009-12-29 10:45:25.787198223 -0500
+++ K/kernel/sys.c 2010-01-03 13:04:00.485591316 -0500
@@ -1444,6 +1444,17 @@ SYSCALL_DEFINE5(prctl, int, option, unsi
error = 0;
switch (option) {
+ case 666:
+ user_enable_single_step(current);
+ break;
+
+ case 777:
+ /* same as 666, but force the context switch
+ * after user_enable_single_step() */
+ user_enable_single_step(current);
+ schedule_timeout_interruptible(HZ/10);
+ break;
+
case PR_SET_PDEATHSIG:
if (!valid_signal(arg2)) {
error = -EINVAL;
--- K/arch/s390/kernel/traps.c~ 2009-12-22 10:41:52.909174198 -0500
+++ K/arch/s390/kernel/traps.c 2009-12-30 10:31:12.985266686 -0500
@@ -378,11 +378,14 @@ static inline void __user *get_check_add
void __kprobes do_single_step(struct pt_regs *regs)
{
+ printk("SS enter\n");
+
if (notify_die(DIE_SSTEP, "sstep", regs, 0, 0,
SIGTRAP) == NOTIFY_STOP){
+ printk(KERN_INFO "SS cancelled ???\n");
return;
}
- if (tracehook_consider_fatal_signal(current, SIGTRAP))
+// if (tracehook_consider_fatal_signal(current, SIGTRAP))
force_sig(SIGTRAP, current);
}
-------------------------------------------------------------------------------
The change in do_single_step() just removes "is it traced" check
and adds a couple of printk's.
With this patch I assume that the task which does prctl(666) should
be killed by SIGTRAP, but this doesn't happen:
# taskset -c 0 perl -le 'syscall 172,666 and die $!'
# taskset -c 0 perl -le 'syscall 172,666 and die $!'
# taskset -c 0 perl -le 'syscall 172,666 and die $!'
(syscall 172,666 == prctl(666))
the task exits normally, there is nothing in dmesg.
However,
# taskset -c 0 perl -le 'syscall 172,777 and die $!'
Trace/breakpoint trap
Now prctl(777)->user_enable_single_step() does work, the task is
killed by do_single_step()->force_sig(SIGTRAP).
Now prctl(666) works too on CPU 0
# taskset -c 0 perl -le 'syscall 172,666 and die $!'
Trace/breakpoint trap
# taskset -c 0 perl -le 'syscall 172,666 and die $!'
Trace/breakpoint trap
# taskset -c 0 perl -le 'syscall 172,666 and die $!'
Trace/breakpoint trap
And please note "# taskset -c 0", we can repeat the same on another
CPU:
# taskset -c 1 perl -le 'syscall 172,666 and die $!'
# taskset -c 1 perl -le 'syscall 172,666 and die $!'
doesn't work, but
# taskset -c 1 perl -le 'syscall 172,777 and die $!'
Trace/breakpoint trap
magically "fixes" user_enable_single_step(), now we can use prctl(666)
on CPU 1.
The kernel is 2.6.32.2 plus ca633fd006486ed2c2d3b542283067aab61e6dc8,
could you help?
Oleg.
next parent reply other threads:[~2010-01-04 15:52 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 ` Oleg Nesterov [this message]
2010-01-04 16:16 ` s390 && user_enable_single_step() (Was: odd utrace testing results on s390x) Martin Schwidefsky
2010-01-04 18:14 ` Oleg Nesterov
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=20100104155225.GA16650@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.