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 2C1F8439329 for ; Wed, 8 Jul 2026 15:28:01 +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=1783524483; cv=none; b=XO87UkXZTJ95KYgBRrSN6Zr/uWI71s4azoQme2m7AW9LtlhlAZBd2dJU6tcOr2ocO83nMuDFuEZb/bQ8EWXkYyKmuAU2mcLnlH6cOxQ89hVIhyXxTfFU/moax4Vr4CqpSG8cJ5uqI8VkDKdb3MxIxOjPEVbG30ClY00YjVGVr3A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783524483; c=relaxed/simple; bh=E0EpEwo5U/H4KP0Po388i5gA/GVuJuzm9ZZhlZW19k4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VqbrF2/QD+rK/4nMaJiSD7MS8SPc0IibX4kC1WKXusjqfrNPB5kD5IHQFtqC2B1hzfM3AsSWXWvi6K/sB9qbwe6fTIgWxocQIM8jjfLQm7aatfsOMaXeUjeT8HZR1sf5b1FQXdqbGIMrVxuqZcWH6nimXvPhjdIcm60abg+QvJM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=ZV16tox9; 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=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="ZV16tox9" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6yDhDVnrCfaKrQ+22sMmiFchSJXBq2Qz61OjYkcPCas=; b=ZV16tox9VfwCYdfCoIRgWy8lLR Y8jsqsPc/j7QzZLkxZR5FgjpPm8rzoeaooBKQxLf+3zwqLcZkvweqcCKVoqTJ8Bv+HtLYhQ3rYVTE syCd0iXodzxTNKnZGklC0jrp+SDEQqCLrvv2N3d0pdPOsLgRSxSVdgB1QofeqadBCG8H2lFt6aLp6 cv+zIdLbcbqXj0jUr6vC7FjdnuW8FiadBo7TmHVffSmjBHCdewGTElmrYpeRnOxFwhLdsxnel59ah KrE5ArwRJlKTtcqMx0P1Xvgs3MKQxloZ/4Nc706C1kKIjAU+QLLXX978WwZv09OxsAypw5U0KEhtb 4K0uy2ew==; Received: from [2601:18c:8180:83cc:5a47:caff:fe78:8708] (helo=fangorn) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1whUBF-000000002qJ-3U6L; Wed, 08 Jul 2026 11:27:21 -0400 Date: Wed, 8 Jul 2026 11:27:18 -0400 From: Rik van Riel To: Matt Fleming Cc: Henrik =?UTF-8?B?QsO2dmluZw==?= , dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org, Sebastian Ullrich , Joscha Mennicken , kernel-team@cloudflare.com, Tom Lendacky , Borislav Petkov , David.Kaplan@amd.com, kernel-team@meta.com, Ingo Molnar Subject: Re: PROBLEM: Probabilistic segfault on AMD hardware with INVLPGB Message-ID: <20260708112718.13323f59@fangorn> In-Reply-To: References: <9363eca429424d967052bc401d4d835f1e6d2716.camel@surriel.com> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.49; x86_64-redhat-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 7 Jul 2026 13:18:30 +0100 Matt Fleming wrote: > Hi Rik and Henrik, > > I've got a small C reproducer that triggers this within the first round > on Cloudflare's AMD Turin machines: > > https://gist.github.com/mfleming/ca26ad3f8d65a12d23d62fb176480fc1 > > Build: > > gcc -O2 -Wall -Wextra -pthread -static -o repro-invlpgb repro-invlpgb.c > > Run: > > ./repro-invlpgb --batch --rounds 20 --jobs 32 -d 5 -w 8 -m 2 -s 512 -q > > The mutator side holds a pthread rwlock write lock while doing > munmap() + mmap(MAP_FIXED) on the same VA and filling the range with > {cookie, slot, generation, offset} markers. Reader threads hold the read > lock while checking those markers. > > The failure mode is usually a CORRUPTION line rather than a direct > SIGSEGV: a read from one virtual offset returns a valid marker for a > different offset. That looks consistent with a stale or wrong translation > after VA reuse. I poked at the reproducer yesterday, and it seems like the pages in the buffer get reversed between uses, so in one pass they will be ABCDEFGH while the next run they'll be HGFEDCBA. This showed up in the observed corruption pattern, where the second slot in run N+1 would see the data from the second to last slot in run N, etc. All the observed corruptions end up seeing data from the last run, from the flipped location (Nth slot, where the page used to be in the Nth-from-last slot). The change below seems to close off the race in practice with this reproducer, but since I do not know what really goes on inside the CPU, there are likely better ways to fix it. AMD friends, do we need to gather any additional data for the hardware and/or firmware people to take a look at this, or is there anything else needed? diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h index 866ea78ba156..2d30426f9183 100644 --- a/arch/x86/include/asm/tlb.h +++ b/arch/x86/include/asm/tlb.h @@ -110,6 +110,13 @@ static inline void __tlbsync(void) /* TLBSYNC: supported in binutils >= 0.36. */ asm volatile(".byte 0x0f, 0x01, 0xff" ::: "memory"); + + /* + * TLBSYNC: we should not have to do this, but it seems to + * mitigate the stale TLB visibility issue reported by + * https://lore.kernel.org/lkml/CAAuFnRTyva1_3tsF3vrMBL+TLS1YL4EgUPT2c3O9k7A9hWUMnA@mail.gmail.com/ + */ + asm volatile(".byte 0x0f, 0x01, 0xff" ::: "memory"); } #else /* Some compilers (I'm looking at you clang!) simply can't do DCE */