public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: gutierrez.asier@huawei-partners.com
Cc: SeongJae Park <sj@kernel.org>,
	artem.kuzin@huawei.com, stepanov.anatoly@huawei.com,
	wangkefeng.wang@huawei.com, yanquanmin1@huawei.com,
	zuoze1@huawei.com, damon@lists.linux.dev,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: (sashiko review) [PATCH v1 1/1] mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action
Date: Mon, 30 Mar 2026 16:43:37 -0700	[thread overview]
Message-ID: <20260330234337.4456-1-sj@kernel.org> (raw)
In-Reply-To: <20260330145758.2115502-1-gutierrez.asier@huawei-partners.com>

Forwarding Sashiko review for doing discussions via mails.

# review url: https://sashiko.dev/#/patchset/20260330145758.2115502-1-gutierrez.asier@huawei-partners.com
# start of sashiko.dev inline review
commit cd78854e55ee90102333f0331c58417c16e8d798
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action

This commit introduces the DAMOS_COLLAPSE action to DAMON. It allows DAMON
to synchronously collapse memory regions into huge pages by leveraging the
existing MADV_COLLAPSE mechanism.

Link: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/

[ ... ]

> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> index b069dbc7e3d2..dd5f2d7027ac 100644
> --- a/mm/damon/vaddr.c
> +++ b/mm/damon/vaddr.c
> @@ -903,6 +903,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
>  	case DAMOS_NOHUGEPAGE:
>  		madv_action = MADV_NOHUGEPAGE;
>  		break;
> +	case DAMOS_COLLAPSE:
> +		madv_action = MADV_COLLAPSE;

Could exposing MADV_COLLAPSE to automated continuous execution via DAMOS
trigger a pre-existing use-after-free in the core madvise logic?

In madvise_collapse(), the lock_dropped boolean tracks whether the lock is
currently dropped and tells madvise_walk_vmas() if the lock was ever dropped.

If collapse_single_pmd() drops the mmap lock, *lock_dropped is set to true.
On the next loop iteration, madvise_collapse() re-acquires the lock,
validates the VMA, and resets *lock_dropped = false to avoid double-locking.
If a subsequent iteration does not drop the lock, the function returns to
madvise_walk_vmas() with lock_dropped set to false.

Because madvise_walk_vmas() sees false, it assumes the lock was continuously
held and the original VMA pointer is still safe. However, another thread
could have freed the original VMA while the lock was temporarily dropped,
leading to a use-after-free when madvise_walk_vmas() dereferences
vma->vm_end.

While this flaw pre-dates this patch, does introducing DAMOS_COLLAPSE expose
it to continuous background execution by kdamond, making the race condition
much more likely to occur in practice?

> +		break;
>  	case DAMOS_MIGRATE_HOT:
>  	case DAMOS_MIGRATE_COLD:


# end of sashiko.dev inline review
# review url: https://sashiko.dev/#/patchset/20260330145758.2115502-1-gutierrez.asier@huawei-partners.com
#
# hkml [1] generated a draft of this mail.  It can be regenerated
# using below command:
#
#     hkml patch sashiko_dev --for_forwarding \
#             20260330145758.2115502-1-gutierrez.asier@huawei-partners.com
#
# [1] https://github.com/sjp38/hackermail

Sent using hkml (https://github.com/sjp38/hackermail)


  reply	other threads:[~2026-03-30 23:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 14:57 [PATCH v1 1/1] mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action gutierrez.asier
2026-03-30 23:43 ` SeongJae Park [this message]
2026-03-31  0:01   ` (sashiko review) " SeongJae Park
2026-03-31  1:31 ` SeongJae Park
2026-03-31 10:46   ` Stepanov Anatoly
2026-03-31 10:50     ` Stepanov Anatoly
2026-04-01  0:54       ` SeongJae Park
2026-03-31 15:15   ` Gutierrez Asier
2026-04-01  0:59     ` SeongJae Park

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=20260330234337.4456-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=artem.kuzin@huawei.com \
    --cc=damon@lists.linux.dev \
    --cc=gutierrez.asier@huawei-partners.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=stepanov.anatoly@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=yanquanmin1@huawei.com \
    --cc=zuoze1@huawei.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