On Wed, Jan 02, 2019 at 02:50:05PM -0800, Matthew Wilcox wrote: > On Wed, Jan 02, 2019 at 01:25:31PM -0800, Matthew Wilcox wrote: > > On Thu, Jan 03, 2019 at 08:13:32AM +1100, Dave Chinner wrote: > > > Hi folks, > > > > > > An overnight test run on a current TOT kernel failed generic/413 > > > with the following dmesg output: > > > > > > [ 9487.276402] RIP: 0010:__follow_pte_pmd+0x22d/0x340 > > > [ 9487.305065] Call Trace: > > > [ 9487.307310] dax_entry_mkclean+0xbb/0x1f0 > > > > We've only got one commit touching dax_entry_mkclean and it's Jerome's. > > Looking through ac46d4f3c43241ffa23d5bf36153a0830c0e02cc, I'd say > > it's missing a call to mmu_notifier_range_init(). > > Could I persuade you to give this a try? Yup, that fixes it. And looking at the code, the dax mmu notifier code clearly wasn't tested. i.e. dax_entry_mkclean() is the *only* code that exercises the conditional range parameter code paths inside __follow_pte_pmd(). This means it wasn't tested before it was proposed for inclusion and since inclusion no-one using -akpm, linux-next or the current mainline TOT has done any filesystem DAX testing until I tripped over it. IOws, this is the second "this was never tested before it was merged into mainline" XFS regression that I've found in the last 3 weeks. Both commits have been merged through the -akpm tree, and that implies we currently have no significant filesystem QA coverage on changes being merged through this route. This seems like an area that needs significant improvement to me.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
