Received-SPF: pass (google.com: domain of linux-kernel+bounces-50657-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Fri, 2 Feb 2024 23:22:20 +0100
From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Tong Tiangen <tongtiangen@huawei.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	"wangkefeng.wang@huawei.com" <wangkefeng.wang@huawei.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Guohanjun <guohanjun@huawei.com>
Subject: Re: [PATCH -next v4 2/3] x86/mce: rename MCE_IN_KERNEL_COPYIN to
 MCE_IN_KERNEL_COPY_MC
Message-ID: <20240202222220.GIZb1rHG3NiZKmdRXu@fat_crate.local>
References: <20240111135548.3207437-1-tongtiangen@huawei.com>
 <20240111135548.3207437-3-tongtiangen@huawei.com>
 <20240131070258.GGZbnwov0g918F-FGz@fat_crate.local>
 <3009aadd-69d6-c797-20b4-95cf926b6dd9@huawei.com>
 <20240201142016.GFZbuooG9CRoK90U2C@fat_crate.local>
 <39c1e4d2-b1d0-91ae-595e-1add4698dd7f@huawei.com>
 <20240202133911.GBZbzwf-M37M-J3EJX@fat_crate.local>
 <SJ1PR11MB6083A60DE19FBFB1B0CA6B3DFC422@SJ1PR11MB6083.namprd11.prod.outlook.com>
 <20240202194257.GFZb1FwcPPO8WXF86H@fat_crate.local>
 <SJ1PR11MB6083BDC3A0596FA87BC25259FC422@SJ1PR11MB6083.namprd11.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <SJ1PR11MB6083BDC3A0596FA87BC25259FC422@SJ1PR11MB6083.namprd11.prod.outlook.com>

On Fri, Feb 02, 2024 at 09:36:27PM +0000, Luck, Tony wrote:
> There are two places in the pipeline where poison is significant.
> 
> 1) When the memory controller gets a request to fetch some data. If the ECC
> check on the bits returned from the DIMMs the memory controller will log
> a "UCNA" signature error to a machine check bank for the memory channel
> where the DIMMs live. If CMCI is enabled for that bank, then a CMCI is
> sent to all logical CPUs that are in the scope of that bank (generally a
> CPU socket). The data is marked with a POISON signature and passed
> to the entity that requested it. Caches support this POISON signature
> and preserve it as data is moved between caches, or written back to
> memory. This may have been a prefetch or a speculative read. In these
> cases there won't be a machine check. Linux uc_decode_notifier() will
> try to offline pages when it sees UCNA signatures.

Yap, deferred errors.

> 2) When a CPU core tries to retire an instruction that consumes poison
> data, or needs to retire a poisoned instruction. These log an SRAR signature
> into a core scoped bank (on most Xeons to date bank 0 for poisoned instructions,
> bank 1 for poisoned data consumption). Then they signal a machine check.

And that is the #MC on a poison data load thing. FWIW, the other vendor
does it very similarly.

> Partial cacheline stores to data marked as POISON in the cache maintain
> the poison status. Full cacheline writes (certainly with MOVDIR64B instruction,
> possibly with some AVX512 instructions) can clear the POISON status (since
> you have all new data). A sequence of partial cache line stores that overwrite
> all data in a cache line will NOT clear the POISON status.

That's interesting - partial stores don't clear poison data.

> Nothing is logged or signaled when updating data in the cache.

Ok, no #MC on writing to poisoned cachelines.

Ok, so long story short, #MC only on loads. Good.

Now, since you're explaining things today :) pls explain to me what this
patchset is all about? You having reviewed patch 3 and all?

Why is this pattern:

	if (copy_mc_user_highpage(dst, src, addr, vma)) {
		memory_failure_queue(page_to_pfn(src), 0);

not good anymore?

Or is the goal here to poison straight from the #MC handler and not
waste time and potentially get another #MC while memory_failure_queue()
on the source address is done?

Or something completely different?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette