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 66364C021AD for ; Tue, 18 Feb 2025 13:08:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECCF028012D; Tue, 18 Feb 2025 08:08:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7D8728012B; Tue, 18 Feb 2025 08:08:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D93C428012D; Tue, 18 Feb 2025 08:08:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BBEDD28012B for ; Tue, 18 Feb 2025 08:08:35 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 16D4D81254 for ; Tue, 18 Feb 2025 13:08:35 +0000 (UTC) X-FDA: 83133094590.28.57F2DD7 Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) by imf17.hostedemail.com (Postfix) with ESMTP id 8DBF540017 for ; Tue, 18 Feb 2025 13:08:31 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=CwngyFzG; spf=pass (imf17.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.99 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739884113; a=rsa-sha256; cv=none; b=Cxw4kNCT69f+WvH6yo9tR7Rzo/yKrA9Iu1azDnPI3CYzYzKGheJlIlmokzmUONjd9gZ6jc wE4gEIawFEMWZnxgRaW851GSKV81yHLnttcr2vVHAFOwv2PX4/Lwe07SmYguG+352eJW9S XFfnvUEMe/BjtHG2LGbdXZR/QXI3md0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=CwngyFzG; spf=pass (imf17.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.99 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739884113; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TbbAJDp0lKjl1Ir7re/8wHjJPIfZzfK9AVrTv+4wnSo=; b=kaGkvFcni27o3MxDV8m+lwJtL/qCUP4khhP44zb36JgDbjMmIzD4EimJpj38wU6DclRHJO 6jm2OmfViejwN/dXwzc0zX+oN0szAGNT5gl06xYFkBJzrG3cGDqvEZH4byK+7D46QTj2De VkDqXj0xCTMFRLlcJoyGRc5yXzIh+hw= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1739884108; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=TbbAJDp0lKjl1Ir7re/8wHjJPIfZzfK9AVrTv+4wnSo=; b=CwngyFzGZD/aK1cItPbwB54I+KYwaDcPVwa0QVCteZ/M5bT2OHElEFJwPCvw4kJHMInH/TGBSALcKjRwmCHomGT0DZhHey2RT4bEIfDuX2SZMJ06w9BrrTymN1Lbmxnhwz3jEMlIwliIkwgU6Y2vABXuAewmIrBEsZ98XmVUgDg= Received: from 30.246.161.128(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0WPlu2WV_1739884106 cluster:ay36) by smtp.aliyun-inc.com; Tue, 18 Feb 2025 21:08:27 +0800 Message-ID: <02164ab7-c65b-4b2e-8686-5539bdcb8f43@linux.alibaba.com> Date: Tue, 18 Feb 2025 21:08:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/5] mm/hwpoison: Fix regressions in memory failure handling To: Borislav Petkov , tony.luck@intel.com Cc: nao.horiguchi@gmail.com, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, linmiaohe@huawei.com, akpm@linux-foundation.org, peterz@infradead.org, jpoimboe@kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, tianruidong@linux.alibaba.com References: <20250217063335.22257-1-xueshuai@linux.alibaba.com> <20250218082727.GCZ7REb7OG6NTAY-V-@fat_crate.local> <7393bcfb-fe94-4967-b664-f32da19ae5f9@linux.alibaba.com> <20250218122417.GHZ7R78fPm32jKYUlx@fat_crate.local> From: Shuai Xue In-Reply-To: <20250218122417.GHZ7R78fPm32jKYUlx@fat_crate.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: 8wo6u96pmk19haq8bo93w9bf1cm8wqw4 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8DBF540017 X-Rspam-User: X-HE-Tag: 1739884111-800682 X-HE-Meta: U2FsdGVkX1/D9+slm/COomJruIp4HlfQ+0WYhlLdl34T5m84A8JdsDmJMqK1re99P+sdTjClJYcS8lh/sZsdXeIgrHKCJ+O2RM+re2BMD4y57so+33YBkrQOQY4lMrbWC5cXZ45JGCV7pthmX+agJggD6Hx9KN9Sx3UpXgxJGPoR9kKdjpKc2zda0STHyktrf94kJzsraVcRKeZq0CS+tnRKJ2jpkKpjFgDy+CHoBcr1R0cFBhWzmKHq4Q8nuAecjv09BxkGz0eM6bOVzm/l/wddlnbXl0VGLmYWN6zvr9V/lVffArl2K9Ez3ET5kjYqh9cxEGb+Ecq+WifU7aSinMsN6EXxi+z7xPXxH5DWsf6kLCzwCUdB2/ULDzyh0vzJH75KQdxz6WdUx51qdAfIAXIwKcfzChHs8H4s57JtR1w1xh0NfoA2Y1rHi/OTlJmrRZa0fXy3RjOMuk7IyxEkpMFGdKHBOodxBTayxl5G8PcJewudRW8gL1M239ggIMFS8AG9fUXdgEtpW0HwS5VUk+JyoE/76XVnQbIeHUSkQOhMKFsgDyXvoETQOMB+VQ4LiPn9QfwEUQpDTz3mFQRZVeTN2GKmYFGVZZz8+FzogH2nK+wcUs7TrguM+hxgxqh+YknOUgXkMCLgmdFL6n02D4jU3eQkG/IERzNoaPdZ5KrNRXyZRx20Z1ODZFsWt2Dwu5a6JqZVm2+ivg89mYh1QpXkQooDGBtJOdaDaJQ1WTCiGyCsmmnU8hF19Xw92V8y6LutmL/pJyGblzjsCsgm67PQmgGSsBFU3HvMGjXd/sRbSsDp+f4t74nEgD9kA9SLoNzHxD5g8YOt7YK5f2ok1vvolvRTCd89SR+jg/EP3uXz8/FTSaVJd/C06wFp/zkBtsSeoMa5rij2P2UYh+gA1rASNbPWZvhT4gfYAsFOx8AdXHH6Xcp5OxwiE8He8owUiQVTInN3R13ht9URoe8 dPeNQvzu Htzl4riRxVpnieodnKm8ag4jlNnzFvqAEIovl4VIKQQqPEvWcaOfoP5L4SrhNxoCiGv3hcZrJ19TaRr+Fz1KJiPsilTIPw7HHXEblvjYsrGojw0UfVD/3EFeks6CKRrq0OADAIHwQH1K5Y8MtG3ZChQocVOII9TRTLVzko8xwe+JiTehx+P2xUmIiHNAKnnHUabLaszGHwYoySXEo7+MazRQwoCQTGPKwif01RZOkm2ucAuy7lttciiZ727j73nzu2/VsUEmvoazUHbLk9hiUiMx2qOvQefdsKT4SDVG3Ya+1mCpVX4J1/rK52yg4bu4jyawSqrL+In8Io1+RQt9KTkZEWvYMvchZ/blsWJ477AT6a8Ts7P6FDKWLwJy9khNFStw5K2gWQRz7Ihg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 在 2025/2/18 20:24, Borislav Petkov 写道: > On Tue, Feb 18, 2025 at 07:31:34PM +0800, Shuai Xue wrote: >> Kernel can recover from poison found while copying from user space. > > Where was that poison found? On user pages? So reading them consumes the > poison? Yes, the poison is found on user pages. Form commit log, the mechanism is added by Tony and suggested by you. https://lkml.kernel.org/r/20210818002942.1607544-3-tony.luck@intel.com > > So you're not really seeing real issues on real hw - you're using ras tools to > trigger those, correct? > > If so, what guarantees ras tools are doing the right thing? Ras-tools do it by three step: - alloc memory in userspace - inject two bit ECC error (uncorretable error) to the memory (by EINJ interface) - write the memory to a file fd ( by write(2) ) It's the same as with real issue. There's no magic to it. Doesn't AMD support it? > >> MCE check the fixup handler type to decide whether an in kernel #MC can be >> recovered. When EX_TYPE_UACCESS is found, > > Sounds like poison on user memory... Yes, sorry for confusion. > >> the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return >> a -EFAULT to user space. > >> For instr case: >> >> If a poison found while instruction fetching in user space, full recovery is >> possible. User process takes #PF, Linux allocates a new page and fills by >> reading from storage. >> >>> 3. What actually happens and why >> >> For copyin case: kernel panic since v5.17 >> >> Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable >> fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup >> type for copy-from-user operations, changing it from EX_TYPE_UACCESS to >> EX_TYPE_EFAULT_REG. > > What do futexes have to do with copying user memory? Return -EFAULT to userspace. > >> For instr case: user process is killed by a SIGBUS signal >> >> Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not >> recovered"") introduced a bug that kill_accessing_process() return -EHWPOISON >> for instr case, as result, kill_me_maybe() send a SIGBUS to user process. > > This makes my head hurt... a race between the CMCI reporting an uncorrected > error... why does the CMCI report uncorrected errors? This sounds like some > nasty confusion. > > And you've basically reused the format and wording of 046545a661af for your > commit message and makes staring at those a PITA. > > Tony, what's going on with that CMCI and SRAR race? > I try to answer why the CMCI reporting an uncorrected error. Tony, please correct me if I missed anyting. When core issue a memory to a memory controller finds a 2 bit ECC error, it will pass data with a poison flag through bus. 1. Home Agent logs UNCA error and signals CMCI ifenable. 2. Home Agent forwards data with poison indication bit set. 3. DCU detects the posion data, logs SRAR eror and triggers #MCE if recoverable. Thanks. Shuai