Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1577693pxa; Thu, 6 Aug 2020 10:40:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdtyA349wZV3WK8E18Ek8tMTvBEqRJhkU+QXfjnW+AhP0sDtwFvVud4DQOGQHwUJKvDFis X-Received: by 2002:aa7:dd15:: with SMTP id i21mr5137341edv.153.1596735657127; Thu, 06 Aug 2020 10:40:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596735657; cv=none; d=google.com; s=arc-20160816; b=ISQ1iSKZSmphkEWgDujOU37fZaNzq/wpJfDYhN2xjQynI3Tv777JpTJqEev7GBucyi c7rm2cnzO/46Pju5oN7hm0mzrGvlIjbDTyiZV1g8yfv+0iX9/kCSoAUpwUg7fY0mo1ZE F2rRjK2OtVoz+z0oI67WSYnQ7z2T3OpsiduSuJkZrG1fyO/itDAbxlxpay7PLMdq8hF0 GhxzE1S5VCSOtO3lEEFtbBhr3GB3bb0QNuAMc4mgJ2Q9fB1od//wEmMthW7kr2vWVUTM a35TqLFAWL2zZgv4xRaaAm2GoLkaxFNb27uHWtA0rXvNULElSR35mYukYAeF5CmLcsNL y/5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter; bh=OrosOIBuaBgs7qXL5uOz7bAbp98TAnrOMrITAMPW1Rk=; b=EWDnUeBuL9N0k8KisXku1DTbO5GtLKGijfa80m6bZ49WfBFUZ1vm22u0MUs2tvA5LS kaaUOEZQw66o0NnFMPl4F65kjlElqBjj1Q9XrLtW1tAhVIiCC9cOed10wNb00bfFkaF7 TSMbWvRx/Z+A8VAVvW3VaPo9RabevgH8tSjl3R/rppDZBwV1tFnmcLNfXc3RL2yjRbvo damwQbPmAQa0pkW++T4ERShC5Q765qVXtGQnTN0ttpIGs/4nJo8XHYsdmWEgbEVXW/qf OE5bG5UpiA+uGFIQ7wt6rUNzfn/tMhVmdJLpvh+xd+GgCH9xtubt9ZlxXsDZxziXSE3K 3AzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=eUWfIcTP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u23si3577645edr.459.2020.08.06.10.40.33; Thu, 06 Aug 2020 10:40:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=eUWfIcTP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729100AbgHFRhz (ORCPT + 99 others); Thu, 6 Aug 2020 13:37:55 -0400 Received: from mail.efficios.com ([167.114.26.124]:44178 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728584AbgHFRhH (ORCPT ); Thu, 6 Aug 2020 13:37:07 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 3FDA329B3CB; Thu, 6 Aug 2020 13:37:06 -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 H0HhRYvWXMqS; Thu, 6 Aug 2020 13:37:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id B325F29B5B3; Thu, 6 Aug 2020 13:37:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com B325F29B5B3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1596735425; bh=OrosOIBuaBgs7qXL5uOz7bAbp98TAnrOMrITAMPW1Rk=; h=Date:From:To:Message-ID:MIME-Version; b=eUWfIcTPd+W2tkiWaomJrp/lm1s26VFGZYzc8N6C0gBcJso2X1b7D55AtOjMYAOfc CCWCmmQMYQDFYX08/W/jRirCdr3UxcRRR1wc2kjY/PFAJnjp1FZD14Qjv0o4mgFtfq kjNyaWu/xdZLW8Le17XnYDI8siemWZ1CPItnbbkYfzDWlwCFRIAd91+oG6DpdMHUfa cAOw2Ft/ugPTyfzVJWWLjekkX6oCZ6FFeM8Z6Y6z3+kSGUHwj5MawO7KF4RmTceBHK 2A1pzq35vSRMTGS03UWAVOKn4k0nBmk+h/V6ZZvaZaILA4fXJgk77DhD72ed8VrjyC ZTAEnS3oHdfvg== 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 nI9X0H-SkiRq; Thu, 6 Aug 2020 13:37:05 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id A408529B636; Thu, 6 Aug 2020 13:37:05 -0400 (EDT) Date: Thu, 6 Aug 2020 13:37:05 -0400 (EDT) From: Mathieu Desnoyers To: Peter Oskolkov Cc: Peter Zijlstra , Peter Oskolkov , paulmck , linux-kernel , Paul Turner , Chris Kennelly Message-ID: <1668913120.1621.1596735425601.JavaMail.zimbra@efficios.com> In-Reply-To: References: <20200806000859.160882-1-posk@google.com> <20200806134828.GA165568@hirez.programming.kicks-ass.net> Subject: Re: [PATCH 1/2] membarrier: add MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU 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_3959 (ZimbraWebClient - FF79 (Linux)/8.8.15_GA_3953) Thread-Topic: membarrier: add MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU Thread-Index: S/ODafaL6Qc5NbUukMlKTrc5xZy9ZQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Aug 6, 2020, at 1:07 PM, Peter Oskolkov posk@posk.io wrote: > On Thu, Aug 6, 2020 at 6:48 AM wrote: >> >> On Wed, Aug 05, 2020 at 05:08:58PM -0700, Peter Oskolkov wrote: >> >> Thanks for the Cc! > > Always a pleasure! > > (Sorry, included only membarrier maintainers in v1; in v2 included > both membarrier and rseq maintainers). > >> >> > + * @MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU: >> > + * If a thread belonging to the current process >> > + * is currently in an RSEQ critical section on the >> > + * CPU identified by flags parameter, restart it. >> > + * @flags: if @flags >= 0, identifies the CPU to >> > + * restart RSEQ CS on; if == -1, restarts >> > + * RSEQ CSs on all CPUs. >> >> > + } else if (cpu_id == -1) { >> > + on_each_cpu(membarrier_rseq_ipi, >> > + current->group_leader, true); >> >> This is an unpriv IPI the world. That's a big no-no. > > removed in v2. I don't think the feature must be removed, but its implementation needs adjustment. How about we simply piggy-back on the membarrier schemes we already have, and implement: membarrier_register_private_expedited(MEMBARRIER_FLAG_RSEQ) membarrier_private_expedited(MEMBARRIER_FLAG_RSEQ) All the logic is there to prevent sending IPIs to runqueues which are not running threads associated with the same mm. Considering that preemption does an rseq abort, running a thread belonging to a different mm should mean that this CPU is not currently executing an rseq critical section, or if it was, it has already been aborted, so it is quiescent. Then you'll probably want to change membarrier_private_expedited so it takes an extra "cpu" argument. If cpu=-1, iterate on all runqueues like we currently do. If cpu >= 0, only IPI that CPU if the thread currently running has the same mm. Also, should this belong to the membarrier or the rseq system call ? It just looks like the membarrier happens to implement very similar things for barriers, but arguably this is really about rseq. I wonder if we should expose this through rseq instead, even if we end up using membarrier code. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com