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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 989AEC433E1 for ; Thu, 16 Jul 2020 23:27:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5C26920760 for ; Thu, 16 Jul 2020 23:27:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BxY54KCj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C26920760 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DA0FE6B0027; Thu, 16 Jul 2020 19:27:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D51A66B0062; Thu, 16 Jul 2020 19:27:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C66BA6B0068; Thu, 16 Jul 2020 19:27:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id B04126B0027 for ; Thu, 16 Jul 2020 19:27:05 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 463DA181AC9C6 for ; Thu, 16 Jul 2020 23:27:05 +0000 (UTC) X-FDA: 77045526810.22.hole99_0915bd626f06 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 11E3118038E60 for ; Thu, 16 Jul 2020 23:27:05 +0000 (UTC) X-HE-Tag: hole99_0915bd626f06 X-Filterd-Recvd-Size: 6444 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jul 2020 23:27:04 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id 207so4446572pfu.3 for ; Thu, 16 Jul 2020 16:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=emv834qbGgi893dX/IaKrVeomPzEVS0ZG+EyN4ke6Jw=; b=BxY54KCj4kiARNkK+N4vp/W9OTuudktsuJd+WODxPAeDB4oFxO4DQsQB4GI6IM8Gas UJN/mRtbMfMb7XYESBrFdSYxHm0/dz5lI2i/IvV6zif0bXiZCQ+gabEvMQ/IDQfQisVf qes+jiODle+UMzXIbB4xMZ9XK1erPvZaombyKjkf2dPCBjxm1hRdpabhchByUJPhDzib 1F8S+2UX/dzkcedaYb5el1Xm3NMrNgCIzlZ/QU0AfZ6HYI73UBsnFviQsYS1R4bLJyiY ZznnhHQxDV5gPYJtSWQnGIgTy8kG8Ine/794rLiZ9vTmkP2RhhiHUWsR4lNJs0KKqWp4 Ibpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=emv834qbGgi893dX/IaKrVeomPzEVS0ZG+EyN4ke6Jw=; b=s2YbWxienkQ/12Vh0WCAYZRVRJj/MNNnNCe7M/x60TnAmw1SNP70/PsfLhVKNWcqgf P+Z/JGsC+t/ZWB9xAcjEhBkfw/u5DGoj/kyyDH4dr0lccUuBd6LqNY9qPKJGJl39ml9T vZc3s8MkU+TZ8wG8YUmuvQM88aMghdBeESNETzlqzCxGDF1UwFLdG0XbqBJxEvU5w/Gf qSnL6Pciz9AKpXgQElwU8raQwN2Z6smhdiNwLk6KWA8UN9q78fscSWnjpX4ELPEUaQ80 ioUeL05bfiNfZ/Lptvweo6DrmL++1WJ1pHZupEbN+513bPfJ0cvd//u8Hk1B77Wc/WkX tSHw== X-Gm-Message-State: AOAM533VwVSSkEWxmbzaKyGxLvryioY4qSY4FeyGm5LUsjuAPaJuehTN utS4KNzTGPibFUUeAZ/sYBg= X-Google-Smtp-Source: ABdhPJzsas/W/l7YZ8rsW53AbEGEaqr8R3Pt+kUjAsFkMcalVEs2KKHzvH8Zn5PQ137qjCJoqRQ5XQ== X-Received: by 2002:a63:fc52:: with SMTP id r18mr6477752pgk.334.1594942023742; Thu, 16 Jul 2020 16:27:03 -0700 (PDT) Received: from localhost (110-174-173-27.tpgi.com.au. [110.174.173.27]) by smtp.gmail.com with ESMTPSA id 4sm5684665pgk.68.2020.07.16.16.27.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jul 2020 16:27:03 -0700 (PDT) Date: Fri, 17 Jul 2020 09:26:57 +1000 From: Nicholas Piggin Subject: Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode To: peterz@infradead.org Cc: Anton Blanchard , Arnd Bergmann , linux-arch , linux-kernel , linux-mm , linuxppc-dev , Andy Lutomirski , Andy Lutomirski , Mathieu Desnoyers , x86 References: <1594868476.6k5kvx8684.astroid@bobo.none> <20200716085032.GO10769@hirez.programming.kicks-ass.net> <1594892300.mxnq3b9a77.astroid@bobo.none> <20200716110038.GA119549@hirez.programming.kicks-ass.net> In-Reply-To: <20200716110038.GA119549@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Message-Id: <1594906688.ikv6r4gznx.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 11E3118038E60 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: Excerpts from peterz@infradead.org's message of July 16, 2020 9:00 pm: > 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 wr= ote: >=20 >> >> But I=E2=80=99m wondering if all this deferred sync stuff is wrong. I= n 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. >=20 > So we're talking about regular membarrier() then? Not the SYNC_CORE > variant per-se. Well, both but Andy in this case was wondering about kernel writes vs user. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. membarrier does replace barrier instructions on remote CPUs, which do order accesses performed by the kernel on the user address space. So membarrier should too I guess. Normal process context accesses like read(2) will do so because they don't get filtered out from IPIs, but kernel threads using the mm may not. Thanks, Nick