From: Florian Weimer <fweimer@redhat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: carlos <carlos@redhat.com>,
Joseph Myers <joseph@codesourcery.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
libc-alpha <libc-alpha@sourceware.org>,
Thomas Gleixner <tglx@linutronix.de>, Ben Maurer <bmaurer@fb.com>,
Peter Zijlstra <peterz@infradead.org>,
Paul <paulmck@linux.vnet.ibm.com>,
Boqun Feng <boqun.feng@gmail.com>,
Will Deacon <will.deacon@arm.com>, Paul Turner <pjt@google.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-api <linux-api@vger.kernel.org>
Subject: Re: [PATCH 2/3] Linux: Use rseq in sched_getcpu if available (v9)
Date: Mon, 06 Jul 2020 19:50:54 +0200 [thread overview]
Message-ID: <87k0zg3535.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <1679448037.22891.1594056826859.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Mon, 6 Jul 2020 13:33:46 -0400 (EDT)")
* Mathieu Desnoyers:
> Now we need to discuss how we introduce that fix in a way that will
> allow user-space to trust the __rseq_abi.cpu_id field's content.
I don't think that's necessary. We can mention it in the glibc
distribution notes on the wiki.
> The usual approach to kernel bug fixing is typically to push the fix,
> mark it for stable kernels, and expect everyone to pick up the
> fixes. I wonder how comfortable glibc would be to replace its
> sched_getcpu implementation with a broken-until-fixed kernel rseq
> implementation without any mechanism in place to know whether it can
> trust the value of the cpu_id field. I am extremely reluctant to do
> so.
We have already had similar regressions in sched_getcpu, and we didn't
put anything into glibc to deal with those.
Just queue the fix for the stable kernels. I expect that all
distributions track stable kernel branches in some way, so just put into
the kernel commit message that this commit is needed for a working
sched_getcpu in glibc 2.32 and later.
Once the upstream fix is in Linus' tree, I'm going to file a request to
backport the fix into the Red Hat Enterprise Linux 8.
Thanks for finding the root cause so quickly,
Florian
next prev parent reply other threads:[~2020-07-06 17:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200629190036.26982-1-mathieu.desnoyers@efficios.com>
2020-06-29 19:00 ` [PATCH 1/3] glibc: Perform rseq registration at C startup and thread creation (v22) Mathieu Desnoyers
2020-07-02 14:46 ` Florian Weimer
2020-07-03 17:50 ` Carlos O'Donell
2020-06-29 19:00 ` [PATCH 2/3] Linux: Use rseq in sched_getcpu if available (v9) Mathieu Desnoyers
2020-07-06 13:59 ` Florian Weimer
2020-07-06 14:49 ` Mathieu Desnoyers
2020-07-06 17:33 ` Mathieu Desnoyers
2020-07-06 17:50 ` Florian Weimer [this message]
2020-07-06 18:02 ` Mathieu Desnoyers
2020-07-06 18:11 ` Florian Weimer
2020-07-06 21:08 ` Mathieu Desnoyers
[not found] <20200622180803.1449-1-mathieu.desnoyers@efficios.com>
2020-06-22 18:08 ` 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=87k0zg3535.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=bmaurer@fb.com \
--cc=boqun.feng@gmail.com \
--cc=carlos@redhat.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=szabolcs.nagy@arm.com \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.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.