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;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.82\))
Subject: Re: kernel BUG at mm/page-writeback.c:2241 [
 BUG_ON(PageWriteback(page); ]
From:   William Kucharski <william.kucharski@oracle.com>
In-Reply-To: <20201022004906.GQ20115@casper.infradead.org>
Date:   Thu, 22 Oct 2020 07:23:33 -0600
Cc:     Qian Cai <cai@lca.pw>, 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
Content-Transfer-Encoding: quoted-printable
Message-Id: <361D9B8E-CE8F-4BA0-8076-8384C2B7E860@oracle.com>
References: <645a3f332f37e09057c10bc32f4f298ce56049bb.camel@lca.pw>
 <20201022004906.GQ20115@casper.infradead.org>
To:     Matthew Wilcox <willy@infradead.org>
Precedence: bulk


> On Oct 21, 2020, at 6:49 PM, Matthew Wilcox <willy@infradead.org> =
wrote:
>=20
> 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.
>=20
> 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.
>=20
> I don't understand how it can happen.  We have the page locked, and =
then we do:
>=20
>                        if (PageWriteback(page)) {
>                                if (wbc->sync_mode !=3D WB_SYNC_NONE)
>                                        wait_on_page_writeback(page);
>                                else
>                                        goto continue_unlock;
>                        }
>=20
>                        VM_BUG_ON_PAGE(PageWriteback(page), page);
>=20
> 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.

Looking at __test_set_page_writeback(), I see that it (and most other
callers to lock_page_memcg()) do the following:

  lock_page_memcg(page)

  /* do other stuff */

  ret =3D TestSetPageWriteback(page);

  /* do more stuff */

  unlock_page_memcg(page)

yet lock_page_memcg() does have a few cases where it can (silently)
return NULL to indicate an error.

Only test_clear_page_writeback() actually saves off the return value
(but it too never bothers to check whether it is NULL or not.)

Could it be one of those error conditions is occurring leading to no
lock actually being taken?

The conditions would be extremely rare, but it feels wrong not to check
somewhere:

	  struct page *head =3D compound_head(page); /* rmap on tail =
pages */

[ ... ]

          if (mem_cgroup_disabled())
              return NULL;
  again:
          memcg =3D head->mem_cgroup;
          if (unlikely(!memcg))
                  return NULL;