From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id C22AC3861953 for ; Wed, 27 Sep 2023 15:58:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C22AC3861953 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-405459d9a96so125595e9.0 for ; Wed, 27 Sep 2023 08:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695830309; x=1696435109; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=H6EKhbh+uwSaVjjFLye5TVhjia4Fh1KKJgT0N4UEBx0=; b=R4AbYtz599N4oo1DVw8EVnEQfreGqyJEOTYtg6GG0CaXYTXeWOOnc4hEakqBx2KEQz aKppJYldxB1TD855VEh9rzS398HvZ8Px5qvEU4grQ+benkLp5D61HNAQp+AiSe2B02dT 6/4N0pOQFVQwcPH0EJyui+E8atsZWaQXrVQDIqzT7R9zXs6fxqDRewOhyHPdtUStCFA1 K2enfa3d7coFA1S9cJuKBsMjFaBxJBmVXYBesCr0yVDXy2fsEum/h5q+LS3UnuW/VCcm nMvZt2Be5nID7daBT+jDjRTH8Ff9+XVR/uHVFA3EQPXokaletg+B2Jy6Zmhio4nvD+Gh VgXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695830309; x=1696435109; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=H6EKhbh+uwSaVjjFLye5TVhjia4Fh1KKJgT0N4UEBx0=; b=mGFRZxz9+xiygi9icvnEe6ikgUxge522Tql9gn4FJXQoVsHYo5sC62MS5PYJoB6I2m XYTWRa72k9L5QC2CxKLY2+DbHQDQnbzIphEImvDsjRaO3N5nfvyXWJf1Q/L1dzYqmNYF /OFcWoyQVDtoui1J2sN2GT8Wg6TQvku7BTqsQHrpY4eBr0J+kRMSf2HgerZHWgtHkEm6 Nzkrbj9TC5YpSLFIsi6e8osLQ3cwa9eC73ur5qOPBLI+CsVtgfDkvpw3+DaVr6rACpAx u3k72HI+tXeVHDw3nlR7sCKHk+wfyqk/cceEYU7QmH7P0fQew88aGJcVhGCHoGbMaiYK YEVg== X-Gm-Message-State: AOJu0YyrEDe6NKVXFugKC/1Poup5Gu102DWGXmbswnF54cZOwA0+Ej5f EXwU1sNCasf4HJ07Pg+SZIDhIa6UWavIS4W+rrQPKg== X-Google-Smtp-Source: AGHT+IHouwphCDErmnOKBhP+lk3XKIj4HPNAIxtupjaE9J/Cluv/KAGLM81/gWknqRfgR0LQ3k569YyhTiEpXvolNAA= X-Received: by 2002:a05:600c:4e42:b0:3fe:eb42:7ec with SMTP id e2-20020a05600c4e4200b003feeb4207ecmr218651wmq.1.1695830309055; Wed, 27 Sep 2023 08:58:29 -0700 (PDT) MIME-Version: 1.0 References: <2c421e36-a749-7dc3-3562-7a8cf256df3c@efficios.com> <20230926205215.472650-1-dvyukov@google.com> <875y3wp6au.fsf@oldenburg.str.redhat.com> In-Reply-To: <875y3wp6au.fsf@oldenburg.str.redhat.com> From: Dmitry Vyukov Date: Wed, 27 Sep 2023 08:58:16 -0700 Message-ID: Subject: Re: [RFC PATCH v2 1/4] rseq: Add sched_state field to struct rseq To: Florian Weimer Cc: mathieu.desnoyers@efficios.com, David.Laight@aculab.com, alexander@mihalicyn.com, andrealmeid@igalia.com, boqun.feng@gmail.com, brauner@kernel.org, carlos@redhat.com, ckennelly@google.com, corbet@lwn.net, dave@stgolabs.net, dvhart@infradead.org, goldstein.w.n@gmail.com, hpa@zytor.com, libc-alpha@sourceware.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, longman@redhat.com, mingo@redhat.com, paulmck@kernel.org, peterz@infradead.org, pjt@google.com, posk@posk.io, rostedt@goodmis.org, tglx@linutronix.de Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 26 Sept 2023 at 21:51, Florian Weimer wrote: > > * Dmitry Vyukov: > > > In reality it's a bit more involved since the field is actually 8 > > bytes and only partially overlaps with rseq.cpu_id_start (it's an > > 8-byte pointer with high 4 bytes overlap rseq.cpu_id_start): > > > > https://github.com/google/tcmalloc/blob/229908285e216cca8b844c1781bf16b838128d1b/tcmalloc/internal/percpu.h#L101-L165 > > This does not compose with other rseq users, as noted in the sources: > > // Note: this makes __rseq_abi.cpu_id_start unusable for its original purpose. > > For a core library such a malloc replacement, that is a very bad trap. I agree. I wouldn't do this if there were other options. That's why I am looking for official kernel support for this. If we would have a separate 8 bytes that are overwritten with 0 when a thread is descheduled, that would be perfect.