linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>,
	Nhat Pham <nphamcs@gmail.com>, Yang Shi <shy828301@gmail.com>,
	Zi Yan <ziy@nvidia.com>, Barry Song <baohua@kernel.org>,
	David Hildenbrand <david@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH hotfix] mm: fix crashes from deferred split racing folio migration
Date: Thu, 4 Jul 2024 14:12:00 +0800	[thread overview]
Message-ID: <7b7f2eb7-953a-4aa0-acb0-1ab32c7cc1bf@huawei.com> (raw)
In-Reply-To: <825653a7-a4d4-89f2-278f-4b18f8f8da5d@google.com>



On 2024/7/4 11:21, Hugh Dickins wrote:
> On Wed, 3 Jul 2024, Andrew Morton wrote:
>> On Tue, 2 Jul 2024 00:40:55 -0700 (PDT) Hugh Dickins <hughd@google.com> wrote:
>>
...
> 
> And perhaps a conflict with another one of Kefeng's, which deletes a hunk
> in mm/migrate.c just above where I add a hunk: and that's indeed how it
> should end up, hunk deleted by Kefeng, hunk added by me.
> 
>>
>> --- mm/memcontrol.c~mm-refactor-folio_undo_large_rmappable
>> +++ mm/memcontrol.c
>> @@ -7832,8 +7832,7 @@ void mem_cgroup_migrate(struct folio *ol
>>   	 * In addition, the old folio is about to be freed after migration, so
>>   	 * removing from the split queue a bit earlier seems reasonable.
>>   	 */
>> -	if (folio_test_large(old) && folio_test_large_rmappable(old))
>> -		folio_undo_large_rmappable(old);
>> +	folio_undo_large_rmappable(old);
>>   	old->memcg_data = 0;
>>   }
>>
>> I'm resolving this by simply dropping the above hunk.  So Kefeng's
>> patch is now as below.  Please check.
> 
> Checked, and that is correct, thank you Andrew.  Correct, but not quite
> complete: because I'm sure that if Kefeng had written his patch after
> mine, he would have made the equivalent change in mm/migrate.c:
> 

Yes,

> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -443,8 +443,7 @@ int folio_migrate_mapping(struct address_space *mapping,
>   	}
>   
>   	/* Take off deferred split queue while frozen and memcg set */
> -	if (folio_test_large(folio) && folio_test_large_rmappable(folio))
> -		folio_undo_large_rmappable(folio);
> +	folio_undo_large_rmappable(folio);
>   
>   	/*
>   	 * Now we know that no one else is looking at the folio:
> 
> But there's no harm done if you push out a tree without that additional
> mod: we can add it as a fixup afterwards, it's no more than a cleanup.
> 
Maybe we could convert to __folio_undo_large_rmappable() for !maping 
part, which will avoid unnecessary freeze/unfreeze for empty deferred
list.

diff --git a/mm/migrate.c b/mm/migrate.c
index ca65f03acb31..e6af9c25c25b 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -412,10 +412,11 @@ static int __folio_migrate_mapping(struct 
address_space *mapping,
         if (!mapping) {
                 /* Take off deferred split queue while frozen and memcg 
set */
                 if (folio_test_large(folio) &&
-                   folio_test_large_rmappable(folio)) {
+                   folio_test_large_rmappable(folio) &&
+                   !data_race(list_empty(&folio->_deferred_list))) {
                         if (!folio_ref_freeze(folio, expected_count))
                                 return -EAGAIN;
-                       folio_undo_large_rmappable(folio);
+                       __folio_undo_large_rmappable(folio);
                         folio_ref_unfreeze(folio, expected_count);
                 }


> (I'm on the lookout for an mm.git update, hope to give it a try when it
> appears.)
> 
> Thanks,
> Hugh
> 


  parent reply	other threads:[~2024-07-04  6:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-02  7:40 Hugh Dickins
2024-07-02  9:25 ` Baolin Wang
2024-07-02 16:15   ` Hugh Dickins
2024-07-03  1:51     ` Baolin Wang
2024-07-03  2:13     ` Andrew Morton
2024-07-03 14:30 ` Zi Yan
2024-07-03 16:21   ` David Hildenbrand
2024-07-03 16:22     ` Zi Yan
2024-07-04  2:35 ` Andrew Morton
2024-07-04  3:21   ` Hugh Dickins
2024-07-04  3:28     ` Andrew Morton
2024-07-04  6:12     ` Kefeng Wang [this message]
2024-07-06 21:29       ` Hugh Dickins
2024-07-07  2:11         ` Andrew Morton
2024-07-07  3:07           ` Kefeng Wang
2024-07-07  8:28         ` David Hildenbrand

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=7b7f2eb7-953a-4aa0-acb0-1ab32c7cc1bf@huawei.com \
    --to=wangkefeng.wang@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=shy828301@gmail.com \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.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