From: Frederic Weisbecker <fweisbec@gmail.com>
To: Dave Jones <davej@redhat.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: [PATCH] rcu: Fix unrecovered RCU user mode in syscall_trace_leave()
Date: Fri, 26 Oct 2012 11:40:28 +0200 [thread overview]
Message-ID: <1351244428-2277-1-git-send-email-fweisbec@gmail.com> (raw)
In-Reply-To: <20121025074147.GA2240@swordfish>
On x86-64 syscall exit, 3 non exclusive events may happen
looping in the following order:
1) Check if we need resched for user preemption, if so call
schedule_user()
2) Check if we have pending signals, if so call do_notify_resume()
3) Check if we do syscall tracing, if so call syscall_trace_leave()
However syscall_trace_leave() has been written assuming it directly
follows the syscall and forget about the above possible 1st and 2nd
steps.
Now schedule_user() and do_notify_resume() exit in RCU user mode
because they have most chances to resume userspace immediately and
this avoids an rcu_user_enter() call in the syscall fast path.
So by the time we call syscall_trace_leave(), we may well be in RCU
user mode. To fix this up, simply call rcu_user_exit() in the beginning
of this function.
This fixes some reported RCU uses in extended quiescent state.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
---
arch/x86/kernel/ptrace.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index b00b33a..eff5b8c 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1511,6 +1511,13 @@ void syscall_trace_leave(struct pt_regs *regs)
{
bool step;
+ /*
+ * We may come here right after calling schedule_user()
+ * or do_notify_resume(), in which case we can be in RCU
+ * user mode.
+ */
+ rcu_user_exit();
+
audit_syscall_exit(regs);
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
--
1.7.5.4
next prev parent reply other threads:[~2012-10-26 9:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-17 3:49 lots of suspicious RCU traces Dave Jones
2012-10-24 16:42 ` Sergey Senozhatsky
2012-10-24 18:06 ` Oleg Nesterov
2012-10-24 18:21 ` Sergey Senozhatsky
2012-10-24 18:52 ` Oleg Nesterov
2012-10-24 19:17 ` Sergey Senozhatsky
2012-10-24 19:41 ` Paul E. McKenney
2012-10-24 19:50 ` Sergey Senozhatsky
2012-10-24 20:11 ` Paul E. McKenney
2012-10-24 20:15 ` Sergey Senozhatsky
2012-10-24 22:32 ` Frederic Weisbecker
2012-10-25 5:50 ` Sergey Senozhatsky
2012-10-25 7:06 ` Frederic Weisbecker
2012-10-25 7:41 ` Sergey Senozhatsky
2012-10-26 9:40 ` Frederic Weisbecker [this message]
2012-10-26 9:44 ` Frederic Weisbecker
2012-10-26 11:16 ` Sergey Senozhatsky
2012-10-26 15:16 ` Dave Jones
2012-10-25 5:55 ` Sergey Senozhatsky
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=1351244428-2277-1-git-send-email-fweisbec@gmail.com \
--to=fweisbec@gmail.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=sergey.senozhatsky@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).