From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 25CF03858D35 for ; Mon, 6 Jul 2020 18:11:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 25CF03858D35 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-293-PmdPXVQlP5qp4MZ3G1noig-1; Mon, 06 Jul 2020 14:11:39 -0400 X-MC-Unique: PmdPXVQlP5qp4MZ3G1noig-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 01D50A0BD8; Mon, 6 Jul 2020 18:11:37 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-118.ams2.redhat.com [10.36.112.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 74C1C10021B3; Mon, 6 Jul 2020 18:11:31 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers 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 Subject: Re: [PATCH 2/3] Linux: Use rseq in sched_getcpu if available (v9) 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> Date: Mon, 06 Jul 2020 20:11:29 +0200 In-Reply-To: <1449254526.22910.1594058539512.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Mon, 6 Jul 2020 14:02:19 -0400 (EDT)") Message-ID: <87blks344u.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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 18:11:42 -0000 * 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. Thanks, Florian