From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C723BC4828F for ; Fri, 2 Feb 2024 22:22:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33FFD6B00AA; Fri, 2 Feb 2024 17:22:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EF4C6B00AF; Fri, 2 Feb 2024 17:22:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B6F86B00B0; Fri, 2 Feb 2024 17:22:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0C0346B00AA for ; Fri, 2 Feb 2024 17:22:51 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BCB001A105F for ; Fri, 2 Feb 2024 22:22:50 +0000 (UTC) X-FDA: 81748289700.24.C9BF294 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf10.hostedemail.com (Postfix) with ESMTP id 92330C000C for ; Fri, 2 Feb 2024 22:22:48 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=jFDFX3UJ; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf10.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706912569; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sNyqIbKGi0aGVOVLD44ssIoLe6QNqeVe9459dcb6Bvo=; b=KJBNlw9GdqTnmYYvXlDLzYojO8IxfzixQa1USbPaTLdQ5NjwkvKhFERH8PRTNc2o3QiUYK XxogtVsK7oXWJT34xf1iUPZF8HoUZak3ZiVF3qXAPmiAUSqf0QCwp5jGySSKdr5Hi7z4o1 CKexx4Ay4Ur/B3nnoClVSc0+0Y9N4Bg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=jFDFX3UJ; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf10.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706912569; a=rsa-sha256; cv=none; b=5Y8nJHzsstN5q4fmze5JD7P3ncM4Kdl7tVB6gpdemidm7ledIMQSzrA4GC+FBmN4uS41bd unYSi5vxuvMtwMsCVsDSGO9Qq6UeaXqDSk3OI7sqq42WkVtbDpdvQANvt2OXD81EUoAOtY co1Oe6nY/ESykj91YdApqlaaF/chkLQ= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id B031B40E01A9; Fri, 2 Feb 2024 22:22:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4ZSY74Yz66Xt; Fri, 2 Feb 2024 22:22:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1706912562; bh=sNyqIbKGi0aGVOVLD44ssIoLe6QNqeVe9459dcb6Bvo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jFDFX3UJ3LdDOh3U9RxCfy+dLlli8OwkPJl6vDX+UDne+orVAQ2kB/SsYbVG0l+CH iuM3/2vkYvZJjy4BUuriq1obO1sW2lDqM/wHIMxtdPdPhZyd5NIySH7J5FRIoAnUOi 3fTdZBufBCgpT7V4zin4UVfiHBKpak6dUTTWgL0VT1dqRTTbYEvXcWlWW4dXoHDuko PUBhNg8KfqZJ8Z/PAZtZQkWwEbPPE0g+ZZDtbfOgpFsZgx/tY9rd3oC7F4wA5tymuP Alsw8hkdgkmOCE2BU+TV5ZxhvO7Wm42+4zxg62zmBDE7FUaPoVhBjE7LwGOHh1Weq8 rTX/TlZUsQOtJFZkdQrAkGp6MXNQUpshH8ZBUHjDGiNy4gCiUl2Ij11bIi71a5MpCh RP3kFmYrJS7ECjhILLBivwgh/fhJOfqqyFVG4A7lzUR8+HGDvK5gck2/UhBY83YSYu 6hIrqOeGmOHZ7bRoF1BvxBp8ODlzW+0O3Sh8rEslLATqbJlpNE0N83b5Cmxls2a0Ko 2xsjfW+p85wOQI0ZalJsCsj6r1wkZe0nsPzn90nrC3FCvlFTvqYhsn21vnAv88YV4T 5W0eM2fSxn++NnQyQ110Kg1fzh1orPW2Gf76lfBpTq/sFx/jB+iGZrjapP7fRiJOaX 6r9jrEyyWrMFnpjA0sf7xu7c= Received: from zn.tnic (pd953021b.dip0.t-ipconnect.de [217.83.2.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1080040E00C5; Fri, 2 Feb 2024 22:22:26 +0000 (UTC) Date: Fri, 2 Feb 2024 23:22:20 +0100 From: Borislav Petkov To: "Luck, Tony" Cc: Tong Tiangen , Thomas Gleixner , Ingo Molnar , "wangkefeng.wang@huawei.com" , Dave Hansen , "x86@kernel.org" , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Andrew Morton , Naoya Horiguchi , "linux-kernel@vger.kernel.org" , "linux-edac@vger.kernel.org" , "linux-mm@kvack.org" , Guohanjun 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> <20240202194257.GFZb1FwcPPO8WXF86H@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 92330C000C X-Stat-Signature: u1cydjtruruw641wjzkmaxzmdrxik61y X-Rspam-User: X-HE-Tag: 1706912568-802104 X-HE-Meta: U2FsdGVkX1+MDh9dOftmbLTiILX5OWrFKHbvtzXjkKrv2AOFNPyZsvDTg0CTatVFoDfJpHgVY+svyLeWcAu9sHa7KV7Ay72eRPzNacSvxXQIvbHqGiO2IDuEHUHST/7OJUzm23w9fSYt2yKhW7btjUENelkcJqt3xB7uEYRK0AM0Klx5palPI8GlDIRFxIOR7zaZL6lvpSHi8gruFkKBYaXAWE5Hx4UZIPXz1nr8JGGd/OZO3mfsg/k/eyAltqh6Ypuk/76F93+Wnj93w2t8wgEBeqQ6btavh3CBPFXJJlnMF0Zg/1yjYNpmdvTewc6gUGFCb5yBIJn0duhQISLdvErtO7lh/FlwDAD0VtI9eEB1UhctP/TBUXh8yr0pz2inQhKmCqe9csZuakr7uL4xPApuLEZvT3U5PNRq4z78DiMLHyKnvwCb/3kQs6DtsO4FwUob+Ndo0foht1HGyfwn/TzxNMKlY8XmB7Orfglcy3fh86lDAriQDcjGHaZlhOV6TM5oxrKGAS8z2XXTsz5bqipMqiE6Zos8crhTcnr4RlkKoCi6UKTcQQx049Scpo/zcYurnbYarUG2FIo7+nYENf4DUvQCyL51a0ijwUAGYxkUycBaZaGbFXihmhVMOWAG+vnTi5Ii3pqqsWL2NdTwFEUU552jeQ7t/z3rBfeT6vuqs407IfciqhiFCg49TxMsE4fn7NWmBnAMNQyqD6PKmC+yOetd2v5R7QQBUajzTi20ze792zEy3c8z/nQ6vTDInph/N0t10dHghSyyuu3wnJGz8g3wZRrGk4Sb7lK7NsoDjvMd45ohmWmgHXpJEcb/PvDujghcRhtISM5EBq8VGFUd3RySGkh2XmswvYlmaOeri0DoaTwvKoqVlSUKQv+tI8reZsqNJcZnjMQN8C7RrlEnmvX2DmX8Gihn3XqTlfovye/hQ7wdRNwmdHstPQennt1oRC4dOtifTWUr+gC 0iqK0pPw eIASxB6Hm24WuwEyWPIc9EQNYTQBsT34VwDUORdcWH6cNu2WWZczZ8rS9DPssqgr4d3jSeLxpbZmrbH84ZCunA90Ymv2zI8hise6MZfckTIEiU0cHeyssLS6NvuFrUZ1LgxxYkw1s+YeuXsbgcNoP8JwYdg0nXD2O/IrySKcX4pxQWSTzSXthXxJkG4wq2CEn7GoPD7FQjsF4dvdbheTr/79dfI8VtBiNo4+bqZA/yHqYMd+evRzWOq//iqYu0V9ogRF/DPaJl1jEV7raOZSZClVhNCF+pxcNU/tw X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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