From nobody Wed Jul 1 09:55:00 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EED18C433F5 for ; Thu, 23 Dec 2021 09:45:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347525AbhLWJp1 (ORCPT ); Thu, 23 Dec 2021 04:45:27 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:24879 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232539AbhLWJpZ (ORCPT ); Thu, 23 Dec 2021 04:45:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1640252725; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MioVwl50/1zwGEDq/n1UXoEdkpTw5W8/roYGjRktX6M=; b=EGadDvAzfVz4IfeyoA6LE+JeKlvauUSq+zQv4himC6T3iEJuH0Wm+3MbZB55w+pz1X+Efu QvGVLcoooOIWFLg838KCC9l98a+EI6jg1uqb68fpgXxmoY2kvRdxqbPb58mwgK1aGZ6EXG IOzxnJloFwg6ZLMeKdSMsWoAhfA7b4w= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-488-qTwuIA3kOOO6jy3G6Mc_dg-1; Thu, 23 Dec 2021 04:45:21 -0500 X-MC-Unique: qTwuIA3kOOO6jy3G6Mc_dg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C777318397A7; Thu, 23 Dec 2021 09:45:19 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-13-71.pek2.redhat.com [10.72.13.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2CA215F4E7; Thu, 23 Dec 2021 09:44:55 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hch@lst.de, cl@linux.com, John.p.donnelly@oracle.com, kexec@lists.infradead.org, bhe@redhat.com, 42.hyeyoo@gmail.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, vbabka@suse.cz, David.Laight@ACULAB.COM, david@redhat.com, x86@kernel.org, bp@alien8.de Subject: [PATCH v4 1/3] mm_zone: add function to check if managed dma zone exists Date: Thu, 23 Dec 2021 17:44:33 +0800 Message-Id: <20211223094435.248523-2-bhe@redhat.com> In-Reply-To: <20211223094435.248523-1-bhe@redhat.com> References: <20211223094435.248523-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" In some places of the current kernel, it assumes that dma zone must have managed pages if CONFIG_ZONE_DMA is enabled. While this is not always true. E.g in kdump kernel of x86_64, only low 1M is presented and locked down at very early stage of boot, so that there's no managed pages at all in DMA zone. This exception will always cause page allocation failure if page is requested from DMA zone. Here add function has_managed_dma() and the relevant helper functions to check if there's DMA zone with managed pages. It will be used in later patches. Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashke= rnel option is specified") Cc: stable@vger.kernel.org Signed-off-by: Baoquan He Reviewed-by: David Hildenbrand Tested-by: John Donnelly --- include/linux/mmzone.h | 9 +++++++++ mm/page_alloc.c | 15 +++++++++++++++ 2 files changed, 24 insertions(+) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 58e744b78c2c..6e1b726e9adf 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -1046,6 +1046,15 @@ static inline int is_highmem_idx(enum zone_type idx) #endif } =20 +#ifdef CONFIG_ZONE_DMA +bool has_managed_dma(void); +#else +static inline bool has_managed_dma(void) +{ + return false; +} +#endif + /** * is_highmem - helper function to quickly check if a struct zone is a * highmem zone or not. This is an attempt to keep references diff --git a/mm/page_alloc.c b/mm/page_alloc.c index c5952749ad40..7c7a0b5de2ff 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -9460,3 +9460,18 @@ bool take_page_off_buddy(struct page *page) return ret; } #endif + +#ifdef CONFIG_ZONE_DMA +bool has_managed_dma(void) +{ + struct pglist_data *pgdat; + + for_each_online_pgdat(pgdat) { + struct zone *zone =3D &pgdat->node_zones[ZONE_DMA]; + + if (managed_zone(zone)) + return true; + } + return false; +} +#endif /* CONFIG_ZONE_DMA */ --=20 2.26.3 From nobody Wed Jul 1 09:55:00 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5441C433F5 for ; Thu, 23 Dec 2021 09:45:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347529AbhLWJpf (ORCPT ); Thu, 23 Dec 2021 04:45:35 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:35975 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232539AbhLWJpc (ORCPT ); Thu, 23 Dec 2021 04:45:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1640252732; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6UqqjKGACJXiy3AfQtPBei4e8FekNIezY6zLwdw084M=; b=HACUcOomYTv7qHgwFjI7LbSmzvPpNAEJy5aDhzwXcmh553ZTcW/BTzHvALL/EaDkyxErIv 40DIMznreBlswjgRLgtlRAOfCOd9cy8+sUL+hNnM0C7/sk4HYN99PrOIzYcfNU05g2PIbm Yp/ZfA/GymXiygwr9F2SLyAMx+QhsKY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-492-O0bdacZwNhqwyRwU0_VF_Q-1; Thu, 23 Dec 2021 04:45:29 -0500 X-MC-Unique: O0bdacZwNhqwyRwU0_VF_Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 64EB41853032; Thu, 23 Dec 2021 09:45:26 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-13-71.pek2.redhat.com [10.72.13.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6DA105F4EA; Thu, 23 Dec 2021 09:45:20 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hch@lst.de, cl@linux.com, John.p.donnelly@oracle.com, kexec@lists.infradead.org, bhe@redhat.com, 42.hyeyoo@gmail.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, vbabka@suse.cz, David.Laight@ACULAB.COM, david@redhat.com, x86@kernel.org, bp@alien8.de Subject: [PATCH v4 2/3] dma/pool: create dma atomic pool only if dma zone has managed pages Date: Thu, 23 Dec 2021 17:44:34 +0800 Message-Id: <20211223094435.248523-3-bhe@redhat.com> In-Reply-To: <20211223094435.248523-1-bhe@redhat.com> References: <20211223094435.248523-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Currently three dma atomic pools are initialized as long as the relevant kernel codes are built in. While in kdump kernel of x86_64, this is not right when trying to create atomic_pool_dma, because there's no managed pages in DMA zone. In the case, DMA zone only has low 1M memory presented and locked down by memblock allocator. So no pages are added into buddy of DMA zone. Please check commit f1d4d47c5851 ("x86/setup: Always reserve the first 1M of RAM"). Then in kdump kernel of x86_64, it always prints below failure message: DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations swapper/0: page allocation failure: order:5, mode:0xcc1(GFP_KERNEL|GFP_DMA= ), nodemask=3D(null),cpuset=3D/,mems_allowed=3D0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-0.rc5.20210611git929d931f= 2b40.42.fc35.x86_64 #1 Hardware name: Dell Inc. PowerEdge R910/0P658H, BIOS 2.12.0 06/04/2018 Call Trace: dump_stack+0x7f/0xa1 warn_alloc.cold+0x72/0xd6 ? _raw_spin_unlock_irq+0x24/0x40 ? __alloc_pages_direct_compact+0x90/0x1b0 __alloc_pages_slowpath.constprop.0+0xf29/0xf50 ? __cond_resched+0x16/0x50 ? prepare_alloc_pages.constprop.0+0x19d/0x1b0 __alloc_pages+0x24d/0x2c0 ? __dma_atomic_pool_init+0x93/0x93 alloc_page_interleave+0x13/0xb0 atomic_pool_expand+0x118/0x210 ? __dma_atomic_pool_init+0x93/0x93 __dma_atomic_pool_init+0x45/0x93 dma_atomic_pool_init+0xdb/0x176 do_one_initcall+0x67/0x320 ? rcu_read_lock_sched_held+0x3f/0x80 kernel_init_freeable+0x290/0x2dc ? rest_init+0x24f/0x24f kernel_init+0xa/0x111 ret_from_fork+0x22/0x30 Mem-Info: ...... DMA: failed to allocate 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocat= ion DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations Here, let's check if DMA zone has managed pages, then create atomic_pool_dma if yes. Otherwise just skip it. Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashke= rnel option is specified") Cc: stable@vger.kernel.org Signed-off-by: Baoquan He Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Cc: iommu@lists.linux-foundation.org Tested-by: John Donnelly --- kernel/dma/pool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c index 5a85804b5beb..00df3edd6c5d 100644 --- a/kernel/dma/pool.c +++ b/kernel/dma/pool.c @@ -206,7 +206,7 @@ static int __init dma_atomic_pool_init(void) GFP_KERNEL); if (!atomic_pool_kernel) ret =3D -ENOMEM; - if (IS_ENABLED(CONFIG_ZONE_DMA)) { + if (has_managed_dma()) { atomic_pool_dma =3D __dma_atomic_pool_init(atomic_pool_size, GFP_KERNEL | GFP_DMA); if (!atomic_pool_dma) @@ -229,7 +229,7 @@ static inline struct gen_pool *dma_guess_pool(struct ge= n_pool *prev, gfp_t gfp) if (prev =3D=3D NULL) { if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32)) return atomic_pool_dma32; - if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA)) + if (atomic_pool_dma && (gfp & GFP_DMA)) return atomic_pool_dma; return atomic_pool_kernel; } --=20 2.26.3 From nobody Wed Jul 1 09:55:00 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0256C433FE for ; Thu, 23 Dec 2021 09:45:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239336AbhLWJpm (ORCPT ); Thu, 23 Dec 2021 04:45:42 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:22360 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347552AbhLWJpj (ORCPT ); Thu, 23 Dec 2021 04:45:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1640252738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S30AMcsWRzj5FbDwBVOYdvq2fsVpYDvDmuFN0e3Wc5g=; b=I2KrfkqbktHyGyvmwlzG71ckFdZGM4/JOlD1N01l8pnRogwSV98SSNlcJ7EyrifJmX61hi tWNQo+TULecC8hglXZLXY5PMiolxSgpK3QhMJ5BuwwAxrIPttMQeGtb7Mt5XUSxTrwiVGi kz+69aJzDPhSSvQBvtxIIY0d8BC+6WY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-576-PHrXd3S8M7aSWUFEt_-BXA-1; Thu, 23 Dec 2021 04:45:35 -0500 X-MC-Unique: PHrXd3S8M7aSWUFEt_-BXA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 79E1D1853026; Thu, 23 Dec 2021 09:45:33 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-13-71.pek2.redhat.com [10.72.13.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 083585F4E1; Thu, 23 Dec 2021 09:45:26 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hch@lst.de, cl@linux.com, John.p.donnelly@oracle.com, kexec@lists.infradead.org, bhe@redhat.com, 42.hyeyoo@gmail.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, vbabka@suse.cz, David.Laight@ACULAB.COM, david@redhat.com, x86@kernel.org, bp@alien8.de Subject: [PATCH v4 3/3] mm/page_alloc.c: do not warn allocation failure on zone DMA if no managed pages Date: Thu, 23 Dec 2021 17:44:35 +0800 Message-Id: <20211223094435.248523-4-bhe@redhat.com> In-Reply-To: <20211223094435.248523-1-bhe@redhat.com> References: <20211223094435.248523-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" In kdump kernel of x86_64, page allocation failure is observed: kworker/u2:2: page allocation failure: order:0, mode:0xcc1(GFP_KERNEL|GFP_= DMA), nodemask=3D(null),cpuset=3D/,mems_allowed=3D0 CPU: 0 PID: 55 Comm: kworker/u2:2 Not tainted 5.16.0-rc4+ #5 Hardware name: AMD Dinar/Dinar, BIOS RDN1505B 06/05/2013 Workqueue: events_unbound async_run_entry_fn Call Trace: dump_stack_lvl+0x48/0x5e warn_alloc.cold+0x72/0xd6 __alloc_pages_slowpath.constprop.0+0xc69/0xcd0 __alloc_pages+0x1df/0x210 new_slab+0x389/0x4d0 ___slab_alloc+0x58f/0x770 __slab_alloc.constprop.0+0x4a/0x80 kmem_cache_alloc_trace+0x24b/0x2c0 sr_probe+0x1db/0x620 ...... device_add+0x405/0x920 ...... __scsi_add_device+0xe5/0x100 ata_scsi_scan_host+0x97/0x1d0 async_run_entry_fn+0x30/0x130 process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x350/0x350 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 Mem-Info: ...... The above failure happened when calling kmalloc() to allocate buffer with GFP_DMA. It requests to allocate slab page from DMA zone while no managed pages at all in there. sr_probe() --> get_capabilities() --> buffer =3D kmalloc(512, GFP_KERNEL | GFP_DMA); Because in the current kernel, dma-kmalloc will be created as long as CONFIG_ZONE_DMA is enabled. However, kdump kernel of x86_64 doesn't have managed pages on DMA zone since commit 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified"). The failure can be always reproduced. For now, let's mute the warning of allocation failure if requesting pages from DMA zone while no managed pages. Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashke= rnel option is specified") Cc: stable@vger.kernel.org Signed-off-by: Baoquan He Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Vlastimil Babka Tested-by: John Donnelly --- mm/page_alloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7c7a0b5de2ff..843bc8e5550a 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4204,7 +4204,8 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask,= const char *fmt, ...) va_list args; static DEFINE_RATELIMIT_STATE(nopage_rs, 10*HZ, 1); =20 - if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(&nopage_rs)) + if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(&nopage_rs) || + (gfp_mask & __GFP_DMA) && !has_managed_dma()) return; =20 va_start(args, fmt); --=20 2.26.3