From: john.p.donnelly@oracle.com To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hch@lst.de, cl@linux.com, kexec@lists.infradead.org, 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, John Donnelly <john.p.donnelly@oracle.com> Subject: Re: [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 09:01:38 -0600 [thread overview] Message-ID: <a5bbe855-2980-0e99-dbf6-6f860bffe491@oracle.com> (raw) In-Reply-To: <20211223094435.248523-4-bhe@redhat.com> On 12/23/21 3:44 AM, Baoquan He wrote: > 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: > <TASK> > 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 > </TASK> > 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. > > Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") > Cc: stable@vger.kernel.org > Signed-off-by: Baoquan He <bhe@redhat.com> Acked-by: John Donnelly <john.p.donnelly@oracle.com> > Cc: Christoph Lameter <cl@linux.com> > Cc: Pekka Enberg <penberg@kernel.org> > Cc: David Rientjes <rientjes@google.com> > Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> > Cc: Vlastimil Babka <vbabka@suse.cz> > --- > 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); > > - 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);
WARNING: multiple messages have this Message-ID (diff)
From: john.p.donnelly@oracle.com To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hch@lst.de, cl@linux.com, kexec@lists.infradead.org, 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, John Donnelly <john.p.donnelly@oracle.com> Subject: Re: [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 09:01:38 -0600 [thread overview] Message-ID: <a5bbe855-2980-0e99-dbf6-6f860bffe491@oracle.com> (raw) In-Reply-To: <20211223094435.248523-4-bhe@redhat.com> On 12/23/21 3:44 AM, Baoquan He wrote: > 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: > <TASK> > 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 > </TASK> > 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. > > Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") > Cc: stable@vger.kernel.org > Signed-off-by: Baoquan He <bhe@redhat.com> Acked-by: John Donnelly <john.p.donnelly@oracle.com> > Cc: Christoph Lameter <cl@linux.com> > Cc: Pekka Enberg <penberg@kernel.org> > Cc: David Rientjes <rientjes@google.com> > Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> > Cc: Vlastimil Babka <vbabka@suse.cz> > --- > 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); > > - 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); _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2021-12-23 15:02 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-23 9:44 [PATCH v4 0/3] Handle warning of allocation failure on DMA zone w/o managed pages Baoquan He 2021-12-23 9:44 ` Baoquan He 2021-12-23 9:44 ` [PATCH v4 1/3] mm_zone: add function to check if managed dma zone exists Baoquan He 2021-12-23 9:44 ` Baoquan He 2021-12-23 15:00 ` john.p.donnelly 2021-12-23 15:00 ` john.p.donnelly 2021-12-23 9:44 ` [PATCH v4 2/3] dma/pool: create dma atomic pool only if dma zone has managed pages Baoquan He 2021-12-23 9:44 ` Baoquan He 2021-12-23 10:21 ` Christoph Hellwig 2021-12-23 10:21 ` Christoph Hellwig 2021-12-23 15:01 ` john.p.donnelly 2021-12-23 15:01 ` john.p.donnelly 2022-01-03 9:34 ` David Hildenbrand 2022-01-03 9:34 ` David Hildenbrand 2021-12-23 9:44 ` [PATCH v4 3/3] mm/page_alloc.c: do not warn allocation failure on zone DMA if no " Baoquan He 2021-12-23 9:44 ` Baoquan He 2021-12-23 15:01 ` john.p.donnelly [this message] 2021-12-23 15:01 ` john.p.donnelly 2021-12-25 5:53 ` Hyeonggon Yoo 2021-12-25 5:53 ` Hyeonggon Yoo 2021-12-27 8:32 ` Baoquan He 2021-12-27 8:32 ` Baoquan He 2021-12-28 5:06 ` Hyeonggon Yoo 2021-12-28 5:06 ` Hyeonggon Yoo 2022-01-12 16:25 ` [PATCH v4 0/3] Handle warning of allocation failure on DMA zone w/o " john.p.donnelly 2022-01-12 16:25 ` john.p.donnelly
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=a5bbe855-2980-0e99-dbf6-6f860bffe491@oracle.com \ --to=john.p.donnelly@oracle.com \ --cc=42.hyeyoo@gmail.com \ --cc=David.Laight@ACULAB.COM \ --cc=akpm@linux-foundation.org \ --cc=bhe@redhat.com \ --cc=bp@alien8.de \ --cc=cl@linux.com \ --cc=david@redhat.com \ --cc=hch@lst.de \ --cc=iamjoonsoo.kim@lge.com \ --cc=kexec@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=penberg@kernel.org \ --cc=rientjes@google.com \ --cc=vbabka@suse.cz \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.