On Mon, Jul 20, 2020 at 04:51:44PM -0700, Andrew Morton wrote: > On Sun, 19 Jul 2020 14:10:19 -0700 syzbot <syzbot+c48f34012b06c4ac67dd@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > syzbot has found a reproducer for the following issue on: > > > > HEAD commit: 4c43049f Add linux-next specific files for 20200716 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=12c56087100000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=2c76d72659687242 > > dashboard link: https://syzkaller.appspot.com/bug?extid=c48f34012b06c4ac67dd > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1344abeb100000 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+c48f34012b06c4ac67dd@xxxxxxxxxxxxxxxxxxxxxxxxx > > Thanks. > > __handle_mm_fault > ->pmd_migration_entry_wait > ->migration_entry_to_page > > stumbled onto an unlocked page. > > I don't immediately see a cause. Perhaps Matthew's "THP prep patches", > perhaps something else. That's interesting. I'm currently chasing that signature too. Of course, almost anything can cause this. What I do have in my tree is a patch to turn that WARN_ON into a VM_BUG_ON_PAGE and what I see is not just an unlocked page, but one that's been freed. > Is it possible to perform a bisection? My testing (xfstests with the full THP patch set) takes about 45 minutes to hit this bug usually. Sometimes two hours. I haven't tried running it against fewer patches because I thought it was related to having THPs smaller than PMD size in the page cache. I don't think it is my patches because they're essentially just a rename. But of course, I've been wrong before ...
