From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 414FB367F58; Fri, 29 May 2026 03:41:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780026087; cv=none; b=O06719//HLY0zwlGPOFCc5/NwBcYDUGDu7Sll2kn4HO+awjYaxFbh20iD+WSEG585AHEHgsgybJr6NDtrT6IixtUBR3ThqnQk5CeJNrU5FD2c9HVetVj/6OshGdo5hkPpK/OrYzMQsONG5PcopZpO61L8dBInKfJZBh70Ohf7DI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780026087; c=relaxed/simple; bh=OsS1e+Qw/QnKrZzlo/+MNIKnYxQSH/Bs/+Zy/VsCM9k=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=O7q+8n6hZMbh0buYVBuq1XRxmdUJeFxayglxqgW+Mgpa3KXIEkz3zFrNEuj8759za16/zTL5tntmgsAoMCCOaTAvLLefWwOlt0BYb7bDNsru+wLQdiQ1KnUM37BAXJ+eAKrDmaPLqHune/pe0b5MADi/FtPe3b/KLtTLWaYh/34= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Ou2aIZQT; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Ou2aIZQT" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=uwFcWOwJkeegfR4BbQvBChM0ATs2whx7uh0xno0g6bQ=; b=Ou2aIZQTUFpHcWM+GeEoYlPUKFbytDZomcHoIvdgX1B/fp6vmhzUnHBLV6dN1fgZWhRAvfO00 yyrmQqLpqo5kVx1iIuJMLmbbI7BFCRtFoxGVY+meJQsjXzhnrE9tpFozx8Yl/KY+cL5W/0poiWo ZeMftN5tD1TtYSkCuGzTk0g= Received: from mail.maildlp.com (unknown [172.19.162.223]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4gRTTY4FLKz12Lgj; Fri, 29 May 2026 11:33:21 +0800 (CST) Received: from dggemv706-chm.china.huawei.com (unknown [10.3.19.33]) by mail.maildlp.com (Postfix) with ESMTPS id 5496D40561; Fri, 29 May 2026 11:41:20 +0800 (CST) Received: from kwepemq500010.china.huawei.com (7.202.194.235) by dggemv706-chm.china.huawei.com (10.3.19.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 29 May 2026 11:41:20 +0800 Received: from [10.173.124.160] (10.173.124.160) by kwepemq500010.china.huawei.com (7.202.194.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 29 May 2026 11:41:18 +0800 Subject: Re: [PATCH RFC v2 6/7] KVM: selftests: Add memory failure tests in guest_memfd_test To: Lisa Wang CC: , , , , , , , , Naoya Horiguchi , Andrew Morton , "Paolo Bonzini" , Shuah Khan , Hugh Dickins , Baolin Wang , "David Hildenbrand" , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , , , , References: <20260319-memory-failure-mf-delayed-fix-rfc-v2-v2-0-92c596402a7a@google.com> <20260319-memory-failure-mf-delayed-fix-rfc-v2-v2-6-92c596402a7a@google.com> <149c954e-dfe1-6bdd-295c-792642a9d915@huawei.com> From: Miaohe Lin Message-ID: Date: Fri, 29 May 2026 11:41:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemq500010.china.huawei.com (7.202.194.235) On 2026/5/29 9:50, Lisa Wang wrote: > On Mon, Mar 30, 2026 at 03:20:15PM +0800, Miaohe Lin wrote: >> On 2026/3/20 7:30, Lisa Wang wrote: >>> After modifying truncate_error_folio(), we expect memory_failure() will >>> return 0 instead of MF_FAILED. Also, we want to make sure memory_failure() >>> signaling function is same. >>> >>> Test that memory_failure() returns 0 for guest_memfd, where >>> .error_remove_folio() is handled by not actually truncating, and returning >>> MF_DELAYED. >>> >>> In addition, test that SIGBUS signaling behavior is not changed before >>> and after this modification. >>> >>> There are two kinds of guest memory failure injections - madvise or >>> debugfs. When memory failure is injected using madvise, the >>> MF_ACTION_REQUIRED flag is set, and the page is mapped and dirty, the >>> process should get a SIGBUS. When memory is failure is injected using >>> debugfs, the KILL_EARLY machine check memory corruption kill policy is >>> set, and the page is mapped and dirty, the process should get a SIGBUS. >>> >>> Co-developed-by: Ackerley Tng >>> Signed-off-by: Ackerley Tng >>> Signed-off-by: Lisa Wang >> >> Should we add a testcase for hugetlbfs? It seems hugetlbfs_error_remove_folio() behaves same as shmem. > > I agree that it would be more consistent to modify > hugetlbfs_error_remove_folio() to return MF_DELAYED and update > me_huge_page() to align with me_pagecache_clean(). > > However, I prefer to let this patch series focus on the > me_pagecache_clean() path (affecting shmem, guest_memfd and generic > pagecache), because the hugepage memory failure test is not working now > (hugetlb-read-hwpoison.c). Commit 66802526298e changed madvise() > behavior to always force-deliver a SIGBUS to the calling process if it > has the poisoned dirty page mapped. Aligning HugeTLB would require us to > fix this part together. > > To keep this series focused, I would like to handle the HugeTLB > alignment in the follow-up series. Would you be okay with this approach? Sure, this will be better. Thanks for your work. It's really helpful. :)