Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1077579ybh; Mon, 13 Jul 2020 08:49:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzObCJEGgroJ5MDXmtj5R/fGputTzApzI0ccZNjV8/ENn3Bvga2szunvHLHFL/9kH4qPoln X-Received: by 2002:a17:906:1a54:: with SMTP id j20mr327694ejf.455.1594655344950; Mon, 13 Jul 2020 08:49:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594655344; cv=none; d=google.com; s=arc-20160816; b=BX2FQkrkZIJjgJhCpUCatm+Si1xMoJSvKfhSMYJUAOp86S4DMs0IiZewbDJYXEfMdF jqJMR0pokD/pL8QTQz7egBa/mU0WW7wimqPKjtMiIsKafhxaNEzWDAuuHuW209sdycZp gUj6wfFl+ZM/qBLwhHsHYuUR4EYz1RH6DGeA+vW1W8efjDmh9t+donWYmtzYFTLzqZcK wJBG2P9OIcR9i9oLaaDT4zxAXMr5+m2A3hm11QVIKiXg04Lv7WE12ov7ynvOC6ilUAQo 7dRVdu7aqvw70A3+KgDcqAElEJv+wOIgGSh63gL0lAMvGD5z2UDohQ51lzgoDn/cwk2T Q76Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=tqzFNV5MNvxlKlNpny79roPS74XcrPq4aTv7ZUYE9+0=; b=m1v354nmwQygTHsQHh72p+NljCKtvYI9FIgqOlzRDrHWrQziRBeQThlvUFt0osLFqQ cxpOEeoQWbMVtRmnvVH3QNjmD2vHHbxFRWm/nnQ15DQ5+wrq7k0ubCczqyzGgrTEFuom axAEWxKKVnX8KjvPgs/7IR6gp07zxsb7HSv4Qk7mgVlduT9VhOIbpxREQn8kX8bK/I8v owpJBljQGgiSG47FHzzZfTOjXO/TRBx9JqVzLpp+GaKqmsAzHcAvOS3YqaXnOE8YdG+b xKmqkeOaNr7iauStSZXE2gB9OPhtMV4eoAMLH3xwI7lDXnMvds4Ynx9WfiVCh04kRN3a DzOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="u/HSfMU9"; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o17si9572485ejg.160.2020.07.13.08.48.41; Mon, 13 Jul 2020 08:49:04 -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=@kernel.org header.s=default header.b="u/HSfMU9"; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729649AbgGMPsa (ORCPT + 99 others); Mon, 13 Jul 2020 11:48:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:43286 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729492AbgGMPs3 (ORCPT ); Mon, 13 Jul 2020 11:48:29 -0400 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 74402207BC for ; Mon, 13 Jul 2020 15:48:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594655309; bh=FiLSo9R0STPJ54NQ+j4cquzz90YqRrZ+tVdT8FICfPw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=u/HSfMU9F7rxmTiqX4sRr4Pk8VxlDbewsgkjIe6pG2nB4ATgq01e1Xrr0clJ4LJmf KF6xr1Xv2GX82a28cw4dDUZuiL8A6ohB3EUIdPA0Gz22eJVXxmjte4lc3XkjzocFbw v5Jvv0F2fEGEoQbUjFwMLPV7iO/JAL2dOHC42qck= Received: by mail-wr1-f41.google.com with SMTP id o11so17104053wrv.9 for ; Mon, 13 Jul 2020 08:48:29 -0700 (PDT) X-Gm-Message-State: AOAM530tom3A97R68mbGlaHoXk8oCo/OVIXgx6qkqAHNYL7Oz/xQfYxF ablweiqaJkwDY2AWBF2o06yFs/RW6MIRaChZOXZYLQ== X-Received: by 2002:adf:a111:: with SMTP id o17mr79174967wro.257.1594655308027; Mon, 13 Jul 2020 08:48:28 -0700 (PDT) MIME-Version: 1.0 References: <20200710015646.2020871-1-npiggin@gmail.com> <20200710015646.2020871-5-npiggin@gmail.com> <1594613902.1wzayj0p15.astroid@bobo.none> <1594647408.wmrazhwjzb.astroid@bobo.none> <284592761.9860.1594649601492.JavaMail.zimbra@efficios.com> In-Reply-To: <284592761.9860.1594649601492.JavaMail.zimbra@efficios.com> From: Andy Lutomirski Date: Mon, 13 Jul 2020 08:48:16 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode To: Mathieu Desnoyers Cc: Nicholas Piggin , Andy Lutomirski , Anton Blanchard , Arnd Bergmann , linux-arch , linux-kernel , linux-mm , linuxppc-dev , Peter Zijlstra , x86 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 13, 2020 at 7:13 AM Mathieu Desnoyers wrote: > > ----- On Jul 13, 2020, at 9:47 AM, Nicholas Piggin npiggin@gmail.com wrote: > > > Excerpts from Nicholas Piggin's message of July 13, 2020 2:45 pm: > >> Excerpts from Andy Lutomirski's message of July 11, 2020 3:04 am: > >>> Also, as it stands, I can easily see in_irq() ceasing to promise to > >>> serialize. There are older kernels for which it does not promise to > >>> serialize. And I have plans to make it stop serializing in the > >>> nearish future. > >> > >> You mean x86's return from interrupt? Sounds fun... you'll konw where to > >> update the membarrier sync code, at least :) > > > > Oh, I should actually say Mathieu recently clarified a return from > > interrupt doesn't fundamentally need to serialize in order to support > > membarrier sync core. > > Clarification to your statement: > > Return from interrupt to kernel code does not need to be context serializing > as long as kernel serializes before returning to user-space. > > However, return from interrupt to user-space needs to be context serializing. > Indeed, and I figured this out on the first read through because I'm quite familiar with the x86 entry code. But Nick somehow missed this, and Nick is the one who wrote the patch. Nick, I think this helps prove my point. The code you're submitting may well be correct, but it's unmaintainable. At the very least, this needs a comment explaining, from the perspective of x86, *exactly* what exit_lazy_tlb() is promising, why it's promising it, how it achieves that promise, and what code cares about it. Or we could do something with TIF flags and make this all less magical, although that will probably end up very slightly slower. --Andy