From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.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 A21243043D7 for ; Wed, 15 Oct 2025 19:00:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760554819; cv=none; b=Mc2ScNQ1zv5JX5kExIasKgaC82zxGg4fApvuJz1OQZK3BJdp9y0LLG8hbpBp7F1CJiugGgKenFKguNqND/vfaw+DzieAElUyLvDaY2x1eW4q+xQVJAZlG4Sp/xWPTg3J/wtEjohYON7MtxH8VpRBLYwTvXOzdUWhMXVqH6qF4bw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760554819; c=relaxed/simple; bh=sdq4ws5usmc98rsRoCAVeqpBx+16F1AHykhqmbfPX2w=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=MrWFc5yvDUWBzXH0KIR1ZRuWoev+CPn3kFxlmvyZZf9dC/hPOpDEb+FHfPvEGF2fZTVvMri9Hkb0StoWklKsvr72e80pn9TwL6ICrRc1CKx3xQm4y5REpxCedrIxxqN7hRyS/c0nu7Xd3r0ircn/kBSJroWBV0VuYsopUlRtPOw= 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.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="1sTXEtr7" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-277f0ea6fc6so234491935ad.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=u8FD/mKKat/Bz+ZwUh7zOnUtH6mBYaX4hhIv5Dw+BY1U4PuBNeY2mLN3wdjS6+5qVy +7+MAl2dEI5i1V/3X1qR/hcB1u/XZ2Oqqj2ZfdKUR/q/Pxug/hwrOHTsMElYrrbiDSQC 2w8OSZHlc3Zr4uZteHpTvy542GKxn4WGJn98bPNmNmgcqMZZ5A4XbfO7XVUyHlGv8eXP 305M5x9gI51ahL9hHpqC4xkygWBrZRYW4C1VV/z+xCpZG0IDlOohnIXPXxMezMNnCGPA mK5Bqzk8OzrtEanEdglE7QBnHxfKQ1uvCkzch3GTWlRtZCjsanZUnqVRyxA8WtwWnRw5 GEoA== X-Forwarded-Encrypted: i=1; AJvYcCWK/bTSJXrtCl955Lp2Ku5tyNFxoFE9oKz0t772XBDNXzUQOfmoYEZdjIRk0/v7iqAL8q4=@vger.kernel.org X-Gm-Message-State: AOJu0YyOlpzMFAyNWju7qtvYktVFt5G7r0j5Mpou2tUFwxui4Wgmr1Ml bf+jea3sgsOsdXBxkiqYwQZ+Qa+mcIO98eISXM9J2E9tPk8s/AmRxUmuhK8yX9EV4zMISXVkygh Tc2o2mg== 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: kvm@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 [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