Message ID | 20221024112935.173960536@linuxfoundation.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> 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 <rfc822;pwkd43@gmail.com> + 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 <rfc822;linux-kernel@vger.kernel.org>); 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 <gregkh@linuxfoundation.org> To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, stable@vger.kernel.org, Mel Gorman <mgorman@techsingularity.net>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, Yang Shi <shy828301@gmail.com>, Brian Foster <bfoster@redhat.com>, Dan Streetman <ddstreet@ieee.org>, Miaohe Lin <linmiaohe@huawei.com>, Oleksandr Natalenko <oleksandr@natalenko.name>, Seth Jennings <sjenning@redhat.com>, Vitaly Wool <vitaly.wool@konsulko.com>, Andrew Morton <akpm@linux-foundation.org> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: <linux-kernel.vger.kernel.org> 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?= |
Series |
None
|
|
Commit Message
Greg KH
Oct. 24, 2022, 11:31 a.m. UTC
From: Mel Gorman <mgorman@techsingularity.net> 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: <TASK> 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 <mgorman@techsingularity.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Yang Shi <shy828301@gmail.com> Cc: Brian Foster <bfoster@redhat.com> Cc: Dan Streetman <ddstreet@ieee.org> Cc: Miaohe Lin <linmiaohe@huawei.com> Cc: Oleksandr Natalenko <oleksandr@natalenko.name> Cc: Seth Jennings <sjenning@redhat.com> Cc: Vitaly Wool <vitaly.wool@konsulko.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- mm/huge_memory.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
Comments
On Mon, 24 Oct 2022, Greg Kroah-Hartman wrote: > From: Mel Gorman <mgorman@techsingularity.net> > > 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: > <TASK> > 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 <mgorman@techsingularity.net> > Cc: Matthew Wilcox (Oracle) <willy@infradead.org> > Cc: Mel Gorman <mgorman@techsingularity.net> > Cc: Yang Shi <shy828301@gmail.com> > Cc: Brian Foster <bfoster@redhat.com> > Cc: Dan Streetman <ddstreet@ieee.org> > Cc: Miaohe Lin <linmiaohe@huawei.com> > Cc: Oleksandr Natalenko <oleksandr@natalenko.name> > Cc: Seth Jennings <sjenning@redhat.com> > Cc: Vitaly Wool <vitaly.wool@konsulko.com> > Cc: <stable@vger.kernel.org> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Greg, this patch from Mel is important, but introduces a warning which is giving Tvrtko trouble - see linux-mm https://lore.kernel.org/linux-mm/1596edbb-02ad-6bdf-51b8-15c2d2e08b76@linux.intel.com/ We already have the fix for the warning, it's making its way through the system, and is marked for stable, but it has not reached Linus's tree yet. Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know when the fix does reach Linus's tree - hopefully the two can go together in the next 6.0-stable. I apologize for not writing yesterday: gmail had gathered together different threads with the same subject, I thought you and stable were Cc'ed on the linux-mm mail and you would immediately drop it yourself, but in fact you were not on that thread at all. Thanks, Hugh
On Tue, Oct 25, 2022 at 08:11:44AM -0700, Hugh Dickins wrote: > On Mon, 24 Oct 2022, Greg Kroah-Hartman wrote: > > From: Mel Gorman <mgorman@techsingularity.net> > > > > 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: > > <TASK> > > 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 <mgorman@techsingularity.net> > > Cc: Matthew Wilcox (Oracle) <willy@infradead.org> > > Cc: Mel Gorman <mgorman@techsingularity.net> > > Cc: Yang Shi <shy828301@gmail.com> > > Cc: Brian Foster <bfoster@redhat.com> > > Cc: Dan Streetman <ddstreet@ieee.org> > > Cc: Miaohe Lin <linmiaohe@huawei.com> > > Cc: Oleksandr Natalenko <oleksandr@natalenko.name> > > Cc: Seth Jennings <sjenning@redhat.com> > > Cc: Vitaly Wool <vitaly.wool@konsulko.com> > > Cc: <stable@vger.kernel.org> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Greg, this patch from Mel is important, > but introduces a warning which is giving Tvrtko trouble - see linux-mm > https://lore.kernel.org/linux-mm/1596edbb-02ad-6bdf-51b8-15c2d2e08b76@linux.intel.com/ > > We already have the fix for the warning, it's making its way through the > system, and is marked for stable, but it has not reached Linus's tree yet. > > Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know > when the fix does reach Linus's tree - hopefully the two can go together > in the next 6.0-stable. > > I apologize for not writing yesterday: gmail had gathered together > different threads with the same subject, I thought you and stable > were Cc'ed on the linux-mm mail and you would immediately drop it > yourself, but in fact you were not on that thread at all. No worries, now dropped, thanks. greg k-h
On Tue, 25 Oct 2022, Greg Kroah-Hartman wrote: > On Tue, Oct 25, 2022 at 08:11:44AM -0700, Hugh Dickins wrote: > > On Mon, 24 Oct 2022, Greg Kroah-Hartman wrote: > > > From: Mel Gorman <mgorman@techsingularity.net> > > > > > > commit 71e2d666ef85d51834d658830f823560c402b8b6 upstream. > > >... > > > > Greg, this patch from Mel is important, > > but introduces a warning which is giving Tvrtko trouble - see linux-mm > > https://lore.kernel.org/linux-mm/1596edbb-02ad-6bdf-51b8-15c2d2e08b76@linux.intel.com/ > > > > We already have the fix for the warning, it's making its way through the > > system, and is marked for stable, but it has not reached Linus's tree yet. > > > > Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know > > when the fix does reach Linus's tree - hopefully the two can go together > > in the next 6.0-stable. > > > > I apologize for not writing yesterday: gmail had gathered together > > different threads with the same subject, I thought you and stable > > were Cc'ed on the linux-mm mail and you would immediately drop it > > yourself, but in fact you were not on that thread at all. > > No worries, now dropped, thanks. Thanks Greg. Linus's tree now contains my fix 5aae9265ee1a ("mm: prep_compound_tail() clear page->private") to Mel's fix 71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split") so they can now go on together into 6.0 stable. They would also have been good in 5.19 stable: but too late now, it's EOL. Hugh
On Sat, Oct 29, 2022 at 08:33:01PM -0700, Hugh Dickins wrote: > On Tue, 25 Oct 2022, Greg Kroah-Hartman wrote: > > On Tue, Oct 25, 2022 at 08:11:44AM -0700, Hugh Dickins wrote: > > > On Mon, 24 Oct 2022, Greg Kroah-Hartman wrote: > > > > From: Mel Gorman <mgorman@techsingularity.net> > > > > > > > > commit 71e2d666ef85d51834d658830f823560c402b8b6 upstream. > > > >... > > > > > > Greg, this patch from Mel is important, > > > but introduces a warning which is giving Tvrtko trouble - see linux-mm > > > https://lore.kernel.org/linux-mm/1596edbb-02ad-6bdf-51b8-15c2d2e08b76@linux.intel.com/ > > > > > > We already have the fix for the warning, it's making its way through the > > > system, and is marked for stable, but it has not reached Linus's tree yet. > > > > > > Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know > > > when the fix does reach Linus's tree - hopefully the two can go together > > > in the next 6.0-stable. > > > > > > I apologize for not writing yesterday: gmail had gathered together > > > different threads with the same subject, I thought you and stable > > > were Cc'ed on the linux-mm mail and you would immediately drop it > > > yourself, but in fact you were not on that thread at all. > > > > No worries, now dropped, thanks. > > Thanks Greg. Linus's tree now contains my fix > 5aae9265ee1a ("mm: prep_compound_tail() clear page->private") > to Mel's fix > 71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split") > so they can now go on together into 6.0 stable. > > They would also have been good in 5.19 stable: but too late now, it's EOL. Thanks, both now queued up for 6.0 greg k-h
--- 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();