From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 455161C860C for ; Wed, 15 Oct 2025 18:36:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760553410; cv=none; b=FIGY3kq4X5nH10NREL4P+dy1iWbGM0XX6cAoPLw1BgVykwxuUD6hmbSK6NuSUVUn05HzvZ1pwX7UI7tyw9h4c/K5wRxOQ8Bj2uaqoltEINI7EFelCAU6pEfKRRa8tae99cOLBTDKZk5yAM36gQSDqstwJCGQ5I0Mn9to9GnbH+I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760553410; c=relaxed/simple; bh=+ewbUy3AHFgUEwycvkbHsOaDseVTEdJWwpTlP6Kuyo4=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=fQG67D3hJy8dCzxu6mxshuw+srPEfq+i1HxeFsi38Jh8pUsRj6icU5vdl8O6LPjmwhCvO8Qb06PYLD3urUxIqo2aSIbrR1QdnjopUi4ZU2Df+q7+RAFSSrOUXBpBAKh8Hr/WD4P8PtYJCfSXwqA7MlmIpx5tAIXZgcdGJfv/mHw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--wyihan.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Uxi7iJ+L; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--wyihan.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Uxi7iJ+L" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-7810e5a22f3so19616794b3a.1 for ; Wed, 15 Oct 2025 11:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1760553408; x=1761158208; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=0ilCg17JQ++to0ldYWXPZYiNCoMtQnD6yTXTJa/H8UI=; b=Uxi7iJ+L0bDVYVPbcCV1xpE/EceJ1lIFMIHhTkZE9eLlmRzDJqf/RYYA8GRpayeow9 z0uCq46Sgy9KTWIwJgUNYoCjDFI1aB96uLOfMiQdbCPMlZaZQKnZ0YNuLLSryy7XdOLk J6fuU90u8snSA1hKOwyYOo+dyuRtTYGgTGBsPSaqt32SgzhssiROZ22icUXhmm3IwHg4 yaW5KD8ruKwtt1807mbWsbiuvQw+3WPTMVMJ3ev9HmxUQWb5GP92yrGtqHmC2Zx1Gng5 i3t7Q4gm+XRrSyiHXoahJJ/f+d8sucbrP+oC7gGyCFgi/VIjAD3LfQAXRhXmz6+7FSxE VR6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760553408; x=1761158208; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0ilCg17JQ++to0ldYWXPZYiNCoMtQnD6yTXTJa/H8UI=; b=JOPGkgEyuTk6+vfrnFYiETW2aqa6//IGnVpvVbISZUQ1bptNyFPqHj2diP6RaEG5pg BHgcJWYXFXRgekqrRCoI3ufb4TbPvRHm/4q065czDgps5g0l3aL2qZR2EnswzMNael7l 7MUddl4jALWwfpX/kX3x3KWBUmMIXcmnR8LKelIFKd6fSbp1vRN+HQsNxPDsBYicTKvK 6mz9wvb4/3Eg7FMa4jKP93Aq2Tt+D+wXNbcIB1YkP59914XG/uxJOnaNFWxmSoEGe/ou AnZtjoqnEPsRc8twSIaJlJPXwDlEK05JJjqmsLyf1f34kNPEDywNNNFqPQYegvoiGujR Rxxg== X-Forwarded-Encrypted: i=1; AJvYcCVaU1zodY7xnVgL64qned3o66ZjPYFd3cYc4WjAzsDWwQzo9RXQd7Zaqt5ksHKhUpwEpaZdv3melHDvun8=@vger.kernel.org X-Gm-Message-State: AOJu0Yyserg5ffm+gS0GBJEeesZH1PJaNx3wjePWnI0XBILhYc6fM+NW +sT7aCrHoOLdqKm0xfZ8dgX6Q4mL034V8kgtSZBUQMU262cX649TPwhie7uRdMUdDhhfOEj8b/B CQA9+pw== X-Google-Smtp-Source: AGHT+IH8PPaE3dBlYhL9Cayq48vHN7MW+dNQWzXLTzpeemhgXmBd6s/PSaBxdBzVpqnpNlS0tiwU3TI6UZk= X-Received: from pfbbe19.prod.google.com ([2002:a05:6a00:1f13:b0:77f:6432:dc09]) (user=wyihan job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2e13:b0:781:1771:c12c with SMTP id d2e1a72fcca58-7938269d8b7mr36969858b3a.0.1760553408537; Wed, 15 Oct 2025 11:36:48 -0700 (PDT) Date: Wed, 15 Oct 2025 18:35:51 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.51.0.788.g6d19910ace-goog Message-ID: Subject: [RFC PATCH 0/3] mm: Fix MF_DELAYED handling on memory failure From: Lisa Wang To: linmiaohe@huawei.com, nao.horiguchi@gmail.com, akpm@linux-foundation.org, pbonzini@redhat.com, shuah@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.or, linux-kselftest@vger.kernel.org Cc: david@redhat.com, rientjes@google.com, seanjc@google.com, ackerleytng@google.com, vannapurve@google.com, michael.roth@amd.com, jiaqiyan@google.com, tabba@google.com, dave.hansen@linux.intel.com, Lisa Wang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, This patch series addresses an issue in the memory failure handling path where MF_DELAYED is incorrectly treated as an error. This issue was revealed because guest_memfd=E2=80=99s .error_remove_folio() callback retur= ns MF_DELAYED. Currently, when the .error_remove_folio() callback for guest_memfd returns MF_DELAYED, there are a few issues. 1. truncate_error_folio() maps this to MF_FAILED. This causes memory_failure() to return -EBUSY, which unconditionally triggers a SIGBUS. The process=E2=80=99 configured memory corruption kill policy is= ignored - even if PR_MCE_KILL_LATE is set, the process will still get a SIGBUS on deferred memory failures. 2. =E2=80=9CFailed to punch page=E2=80=9D is printed, even though MF_DELAYE= D indicates that it was intentionally not punched. The first patch corrects this by updating truncate_error_folio() to propagate MF_DELAYED to its caller. This allows memory_failure() to return 0, indicating success, and lets the delayed handling proceed as designed. This patch also updates me_pagecache_clean() to account for the folio's refcount, which remains elevated during delayed handling, aligning its logic with me_swapcache_dirty(). The subsequent two patches add KVM selftests to validate the fix and the expected behavior of guest_memfd memory failure: The first test patch verifies that memory_failure() now returns 0 in the delayed case and confirms that SIGBUS signaling logic remains correct for other scenarios (e.g., madvise injection or PR_MCE_KILL_EARLY). The second test patch confirms that after a memory failure, the poisoned page is correctly unmapped from the KVM guest's stage 2 page tables and that a subsequent access by the guest correctly notifies the userspace VMM with EHWPOISON. This patch series is built upon kvm/next. In addition, to align with the change of INIT_SHARED and to use the macro wrapper in guest_memfd selftests, we put these patches behind Sean=E2=80=99s patches [1]. For ease of testing, this series is also available, stitched together, at https://github.com/googleprodkernel/linux-cc/tree/memory-failure-mf-delayed= -fix-rfc-v1=20 [1]: https://lore.kernel.org/all/20251003232606.4070510-1-seanjc@google.com= /T/ Thank you, Lisa Wang (3): mm: memory_failure: Fix MF_DELAYED handling on truncation during failure KVM: selftests: Add memory failure tests in guest_memfd_test KVM: selftests: Test guest_memfd behavior with respect to stage 2 page tables mm/memory-failure.c | 24 +- .../testing/selftests/kvm/guest_memfd_test.c | 233 ++++++++++++++++++ 2 files changed, 248 insertions(+), 9 deletions(-) --=20 2.51.0.788.g6d19910ace-goog From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE45D303A1A for ; Wed, 15 Oct 2025 19:00:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760554818; cv=none; b=coccpHUX28PMCvrLKs0uqNWgD8k5X9OgHeEpF9QrRUb1+3DyyxfR0hYBrErOiaIDfrjsZ3ttx3fUXZclWgjME0GJvag2/AOkTc0sa2CygoSX51MYVnWirewdZWd//0uMrYNv/zkhbTJRVJU/ZfnUxAZWUjRZbL7WGUFdRth/5JA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760554818; c=relaxed/simple; bh=sdq4ws5usmc98rsRoCAVeqpBx+16F1AHykhqmbfPX2w=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=MApzNqt4MIw6Wl+BBMF4tFhPEWpWyF5dhZoTR+HMqmHF6IcydBf2F/jQdlmVuLVGzA0fnHKFfXi1HYX4CVa/uGQNa0KQlKeR8E9e2VNFqrqOCPq+TCZRik+T+3pK13mmElubYEWdctsyDCia2QuYOkHyTmtV0VVQu0a7EgeFF+g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--wyihan.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=1sTXEtr7; arc=none smtp.client-ip=209.85.214.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--wyihan.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="1sTXEtr7" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-277f0ea6fc6so234491945ad.2 for ; Wed, 15 Oct 2025 12:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1760554812; x=1761159612; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=cqsd/vPXiuTR4hJNd2SCH3oN5KwWIK1dnn9ppreK3H0=; b=1sTXEtr7vUkiMkQ0uHR08smc/iooqnEyjuY+W9wks1tsBYPA+m+6Lx3ca4hy/SZyFb ATnMlJ/BVgpcUNTguAiYaD2KfbD+ZoRU7aK7GynqE2O8C4WqZMrYMbStaxnLY5qxSnW1 d4cf29GXLL2X/IDonSpO9lJJrONMW/YtyY7o2p93jbzit+lFQfvuSqgmvpi5TXaMcB7T F7oX8KU0xjEItAtgkTT5DkGRKI2ONtD33MMGl2NqQ4EIL74n8F4SZkw6OgAA/uKVwURn yUotVHDKCLff4DHp2OJ/3H5zbQIBi9bHAKBQZPU8e7fC1L1Q+ZcwDZkp3M1UIJ658puv ymOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760554812; x=1761159612; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cqsd/vPXiuTR4hJNd2SCH3oN5KwWIK1dnn9ppreK3H0=; b=T95yXEQIchTxLfQ+OoTNsM4g2VQ0iHALucO5Epce5o87abJEhJsXf+qOlpZJH1GYsy TD9UOIL57yQSp1BoEmB7l4MTxf/8ElJohU6xqSvgfeyERdoNpg/64+Po3XBZ99BPpmR0 OSK4eurEfCWgSYje4RRbAUlsNgy0tTONaI7f6RLS9ky0J7KUlYU58/k7MytEOPinQRBp Gbj6LrCnd3/GgoAdOxlWZFJQkBxwlqWH1rDjjriD9GrE1dUsSWozBUCaJV2bfeKB2X2O 0WfWkcQuKWkT3eGojM3iQq/JRA/u4DZ3wuOIprIFx3rCYmrQHtD8y24KFiWJRM+tbsFa OeCg== X-Forwarded-Encrypted: i=1; AJvYcCVtQGxF/PXZgJxvo2VKWgTeqV7FbFT0F6tOcYFLO/X9WYZUrduegTwysiI0yF1gPtsvnHjf904P3MDNiUU=@vger.kernel.org X-Gm-Message-State: AOJu0YwJ/MOTjrzzUem6p634CWIisEUimTIeXds4LaHAEpLWjfrYyl53 VzKZVFvA6ULHd4JETy9ynS3HiSPBk2pFae1nZF6IGruydxDXA0FjExqLzrTtMCNPkeO0KeFtaGN NbY9ccg== X-Google-Smtp-Source: AGHT+IFnNgFHzdVwVBgjv1vYxeJtKWTDydfUHZWWQm4sogrJBUuU/RaThVnJNJ/l8yi1LMJs0OC3cJqUm/M= X-Received: from plhy4.prod.google.com ([2002:a17:902:d644:b0:290:9abe:4419]) (user=wyihan job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ec81:b0:290:6b30:fa8 with SMTP id d9443c01a7336-2906b301097mr149049165ad.23.1760554811768; Wed, 15 Oct 2025 12:00:11 -0700 (PDT) Date: Wed, 15 Oct 2025 18:58:54 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.51.0.788.g6d19910ace-goog Message-ID: Subject: [RFC PATCH RESEND 0/3] mm: Fix MF_DELAYED handling on memory failure From: Lisa Wang To: linmiaohe@huawei.com, nao.horiguchi@gmail.com, akpm@linux-foundation.org, pbonzini@redhat.com, shuah@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: david@redhat.com, rientjes@google.com, seanjc@google.com, ackerleytng@google.com, vannapurve@google.com, michael.roth@amd.com, jiaqiyan@google.com, tabba@google.com, dave.hansen@linux.intel.com, Lisa Wang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID: <20251015185854.2-aI27LAkTVMyur38HRG8upvGWn-Kt49TfM8wHIRH9s@z> [resend to correct the mailing list address] Hello, This patch series addresses an issue in the memory failure handling path where MF_DELAYED is incorrectly treated as an error. This issue was revealed because guest_memfd=E2=80=99s .error_remove_folio() callback retur= ns MF_DELAYED. Currently, when the .error_remove_folio() callback for guest_memfd returns MF_DELAYED, there are a few issues. 1. truncate_error_folio() maps this to MF_FAILED. This causes memory_failure() to return -EBUSY, which unconditionally triggers a SIGBUS. The process=E2=80=99 configured memory corruption kill policy is= ignored - even if PR_MCE_KILL_LATE is set, the process will still get a SIGBUS on deferred memory failures. 2. =E2=80=9CFailed to punch page=E2=80=9D is printed, even though MF_DELAYE= D indicates that it was intentionally not punched. The first patch corrects this by updating truncate_error_folio() to propagate MF_DELAYED to its caller. This allows memory_failure() to return 0, indicating success, and lets the delayed handling proceed as designed. This patch also updates me_pagecache_clean() to account for the folio's refcount, which remains elevated during delayed handling, aligning its logic with me_swapcache_dirty(). The subsequent two patches add KVM selftests to validate the fix and the expected behavior of guest_memfd memory failure: The first test patch verifies that memory_failure() now returns 0 in the delayed case and confirms that SIGBUS signaling logic remains correct for other scenarios (e.g., madvise injection or PR_MCE_KILL_EARLY). The second test patch confirms that after a memory failure, the poisoned page is correctly unmapped from the KVM guest's stage 2 page tables and that a subsequent access by the guest correctly notifies the userspace VMM with EHWPOISON. This patch series is built upon kvm/next. In addition, to align with the change of INIT_SHARED and to use the macro wrapper in guest_memfd selftests, we put these patches behind Sean=E2=80=99s patches [1]. For ease of testing, this series is also available, stitched together, at https://github.com/googleprodkernel/linux-cc/tree/memory-failure-mf-delayed= -fix-rfc-v1=20 [1]: https://lore.kernel.org/all/20251003232606.4070510-1-seanjc@google.com= /T/ Thank you, Lisa Wang (3): mm: memory_failure: Fix MF_DELAYED handling on truncation during failure KVM: selftests: Add memory failure tests in guest_memfd_test KVM: selftests: Test guest_memfd behavior with respect to stage 2 page tables mm/memory-failure.c | 24 +- .../testing/selftests/kvm/guest_memfd_test.c | 233 ++++++++++++++++++ 2 files changed, 248 insertions(+), 9 deletions(-) --=20 2.51.0.788.g6d19910ace-goog