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? > > My best guess is that page->index still contains the file index from > > when this page was in the page cache instead of being overwritten with > > the migratetype. > > Yeah that was my guess too. But I couldn't see how that was possible. So started > thinking it could be some separate corruption somehow... It could be, but a value around 10,000 would put the page at being offset 40MB into the file, which is entirely plausible. But yes, it could have been some entirely separate path that freed it. VM_BUG_ON_PAGE() would dump the entire struct page which will give us a lot more clues including the order of the page.
