From patchwork Mon Oct 24 11:31:21 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 8355 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp391780wru; Mon, 24 Oct 2022 04:33:57 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6AYXMnQs0AX8R+CI5UVUWb0SnhhbBr8A2xk7h62LkQglUkT68X+UXR3jhmAmy7BXSWLLSF X-Received: by 2002:aa7:9298:0:b0:56b:b6dc:988a with SMTP id j24-20020aa79298000000b0056bb6dc988amr6948832pfa.5.1666611236796; Mon, 24 Oct 2022 04:33:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666611236; cv=none; d=google.com; s=arc-20160816; b=o06TXY3H2MFdTM4WH5VPLdZbd9IMvwlCf+DyhMccgVv5X2PsDtTNQMnMNA5s7lYklQ W2GIfl5UxWJ0HqiAIeI43SotNKNmt46rKCaOZRAvLSJ/ysXfrcEFzrWFxaizI7yOiE80 ib0U8aOZUehHovNz/GuuC7AM3pE7bTvDH/Ja9hdbf6K/ZrMRrZlp+cevzaGzaIfhThR2 Tf16Rjdmrkdxzt20zG30Rmg7OR7LosOOpN2ni0bzEj4tix1GLXSSBo9TgU8rMmzLbkKY 4+suZKdWi67xpbpJEtlOAAsxqEcRE9ucdoSQzunFHpyMkw5IumhrjjeeKUmAZSVZ3lv3 T2pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=tqUAgLflPN4apDlIhXki5dXSdndEiPtJVUR6SoXH6Pg=; b=mt7veR5JgzO1lZFYQiLBhQ2zD2RH4HmZY44iUf2co/lkzSEJR1knmBblwIPzKKZsbr Xl2k6RfVRXLxuFBve38B5Mn9ItfOC/V1FRNmgtV7jriIzGA4RkNSW641gL1dpg7jzlag lfg6eHboS0qIeyKSHwkQZZQis6MEnxJXu50YnxuxZmwSAxSrEeDEK7JT0LxkpFsRIbNE hUcwO4MYa+ymeyh+Xi0chaIu6J1rvbeoULGcoRKsjRqx38tOPLcl7h6B7iL2mHY88jTv maR7W456Z3PRpAWapVbQmpoLybc6n8i2ZiLQBo/CyKwWQ7K+wEfh366lmgyMKg3ykq6C n1kw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=1djbrR69; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bk13-20020a056a02028d00b0046b2bef339csi32585304pgb.257.2022.10.24.04.33.43; Mon, 24 Oct 2022 04:33:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=1djbrR69; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230378AbiJXLcm (ORCPT + 99 others); Mon, 24 Oct 2022 07:32:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230293AbiJXLcV (ORCPT ); Mon, 24 Oct 2022 07:32:21 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CCBB75BC17; Mon, 24 Oct 2022 04:32:08 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 451E661253; Mon, 24 Oct 2022 11:32:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 344B2C433D6; Mon, 24 Oct 2022 11:32:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666611126; bh=vAYOtUxPKtKKMTHciRMMwaYZ0q7PAkLwIDwOv9ss5wg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1djbrR69potVnEpqeZbgvkmevDlj3AP8s3SNi52lZzHpobLFDqPNKGO7Yz6aZ1sBK sIENYk/E/zBvoq69z1IETYxr6Ec/dFuRwtCowS91oXpXbHX0kC8+ujKxXHsIrlARqt IvSUSps4QwbyDVas/grLr0Ah1AmC/ZYCkb630Af8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mel Gorman , "Matthew Wilcox (Oracle)" , Yang Shi , Brian Foster , Dan Streetman , Miaohe Lin , Oleksandr Natalenko , Seth Jennings , Vitaly Wool , Andrew Morton Subject: [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split Date: Mon, 24 Oct 2022 13:31:21 +0200 Message-Id: <20221024112935.173960536@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024112934.415391158@linuxfoundation.org> References: <20221024112934.415391158@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747568543836495641?= X-GMAIL-MSGID: =?utf-8?q?1747568543836495641?= From: Mel Gorman commit 71e2d666ef85d51834d658830f823560c402b8b6 upstream. The following has been observed when running stressng mmap since commit b653db77350c ("mm: Clear page->private when splitting or migrating a page") watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546] CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374 Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016 RIP: 0010:xas_descend+0x28/0x80 Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2 RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246 RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002 RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0 RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0 R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000 R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88 FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: xas_load+0x3a/0x50 __filemap_get_folio+0x80/0x370 ? put_swap_page+0x163/0x360 pagecache_get_page+0x13/0x90 __try_to_reclaim_swap+0x50/0x190 scan_swap_map_slots+0x31e/0x670 get_swap_pages+0x226/0x3c0 folio_alloc_swap+0x1cc/0x240 add_to_swap+0x14/0x70 shrink_page_list+0x968/0xbc0 reclaim_page_list+0x70/0xf0 reclaim_pages+0xdd/0x120 madvise_cold_or_pageout_pte_range+0x814/0xf30 walk_pgd_range+0x637/0xa30 __walk_page_range+0x142/0x170 walk_page_range+0x146/0x170 madvise_pageout+0xb7/0x280 ? asm_common_interrupt+0x22/0x40 madvise_vma_behavior+0x3b7/0xac0 ? find_vma+0x4a/0x70 ? find_vma+0x64/0x70 ? madvise_vma_anon_name+0x40/0x40 madvise_walk_vmas+0xa6/0x130 do_madvise+0x2f4/0x360 __x64_sys_madvise+0x26/0x30 do_syscall_64+0x5b/0x80 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? do_syscall_64+0x67/0x80 ? common_interrupt+0x8b/0xa0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The problem can be reproduced with the mmtests config config-workload-stressng-mmap. It does not always happen and when it triggers is variable but it has happened on multiple machines. The intent of commit b653db77350c patch was to avoid the case where PG_private is clear but folio->private is not-NULL. However, THP tail pages uses page->private for "swp_entry_t if folio_test_swapcache()" as stated in the documentation for struct folio. This patch only clobbers page->private for tail pages if the head page was not in swapcache and warns once if page->private had an unexpected value. Link: https://lkml.kernel.org/r/20221019134156.zjyyn5aownakvztf@techsingularity.net Fixes: b653db77350c ("mm: Clear page->private when splitting or migrating a page") Signed-off-by: Mel Gorman Cc: Matthew Wilcox (Oracle) Cc: Mel Gorman Cc: Yang Shi Cc: Brian Foster Cc: Dan Streetman Cc: Miaohe Lin Cc: Oleksandr Natalenko Cc: Seth Jennings Cc: Vitaly Wool Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- mm/huge_memory.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2445,7 +2445,16 @@ static void __split_huge_page_tail(struc page_tail); page_tail->mapping = head->mapping; page_tail->index = head->index + tail; - page_tail->private = 0; + + /* + * page->private should not be set in tail pages with the exception + * of swap cache pages that store the swp_entry_t in tail pages. + * Fix up and warn once if private is unexpectedly set. + */ + if (!folio_test_swapcache(page_folio(head))) { + VM_WARN_ON_ONCE_PAGE(page_tail->private != 0, head); + page_tail->private = 0; + } /* Page flags must be visible before we make the page non-compound. */ smp_wmb();