Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7750175rdb; Thu, 4 Jan 2024 06:40:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IGYOMinFO1UfynO4p4S2JF/ZoQUwABWie/K+QkIs6FkRZ8JSUGQF+js7DwwTmu1ogGjZGzt X-Received: by 2002:a05:622a:4d1:b0:428:25a2:9177 with SMTP id q17-20020a05622a04d100b0042825a29177mr773020qtx.29.1704379235579; Thu, 04 Jan 2024 06:40:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704379235; cv=none; d=google.com; s=arc-20160816; b=ynEBJdd73QKRYTcycBroGybzVbVqP/6hCg8zf3PNuUyPur0Ak4j7g+ACppQOQ1/OUH mq0AhBF42rT18vwwXl/3MgWZNDwashxfq6rNaNEGlmwftTmZyK/bShu/zkwWpKsRLCyX Ggsf2f3ChhcOvfFYSTtQ7RSzMDHqop720VSIWw4UFLcy+6V2PtgosR2DmUaBS6WxbWHZ ELcKyv7A7no7gMkaOezoCkGikUOA4AvPFfUEdk0Swr8oxtU/6CT1gp8bM6j0DtoL3ejF KDZY3X6bZ3DRm93cf8z+buYRiojRwjuIiwInqx/zxoJHrSFAvywJaT7Wph/DbHrXkgYi 1CaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:references:message-id:subject:cc:to:from:date :dkim-signature; bh=0ArKA/a10ecvcp4EcwXKlK7K8Xf+GtzOe5tljW0dpjo=; fh=RpO+9gWLCgfZ8/MQT73kNyjGZ9NPZfbx6dRr8/rk3Os=; b=B9hGaxH7U/SGgRnq1ON32CZfFXLcMYdaYjW5+58fKNnLctafsLNt1YaYlhCqI1sYed Du46jPfwiMH6GeF2bjT6T9UhNmV3ZK38wys88qHTV114H1K9KDVN0FCnEWuusL6xNWV2 1ZMtZr7pilqcxBIBKacFxqvKNguVf7zsyaVnNjssTQxwBaXIfMXrIx2yLPRQb29mPobr lOlzCUf90fTnMe9wJTLOOnoI3iKb5MNDeE4RhACgOUHVPq1QmGwRMS72uYNwuUi95v98 xIh8qlB8feAb6zYed+vi5NcrJeV8J1VNaNQ+BLd+qQpdN9K4CQHLJnAm0GFmjNstlTxf /hLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CmMMliqp; spf=pass (google.com: domain of linux-kernel+bounces-16797-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16797-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id p19-20020a05622a00d300b004283d2aa003si2519137qtw.467.2024.01.04.06.40.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 06:40:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-16797-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CmMMliqp; spf=pass (google.com: domain of linux-kernel+bounces-16797-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16797-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 55D6E1C21E9E for ; Thu, 4 Jan 2024 14:40:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 100962374B; Thu, 4 Jan 2024 14:40:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CmMMliqp" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F09822F10; Thu, 4 Jan 2024 14:40:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0633AC433C7; Thu, 4 Jan 2024 14:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704379221; bh=mKB4DEZxIw57eKu739it6g3eVDl5U5ssEGaV5HTsHMo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CmMMliqpZQ3d3p5RkVIPwbQ8Unhh9n57IKcVI9zAgcZFqIqGa9h0Hu+55ZdK0D5nq wt6xrFMuRiHKv/RvSMSvDQFyGvXZxrodci/0xVv4XS49CDNeNLVxXvmY3QEZhQHayg daO/lorO4VIRrEm//7YzcjlSaAzPRU+1qK7nNO7IptjTby4G8GP/yybFjxN5CN3L7f UnTX0iHH4qx/J9L22NBgxcfDBVKYRDTZrnbVvl2NMekyRJ9x5bvZVHeLJFOd3DXFyH 1obF2vxG5o8SLmHhqrTE6QMA3pUGnaA2Jlw+hSvh1a+6tx0CfrWYTq2Qr1laOTlWAj mRjU16QNsUJqA== Date: Thu, 4 Jan 2024 14:40:13 +0000 From: Will Deacon To: Nadav Amit Cc: Jisheng Zhang , Aneesh Kumar K V , Andrew Morton , Nick Piggin , Peter Zijlstra , Catalin Marinas , Paul Walmsley , Palmer Dabbelt , Albert Ou , Arnd Bergmann , linux-arch@vger.kernel.org, linux-mm , linux-arm-kernel@lists.infradead.org, Linux Kernel Mailing List , linux-riscv@lists.infradead.org, Nadav Amit , Andrea Arcangeli , Andy Lutomirski , Dave Hansen , Thomas Gleixner , Yu Zhao , the arch/x86 maintainers Subject: Re: [PATCH 1/2] mm/tlb: fix fullmm semantics Message-ID: <20240104144013.GA7179@willie-the-truck> References: <20231228084642.1765-1-jszhang@kernel.org> <20231228084642.1765-2-jszhang@kernel.org> <204B6410-2EFA-462B-9DF7-64CC5F1D3AD2@broadcom.com> <0468E994-273E-4A8B-A521-150723DA9774@broadcom.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0468E994-273E-4A8B-A521-150723DA9774@broadcom.com> User-Agent: Mutt/1.10.1 (2018-07-13) On Thu, Jan 04, 2024 at 03:26:43PM +0200, Nadav Amit wrote: > > > > On Jan 2, 2024, at 4:41 AM, Jisheng Zhang wrote: > > > > On Sat, Dec 30, 2023 at 11:54:02AM +0200, Nadav Amit wrote: > > > >> > >> My knowledge of arm64 is a bit limited, but the code does not seem > >> to match the comment, so if it is correct (which I strongly doubt), > >> the comment should be updated. > > > > will do if the above change is accepted by arm64 > > Jisheng, I expected somebody with arm64 knowledge to point it out, and > maybe I am wrong, but I really don’t understand something about the > correctness, if you can please explain. > > In the following code: > > --- a/arch/arm64/include/asm/tlb.h > +++ b/arch/arm64/include/asm/tlb.h > @@ -62,7 +62,10 @@ static inline void tlb_flush(struct mmu_gather *tlb) > * invalidating the walk-cache, since the ASID allocator won't > * reallocate our ASID without invalidating the entire TLB. > */ > - if (tlb->fullmm) { > + if (tlb->fullmm) > + return; > > You skip flush if fullmm is on. But if page-tables are freed, you may > want to flush immediately and not wait for ASID to be freed to avoid > speculative page walks; these walks at least on x86 caused a mess. > > No? I think Catalin made the same observation here: https://lore.kernel.org/r/ZZWh4c3ZUtadFqD1@arm.com and it does indeed look broken. Will