From mboxrd@z Thu Jan 1 00:00:00 1970 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 67A7F22424C for ; Tue, 17 Feb 2026 15:20:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771341604; cv=none; b=H/XhgIATg1r5pygK+qfqaGfo0kY0X/4SqbXlQUx76JrwqOvB2wKW7ovBFGz64xAfXDHbQY5/NF6uD30sAdm4fOuebjg2t+3upMbrSKH9K13SUo6PfbAlCiq1b9aYtVlD2ExWZnqMV5sXM0o3+f0Tj5/8y+zcYTYaVR3NHbM+ej8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771341604; c=relaxed/simple; bh=jrc6cvtYdF6nHdbdgBeNW1xB29vujuKdqeUn7m5GHGQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Bxz58g46ig8mvTpzxQ9aMwMExDTkU+jrQ8YdTk2HjQp+ExMiTQ1GrmCshkjbZxVf+V3vm4oZ9yxjHqSfWa5M74kN4g7s11OH4rp44YAwdMkP7FFGVVclkkQkLyj0yZJK2ig14/bEJqNFq1B7o4jmpFql7gh6ATVYwfj/R+akxKY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cFtUdreZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cFtUdreZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC7EEC4CEF7; Tue, 17 Feb 2026 15:20:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771341603; bh=jrc6cvtYdF6nHdbdgBeNW1xB29vujuKdqeUn7m5GHGQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cFtUdreZAsVkAgDgC0+TRZJunaFh4DUeDmFSdSlkEazyDMD9PsM8zBldbSW1dsS5I OZW0e0/8pMpexOwAGwu9vUClQtNINCAhtgu8OZPEJFGfyYZNW4KbHlBNDmve2pZj36 Ujo3eN4CiKCT4kHgfIdaeQcGct95Vp3YiIl3lBgdCt2jc1/bi8L5ws5cN3R0fzMP94 aRWESsQ6HILeLyplTe5GdgA2BYWGw9UZFL2G09t5FtgEELJm+Igpb2g9z5oEH0uVrG GLsQRKQqFDaNPgBnbb5phlh/tR6zD5JMGpM2vxZ/eknTmlHBKJABvVqN+cqv+XwSxF iB7+rsDkfHwFQ== Date: Tue, 17 Feb 2026 09:20:02 -0600 From: Seth Forshee To: Dave Hansen Cc: Stephen Dolan , Andy Lutomirski , Peter Zijlstra , linux-kernel@vger.kernel.org, Eric Hagberg , Nick Barnes Subject: Re: x86/mm: Finishing off the fix for a should_flush_tlb race Message-ID: References: <281e8018-5506-4a79-8775-e0de7e58b95f@intel.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=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Feb 17, 2026 at 09:12:43AM -0600, Seth Forshee wrote: > On Fri, Oct 10, 2025 at 01:45:45PM -0700, Dave Hansen wrote: > > On 10/9/25 07:01, Stephen Dolan wrote: > > > That way, either shootdown sees LOADED_MM_SWITCHING and sends an IPI, or > > > switch_mm_irqs_off sees the updated tlb_gen. The problem in both cases > > > is about the *before*-ness in switch_mm_irqs_off: > > > > > > - in the latest tree, there isn't enough fencing to enforce this > > > ordering. > > > > Stephen, thank you again for the stunningly great bug report! > > > > I'll plan to stick the upstream fix into our x86/urgent pile early next > > week. > > > > > - in the stable kernel trees (6.1, 6.6, 6.12), the code is in the > > > wrong order. > > > > This fix also makes sense to me. It's a bummer that the stable fixes are > > diverging, but I don't have a better idea. So: > > > > Acked-by: Dave Hansen > > > > It would be best if you could just submit that patch directly to the > > stable trees: > > > > https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst > > > > after the equivalent upstream fix lands (even though it is a different > > logical patch). > > I wanted to check on the status of the stable patches, since I see the > upstream fix went into 6.18 but there's still no fix in the 6.12 stable > tree. We've been seeing segfaults during a test case with 6.12, and > after bisecting we found that reverting both "x86/mm: Eliminate window > where TLB flushes may be inadvertently skipped" and "x86/mm/tlb: Only > trim the mm_cpumask once a second" seems to get rid of the segfaults. > I'll try to get some testing with the proposed stable patch today. Sorry, had something wrong in my mail config that messed up the From: address in the last email. Please reply to this addrees instead.