Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


  reply	other threads:[~2026-09-02 11:19 UTC|newest]

Thread overview: 14+ 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 10:52 ` [PATCH RFC 02/11] mm/migrate: handle retries in migrate_folios_move() Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 03/11] mm/migrate: factor out folio splitting on allocation failure Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 04/11] mm/migrate: use a dedicated list for hugetlb folios Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 05/11] mm/migrate: add a dedicated movable_ops migration pass Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 06/11] mm/migrate: rename migrate_pages_batch() to migrate_folios_batch() Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 07/11] mm/migrate: add migrate_lru_folios() entry point Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 08/11] mm/migrate: move LRU batching into migrate_lru_folios() Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 09/11] mm/migrate: thread migration policy through a control struct Shivank Garg
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 10:52 ` [PATCH RFC 11/11] mm/migrate: pass migrate_control to migrate_folio() Shivank Garg
2026-09-02 11:10   ` Jan Kara

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox