Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 21 Jul 2020 01:21:47 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     syzbot <syzbot+c48f34012b06c4ac67dd@syzkaller.appspotmail.com>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        syzkaller-bugs@googlegroups.com,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Ralph Campbell <rcampbell@nvidia.com>,
        David Hildenbrand <david@redhat.com>,
        Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: kernel BUG at include/linux/swapops.h:LINE!
Message-ID: <20200721002147.GA15516@casper.infradead.org>
References: <000000000000bc4fd705a6e090e2@google.com>
 <0000000000004c38cd05aad1d13f@google.com>
 <20200720165144.93189f7825bd28e234a42cb8@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200720165144.93189f7825bd28e234a42cb8@linux-foundation.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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@syzkaller.appspotmail.com> 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@syzkaller.appspotmail.com
> 
> 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 ...