diff mbox series

[v2,2/2] mm: don't warn if the node is offlined

Message ID 20221103213641.7296-2-shy828301@gmail.com
State New
Headers
Series [v2,1/2] mm: khugepaged: allow page allocation fallback to eligible nodes |

Commit Message

Yang Shi Nov. 3, 2022, 9:36 p.m. UTC 
  Syzbot reported the below splat:

WARNING: CPU: 1 PID: 3646 at include/linux/gfp.h:221 __alloc_pages_node
include/linux/gfp.h:221 [inline]
WARNING: CPU: 1 PID: 3646 at include/linux/gfp.h:221
hpage_collapse_alloc_page mm/khugepaged.c:807 [inline]
WARNING: CPU: 1 PID: 3646 at include/linux/gfp.h:221
alloc_charge_hpage+0x802/0xaa0 mm/khugepaged.c:963
Modules linked in:
CPU: 1 PID: 3646 Comm: syz-executor210 Not tainted
6.1.0-rc1-syzkaller-00454-ga70385240892 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 10/11/2022
RIP: 0010:__alloc_pages_node include/linux/gfp.h:221 [inline]
RIP: 0010:hpage_collapse_alloc_page mm/khugepaged.c:807 [inline]
RIP: 0010:alloc_charge_hpage+0x802/0xaa0 mm/khugepaged.c:963
Code: e5 01 4c 89 ee e8 6e f9 ae ff 4d 85 ed 0f 84 28 fc ff ff e8 70 fc
ae ff 48 8d 6b ff 4c 8d 63 07 e9 16 fc ff ff e8 5e fc ae ff <0f> 0b e9
96 fa ff ff 41 bc 1a 00 00 00 e9 86 fd ff ff e8 47 fc ae
RSP: 0018:ffffc90003fdf7d8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888077f457c0 RSI: ffffffff81cd8f42 RDI: 0000000000000001
RBP: ffff888079388c0c R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f6b48ccf700(0000) GS:ffff8880b9b00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6b48a819f0 CR3: 00000000171e7000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 collapse_file+0x1ca/0x5780 mm/khugepaged.c:1715
 hpage_collapse_scan_file+0xd6c/0x17a0 mm/khugepaged.c:2156
 madvise_collapse+0x53a/0xb40 mm/khugepaged.c:2611
 madvise_vma_behavior+0xd0a/0x1cc0 mm/madvise.c:1066
 madvise_walk_vmas+0x1c7/0x2b0 mm/madvise.c:1240
 do_madvise.part.0+0x24a/0x340 mm/madvise.c:1419
 do_madvise mm/madvise.c:1432 [inline]
 __do_sys_madvise mm/madvise.c:1432 [inline]
 __se_sys_madvise mm/madvise.c:1430 [inline]
 __x64_sys_madvise+0x113/0x150 mm/madvise.c:1430
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f6b48a4eef9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 15 00 00 90 48 89 f8 48 89
f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f6b48ccf318 EFLAGS: 00000246 ORIG_RAX: 000000000000001c
RAX: ffffffffffffffda RBX: 00007f6b48af0048 RCX: 00007f6b48a4eef9
RDX: 0000000000000019 RSI: 0000000000600003 RDI: 0000000020000000
RBP: 00007f6b48af0040 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6b48aa53a4
R13: 00007f6b48bffcbf R14: 00007f6b48ccf400 R15: 0000000000022000
 </TASK>

It is because khugepaged allocates pages with __GFP_THISNODE, but the
preferred node is offlined.  The previous patch fixed the khugepaged
code to avoid allocating page from non-existing node.  But it is still
racy against memory hotremove.  There is no synchronization with the
memory hotplug so it is possible that memory gets offline during a
longer taking scanning.

So this warning still seems not quite helpful because:
  * There is no guarantee the node is online for __GFP_THISNODE context
    for all the callsites.
  * Kernel just fails the allocation regardless the warning, and it looks
    all callsites handle the allocation failure gracefully.

It is actually even harmful for those running in panic-on-warn mode.  So
removing the warning seems like a good move.

Reported-by: syzbot+0044b22d177870ee974f@syzkaller.appspotmail.com
Signed-off-by: Yang Shi <shy828301@gmail.com>
Reviewed-by: Zach O'Keefe <zokeefe@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
---
v2: * Added patch 1/2.
    * Reworded the commit log per Michal.

 include/linux/gfp.h | 2 --
 1 file changed, 2 deletions(-)

Comments

Michal Hocko Nov. 4, 2022, 9:35 a.m. UTC | #1 
On Thu 03-11-22 14:36:41, Yang Shi wrote:
> Syzbot reported the below splat:
> 
> WARNING: CPU: 1 PID: 3646 at include/linux/gfp.h:221 __alloc_pages_node
> include/linux/gfp.h:221 [inline]
> WARNING: CPU: 1 PID: 3646 at include/linux/gfp.h:221
> hpage_collapse_alloc_page mm/khugepaged.c:807 [inline]
> WARNING: CPU: 1 PID: 3646 at include/linux/gfp.h:221
> alloc_charge_hpage+0x802/0xaa0 mm/khugepaged.c:963
> Modules linked in:
> CPU: 1 PID: 3646 Comm: syz-executor210 Not tainted
> 6.1.0-rc1-syzkaller-00454-ga70385240892 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 10/11/2022
> RIP: 0010:__alloc_pages_node include/linux/gfp.h:221 [inline]
> RIP: 0010:hpage_collapse_alloc_page mm/khugepaged.c:807 [inline]
> RIP: 0010:alloc_charge_hpage+0x802/0xaa0 mm/khugepaged.c:963
> Code: e5 01 4c 89 ee e8 6e f9 ae ff 4d 85 ed 0f 84 28 fc ff ff e8 70 fc
> ae ff 48 8d 6b ff 4c 8d 63 07 e9 16 fc ff ff e8 5e fc ae ff <0f> 0b e9
> 96 fa ff ff 41 bc 1a 00 00 00 e9 86 fd ff ff e8 47 fc ae
> RSP: 0018:ffffc90003fdf7d8 EFLAGS: 00010293
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: ffff888077f457c0 RSI: ffffffff81cd8f42 RDI: 0000000000000001
> RBP: ffff888079388c0c R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000
> FS:  00007f6b48ccf700(0000) GS:ffff8880b9b00000(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f6b48a819f0 CR3: 00000000171e7000 CR4: 00000000003506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>  collapse_file+0x1ca/0x5780 mm/khugepaged.c:1715
>  hpage_collapse_scan_file+0xd6c/0x17a0 mm/khugepaged.c:2156
>  madvise_collapse+0x53a/0xb40 mm/khugepaged.c:2611
>  madvise_vma_behavior+0xd0a/0x1cc0 mm/madvise.c:1066
>  madvise_walk_vmas+0x1c7/0x2b0 mm/madvise.c:1240
>  do_madvise.part.0+0x24a/0x340 mm/madvise.c:1419
>  do_madvise mm/madvise.c:1432 [inline]
>  __do_sys_madvise mm/madvise.c:1432 [inline]
>  __se_sys_madvise mm/madvise.c:1430 [inline]
>  __x64_sys_madvise+0x113/0x150 mm/madvise.c:1430
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f6b48a4eef9
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 15 00 00 90 48 89 f8 48 89
> f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
> f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f6b48ccf318 EFLAGS: 00000246 ORIG_RAX: 000000000000001c
> RAX: ffffffffffffffda RBX: 00007f6b48af0048 RCX: 00007f6b48a4eef9
> RDX: 0000000000000019 RSI: 0000000000600003 RDI: 0000000020000000
> RBP: 00007f6b48af0040 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6b48aa53a4
> R13: 00007f6b48bffcbf R14: 00007f6b48ccf400 R15: 0000000000022000
>  </TASK>
> 
> It is because khugepaged allocates pages with __GFP_THISNODE, but the
> preferred node is offlined.  The previous patch fixed the khugepaged

I would go and call it out s@offlined@bogus@

> code to avoid allocating page from non-existing node.  But it is still
> racy against memory hotremove.  There is no synchronization with the
> memory hotplug so it is possible that memory gets offline during a
> longer taking scanning.
> 
> So this warning still seems not quite helpful because:
>   * There is no guarantee the node is online for __GFP_THISNODE context
>     for all the callsites.
>   * Kernel just fails the allocation regardless the warning, and it looks
>     all callsites handle the allocation failure gracefully.
> 
> It is actually even harmful for those running in panic-on-warn mode.  So
> removing the warning seems like a good move.

And I would rephrased this as well to:

So while the warning has helped to identify a buggy code it is not safe
in general and this warning could panic the system with panic-on-warn 
configuration which tends to be used surprisingly often.

> Reported-by: syzbot+0044b22d177870ee974f@syzkaller.appspotmail.com
> Signed-off-by: Yang Shi <shy828301@gmail.com>
> Reviewed-by: Zach O'Keefe <zokeefe@google.com>
> Acked-by: Michal Hocko <mhocko@suse.com>

Btw. while you are at it. Considering the warning has helped to identify
a buggy code, do you think it would make sense to chage it to
---
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index ef4aea3b356e..308daafc4871 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -227,7 +227,10 @@ static inline
 struct folio *__folio_alloc_node(gfp_t gfp, unsigned int order, int nid)
 {
 	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
-	VM_WARN_ON((gfp & __GFP_THISNODE) && !node_online(nid));
+	if((gfp & __GFP_THISNODE) && !node_online(nid)) {
+		pr_warn("%pGg allocation from offline node %d\n", &gfp, nid);
+		dump_stack();
+	}
 
 	return __folio_alloc(gfp, order, nid, NULL);
 }
Michal Hocko Nov. 4, 2022, 9:56 a.m. UTC | #2 
On Fri 04-11-22 10:35:21, Michal Hocko wrote:
[...]
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index ef4aea3b356e..308daafc4871 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -227,7 +227,10 @@ static inline
>  struct folio *__folio_alloc_node(gfp_t gfp, unsigned int order, int nid)
>  {
>  	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> -	VM_WARN_ON((gfp & __GFP_THISNODE) && !node_online(nid));
> +	if((gfp & __GFP_THISNODE) && !node_online(nid)) {

or maybe even better
	if ((gfp & (__GFP_THISNODE|__GFP_NOWARN) == __GFP_THISNODE|__GFP_NOWARN) && !node_online(nid))

because it doesn't really make much sense to dump this information if
the allocation failure is going to provide sufficient (and even more
comprehensive) context for the failure. It looks more hairy but this can
be hidden in a nice little helper shared between the two callers.

> +		pr_warn("%pGg allocation from offline node %d\n", &gfp, nid);
> +		dump_stack();
> +	}
>  
>  	return __folio_alloc(gfp, order, nid, NULL);
>  }
> -- 
> Michal Hocko
> SUSE Labs
Yang Shi Nov. 4, 2022, 5:42 p.m. UTC | #3 
On Fri, Nov 4, 2022 at 2:56 AM Michal Hocko <mhocko@suse.com> wrote:
>
> On Fri 04-11-22 10:35:21, Michal Hocko wrote:
> [...]
> > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > index ef4aea3b356e..308daafc4871 100644
> > --- a/include/linux/gfp.h
> > +++ b/include/linux/gfp.h
> > @@ -227,7 +227,10 @@ static inline
> >  struct folio *__folio_alloc_node(gfp_t gfp, unsigned int order, int nid)
> >  {
> >       VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> > -     VM_WARN_ON((gfp & __GFP_THISNODE) && !node_online(nid));
> > +     if((gfp & __GFP_THISNODE) && !node_online(nid)) {
>
> or maybe even better
>         if ((gfp & (__GFP_THISNODE|__GFP_NOWARN) == __GFP_THISNODE|__GFP_NOWARN) && !node_online(nid))
>
> because it doesn't really make much sense to dump this information if
> the allocation failure is going to provide sufficient (and even more
> comprehensive) context for the failure. It looks more hairy but this can
> be hidden in a nice little helper shared between the two callers.

Thanks a lot for the suggestion, printing warning if the gfp flag
allows sounds like a good idea to me. Will adopt it. But the check
should look like:

if ((gfp & __GFP_THISNODE) && !(gfp & __GFP_NOWARN) && !node_online(nid))

>
> > +             pr_warn("%pGg allocation from offline node %d\n", &gfp, nid);
> > +             dump_stack();
> > +     }
> >
> >       return __folio_alloc(gfp, order, nid, NULL);
> >  }
> > --
> > Michal Hocko
> > SUSE Labs
>
> --
> Michal Hocko
> SUSE Labs
Michal Hocko Nov. 4, 2022, 7:51 p.m. UTC | #4 
On Fri 04-11-22 10:42:45, Yang Shi wrote:
> On Fri, Nov 4, 2022 at 2:56 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Fri 04-11-22 10:35:21, Michal Hocko wrote:
> > [...]
> > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > > index ef4aea3b356e..308daafc4871 100644
> > > --- a/include/linux/gfp.h
> > > +++ b/include/linux/gfp.h
> > > @@ -227,7 +227,10 @@ static inline
> > >  struct folio *__folio_alloc_node(gfp_t gfp, unsigned int order, int nid)
> > >  {
> > >       VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> > > -     VM_WARN_ON((gfp & __GFP_THISNODE) && !node_online(nid));
> > > +     if((gfp & __GFP_THISNODE) && !node_online(nid)) {
> >
> > or maybe even better
> >         if ((gfp & (__GFP_THISNODE|__GFP_NOWARN) == __GFP_THISNODE|__GFP_NOWARN) && !node_online(nid))
> >
> > because it doesn't really make much sense to dump this information if
> > the allocation failure is going to provide sufficient (and even more
> > comprehensive) context for the failure. It looks more hairy but this can
> > be hidden in a nice little helper shared between the two callers.
> 
> Thanks a lot for the suggestion, printing warning if the gfp flag
> allows sounds like a good idea to me. Will adopt it. But the check
> should look like:
> 
> if ((gfp & __GFP_THISNODE) && !(gfp & __GFP_NOWARN) && !node_online(nid))

The idea was to warn if __GFP_NOWARN _was_ specified. Otherwise we will
get an allocation failure splat from the page allocator and there it
will be clear that the node doesn't have any memory associated. It is
exactly __GFP_NOWARN case that would be a silent failure and potentially
a buggy code (like this THP collapse path). See my point?
Yang Shi Nov. 4, 2022, 8:52 p.m. UTC | #5 
On Fri, Nov 4, 2022 at 12:51 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Fri 04-11-22 10:42:45, Yang Shi wrote:
> > On Fri, Nov 4, 2022 at 2:56 AM Michal Hocko <mhocko@suse.com> wrote:
> > >
> > > On Fri 04-11-22 10:35:21, Michal Hocko wrote:
> > > [...]
> > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > > > index ef4aea3b356e..308daafc4871 100644
> > > > --- a/include/linux/gfp.h
> > > > +++ b/include/linux/gfp.h
> > > > @@ -227,7 +227,10 @@ static inline
> > > >  struct folio *__folio_alloc_node(gfp_t gfp, unsigned int order, int nid)
> > > >  {
> > > >       VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> > > > -     VM_WARN_ON((gfp & __GFP_THISNODE) && !node_online(nid));
> > > > +     if((gfp & __GFP_THISNODE) && !node_online(nid)) {
> > >
> > > or maybe even better
> > >         if ((gfp & (__GFP_THISNODE|__GFP_NOWARN) == __GFP_THISNODE|__GFP_NOWARN) && !node_online(nid))
> > >
> > > because it doesn't really make much sense to dump this information if
> > > the allocation failure is going to provide sufficient (and even more
> > > comprehensive) context for the failure. It looks more hairy but this can
> > > be hidden in a nice little helper shared between the two callers.
> >
> > Thanks a lot for the suggestion, printing warning if the gfp flag
> > allows sounds like a good idea to me. Will adopt it. But the check
> > should look like:
> >
> > if ((gfp & __GFP_THISNODE) && !(gfp & __GFP_NOWARN) && !node_online(nid))
>
> The idea was to warn if __GFP_NOWARN _was_ specified. Otherwise we will
> get an allocation failure splat from the page allocator and there it
> will be clear that the node doesn't have any memory associated. It is
> exactly __GFP_NOWARN case that would be a silent failure and potentially
> a buggy code (like this THP collapse path). See my point?

Aha, yeah, see your point now. I didn't see the splat from the
allocator from the bug report, then I realized it had not called into
allocator yet before the warning was triggered.

> --
> Michal Hocko
> SUSE Labs
Michal Hocko Nov. 7, 2022, 7:55 a.m. UTC | #6 
On Fri 04-11-22 13:52:52, Yang Shi wrote:
> On Fri, Nov 4, 2022 at 12:51 PM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Fri 04-11-22 10:42:45, Yang Shi wrote:
> > > On Fri, Nov 4, 2022 at 2:56 AM Michal Hocko <mhocko@suse.com> wrote:
> > > >
> > > > On Fri 04-11-22 10:35:21, Michal Hocko wrote:
> > > > [...]
> > > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > > > > index ef4aea3b356e..308daafc4871 100644
> > > > > --- a/include/linux/gfp.h
> > > > > +++ b/include/linux/gfp.h
> > > > > @@ -227,7 +227,10 @@ static inline
> > > > >  struct folio *__folio_alloc_node(gfp_t gfp, unsigned int order, int nid)
> > > > >  {
> > > > >       VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> > > > > -     VM_WARN_ON((gfp & __GFP_THISNODE) && !node_online(nid));
> > > > > +     if((gfp & __GFP_THISNODE) && !node_online(nid)) {
> > > >
> > > > or maybe even better
> > > >         if ((gfp & (__GFP_THISNODE|__GFP_NOWARN) == __GFP_THISNODE|__GFP_NOWARN) && !node_online(nid))
> > > >
> > > > because it doesn't really make much sense to dump this information if
> > > > the allocation failure is going to provide sufficient (and even more
> > > > comprehensive) context for the failure. It looks more hairy but this can
> > > > be hidden in a nice little helper shared between the two callers.
> > >
> > > Thanks a lot for the suggestion, printing warning if the gfp flag
> > > allows sounds like a good idea to me. Will adopt it. But the check
> > > should look like:
> > >
> > > if ((gfp & __GFP_THISNODE) && !(gfp & __GFP_NOWARN) && !node_online(nid))
> >
> > The idea was to warn if __GFP_NOWARN _was_ specified. Otherwise we will
> > get an allocation failure splat from the page allocator and there it
> > will be clear that the node doesn't have any memory associated. It is
> > exactly __GFP_NOWARN case that would be a silent failure and potentially
> > a buggy code (like this THP collapse path). See my point?
> 
> Aha, yeah, see your point now. I didn't see the splat from the
> allocator from the bug report, then I realized it had not called into
> allocator yet before the warning was triggered.

And it would trigger even if it did because GFP_TRANSHUGE has
__GFP_NOWARN
Yang Shi Nov. 7, 2022, 6:48 p.m. UTC | #7 
On Sun, Nov 6, 2022 at 11:55 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Fri 04-11-22 13:52:52, Yang Shi wrote:
> > On Fri, Nov 4, 2022 at 12:51 PM Michal Hocko <mhocko@suse.com> wrote:
> > >
> > > On Fri 04-11-22 10:42:45, Yang Shi wrote:
> > > > On Fri, Nov 4, 2022 at 2:56 AM Michal Hocko <mhocko@suse.com> wrote:
> > > > >
> > > > > On Fri 04-11-22 10:35:21, Michal Hocko wrote:
> > > > > [...]
> > > > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > > > > > index ef4aea3b356e..308daafc4871 100644
> > > > > > --- a/include/linux/gfp.h
> > > > > > +++ b/include/linux/gfp.h
> > > > > > @@ -227,7 +227,10 @@ static inline
> > > > > >  struct folio *__folio_alloc_node(gfp_t gfp, unsigned int order, int nid)
> > > > > >  {
> > > > > >       VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> > > > > > -     VM_WARN_ON((gfp & __GFP_THISNODE) && !node_online(nid));
> > > > > > +     if((gfp & __GFP_THISNODE) && !node_online(nid)) {
> > > > >
> > > > > or maybe even better
> > > > >         if ((gfp & (__GFP_THISNODE|__GFP_NOWARN) == __GFP_THISNODE|__GFP_NOWARN) && !node_online(nid))
> > > > >
> > > > > because it doesn't really make much sense to dump this information if
> > > > > the allocation failure is going to provide sufficient (and even more
> > > > > comprehensive) context for the failure. It looks more hairy but this can
> > > > > be hidden in a nice little helper shared between the two callers.
> > > >
> > > > Thanks a lot for the suggestion, printing warning if the gfp flag
> > > > allows sounds like a good idea to me. Will adopt it. But the check
> > > > should look like:
> > > >
> > > > if ((gfp & __GFP_THISNODE) && !(gfp & __GFP_NOWARN) && !node_online(nid))
> > >
> > > The idea was to warn if __GFP_NOWARN _was_ specified. Otherwise we will
> > > get an allocation failure splat from the page allocator and there it
> > > will be clear that the node doesn't have any memory associated. It is
> > > exactly __GFP_NOWARN case that would be a silent failure and potentially
> > > a buggy code (like this THP collapse path). See my point?
> >
> > Aha, yeah, see your point now. I didn't see the splat from the
> > allocator from the bug report, then I realized it had not called into
> > allocator yet before the warning was triggered.
>
> And it would trigger even if it did because GFP_TRANSHUGE has
> __GFP_NOWARN

Yeah, the syzbot has panic on warn set, so kernel just panicked before
entering the allocator.

> --
> Michal Hocko
> SUSE Labs
Zach O'Keefe Nov. 8, 2022, 12:58 a.m. UTC | #8 
On Nov 07 10:48, Yang Shi wrote:
> On Sun, Nov 6, 2022 at 11:55 PM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Fri 04-11-22 13:52:52, Yang Shi wrote:
> > > On Fri, Nov 4, 2022 at 12:51 PM Michal Hocko <mhocko@suse.com> wrote:
> > > >
> > > > On Fri 04-11-22 10:42:45, Yang Shi wrote:
> > > > > On Fri, Nov 4, 2022 at 2:56 AM Michal Hocko <mhocko@suse.com> wrote:
> > > > > >
> > > > > > On Fri 04-11-22 10:35:21, Michal Hocko wrote:
> > > > > > [...]
> > > > > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > > > > > > index ef4aea3b356e..308daafc4871 100644
> > > > > > > --- a/include/linux/gfp.h
> > > > > > > +++ b/include/linux/gfp.h
> > > > > > > @@ -227,7 +227,10 @@ static inline
> > > > > > >  struct folio *__folio_alloc_node(gfp_t gfp, unsigned int order, int nid)
> > > > > > >  {
> > > > > > >       VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> > > > > > > -     VM_WARN_ON((gfp & __GFP_THISNODE) && !node_online(nid));
> > > > > > > +     if((gfp & __GFP_THISNODE) && !node_online(nid)) {
> > > > > >
> > > > > > or maybe even better
> > > > > >         if ((gfp & (__GFP_THISNODE|__GFP_NOWARN) == __GFP_THISNODE|__GFP_NOWARN) && !node_online(nid))
> > > > > >
> > > > > > because it doesn't really make much sense to dump this information if
> > > > > > the allocation failure is going to provide sufficient (and even more
> > > > > > comprehensive) context for the failure. It looks more hairy but this can
> > > > > > be hidden in a nice little helper shared between the two callers.
> > > > >
> > > > > Thanks a lot for the suggestion, printing warning if the gfp flag
> > > > > allows sounds like a good idea to me. Will adopt it. But the check
> > > > > should look like:
> > > > >
> > > > > if ((gfp & __GFP_THISNODE) && !(gfp & __GFP_NOWARN) && !node_online(nid))
> > > >
> > > > The idea was to warn if __GFP_NOWARN _was_ specified. Otherwise we will
> > > > get an allocation failure splat from the page allocator and there it
> > > > will be clear that the node doesn't have any memory associated. It is
> > > > exactly __GFP_NOWARN case that would be a silent failure and potentially
> > > > a buggy code (like this THP collapse path). See my point?
> > >
> > > Aha, yeah, see your point now. I didn't see the splat from the
> > > allocator from the bug report, then I realized it had not called into
> > > allocator yet before the warning was triggered.
> >
> > And it would trigger even if it did because GFP_TRANSHUGE has
> > __GFP_NOWARN
> 
> Yeah, the syzbot has panic on warn set, so kernel just panicked before
> entering the allocator.
> 

Sorry I'm late to the party here.  I think Michal's suggestion is sound --
catches instances like we saw with MADV_COLLAPSE, but no risk of panic-on-warn.
Thanks for the suggestion.

Best,
Zach

> > --
> > Michal Hocko
> > SUSE Labs
diff mbox series

Patch

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index ef4aea3b356e..594d6dee5646 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -218,7 +218,6 @@  static inline struct page *
 __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
 {
 	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
-	VM_WARN_ON((gfp_mask & __GFP_THISNODE) && !node_online(nid));
 
 	return __alloc_pages(gfp_mask, order, nid, NULL);
 }
@@ -227,7 +226,6 @@  static inline
 struct folio *__folio_alloc_node(gfp_t gfp, unsigned int order, int nid)
 {
 	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
-	VM_WARN_ON((gfp & __GFP_THISNODE) && !node_online(nid));
 
 	return __folio_alloc(gfp, order, nid, NULL);
 }