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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 C8B38C433E1 for ; Thu, 16 Jul 2020 11:00:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7C1AD206C1 for ; Thu, 16 Jul 2020 11:00:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ZvEqGy1x" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7C1AD206C1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1238D8D000B; Thu, 16 Jul 2020 07:00:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D4C68D0001; Thu, 16 Jul 2020 07:00:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F05A58D000B; Thu, 16 Jul 2020 07:00:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id D9CF38D0001 for ; Thu, 16 Jul 2020 07:00:49 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 401D0180AD815 for ; Thu, 16 Jul 2020 11:00:49 +0000 (UTC) X-FDA: 77043646218.27.juice09_420005b26f01 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 014A33D663 for ; Thu, 16 Jul 2020 11:00:48 +0000 (UTC) X-HE-Tag: juice09_420005b26f01 X-Filterd-Recvd-Size: 4985 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jul 2020 11:00:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=BbY/K+4UnilsTl+oqlgwJ2dMlxhYTc/XcqHLxskaZPw=; b=ZvEqGy1xxIdI/hTY3W1GJkx2r3 VQKUuvAJV7HnJFkTj/Q7oPoFev3oBJaDDrZ3zK2bGM1I/iFccHDp8V45HP5t75csnPkTg5o4OT5Rk vE0yH67bgqMdf+dZPGqAu+qjC9jOMOyzEabEdwsmqFL7QtCJydnTulLiLHef+efYKszfTdaBQZL85 sh+T16UFrZzJ0Eb5e4571Q6s5ZQ/bOAKXHrmQ68MBOF+QUsoF1ALM06aZ+cQ/ze0i/oImxaeHQOxS +M4dzjF9p1gqLUH1rptVvmvfThoMBrjxAs6JAczcwRpBAfUl+n8wLTOPXo+4Zcl2UfLZzjqWveZCA zdXIjYuw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1jw1d1-0000Uf-SH; Thu, 16 Jul 2020 11:00:40 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 21E19300130; Thu, 16 Jul 2020 13:00:38 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 0D3EC234E2C20; Thu, 16 Jul 2020 13:00:38 +0200 (CEST) Date: Thu, 16 Jul 2020 13:00:38 +0200 From: peterz@infradead.org To: Nicholas Piggin Cc: Andy Lutomirski , Anton Blanchard , Arnd Bergmann , linux-arch , linux-kernel , linux-mm , linuxppc-dev , Andy Lutomirski , Mathieu Desnoyers , x86 Subject: Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode Message-ID: <20200716110038.GA119549@hirez.programming.kicks-ass.net> References: <1594868476.6k5kvx8684.astroid@bobo.none> <20200716085032.GO10769@hirez.programming.kicks-ass.net> <1594892300.mxnq3b9a77.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1594892300.mxnq3b9a77.astroid@bobo.none> X-Rspamd-Queue-Id: 014A33D663 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 16, 2020 at 08:03:36PM +1000, Nicholas Piggin wrote: > Excerpts from Peter Zijlstra's message of July 16, 2020 6:50 pm: > > On Wed, Jul 15, 2020 at 10:18:20PM -0700, Andy Lutomirski wrote: > >> > On Jul 15, 2020, at 9:15 PM, Nicholas Piggin w= rote: > >> But I=E2=80=99m wondering if all this deferred sync stuff is wrong. = In the > >> brave new world of io_uring and such, perhaps kernel access matter > >> too. Heck, even: > >=20 > > IIRC the membarrier SYNC_CORE use-case is about user-space > > self-modifying code. > >=20 > > Userspace re-uses a text address and needs to SYNC_CORE before it can= be > > sure the old text is forgotten. Nothing the kernel does matters there= . > >=20 > > I suppose the manpage could be more clear there. >=20 > True, but memory ordering of kernel stores from kernel threads for > regular mem barrier is the concern here. >=20 > Does io_uring update completion queue from kernel thread or interrupt, > for example? If it does, then membarrier will not order such stores > with user memory accesses. So we're talking about regular membarrier() then? Not the SYNC_CORE variant per-se. Even there, I'll argue we don't care, but perhaps Mathieu has a different opinion. All we care about is that all other threads (or CPUs for GLOBAL) observe an smp_mb() before it returns. Any serialization against whatever those other threads/CPUs are running at the instant of the syscall is external to the syscall, we make no gauarantees about that. That is, we can fundamentally not say what another CPU is executing concurrently. Nor should we want to. So if you feel that your membarrier() ought to serialize against remote execution, you need to arrange a quiecent state on the remote side yourself. Now, normally membarrier() is used to implement userspace RCU like things, and there all that matters is that the remote CPUs observe the beginngin of the new grace-period, ie counter flip, and we observe their read-side critical sections, or smething like that, it's been a while since I looked at all that. It's always been the case that concurrent syscalls could change user memory, io_uring doesn't change that, it just makes it even less well defined when that would happen. If you want to serialize against that, you need to arrange that externally.