From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by sourceware.org (Postfix) with ESMTPS id 6FCB53858C27 for ; Tue, 26 Sep 2023 23:54:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FCB53858C27 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-lf1-x12e.google.com with SMTP id 2adb3069b0e04-50302e8fca8so2244e87.0 for ; Tue, 26 Sep 2023 16:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695772489; x=1696377289; 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=DgrFSr0lcpMkghymDey2Le+WO5HSrc8DDvJYmyktvLM=; b=E/dl28NwQa4L+UANs1Hv0ePTHtIUOEQgcG9JV/EcrRXLVmOxKqxxtfqj0orPpMUmnS 68IXCO3LylkBPctwk50tK/EhqSq6CMCpH5oV4G3UK0i9aGNbCYp4UsEejS/l5Pmx8+2A 1lvlSRanI2RQyUGIi6Z6klW9q/YB7vJ6wkzrITKXo/shiGZ+jJdMlavwlNhf0tNGMUwX oElRDMG3xu61DdIttNii3Yydbm9/xqZ9SaziRfY4fQsVLN9VysfyfKZOHh05NDxx1rsp gjIZGbHOBoQZJP3rREXWH56UwPk10E6Qq9vYdxIjI8qMQFBWoDSLYA8FNwB/hSHRtJxp zxQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695772489; x=1696377289; 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=DgrFSr0lcpMkghymDey2Le+WO5HSrc8DDvJYmyktvLM=; b=fz1aTe3xcGQEiOhKu9o0eu1AYMxjMso0yt28aU1dqYdzdWL7n0dVaRI6S0pMVTedqh XNY+3WxQ5Jiyr+0RT2ad68372Jle/n4Ru9c1joranwbJX39MmTur/jp3vkw4RmHyIWH/ r0YXagoDZAja86R1lBfxQ6Bis8jGADbr/WGsVRYAiiy4a++JB4QK91Oqf0YFhPMmvIQ1 5lYL4eZv6etNr2zIIGsQ9aSJVEebkKHd4eh3qEr8/nS9EqQe8A68CtuqmCjztyfPfKAm zU1KKj1WZk99SKMtWVX3py8EskkUv2+Fwo1PGtyLK0ZZsEDheHSYy8jVjaPm1sgubWId NG2Q== X-Gm-Message-State: AOJu0Yz7GRuD0BoA/ygH6mAzAbAW3f6hfwKtipjE5nYEKnO/ZeqaPv+J vtUV9nrrSWRuUOnEvdkwilGm7WoyGW4kwLffMpr2Vg== X-Google-Smtp-Source: AGHT+IEwPEUTHesOA8CXADgGak3kYxBneBIHCY/B7MbauZW/qvFRxs2BfhXQxx2fpaRGK29BAzR6CxsK6NG+SMUgl5k= X-Received: by 2002:ac2:5299:0:b0:500:d960:1a75 with SMTP id q25-20020ac25299000000b00500d9601a75mr95687lfm.6.1695772488689; Tue, 26 Sep 2023 16:54:48 -0700 (PDT) MIME-Version: 1.0 References: <2c421e36-a749-7dc3-3562-7a8cf256df3c@efficios.com> <20230926205215.472650-1-dvyukov@google.com> In-Reply-To: From: Dmitry Vyukov Date: Tue, 26 Sep 2023 16:54:36 -0700 Message-ID: Subject: Re: [RFC PATCH v2 1/4] rseq: Add sched_state field to struct rseq To: mathieu.desnoyers@efficios.com Cc: 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, fweimer@redhat.com, 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=-16.5 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: > +void __rseq_set_sched_state(struct task_struct *t, unsigned int state) > +{ > + if (unlikely(t->flags & PF_EXITING)) > + return; Don't we want to do this even if the task is exciting? If rseq is read only only the current task, then it does not matter (exiting task won't read own rseq anymore). But if we extending expected uses cases to tasks reading rseq of other tasks, we may need to updates even in PF_EXITING case. > + pagefault_disable(); This is a bit concerning. Does this mean updates are not done if the page is currently not in memory? Can we make it reliable as for the main rseq data (cpu_id)? For tcmalloc uses (and other uses that require reliable information) this may be problematic. User-space may start thinking that all "CPU slots" are busy and that there more threads running than there are CPUs. > + (void) put_user(state, &t->rseq_sched_state->state); > + pagefault_enable(); > +}