From: Florian Weimer <fw@deneb.enyo.de>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
"Paul E . McKenney" <paulmck@linux.ibm.com>,
Boqun Feng <boqun.feng@gmail.com>,
"H . Peter Anvin" <hpa@zytor.com>, Paul Turner <pjt@google.com>,
linux-api@vger.kernel.org, Dmitry Vyukov <dvyukov@google.com>,
Neel Natu <neelnatu@google.com>
Subject: Re: [RFC PATCH for 5.8 3/4] rseq: Introduce RSEQ_FLAG_RELIABLE_CPU_ID
Date: Tue, 07 Jul 2020 09:29:20 +0200 [thread overview]
Message-ID: <87fta3zstr.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20200706204913.20347-4-mathieu.desnoyers@efficios.com> (Mathieu Desnoyers's message of "Mon, 6 Jul 2020 16:49:12 -0400")
* Mathieu Desnoyers:
> commit 93b585c08d16 ("Fix: sched: unreliable rseq cpu_id for new tasks")
> addresses an issue with cpu_id field of newly created processes. Expose
> a flag which can be used by user-space to query whether the kernel
> implements this fix.
>
> Considering that this issue can cause corruption of user-space per-cpu
> data updated with rseq, it is recommended that user-space detects
> availability of this fix by using the RSEQ_FLAG_RELIABLE_CPU_ID flag
> either combined with registration or on its own before using rseq.
Presumably, the intent is that glibc uses RSEQ_FLAG_RELIABLE_CPU_ID to
register the rseq area. That will surely prevent glibc itself from
activating rseq on broken kernels. But if another rseq library
performs registration and has not been updated to use
RSEQ_FLAG_RELIABLE_CPU_ID, we still end up with an active rseq area
(and incorrect CPU IDs from sched_getcpu in glibc). So further glibc
changes will be needed. I suppose we could block third-party rseq
registration with a registration of a hidden rseq area (not
__rseq_abi). But then the question is if any of the third-party rseq
users are expecting the EINVAL error code from their failed
registration.
The rseq registration state machine is quite tricky already, and the
need to use RSEQ_FLAG_RELIABLE_CPU_ID would make it even more
complicated. Even if we implemented all the changes, it's all going
to be essentially dead, untestable code in a few months, when the
broken kernels are out of circulation. It does not appear to be good
investment to me.
next prev parent reply other threads:[~2020-07-07 7:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-06 20:49 [RFC PATCH for 5.8 0/4] rseq cpu_id ABI fix Mathieu Desnoyers
2020-07-06 20:49 ` [RFC PATCH for 5.8 1/4] sched: Fix unreliable rseq cpu_id for new tasks Mathieu Desnoyers
2020-07-07 7:30 ` Florian Weimer
2020-07-07 10:51 ` Mathieu Desnoyers
2020-07-06 20:49 ` [RFC PATCH for 5.8 2/4] rseq: Introduce RSEQ_FLAG_REGISTER Mathieu Desnoyers
2020-07-06 20:49 ` [RFC PATCH for 5.8 3/4] rseq: Introduce RSEQ_FLAG_RELIABLE_CPU_ID Mathieu Desnoyers
2020-07-07 7:29 ` Florian Weimer [this message]
2020-07-07 10:48 ` Mathieu Desnoyers
2020-07-07 11:32 ` Florian Weimer
2020-07-07 12:06 ` Mathieu Desnoyers
2020-07-07 18:53 ` Carlos O'Donell
2020-07-07 18:59 ` Mathieu Desnoyers
2020-07-08 8:31 ` Florian Weimer
2020-07-07 19:55 ` Florian Weimer
2020-07-08 15:33 ` Mathieu Desnoyers
2020-07-08 16:22 ` Christian Brauner
2020-07-08 16:36 ` Florian Weimer
2020-07-08 17:34 ` Mathieu Desnoyers
2020-07-09 12:49 ` Christian Brauner
2020-07-09 15:15 ` Mathieu Desnoyers
2020-07-11 15:54 ` Christian Brauner
2020-07-13 18:40 ` Mathieu Desnoyers
2020-07-06 20:49 ` [RFC PATCH for 5.8 4/4] rseq: selftests: Expect reliable cpu_id field Mathieu Desnoyers
2020-07-07 6:26 ` [RFC PATCH for 5.8 0/4] rseq cpu_id ABI fix Florian Weimer
2020-07-07 14:54 ` Florian Weimer
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=87fta3zstr.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--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=mathieu.desnoyers@efficios.com \
--cc=neelnatu@google.com \
--cc=paulmck@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--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 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).