Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3635477pxb; Mon, 24 Jan 2022 14:04:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJxG4A0qr99Z73SpTzcunGNV+yo7qT5MMZpn15hABwM8LGGIAynk0jkk7lz0ej5t4CKtA4N/ X-Received: by 2002:a17:902:8695:b0:14a:f006:db03 with SMTP id g21-20020a170902869500b0014af006db03mr15708208plo.173.1643061862116; Mon, 24 Jan 2022 14:04:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643061862; cv=none; d=google.com; s=arc-20160816; b=pVeOjk5iMJzPkpNxGKvTfGPxDZCLICsSZhcNgqI3Fs4Fn/I5iZK6PTnXu8Wp49GKTS AkwvwBPcKZlnLThVZwT+iDEFHn3OmaehNqgaYvG7QGcKcQAx/IOdHDeAR2e91LtIYXcw CptBtULW1oXV/gMTcSurGHOrLKz8DluN7LTEybHlahclUogWwNMLXoyRTFsnjpSTr/MJ QtZdtWWUSTXRDJALxoaEPK8wGZ+Xlf3bQbrJ/h4GemWOgxEQrSyuH/jNFG8V732AII++ Jlau2fCnnSybsfM8ezAGcC2vT6/IWK8wGjvv3Lt3viV58pt969/L/pG0aNuujtMQAicy 8KBQ== 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=kXi4B/IadxCltviu73MnND1UBmbEPk+fD7xDe/SXj44=; b=pONKBvbfYA9ITEvfNuJymZ75S0nd9L4VwQeYHsGe62Lg1+zzDB5a/Rp8tLpuvVbeeB nEo68KTSmC5v+sPU94oj7JB4ibonzzVpuWjxRoyl2uYMUqqs/pLnPGs5G6quJT3yirWW DRbeuWnVBMDfnhl4QwvhEfDnzmvnYHUrI7ve7exMtG1DMYTHQFU2n+dsRatYimTxbopU rR68P6U/koxZ6CamzEot3Uqp2x4pnZVD6q4WSKQxnHzQNEL/sHPHQUr2mrl3f6UMghxR YkFapG6fufQalPusJQnrWPz4L/t+KPYgDaFw5S+U13uPoAhLV5N2ml0+lOztLCGBkSmU NEpg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=dKV1DcMo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j13si14146765pgk.413.2022.01.24.14.04.09; Mon, 24 Jan 2022 14:04:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=dKV1DcMo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1575622AbiAXVwG (ORCPT + 99 others); Mon, 24 Jan 2022 16:52:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1447375AbiAXVTH (ORCPT ); Mon, 24 Jan 2022 16:19:07 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64526C06F8D5; Mon, 24 Jan 2022 12:13:21 -0800 (PST) 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 ams.source.kernel.org (Postfix) with ESMTPS id 06376B811FB; Mon, 24 Jan 2022 20:13:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F28B8C340E5; Mon, 24 Jan 2022 20:13:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643055199; bh=zPh5p7FABxi5Q4+sOjWICwvNeN9fXrty6gLPGE1tFdI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dKV1DcMo8Oc+z3+VrGF1SG8jPgr614sXP4CskWahtgIZ9bYP6QC84ep+gGwOOnwcs h8qeIahjcCdSHGytCElI+UGXpDSpCU0zEoNDw5P9KIbOyGYFl8zhxI9vmy8Dfc6hON hjrf36hNiLA/UN4o131FnKOHYvkG54de1kNi6wVY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Baoquan He , John Donnelly , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Borislav Petkov , Christoph Hellwig , David Hildenbrand , David Laight , Marek Szyprowski , Robin Murphy , Andrew Morton , Linus Torvalds Subject: [PATCH 5.15 072/846] mm/page_alloc.c: do not warn allocation failure on zone DMA if no managed pages Date: Mon, 24 Jan 2022 19:33:09 +0100 Message-Id: <20220124184103.464688090@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124184100.867127425@linuxfoundation.org> References: <20220124184100.867127425@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Baoquan He commit c4dc63f0032c77464fbd4e7a6afc22fa6913c4a7 upstream. 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=(null),cpuset=/,mems_allowed=0 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 = 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. [akpm@linux-foundation.org: fix warning] Link: https://lkml.kernel.org/r/20211223094435.248523-4-bhe@redhat.com Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") Signed-off-by: Baoquan He Acked-by: John Donnelly Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Vlastimil Babka Cc: Borislav Petkov Cc: Christoph Hellwig Cc: David Hildenbrand Cc: David Laight Cc: Marek Szyprowski Cc: Robin Murphy Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/page_alloc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4210,7 +4210,9 @@ void warn_alloc(gfp_t gfp_mask, nodemask va_list args; static DEFINE_RATELIMIT_STATE(nopage_rs, 10*HZ, 1); - if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(&nopage_rs)) + if ((gfp_mask & __GFP_NOWARN) || + !__ratelimit(&nopage_rs) || + ((gfp_mask & __GFP_DMA) && !has_managed_dma())) return; va_start(args, fmt);