From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Hugh Dickins <hughd@google.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>,
David Hildenbrand <david@redhat.com>,
akpm@linux-foundation.org, hannes@cmpxchg.org, mhocko@kernel.org,
zhengqi.arch@bytedance.com, lorenzo.stoakes@oracle.com,
willy@infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] mm: vmscan: remove folio_test_private() check in pageout()
Date: Mon, 22 Sep 2025 14:02:28 +0800 [thread overview]
Message-ID: <392a9ca3-31ac-4447-bd44-3c656d63e4ca@linux.alibaba.com> (raw)
In-Reply-To: <74e0af46-18a0-8c4a-5ae5-3cba69ca77bd@google.com>
On 2025/9/22 13:32, Hugh Dickins wrote:
> On Fri, 19 Sep 2025, Baolin Wang wrote:
>> On 2025/9/19 09:06, Shakeel Butt wrote:
>>> On Thu, Sep 18, 2025 at 05:36:17PM +0800, Baolin Wang wrote:
>>>> On 2025/9/18 14:00, David Hildenbrand wrote:
>>>>> On 18.09.25 05:46, Baolin Wang wrote:
> ...
>>>>>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>>>>>> index f1fc36729ddd..930add6d90ab 100644
>>>>>> --- a/mm/vmscan.c
>>>>>> +++ b/mm/vmscan.c
>>>>>> @@ -701,16 +701,10 @@ static pageout_t pageout(struct folio *folio,
>>>>>> struct address_space *mapping,
>>>>>> return PAGE_KEEP;
>>>>>> if (!mapping) {
>>>>>> /*
>>>>>> - * Some data journaling orphaned folios can have
>>>>>> - * folio->mapping == NULL while being dirty with clean buffers.
>>>>>> + * Is it still possible to have a dirty folio with
>>>>>> + * a NULL mapping? I think not.
>>>>>> */
>>>>>
>>>>> I would rephrase slightly (removing the "I think not"):
>>>>>
>>>>> /*
>>>>> * We should no longer have dirty folios with clean buffers and a NULL
>>>>> * mapping. However, let's be careful for now.
>>>>> */
>>>>
>>>> LGTM.
>>>>
>>>> Andrew, could you help squash these comments into this patch? Thanks.
>
> (Myself, I would delete the comment entirely: it's justifying the change,
> which is good history to go into the commit message, but not so good in
> the final source. And we don't fully understand what to say here anyway.)
>
>>>>
>>>>>> - if (folio_test_private(folio)) {
>>>>>> - if (try_to_free_buffers(folio)) {
>>>>>> - folio_clear_dirty(folio);
>>>>>> - pr_info("%s: orphaned folio\n", __func__);
>>>>>> - return PAGE_CLEAN;
>>>>>> - }
>>>>>> - }
>>>>>> + VM_WARN_ON_FOLIO(true, folio);
>>>
>>> Unexpected but better to use VM_WARN_ON_ONCE_FOLIO here.
>>
>> Um, I don't think it makes much difference, because we should no longer hit
>> this.
>
> We do hit it. Observe, there was no WARNING before in the !mapping
> case, just a pr_info in a particular instance of the !mapping case.
> We believe that instance went away with reiserfs, but that does not
> imply that there are no more !mapping cases left.
>
> We do hit that WARNING: not often, and I've not seen it repeatedly
> (as ONCE-advisors fear), but a few cutdown examples from my testing
> appended below.
Thanks for reporting. That surprises me how that happened.
> I'm sure you'd like me to explain how it comes about: I did spend a
> while looking to do so, but then found better things to do. By all
> means go in search of the explanation if it's worth your time: it
> might indicate a bug somewhere; but more likely it's just a race
> against code elsewhere cleaning up the folio.
Interesting. I'll try to reproduce this issue.
> The fact that it does not appear repeatedly suggests that the folio
> is successfully dealt with afterwards. I didn't think to check at
> first, but in later runs did check back on such folios after, and
> verified that they had moved on to being freed and reused, not leaked.
No leaks, good.
> The examples I've seen have all been swapbacked, though that may
> just reflect my tmpfs swapping load. With mapping NULLed, there's
> not much to go on: but index 0x7ff5ce103 is likely to have been
> anon, and index 0xcff more likely to have been tmpfs.
>
> My vote is simply to delete the warning (and the comment).
Thanks for your examples and sound reasonable to me.
Andrew, could you help squash the following changes (if you need a new
version, please let me know)? Thanks.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4907e255857a..aadbee50a851 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -689,16 +689,8 @@ static pageout_t pageout(struct folio *folio,
struct address_space *mapping,
* A freeable shmem or swapcache folio is referenced only by the
* caller that isolated the folio and the page cache.
*/
- if (folio_ref_count(folio) != 1 + folio_nr_pages(folio))
+ if (folio_ref_count(folio) != 1 + folio_nr_pages(folio) || !mapping)
return PAGE_KEEP;
- if (!mapping) {
- /*
- * We should no longer have dirty folios with clean
buffers and
- * a NULL mapping. However, let's be careful for now.
- */
- VM_WARN_ON_FOLIO(true, folio);
- return PAGE_KEEP;
- }
if (!shmem_mapping(mapping) && !folio_test_anon(folio))
return PAGE_ACTIVATE;
next prev parent reply other threads:[~2025-09-22 6:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 3:46 [PATCH v2 0/2] some cleanups for pageout() Baolin Wang
2025-09-18 3:46 ` [PATCH v2 1/2] mm: vmscan: remove folio_test_private() check in pageout() Baolin Wang
2025-09-18 6:00 ` David Hildenbrand
2025-09-18 9:36 ` Baolin Wang
2025-09-19 1:06 ` Shakeel Butt
2025-09-19 2:12 ` Baolin Wang
2025-09-19 8:00 ` David Hildenbrand
2025-09-22 5:32 ` Hugh Dickins
2025-09-22 6:02 ` Baolin Wang [this message]
2025-09-18 3:46 ` [PATCH v2 2/2] mm: vmscan: simplify the folio refcount " Baolin Wang
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=392a9ca3-31ac-4447-bd44-3c656d63e4ca@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=willy@infradead.org \
--cc=zhengqi.arch@bytedance.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox