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
Subject: Re: [RFC PATCH for 5.8 0/4] rseq cpu_id ABI fix
Date: Tue, 07 Jul 2020 08:26:51 +0200 [thread overview]
Message-ID: <87k0zfzvpw.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20200706204913.20347-1-mathieu.desnoyers@efficios.com> (Mathieu Desnoyers's message of "Mon, 6 Jul 2020 16:49:09 -0400")
* Mathieu Desnoyers:
> This is an RFC aiming for quick inclusion into the Linux kernel, unless
> we prefer reverting the entire rseq glibc integration and try again in 6
> months. Their upcoming release is on August 3rd, so we need to take a
> decision on this matter quickly.
Just to clarify here, I don't think it's necessary to change glibc so
that it only enables the rseq functionality if this particular bug is
not present. From our perspective, it's just another kernel bug.
If you truly feel we must not enable this feature in its present
kernel state, then we need a working patch on all sides by the end of
the week because the hard ABI freeze for glibc 2.32 is coming up, and
at without any other patches, the only safe choice to prevent glibc
from using slightly broken rseq support would be to back out the rseq
patches.
But again, I don't think such drastic action is necessary.
next prev parent reply other threads:[~2020-07-07 6:27 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
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 ` Florian Weimer [this message]
2020-07-07 14:54 ` [RFC PATCH for 5.8 0/4] rseq cpu_id ABI fix 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=87k0zfzvpw.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=boqun.feng@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.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).