From: "Garg, Shivank" <shivankg@amd.com>
To: "ying.huang@linux.alibaba.com" <ying.huang@linux.alibaba.com>,
"sj@kernel.org" <sj@kernel.org>,
"shakeel.butt@linux.dev" <shakeel.butt@linux.dev>,
"joshua.hahnjy@gmail.com" <joshua.hahnjy@gmail.com>,
"david@kernel.org" <david@kernel.org>,
"mhocko@suse.com" <mhocko@suse.com>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"jack@suse.cz" <jack@suse.cz>,
"kasong@tencent.com" <kasong@tencent.com>,
"rientjes@google.com" <rientjes@google.com>,
"anna@kernel.org" <anna@kernel.org>,
"weixugc@google.com" <weixugc@google.com>,
"jgg@ziepe.ca" <jgg@ziepe.ca>, "corbet@lwn.net" <corbet@lwn.net>,
"gourry@gourry.net" <gourry@gourry.net>,
"Rao, Bharata Bhasker" <bharata@amd.com>,
"byungchul@sk.com" <byungchul@sk.com>,
"yuanchu@google.com" <yuanchu@google.com>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"axelrasmussen@google.com" <axelrasmussen@google.com>,
"rppt@kernel.org" <rppt@kernel.org>,
"seanjc@google.com" <seanjc@google.com>,
"bcrl@kvack.org" <bcrl@kvack.org>,
"nao.horiguchi@gmail.com" <nao.horiguchi@gmail.com>,
"willy@infradead.org" <willy@infradead.org>,
"osalvador@suse.de" <osalvador@suse.de>,
"surenb@google.com" <surenb@google.com>,
"jhubbard@nvidia.com" <jhubbard@nvidia.com>,
"matthew.brost@intel.com" <matthew.brost@intel.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"skhan@linuxfoundation.org" <skhan@linuxfoundation.org>,
"brauner@kernel.org" <brauner@kernel.org>,
"clm@fb.com" <clm@fb.com>,
"qi.zheng@linux.dev" <qi.zheng@linux.dev>,
"baohua@kernel.org" <baohua@kernel.org>,
"rakie.kim@sk.com" <rakie.kim@sk.com>,
"brendan.jackman@linux.dev" <brendan.jackman@linux.dev>,
"dsterba@suse.com" <dsterba@suse.com>,
"apopple@nvidia.com" <apopple@nvidia.com>,
"ziy@nvidia.com" <ziy@nvidia.com>,
"vbabka@kernel.org" <vbabka@kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"ljs@kernel.org" <ljs@kernel.org>,
"linmiaohe@huawei.com" <linmiaohe@huawei.com>,
"muchun.song@linux.dev" <muchun.song@linux.dev>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"yiannis@zptcorp.com" <yiannis@zptcorp.com>,
"shaggy@kernel.org" <shaggy@kernel.org>,
"trondmy@kernel.org" <trondmy@kernel.org>
Cc: "jfs-discussion@lists.sourceforge.net"
<jfs-discussion@lists.sourceforge.net>,
"damon@lists.linux.dev" <damon@lists.linux.dev>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-aio@kvack.org" <linux-aio@kvack.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [sos-linux-ext-patches] [PATCH RFC 09/11] mm/migrate: thread migration policy through a control struct
Date: Wed, 2 Sep 2026 11:19:37 +0000 [thread overview]
Message-ID: <1508939ba49c28e06b9cec344ec6a69ab57ce8ac.camel@amd.com> (raw)
In-Reply-To: <20260902-migrate-refactor-shivank-v1-9-9dcca87669c4@amd.com>
On Wed, 2026-09-02 at 10:52 +0000, Shivank Garg wrote:
> Migration mode and reason describe one migration invocation, but are passed
>
[...]
> @@ -2189,27 +2188,29 @@ static int migrate_folios_batch(struct list_head *from,
> */
> static int __migrate_lru_folios(struct list_head *from, new_folio_t get_new_folio,
> free_folio_t put_new_folio, unsigned long private,
> - enum migrate_mode mode, enum migrate_reason reason,
> - struct list_head *ret_folios,
> + const struct migrate_control *ctl, struct list_head *ret_folios,
> struct migrate_pages_stats *stats)
> {
> int rc, nr_failed = 0;
> LIST_HEAD(folios);
> LIST_HEAD(split_folios);
> struct migrate_pages_stats astats;
> + struct migrate_control async_ctl;
>
> - if (mode == MIGRATE_ASYNC) {
> + if (ctl->mode == MIGRATE_ASYNC) {
> rc = migrate_folios_batch(from, get_new_folio, put_new_folio,
> - private, mode, reason, ret_folios,
> + private, ctl, ret_folios,
> &split_folios, stats,
> NR_MAX_MIGRATE_PAGES_RETRY);
> goto out;
> }
>
> + async_ctl = *ctl;
> + async_ctl.mode = MIGRATE_ASYNC;
> memset(&astats, 0, sizeof(astats));
> /* Try to migrate in batch with MIGRATE_ASYNC mode firstly */
Sashiko:
Can this lead to an uninitialized stack variable being used?
If __migrate_lru_folios() is called with ctl->mode == MIGRATE_ASYNC, the
early check jumps directly to the out label, bypassing the initialization
of async_ctl. If large folios were split during that first pass, the
!list_empty(&split_folios) check will be true.
Could this cause migrate_folios_batch() to execute with garbage policy? For
example, it might interpret the uninitialized async_ctl.mode as MIGRATE_SYNC,
causing unintended blocking and sleeping during what should be an asynchronous
migration.
--
Yes, this is valid issue. I should initialize async_ctl early before it make
goto jump.
---
mm/migrate.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 731836664a86..c75300e00388 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2199,8 +2199,9 @@ static int __migrate_lru_folios(struct list_head *from, new_folio_t get_new_foli
LIST_HEAD(folios);
LIST_HEAD(split_folios);
struct migrate_pages_stats astats;
- struct migrate_control async_ctl;
+ struct migrate_control async_ctl = *ctl;
+ async_ctl.mode = MIGRATE_ASYNC;
if (ctl->mode == MIGRATE_ASYNC) {
rc = migrate_folios_batch(from, get_new_folio, put_new_folio,
private, ctl, ret_folios,
@@ -2209,8 +2210,6 @@ static int __migrate_lru_folios(struct list_head *from, new_folio_t get_new_foli
goto out;
}
- async_ctl = *ctl;
- async_ctl.mode = MIGRATE_ASYNC;
memset(&astats, 0, sizeof(astats));
/* Try to migrate in batch with MIGRATE_ASYNC mode firstly */
rc = migrate_folios_batch(from, get_new_folio, put_new_folio, private,
--
2.43.0
next prev parent reply other threads:[~2026-09-02 11:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 10:52 [PATCH RFC 00/11] mm/migrate: separate migration paths and carry migration policy Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 01/11] mm/migrate: extract folio unmap phase Shivank Garg
2026-09-02 11:02 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 02/11] mm/migrate: handle retries in migrate_folios_move() Shivank Garg
2026-09-02 11:01 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 03/11] mm/migrate: factor out folio splitting on allocation failure Shivank Garg
2026-09-02 11:06 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 04/11] mm/migrate: use a dedicated list for hugetlb folios Shivank Garg
2026-09-02 11:02 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 05/11] mm/migrate: add a dedicated movable_ops migration pass Shivank Garg
2026-09-02 11:04 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 06/11] mm/migrate: rename migrate_pages_batch() to migrate_folios_batch() Shivank Garg
2026-09-02 11:02 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 07/11] mm/migrate: add migrate_lru_folios() entry point Shivank Garg
2026-09-02 11:03 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 08/11] mm/migrate: move LRU batching into migrate_lru_folios() Shivank Garg
2026-09-02 11:00 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 09/11] mm/migrate: thread migration policy through a control struct Shivank Garg
2026-09-02 11:06 ` sashiko-bot
2026-09-02 11:19 ` Garg, Shivank [this message]
2026-09-02 10:52 ` [PATCH RFC 10/11] mm/migrate: pass migrate_control to migrate_pages() Shivank Garg
2026-09-02 11:11 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 11/11] mm/migrate: pass migrate_control to migrate_folio() Shivank Garg
2026-09-02 11:10 ` Jan Kara
2026-09-02 11:10 ` sashiko-bot
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=1508939ba49c28e06b9cec344ec6a69ab57ce8ac.camel@amd.com \
--to=shivankg@amd.com \
--cc=akpm@linux-foundation.org \
--cc=anna@kernel.org \
--cc=apopple@nvidia.com \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=bcrl@kvack.org \
--cc=bharata@amd.com \
--cc=brauner@kernel.org \
--cc=brendan.jackman@linux.dev \
--cc=byungchul@sk.com \
--cc=clm@fb.com \
--cc=corbet@lwn.net \
--cc=damon@lists.linux.dev \
--cc=david@kernel.org \
--cc=dsterba@suse.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kasong@tencent.com \
--cc=kvm@vger.kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-aio@kvack.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qi.zheng@linux.dev \
--cc=rakie.kim@sk.com \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=shaggy@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=sj@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=trondmy@kernel.org \
--cc=vbabka@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=yiannis@zptcorp.com \
--cc=ying.huang@linux.alibaba.com \
--cc=yuanchu@google.com \
--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 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.