On Tue, Sep 05, 2023 at 03:00:51PM +0100, Matthew Wilcox wrote:
> On Tue, Sep 05, 2023 at 02:26:54PM +0100, Ryan Roberts wrote:
> > On 05/09/2023 14:15, Matthew Wilcox wrote:
> > > On Mon, Sep 04, 2023 at 02:25:41PM +0100, Ryan Roberts wrote:
> > >> I've been doing some benchmarking of this series, as promised, but have hit an oops. It doesn't appear to be easily reproducible, and I'm struggling to figure out the root cause, so thought I would share in case you have any ideas?
> > >
> > > I didn't hit that with my testing. Admittedly I was using xfs rather
> > > than ext4, but ...
> >
> > I've only seen it once.
> >
> > I have a bit of a hybrid setup - my rootfs is xfs (and using large folios), but
> > the linux tree (which is being built during the benchmark) is on an ext4
> > partition. Large anon folios is enabled in this config, so there will be plenty
> > of large folios in the system.
> >
> > I'm not sure if the fact that this fired from the ext4 path is too relevant -
> > the page with the dodgy index is already on the PCP list so may or may not be large.
>
> Indeed. I have a suspicion that this may be more common, but if pages
> are commonly freed to and allocated from the PCP list without ever being
> transferred to the free list, we'll never see it. Perhaps adding a
> check when pages are added to the PCP list that page->index is less
> than 8 would catch the miscreant relatively quickly?
Somehow my qemu setup started working again. This stuff is black magic.
Anyway, I did this:
+++ b/mm/page_alloc.c
@@ -2405,6 +2405,7 @@ static void free_unref_page_commit(struct zone *zone, struct per_cpu_pages *pcp,
__count_vm_events(PGFREE, 1 << order);
pindex = order_to_pindex(migratetype, order);
+ VM_BUG_ON_PAGE(page->index > 7, page);
list_add(&page->pcp_list, &pcp->lists[pindex]);
pcp->count += 1 << order;
but I haven't caught a wascally wabbit yet after an hour of running
xfstests. I think that's the only place we add a page to the
pcp->lists.
