From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: David Hildenbrand <david@redhat.com>,
Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>,
Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>
Cc: Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Matthew Wilcox <willy@infradead.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: 6.9/BUG: Bad page state in process kswapd0 pfn:d6e840
Date: Thu, 30 May 2024 08:07:19 +0930 [thread overview]
Message-ID: <d67dde35-0c14-4da2-8628-f4a27c32417a@gmx.com> (raw)
In-Reply-To: <ff29f723-32de-421b-a65e-7b7d2e03162d@redhat.com>
在 2024/5/29 16:27, David Hildenbrand 写道:
> On 28.05.24 16:24, David Hildenbrand wrote:
[...]
>> Hmm, your original report mentions kswapd, so I'm getting the feeling
>> someone
>> does one folio_put() too much and we are freeing a pageache folio that
>> is still
>> in the pageache and, therefore, has folio->mapping set ... bisecting
>> would
>> really help.
>>
>
> A little bird just told me that I missed an important piece in the dmesg
> output: "aops:btree_aops ino:1" from dump_mapping():
>
> This is btrfs, i_ino is 1, and we don't have a dentry. Is that
> BTRFS_BTREE_INODE_OBJECTID?
>
> Summarizing what we know so far:
> (1) Freeing an order-0 btrfs folio where folio->mapping
> is still set
> (2) Triggered by kswapd and kcompactd; not triggered by other means of
> page freeing so far
From the implementation of filemap_migrate_folio() (and previous
migrate_page_moving_mapping()), it looks like the migration only involves:
- Migrate the mapping
- Copy the page private value
- Copy the contents (if needed)
- Copy all the page flags
The most recent touch on migration is from v6.0, which I do not believe
is the cause at all.
>
> Possible theories:
> (A) folio->mapping not cleared when freeing the folio. But shouldn't
> this also happen on other freeing paths? Or are we simply lucky to
> never trigger that for that folio?
Yeah, in fact we never manually clean folio->mapping inside btrfs, thus
I'm not sure if it's the case.
> (B) Messed-up refcounting: freeing a folio that is still in use (and
> therefore has folio-> mapping still set)
>
> I was briefly wondering if large folio splitting could be involved.
Although we have all the metadata support for larger folios, we do not
yet enable it.
My current guess is, could it be some race with this commit?
09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to
allocate-then-attach method")
For example, when we're allocating an extent buffer (btrfs' metadata
structure), and one page is already attached to the page cache, then the
page is being migrated meanwhile the remaining pages are not yet attached?
It's first introduced in v6.8, matching the earliest report.
But that patch is not easy to revert.
Do you have any extra reproducibility or extra way to debug the lifespan
of that specific patch?
Or is there any way to temporarily disable migration?
Thanks,
Qu
>
> CCing btrfs maintainers.
>
next prev parent reply other threads:[~2024-05-29 22:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 9:55 6.9/BUG: Bad page state in process kswapd0 pfn:d6e840 Mikhail Gavrilov
2024-05-08 10:16 ` Mikhail Gavrilov
2024-05-08 17:45 ` David Hildenbrand
2024-05-09 11:59 ` Mikhail Gavrilov
2024-05-09 17:50 ` David Hildenbrand
2024-05-23 7:05 ` Mikhail Gavrilov
2024-05-28 6:05 ` Mikhail Gavrilov
2024-05-28 13:57 ` David Hildenbrand
2024-05-28 14:24 ` David Hildenbrand
2024-05-29 6:57 ` David Hildenbrand
2024-05-29 19:00 ` David Sterba
2024-05-29 22:37 ` Qu Wenruo [this message]
2024-05-30 5:26 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d67dde35-0c14-4da2-8628-f4a27c32417a@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=clm@fb.com \
--cc=david@redhat.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mikhail.v.gavrilov@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.