From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id B4D093857C5A for ; Mon, 6 Jul 2020 21:08:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B4D093857C5A Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 628DB2DD101; Mon, 6 Jul 2020 17:08:33 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wcJb0Pe9Wy3C; Mon, 6 Jul 2020 17:08:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 10C842DD029; Mon, 6 Jul 2020 17:08:33 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 10C842DD029 X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xn5wGwpqVwc3; Mon, 6 Jul 2020 17:08:33 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id F34042DCD6D; Mon, 6 Jul 2020 17:08:32 -0400 (EDT) Date: Mon, 6 Jul 2020 17:08:32 -0400 (EDT) From: Mathieu Desnoyers To: Florian Weimer Cc: carlos , Joseph Myers , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , Paul , Boqun Feng , Will Deacon , Paul Turner , linux-kernel , linux-api Message-ID: <901929746.433.1594069712898.JavaMail.zimbra@efficios.com> In-Reply-To: <87blks344u.fsf@oldenburg2.str.redhat.com> References: <20200629190036.26982-1-mathieu.desnoyers@efficios.com> <20200629190036.26982-3-mathieu.desnoyers@efficios.com> <877dvg4ud4.fsf@oldenburg2.str.redhat.com> <942999672.22574.1594046978937.JavaMail.zimbra@efficios.com> <1679448037.22891.1594056826859.JavaMail.zimbra@efficios.com> <87k0zg3535.fsf@oldenburg2.str.redhat.com> <1449254526.22910.1594058539512.JavaMail.zimbra@efficios.com> <87blks344u.fsf@oldenburg2.str.redhat.com> Subject: Re: [PATCH 2/3] Linux: Use rseq in sched_getcpu if available (v9) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3955 (ZimbraWebClient - FF78 (Linux)/8.8.15_GA_3953) Thread-Topic: Linux: Use rseq in sched_getcpu if available (v9) Thread-Index: I6miy1IiklPsyYvl/Xr34Sz2sT8C5Q== X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 21:08:35 -0000 ----- On Jul 6, 2020, at 2:11 PM, Florian Weimer fweimer@redhat.com wrote: > * Mathieu Desnoyers: > >> ----- On Jul 6, 2020, at 1:50 PM, Florian Weimer fweimer@redhat.com wrote: >> >>> * 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. >> >> Was that acceptable because having a wrong cpu number would never trigger >> corruption, only slowdowns ? > > First of all, it's a kernel bug. It's rare that we put workarounds for > kernel bugs into glibc. > > And yes, in pretty much all cases it's just a performance issue for > sched_getcpu. When you know the CPU ID of a thread due to pinning to a > single CPU, why would you call sched_getcpu? (That's the case where you > could get corruption in theory.) > >> In the case of rseq, having the wrong cpu_id value is a real issue >> which will lead to corruption and crashes. So I maintain my reluctance >> to introduce the fix without any way for userspace to know whether the >> cpu_id field value is reliable. > > Yes, for rseq itself, the scenario is somewhat different. Still, it's > just another kernel bug. There will be others. 8-/ > > From a schedule point of view, it looks tough to get the magic flag into > the mainline kernel in time for the upcoming glibc 2.32 release. If you > insist on registering rseq only if the bug is not present, we'll > probably have to back out some or all of the rseq changes. I've just submitted the fix and a the new rseq flag as RFC to lkml: https://lore.kernel.org/lkml/20200706204913.20347-1-mathieu.desnoyers@efficios.com/ Let's see how quickly we can come to an agreement on this on the kernel side. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com