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:   Thu, 22 Oct 2020 01:49:06 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     Qian Cai <cai@lca.pw>
Cc:     Christoph Hellwig <hch@infradead.org>,
        "Darrick J. Wong" <darrick.wong@oracle.com>,
        linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
        linux-mm@kvack.org
Subject: Re: kernel BUG at mm/page-writeback.c:2241 [
 BUG_ON(PageWriteback(page); ]
Message-ID: <20201022004906.GQ20115@casper.infradead.org>
References: <645a3f332f37e09057c10bc32f4f298ce56049bb.camel@lca.pw>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <645a3f332f37e09057c10bc32f4f298ce56049bb.camel@lca.pw>
Precedence: bulk

On Wed, Oct 21, 2020 at 08:30:18PM -0400, Qian Cai wrote:
> Today's linux-next starts to trigger this wondering if anyone has any clue.

I've seen that occasionally too.  I changed that BUG_ON to VM_BUG_ON_PAGE
to try to get a clue about it.  Good to know it's not the THP patches
since they aren't in linux-next.

I don't understand how it can happen.  We have the page locked, and then we do:

                        if (PageWriteback(page)) {
                                if (wbc->sync_mode != WB_SYNC_NONE)
                                        wait_on_page_writeback(page);
                                else
                                        goto continue_unlock;
                        }

                        VM_BUG_ON_PAGE(PageWriteback(page), page);

Nobody should be able to put this page under writeback while we have it
locked ... right?  The page can be redirtied by the code that's supposed
to be writing it back, but I don't see how anyone can make PageWriteback
true while we're holding the page lock.