From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Thomas Gleixner <tglx@linutronix.de>, Neel Natu <neelnatu@google.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
paulmck <paulmck@linux.ibm.com>,
Boqun Feng <boqun.feng@gmail.com>,
"H. Peter Anvin" <hpa@zytor.com>, Paul Turner <pjt@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
linux-api <linux-api@vger.kernel.org>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH for 5.3 2/3] rseq: Fix: Unregister rseq for CLONE_SETTLS
Date: Sat, 14 Sep 2019 10:21:29 -0400 (EDT) [thread overview]
Message-ID: <819646407.3304.1568470889470.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20190913151220.3105-2-mathieu.desnoyers@efficios.com>
There is an ongoing discussion on the choice of flag we want to care
about here. Therefore, please don't pull this patch until we reach an
agreement.
Thanks,
Mathieu
----- On Sep 13, 2019, at 11:12 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
> It has been reported by Google that rseq is not behaving properly
> with respect to clone when CLONE_VM is used without CLONE_THREAD.
> It keeps the prior thread's rseq TLS registered when the TLS of the
> thread has moved, so the kernel deals with the wrong TLS.
>
> The approach of clearing the per task-struct rseq registration
> on clone with CLONE_THREAD flag is incomplete. It does not cover
> the use-case of clone with CLONE_VM set, but without CLONE_THREAD.
>
> Looking more closely at each of the clone flags:
>
> - CLONE_THREAD,
> - CLONE_VM,
> - CLONE_SETTLS.
>
> It appears that the flag we really want to track is CLONE_SETTLS, which
> moves the location of the TLS for the child, making the rseq
> registration point to the wrong TLS.
>
> Suggested-by: "H . Peter Anvin" <hpa@zytor.com>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: "H . Peter Anvin" <hpa@zytor.com>
> Cc: Paul Turner <pjt@google.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: linux-api@vger.kernel.org
> Cc: <stable@vger.kernel.org>
> ---
> include/linux/sched.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 9f51932bd543..76bf55b5cccf 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1919,11 +1919,11 @@ static inline void rseq_migrate(struct task_struct *t)
>
> /*
> * If parent process has a registered restartable sequences area, the
> - * child inherits. Only applies when forking a process, not a thread.
> + * child inherits. Unregister rseq for a clone with CLONE_SETTLS set.
> */
> static inline void rseq_fork(struct task_struct *t, unsigned long clone_flags)
> {
> - if (clone_flags & CLONE_THREAD) {
> + if (clone_flags & CLONE_SETTLS) {
> t->rseq = NULL;
> t->rseq_sig = 0;
> t->rseq_event_mask = 0;
> --
> 2.17.1
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2019-09-14 14:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-13 15:12 [PATCH for 5.3 1/3] rseq: Fix: Reject unknown flags on rseq unregister Mathieu Desnoyers
2019-09-13 15:12 ` [PATCH for 5.3 2/3] rseq: Fix: Unregister rseq for CLONE_SETTLS Mathieu Desnoyers
2019-09-14 14:21 ` Mathieu Desnoyers [this message]
2019-09-16 20:26 ` Mathieu Desnoyers
2019-09-13 15:12 ` [PATCH for 5.3 3/3] rseq/selftests: Fix: Namespace gettid() for compatibility with glibc 2.30 Mathieu Desnoyers
[not found] ` <20190914194716.ED5D020692@mail.kernel.org>
2019-09-16 14:42 ` Mathieu Desnoyers
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=819646407.3304.1568470889470.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=boqun.feng@gmail.com \
--cc=dvyukov@google.com \
--cc=hpa@zytor.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neelnatu@google.com \
--cc=paulmck@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.