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 4D9FAC433EF for ; Fri, 4 Feb 2022 17:57:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF3E16B007E; Fri, 4 Feb 2022 12:57:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D7C3E6B0080; Fri, 4 Feb 2022 12:57:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1CBA6B0081; Fri, 4 Feb 2022 12:57:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id B2BA76B007E for ; Fri, 4 Feb 2022 12:57:14 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 96502605CE for ; Fri, 4 Feb 2022 17:57:14 +0000 (UTC) X-FDA: 79105853988.02.058196A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id EB1281C0006 for ; Fri, 4 Feb 2022 17:57:13 +0000 (UTC) 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 4439161B07; Fri, 4 Feb 2022 17:57:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16FF6C340EB; Fri, 4 Feb 2022 17:57:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1643997432; bh=aD+SvPJUMV8qlmZmYGtEKh2tOLxDc46bz5C2+qUebYM=; h=Date:To:From:In-Reply-To:Subject:From; b=z6lz9jL0Z2vmS7oQYoe1lxU7nQfgvYuB7ZEU4D4yUFNiPyzbibRtOwkafWimg5dxG Efwf78BJdLhVmPquk2tJBwE898Ghdx7gin1W8zduMU5aTOcISqp5grE358E2qWqQ0F BIc/JOcXTL1AWdABd3uCu+veUjNxVmCmkYCbDjjo= Received: by hp1 (sSMTP sendmail emulation); Fri, 04 Feb 2022 09:57:10 -0800 Date: Fri, 04 Feb 2022 09:57:10 -0800 To: stable@vger.kernel.org,osalvador@suse.de,david@redhat.com,catalin.marinas@arm.com,lang.yu@amd.com,akpm@linux-foundation.org,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220203204836.88dcebe504f440686cc63a60@linux-foundation.org> Subject: [patch 08/10] mm/kmemleak: avoid scanning potential huge holes Message-Id: <20220204175711.16FF6C340EB@smtp.kernel.org> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EB1281C0006 X-Rspam-User: nil Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=z6lz9jL0; dmarc=none; spf=pass (imf18.hostedemail.com: domain of akpm@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@kernel.org X-Stat-Signature: 5nn4fri8pqzn5ndkbsg6sfn8durayijc X-HE-Tag: 1643997433-957609 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: From: Lang Yu Subject: mm/kmemleak: avoid scanning potential huge holes When using devm_request_free_mem_region() and devm_memremap_pages() to add ZONE_DEVICE memory, if requested free mem region's end pfn were huge(e.g., 0x400000000), the node_end_pfn() will be also huge (see move_pfn_range_to_zone()). Thus it creates a huge hole between node_start_pfn() and node_end_pfn(). We found on some AMD APUs, amdkfd requested such a free mem region and created a huge hole. In such a case, following code snippet was just doing busy test_bit() looping on the huge hole. for (pfn = start_pfn; pfn < end_pfn; pfn++) { struct page *page = pfn_to_online_page(pfn); if (!page) continue; ... } So we got a soft lockup: watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221] CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1 RIP: 0010:pfn_to_online_page+0x5/0xd0 Call Trace: ? kmemleak_scan+0x16a/0x440 kmemleak_write+0x306/0x3a0 ? common_file_perm+0x72/0x170 full_proxy_write+0x5c/0x90 vfs_write+0xb9/0x260 ksys_write+0x67/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae I did some tests with the patch. (1) amdgpu module unloaded before the patch: real 0m0.976s user 0m0.000s sys 0m0.968s after the patch: real 0m0.981s user 0m0.000s sys 0m0.973s (2) amdgpu module loaded before the patch: real 0m35.365s user 0m0.000s sys 0m35.354s after the patch: real 0m1.049s user 0m0.000s sys 0m1.042s Link: https://lkml.kernel.org/r/20211108140029.721144-1-lang.yu@amd.com Signed-off-by: Lang Yu Acked-by: David Hildenbrand Acked-by: Catalin Marinas Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton --- mm/kmemleak.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) --- a/mm/kmemleak.c~mm-kmemleak-avoid-scanning-potential-huge-holes +++ a/mm/kmemleak.c @@ -1410,7 +1410,8 @@ static void kmemleak_scan(void) { unsigned long flags; struct kmemleak_object *object; - int i; + struct zone *zone; + int __maybe_unused i; int new_leaks = 0; jiffies_last_scan = jiffies; @@ -1450,9 +1451,9 @@ static void kmemleak_scan(void) * Struct page scanning for each node. */ get_online_mems(); - for_each_online_node(i) { - unsigned long start_pfn = node_start_pfn(i); - unsigned long end_pfn = node_end_pfn(i); + for_each_populated_zone(zone) { + unsigned long start_pfn = zone->zone_start_pfn; + unsigned long end_pfn = zone_end_pfn(zone); unsigned long pfn; for (pfn = start_pfn; pfn < end_pfn; pfn++) { @@ -1461,8 +1462,8 @@ static void kmemleak_scan(void) if (!page) continue; - /* only scan pages belonging to this node */ - if (page_to_nid(page) != i) + /* only scan pages belonging to this zone */ + if (page_zone(page) != zone) continue; /* only scan if page is in use */ if (page_count(page) == 0) _