Re: [failures] mm-vmalloc-print-a-warning-message-first-on-failure.patch removed from -mm tree

From: Uladzislau Rezki <urezki@gmail.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Uladzislau Rezki <urezki@gmail.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	Hillf Danton <hdanton@sina.com>, Michal Hocko <mhocko@suse.com>,
	mm-commits@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>,
	Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [failures] mm-vmalloc-print-a-warning-message-first-on-failure.patch removed from -mm tree
Date: Thu, 13 May 2021 22:18:51 +0200	[thread overview]
Message-ID: <20210513201851.GA55390@pc638.lan> (raw)
In-Reply-To: <20210513155133.GN3672@suse.de>

On Thu, May 13, 2021 at 04:51:33PM +0100, Mel Gorman wrote:
> On Thu, May 13, 2021 at 05:29:05PM +0200, Uladzislau Rezki wrote:
> > Could you please send your config? I will try to reproduce with it.
> > 
> 
> Attached.
> 
Thanks.

With your .config file i am able to reproduce the kernel panic. Actually
when a one page is requested the __alloc_pages_bulk() enters to the single
page allocator:

<snip>
    /* Use the single page allocator for one page. */
    if (nr_pages - nr_populated == 1)
        goto failed;

...

failed:
    page = __alloc_pages(gfp, 0, preferred_nid, nodemask);
    if (page) {
        if (page_list)
            list_add(&page->lru, page_list);
        else
            page_array[nr_populated] = page;
                nr_populated++;
    }

    return nr_populated;
<snip>

From the trace i get:

<snip>
[    0.243916] RIP: 0010:__alloc_pages+0x11e/0x310
[    0.243916] Code: 84 c0 0f 85 02 01 00 00 89 d8 48 8b 54 24 08 8b 74 24 1c c1 e8 0c 83 e0 01 88 44 24 20 48 8b 04 24 48 85 d2 0f 85 71 01 00 00 <3b> 70 08 0f 82 68 01 00 00 48 89 44 24 10 48 8b 00 89 da 81 e2 00
[    0.243916] RSP: 0000:ffffffffae803c38 EFLAGS: 00010246
[    0.243916] RAX: 0000000000001cc0 RBX: 0000000000002102 RCX: 0000000000000004
[    0.243916] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000002102
[    0.243916] RBP: 0000000000000000 R08: 0000000000000000 R09: c0000000ffffdfff
[    0.243916] R10: 0000000000000001 R11: ffffffffae803ac0 R12: 0000000000000000
[    0.243916] R13: 0000000000002102 R14: 0000000000000001 R15: ffffa0938000d000
[    0.243916] FS:  0000000000000000(0000) GS:ffff893ab7c00000(0000) knlGS:0000000000000000
[    0.243916] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.243916] CR2: 0000000000001cc8 CR3: 0000000176e10000 CR4: 00000000000006b0
[    0.243916] Call Trace:
[    0.243916]  __alloc_pages_bulk+0xaa1/0xb50
<snip>

(gdb) l *__alloc_pages+0x11e
0xffffffff8129d87e is in __alloc_pages (./include/linux/mmzone.h:1095).
1090            return zoneref->zone;
1091    }
1092
1093    static inline int zonelist_zone_idx(struct zoneref *zoneref)
1094    {
1095            return zoneref->zone_idx;
1096    }
1097
1098    static inline int zonelist_node_idx(struct zoneref *zoneref)
1099    {
(gdb)

Seems like "zoneref" refers to invalid address.

Thoughts?

--
Vlad Rezki