From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40715C433E2 for ; Tue, 7 Jul 2020 10:51:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1B4E1206DF for ; Tue, 7 Jul 2020 10:51:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="fq9dqb9+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727789AbgGGKvq (ORCPT ); Tue, 7 Jul 2020 06:51:46 -0400 Received: from mail.efficios.com ([167.114.26.124]:50334 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725941AbgGGKvp (ORCPT ); Tue, 7 Jul 2020 06:51:45 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 17D5725B0; Tue, 7 Jul 2020 06:51:45 -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 ZPLoVSiFp3tp; Tue, 7 Jul 2020 06:51:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id CEC762900; Tue, 7 Jul 2020 06:51:44 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com CEC762900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1594119104; bh=65U6cZeoHJ0b5uwyqFXxHAmikJcNMvEpm9mPm7idWLY=; h=Date:From:To:Message-ID:MIME-Version; b=fq9dqb9+7BWAfcO430hyxnqpMmln7WEUOJxaiSvhFT5vjgIiTRME3SMA89I0xOYBo 3l1WfNUVziv3M7PJ0PAm2UrR8OZmYz7DFbZZlGKJJxTzA4xOOz33A46RlhPtK1L0/T KfwrtjK1g0e6aog9RyLPwa/SedSVpaVPEtl517OC9NHeIuLP/q3GP4SGMGq9Adw8ud pqrrVg2oIcUXwGmw5hQfZ5+KvK2CzhJI1XcTzju9gkXFCiJtdsDwZw/CYZ58fCN0dS 74mk4Op2uv1LeFQGp4s6g1EQWjSQ6S83FO/6v9FjbMdnEUzJ6r1i5kckncUWvuH9Xa bS/VGsbxKiKXA== 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 6rXMaviP4Q9e; Tue, 7 Jul 2020 06:51:44 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id BC4FD263A; Tue, 7 Jul 2020 06:51:44 -0400 (EDT) Date: Tue, 7 Jul 2020 06:51:44 -0400 (EDT) From: Mathieu Desnoyers To: Florian Weimer Cc: Thomas Gleixner , linux-kernel , Peter Zijlstra , paulmck , Boqun Feng , "H. Peter Anvin" , Paul Turner , linux-api , Dmitry Vyukov , Neel Natu , stable Message-ID: <1513249086.945.1594119104750.JavaMail.zimbra@efficios.com> In-Reply-To: <87blkrzssa.fsf@mid.deneb.enyo.de> References: <20200706204913.20347-1-mathieu.desnoyers@efficios.com> <20200706204913.20347-2-mathieu.desnoyers@efficios.com> <87blkrzssa.fsf@mid.deneb.enyo.de> Subject: Re: [RFC PATCH for 5.8 1/4] sched: Fix unreliable rseq cpu_id for new tasks 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: sched: Fix unreliable rseq cpu_id for new tasks Thread-Index: +EFr9o+gVaPjCkmbkUIMJ25jGoinrQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jul 7, 2020, at 3:30 AM, Florian Weimer fw@deneb.enyo.de wrote: > * Mathieu Desnoyers: > >> While integrating rseq into glibc and replacing glibc's sched_getcpu >> implementation with rseq, glibc's tests discovered an issue with >> incorrect __rseq_abi.cpu_id field value right after the first time >> a newly created process issues sched_setaffinity. >> >> For the records, it triggers after building glibc and running tests, and >> then issuing: >> >> for x in {1..2000} ; do posix/tst-affinity-static & done >> >> and shows up as: >> >> error: Unexpected CPU 2, expected 0 >> error: Unexpected CPU 2, expected 0 >> error: Unexpected CPU 2, expected 0 >> error: Unexpected CPU 2, expected 0 >> error: Unexpected CPU 138, expected 0 >> error: Unexpected CPU 138, expected 0 >> error: Unexpected CPU 138, expected 0 >> error: Unexpected CPU 138, expected 0 > > As far as I can tell, the glibc reproducer no longer shows the issue > with this patch applied. > > Tested-By: Florian Weimer Thanks a lot Florian for your thorough review and testing ! Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com