From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 51110139B for ; Sun, 12 Jan 2025 02:39:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736649593; cv=none; b=XC5vWUrU738iopOZqh8qnh7WFF9nBdE1FXBw4BTJr+f3vrFd700+HIuAXpcaK9IIvfc41iFNt9BgJ/KA9pVe07YY0ep6gIJ+x+qujzkciXterJ/mN1eeKGchopyuBNHuCLB8CAN4LxFEwBi2AvXbl/N++77NOi/xiDMG03crr6E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736649593; c=relaxed/simple; bh=w1/j+N7AbDszmqKo5YYAlvuxKZI52OsziPdgQ4hPWu0=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=p0x504Gu7LNm3NwT+rP59VeJQnXJzHNNFo6t7Umw47vrXCKTkwxRD2gLAhKMSF70B27f+2mb+QnBkn8HHGHXlzFX2VvatBi+xjoDxWKd4cFo6ImqEW5hYm74SKaj86ogqgkDzfE7eqOHOGyHuim07f4Zdr5LEjt0V8K6CANPDdc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=shelob.surriel.com; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shelob.surriel.com Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1tWnt4-000000000Xg-2nVa; Sat, 11 Jan 2025 21:39:38 -0500 Message-ID: <3ebac012ccc6da2ec700fa14e6193cbf5ca98951.camel@surriel.com> Subject: Re: [PATCH 12/12] x86/mm: only invalidate final translations with INVLPGB From: Rik van Riel To: Jann Horn Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org, nadav.amit@gmail.com, zhengqi.arch@bytedance.com, linux-mm@kvack.org Date: Sat, 11 Jan 2025 21:39:38 -0500 In-Reply-To: References: <20241230175550.4046587-1-riel@surriel.com> <20241230175550.4046587-13-riel@surriel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Sender: riel@surriel.com On Fri, 2025-01-03 at 19:40 +0100, Jann Horn wrote: > On Mon, Dec 30, 2024 at 6:53=E2=80=AFPM Rik van Riel > wrote: > >=20 > > +++ b/arch/x86/include/asm/invlpgb.h > > @@ -51,7 +51,7 @@ static inline void invlpgb_flush_user(unsigned > > long pcid, > > =C2=A0static inline void invlpgb_flush_user_nr(unsigned long pcid, > > unsigned long addr, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 int nr, bool pmd_stride) > > =C2=A0{ > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __invlpgb(0, pcid, addr, nr - 1, = pmd_stride, INVLPGB_PCID | > > INVLPGB_VA); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __invlpgb(0, pcid, addr, nr - 1, = pmd_stride, INVLPGB_PCID | > > INVLPGB_VA | INVLPGB_FINAL_ONLY); > > =C2=A0} >=20 > Please note this final-only behavior in a comment above the function > and/or rename the function to make this clear. >=20 > I think this currently interacts badly with pmdp_collapse_flush(), > which is used by retract_page_tables(). pmdp_collapse_flush() removes I've added a freed_tables argument to invlpgb_flush_user_nr_nosync > a PMD entry pointing to a page table with pmdp_huge_get_and_clear(), > then calls flush_tlb_range(), which on x86 calls flush_tlb_mm_range() > with the "freed_tables" parameter set to false. But that's really a > preexisting bug, not something introduced by your series. I've sent a > patch for that, see > < > https://lore.kernel.org/r/20250103-x86-collapse-flush-fix-v1-1-3c521856cf= a6@google.com > >. >=20 With your change, I believe the next version of my patch series should handle this case correctly, too. --=20 All Rights Reversed.