All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zach O'Keefe" <zokeefe@google.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Yang Shi <shy828301@gmail.com>,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: don't warn if the node is offlined
Date: Mon, 31 Oct 2022 17:05:06 -0700	[thread overview]
Message-ID: <CAAa6QmQt9Us8YpirQGXV0_AetuPS+EOqMSGqNn6KW24HXvwO_A@mail.gmail.com> (raw)
In-Reply-To: <Y2BHcBCR2FIJgU4w@dhcp22.suse.cz>

On Mon, Oct 31, 2022 at 3:08 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Mon 31-10-22 11:31:22, 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
>
> This is quite weird, isn't it? alloc_charge_hpage is selecting the most
> busy node (as per collapse_control). How come this can be an offline
> node? Is a parallel memory hotplug happening?

TBH -- I did not look closely at the syzbot reproducer (let alone
attempt to run it) and assumed this was the case. Taking a quick look,
at least memory hot remove is enabled:

CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y
CONFIG_MEMORY_HOTREMOVE=y

But looking at the C reproducer, I don't immediately see anywhere
where we offline nodes. I'll try to run this tomorrow to make sure I'm
not missing something real here.

Thanks,
Zach


> [...]
>
> > It is because khugepaged allocates pages with __GFP_THISNODE, but the
> > preferred node is offlined.  The warning was even stronger before commit
> > 8addc2d00fe17 ("mm: do not warn on offline nodes unless the specific node
> > is explicitly requested").  The commit softened the warning for
> > __GFP_THISNODE.
> >
> > But this warning seems not quite useful because:
> >   * There is no guarantee the node is online for __GFP_THISNODE context
> >     for all the callsites.
>
> The original idea IIRC was to catch a buggy code which mishandled node
> assignment. But this looks like a perfectly valid code. There is no
> synchronization with the memory hotplug so it is possible that memory
> gets offline during a longer taking scanning.
>
> I do agree that the warning is not really helpful in this case. It is
> actually even harmful for those running in panic-on-warn mode.
>
> >   * Kernel just fails the allocation regardless the warning, and it looks
> >     all callsites handle the allocation failure gracefully.
> >
> > So, removing the warning seems like the good move.
> >
> > Reported-by: syzbot+0044b22d177870ee974f@syzkaller.appspotmail.com
> > Signed-off-by: Yang Shi <shy828301@gmail.com>
> > Cc: Zach O'Keefe <zokeefe@google.com>
> > Cc: Michal Hocko <mhocko@suse.com>
>
> Unless I am wrong in my above statement I would appreciate extending the
> changelog to describe the actual code is correct so the warning is
> harmful.
>
> Acked-by: Michal Hocko <mhocko@suse.com>
>
> > ---
> >  include/linux/gfp.h | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > 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);
> >  }
> > --
> > 2.26.3
>
> --
> Michal Hocko
> SUSE Labs

  reply	other threads:[~2022-11-01  0:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31 18:31 [PATCH] mm: don't warn if the node is offlined Yang Shi
2022-10-31 21:16 ` Zach O'Keefe
2022-10-31 22:08 ` Michal Hocko
2022-11-01  0:05   ` Zach O'Keefe [this message]
2022-11-01  7:54     ` Michal Hocko
2022-11-01 17:12       ` Yang Shi
2022-11-01 19:13         ` Zach O'Keefe
2022-11-01 20:09           ` Yang Shi
2022-11-01 22:05             ` Zach O'Keefe
2022-11-02  7:39           ` Michal Hocko
2022-11-02  7:49             ` Michal Hocko
2022-11-02 16:03             ` Yang Shi
2022-11-02 16:15               ` Michal Hocko
2022-11-02 17:36                 ` Yang Shi
2022-11-02 17:47                   ` Michal Hocko
2022-11-02 18:18                     ` Yang Shi
2022-11-02 18:58                       ` Zach O'Keefe
2022-11-02 20:08                         ` Yang Shi
2022-11-02 20:21                           ` Zach O'Keefe
2022-11-03  7:54                           ` Michal Hocko
2022-11-03 17:13                             ` Yang Shi
2022-11-03  7:51                         ` Michal Hocko
2022-11-02  7:14         ` Michal Hocko
2022-11-02 15:58           ` Yang Shi
2022-11-02 16:11             ` Michal Hocko

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=CAAa6QmQt9Us8YpirQGXV0_AetuPS+EOqMSGqNn6KW24HXvwO_A@mail.gmail.com \
    --to=zokeefe@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=shy828301@gmail.com \
    /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: link
Be 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.