Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3587302pxb; Mon, 24 Jan 2022 12:54:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJxkeHQOZPxrdVuiHZof4NzB+qS/4hvnWKVnTvKo/6CZw+ic8ArDe/3FgCPnxBWjF5mrNg9f X-Received: by 2002:a63:8f08:: with SMTP id n8mr12905249pgd.161.1643057694063; Mon, 24 Jan 2022 12:54:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643057694; cv=none; d=google.com; s=arc-20160816; b=mugzCD5UEmwHtz5XTPWAz5dqD3q0XfBAwgWaiyJeTDXMr7MFIR2xisa0FpF2A0RWzk aeBwgFU7KWV7t4UBYxZQL05P0jV1cjEz+KRG9WX4HjM1vJoq9tTSGzmigPGHwuVd0ocK 2/rxSr8ZPmT5EoHazlajkt3ss9zeOhWEdhLoH+R75huooR01d5V5PpsML7qVGxRnVGun vf4ra8A0q0/pHzjXC0Vv8VeRmbE+6rjm14jHFAfB9WRfzjSq9Qu6LDk4KJb1UeshOcj8 xcUlcwgStN6rd5H2jTE/QWUeq1EqdSo3onduxD9KXupT2/Nb9tO1rUv2pejiIsZ7ikzu Bfzg== 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=ii1u56Nmesgss/C4Q+WAZosnZ1pIAxK70M7mLccNe+8=; b=E/9ujquh/6OV7wn+7WfA47aInWmYi6ch9Bo0rzNycDV6Z4XBoPfcFU+n7F2riu/auP 3EYGV7uNvW0GS8hNkc3ebvfSaDLnvtdH2Jox1NbIWWa0DXdJ8Rz3ZwdIztzznNGNxqvH zPo3OKcbGUrmWlDJCcGyIH4ZsLJzSh73wP7Lj3mQoPHaS2kFyZTMJMTF9ehrWTTZpuRa fAp2uVMaiTdSBTI8iFXGp6lXCnQBqyWlrmI29SEpsWwkIEizujab6TZRQH8Om0c9DYwB zgUoRfwpf9lyeFcEXiWgHGybVz8K2t4u0dm9oIHIi5InRncL9yj5LXH8+Vqdad5lC3oX 8wsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=KZqy3sSK; 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 z3si8510732pfw.374.2022.01.24.12.54.38; Mon, 24 Jan 2022 12:54:54 -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=KZqy3sSK; 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 S1380418AbiAXUQR (ORCPT + 99 others); Mon, 24 Jan 2022 15:16:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347390AbiAXT4p (ORCPT ); Mon, 24 Jan 2022 14:56:45 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E14DC02B865; Mon, 24 Jan 2022 11:27:30 -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 dfw.source.kernel.org (Postfix) with ESMTPS id A067F60917; Mon, 24 Jan 2022 19:27:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88966C340E5; Mon, 24 Jan 2022 19:27:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643052449; bh=LzOJr1Lqq1Nnk+HbsxiGbGTjhccq7HG785DI4oHNG5k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KZqy3sSK2ptgYZ9Hd3gixHVfz4r6yOi2lwOZf9d8gSaPQ97PH7n0jpBJ5c/vr0KMl 399exZce/aEVzqifNx9NPUIb9ucT6y0WRmkcXVHQi2g6lIAu47O8R5SA2SftZ5/34Q Uc5BeduLpb5u+tRC+0RRaCHT1AYpq5mE0bNn6/Nk= 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.4 030/320] mm/page_alloc.c: do not warn allocation failure on zone DMA if no managed pages Date: Mon, 24 Jan 2022 19:40:14 +0100 Message-Id: <20220124183954.783058722@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124183953.750177707@linuxfoundation.org> References: <20220124183953.750177707@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 @@ -3767,7 +3767,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);