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 0FAF9C021B8 for ; Wed, 26 Feb 2025 07:03:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92E99280003; Wed, 26 Feb 2025 02:03:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DEF5280001; Wed, 26 Feb 2025 02:03:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A6AB280003; Wed, 26 Feb 2025 02:03:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 59284280001 for ; Wed, 26 Feb 2025 02:03:39 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F2ED6A1BF6 for ; Wed, 26 Feb 2025 07:03:38 +0000 (UTC) X-FDA: 83161205316.23.30C7B62 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf28.hostedemail.com (Postfix) with ESMTP id 4B873C0003 for ; Wed, 26 Feb 2025 07:03:35 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf28.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=liushixin2@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740553417; 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: references; bh=BEvKBAL38FhP8KjziWXvMK2VXOC4iDHlZtZS+SYFTPY=; b=HcA47xxy+/RAiN91D5Y8Vyfzs5+BCa1T5ts9e+LdPS1U1u5e903GjsZpn1ujq0LFma3r7m 0jexueP80EJBwpwZ7K3Q5HL8l3KYA/Z1ir/P9/WrFDgw9ptqlKYy6i6oiwv2Qhtok9mZ9t RIhltxIsX514hAsZToJLZyz4zTfHxlU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf28.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=liushixin2@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740553417; a=rsa-sha256; cv=none; b=n+HOc9VA68O9mfWd669BUUoOrN5jz2KtMkgCzjKYoZ+rbFyudNy8HcOfKvsmTzDY/paZhY XXrAbe6ot38WNRbDjDEO9TySpCSOxy4Abge+Xzc0Mas6dfDQS0j5Fyu1g7Lu3JacqJdkdu qGe2w19YPk1NikeyB1LUn2DzTatC4tQ= Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Z2lhJ5sw6z1ltY8; Wed, 26 Feb 2025 14:59:28 +0800 (CST) Received: from kwepemg200013.china.huawei.com (unknown [7.202.181.64]) by mail.maildlp.com (Postfix) with ESMTPS id 271541A0188; Wed, 26 Feb 2025 15:03:32 +0800 (CST) Received: from [10.174.179.24] (10.174.179.24) by kwepemg200013.china.huawei.com (7.202.181.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 26 Feb 2025 15:03:31 +0800 To: Baolin Wang , "linux-mm@kvack.org" , Linux Kernel Mailing List From: Liu Shixin Subject: Softlockup when test shmem swapout-swapin and compaction CC: Barry Song , David Hildenbrand , Hugh Dickins , Kefeng Wang , Lance Yang , Matthew Wilcox , Ryan Roberts , Andrew Morton Message-ID: <28546fb4-5210-bf75-16d6-43e1f8646080@huawei.com> Date: Wed, 26 Feb 2025 15:03:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemg200013.china.huawei.com (7.202.181.64) X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4B873C0003 X-Stat-Signature: ecftty5tiq41uza76h8b8b5or38ta7bw X-HE-Tag: 1740553415-156603 X-HE-Meta: U2FsdGVkX1+b7Xu+bSlyzY8CR/MIYYMXDnDu9Eq5fcB39yhgBNjl8TALWSOAQ7izx8s0N59vrkno0hlxuyYUqpGCxqEAvGucRXx/YphQyZDhv6PXvhB9xOf+4dX1OpbxJ417gr6X/dARTrX9bM+EAasNybLcsGrw35gF/6zG7zOyK3pv1XntOWhZWWWgjBTvnCwL4wioItl6qT6+ncQmYDlZ7qXD1uKBnVNP8VEuEqj2h9pkNi+eQzj3PMeOJChBPoarLPMMz1NWZB5N5FfQq7bl4FgAcMpaBMnz+7+i2d8QLUdrrYD3aUC+YDFinUEoJvkjurTINTyr0wAknuYAK981AETxZhS/ba5nRjHpMdKvk6az75qfCm8KJZWcnib4QID7o5PfvS4tqrwisvb4UNT0eMHzyqCCyv4g/6znZAv6L8UjwJd40IjX94cdlpHALsHpicKT4svimkQVsw6sIO133USEJmUbZXO9+lya10J3qfYfarGEsmnTseRW/AI0Uk/Lw3A/2JiyHeF9wqiDMZf9XYQ4c+cXFlihEqH/1QQD1T5u977LYc68vojav66J1jPFqsZyxRDrAu49d9SYWLVuPbeDCur5885IyOgxH2+D33M0eRTrqr2VdHVt1dZJ0acBgSMZjv3Mg6LMJd/qSadiZri5WbExLTl0H2sMcrdsLIYSmIECCLqOT0/N1rgkZP4vcmVOEMuFdAmbyM5vFThFe40IDizBqi66jO6OZeL8/DgNjWgIKDnfNy5JqjsdAjPcCHqcJcCw2V6lMvDVKcAT7+PzBcd64QhbejP3Cw3Q9V+K4TG7WlqrVogFazmxESg0IU8BEmmAufO/njSCyUDxF7pzW9Q2at0k1xi96jkbTePhxhJbk+11fY0U/90l0UX52HfVrcy77F4US5tjXt8uagctEzyX42jtvG037J6EhHanx4pYlpCIC09oZOFU2S9fRexvkndD99+mR2X 3Zezrt6r 9LsJmzmSlh+AOae92MSxqMjgdyWzy8BrHunzNfeIdXrh9Cfsvo48wQrMM74DkgIzSpM1BO0TiarYEB885kYO4k13R0PcsPS4nIECS4y6SueZzNA+ihxatfR9zZkz+dAtiXzGClbv2OZYJ7XF8y7VLCDvzk2DEmapVkwT0nUAn/1Z0fqNN2WQDlUGB3ci3u1KWoLgY 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: Hi all, I found a softlockup when testing shmem large folio swapout-swapin and compaction: watchdog: BUG: soft lockup - CPU#30 stuck for 179s! [folio_swap:4714] Modules linked in: zram xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype iptable_filter ip_tantel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit libnvdimm kvm_intel kvm rapl cixt4 mbcache jbd2 sr_mod cdrom ata_generic ata_piix virtio_net net_failover ghash_clmulni_intel libata sha512_ssse3 CPU: 30 UID: 0 PID: 4714 Comm: folio_swap Kdump: loaded Tainted: G L 6.14.0-rc4-next-20250225+ #2 Tainted: [L]=SOFTLOCKUP Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:xas_load+0x5d/0xc0 Code: 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 73 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 48 3d RSP: 0000:ffffadf142f1ba60 EFLAGS: 00000293 RAX: ffffe524cc4f6700 RBX: ffffadf142f1ba90 RCX: 0000000000000000 RDX: 0000000000000011 RSI: ffff9a3e058acb68 RDI: ffffadf142f1ba90 RBP: fffffffffffffffe R08: ffffadf142f1bb50 R09: 0000000000000392 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000011 R13: ffffadf142f1bb48 R14: ffff9a3e04e9c588 R15: 0000000000000000 FS: 00007fd957666740(0000) GS:ffff9a41ac0e5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd922860000 CR3: 000000025c360001 CR4: 0000000000772ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? watchdog_timer_fn+0x1c9/0x250 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x10e/0x250 ? hrtimer_interrupt+0xfb/0x240 ? __sysvec_apic_timer_interrupt+0x4e/0xe0 ? sysvec_apic_timer_interrupt+0x68/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? xas_load+0x5d/0xc0 xas_find+0x153/0x1a0 find_get_entries+0x73/0x280 shmem_undo_range+0x1fc/0x640 shmem_evict_inode+0x109/0x270 evict+0x107/0x240 ? fsnotify_destroy_marks+0x25/0x180 ? _atomic_dec_and_lock+0x35/0x50 __dentry_kill+0x71/0x190 dput+0xd1/0x190 __fput+0x128/0x2a0 task_work_run+0x57/0x90 syscall_exit_to_user_mode+0x1cb/0x1e0 do_syscall_64+0x67/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fd95776eb8b If CONFIG_DEBUG_VM is enabled, we will meet VM_BUG_ON_FOLIO(!folio_test_locked(folio)) in shmem_add_to_page_cache() too. It seems that the problem is related to memory migration or compaction which is necessary for reproduction, although without a clear why. To reproduce the problem, we need firstly a zram device as swap backend, and then run the reproduction program. The reproduction program consists of three parts: 1. A process constantly changes the status of shmem large folio by these interfaces: /sys/kernel/mm/transparent_hugepage/hugepages-/shmem_enabled 2. A process constantly echo 1 > /proc/sys/vm/compact_memory 3. A process constantly alloc/free/swapout/swapin shmem large folios. I'm not sure whether the first process is necessary but the second and third are. In addition, I tried hacking to modify compaction_alloc to return NULL, and the problem disappeared, so I guess the problem is in migration. The problem is different with https://lore.kernel.org/all/1738717785.im3r5g2vxc.none@localhost/ since I have confirmed this porblem still existed after merge the fixed patch. Thanks, Liu Shixin.