All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: tao <tao.wangtao@honor.com>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH v2 03/13] mm: implement __anon_node_prepare for ANON_VMA_FRACTAL
Date: Tue, 07 Jul 2026 07:39:28 +0000	[thread overview]
Message-ID: <20260707073929.046021F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260707063308.29176-4-tao.wangtao@honor.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] `__anon_node_prepare` casts a `struct anon_node *` to a `struct anon_vma *` and assigns it to `vma->anon_vma`, resulting in severe type confusion.
--

--- Patch [3]: [RFC PATCH v2 03/13] mm: implement __anon_node_prepare for ANON_VMA_FRACTAL ---
commit 1ab3065664fb86573b65c2ad490a2b4e7c508707
Author: tao <tao.wangtao@honor.com>

    mm: implement __anon_node_prepare for ANON_VMA_FRACTAL

This commit introduces anon_node APIs corresponding to existing anon_vma
operations for the ANON_VMA_FRACTAL feature. It currently implements
__anon_node_prepare() to attach an anon_node to a VMA.

> diff --git a/mm/rmap.c b/mm/rmap.c
> --- a/mm/rmap.c
> +++ b/mm/rmap.c

[ ... ]

> +int __anon_node_prepare(struct vm_area_struct *vma)
> +{
> +	struct mm_struct *mm = vma->vm_mm;
> +	unsigned long rmap_base = vma_rmap_base(vma);
> +	struct anon_node *anon_nod;
> +	struct anon_vma *anon_old = NULL, *anon_new;

[ ... ]

> +	anon_nod = anon_node_alloc(vma, NULL, false);
> +	if (unlikely(!anon_nod))
> +		return -ENOMEM;
> +
> +	anon_new = (struct anon_vma *)anon_nod;
> +	/* maybe prepared by another thread */
> +	if (!try_cmpxchg(&vma->anon_vma, &anon_old, anon_new)) {

[Severity: Critical]
Will this cause memory corruption for existing reverse mapping and page fault
paths that expect a standard anon_vma?

Because struct anon_node and struct anon_vma have significantly different
memory layouts, storing an anon_node pointer into vma->anon_vma will cause
type confusion. For instance, anon_node places vm_lock_ref at the exact
memory offset where anon_vma expects refcount. 

When standard VMA operations (like folio_lock_anon_vma_read() or
unlink_anon_vmas()) access vma->anon_vma->refcount, won't they read and write
the wrong fields, corrupting vm_lock_ref and permanently leaking the anon_node
since its actual refcount is never decremented?

> +		try_untrack_rmap(anon_nod, rmap_base, &test_empty);
> +		put_anon_node(anon_nod);
> +	}
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707063308.29176-1-tao.wangtao@honor.com?part=3

  reply	other threads:[~2026-07-07  7:39 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07  6:32 [RFC PATCH v2 00/13] mm: rework anon_vma and remove anon_vma_chain tao
2026-07-07  6:32 ` [RFC PATCH v2 01/13] mm: add CONFIG_ANON_VMA_FRACTAL tao
2026-07-07  7:11   ` sashiko-bot
2026-07-07  6:32 ` [RFC PATCH v2 02/13] mm: implement helpers for ANON_VMA_FRACTAL tao
2026-07-07  7:23   ` sashiko-bot
2026-07-07  6:32 ` [RFC PATCH v2 03/13] mm: implement __anon_node_prepare " tao
2026-07-07  7:39   ` sashiko-bot [this message]
2026-07-07  6:32 ` [RFC PATCH v2 04/13] mm: implement anon_node_clone " tao
2026-07-07  8:00   ` sashiko-bot
2026-07-07  6:33 ` [RFC PATCH v2 05/13] mm: implement anon_node_fork_with_prev " tao
2026-07-07  8:22   ` sashiko-bot
2026-07-07  6:33 ` [RFC PATCH v2 06/13] mm: implement unlink_anon_nodes " tao
2026-07-07  6:33 ` [RFC PATCH v2 07/13] mm: handle rmap_base changes " tao
2026-07-07  8:45   ` sashiko-bot
2026-07-07  6:33 ` [RFC PATCH v2 08/13] mm: implement anonymous folio rmap " tao
2026-07-07  9:01   ` sashiko-bot
2026-07-07  6:33 ` [RFC PATCH v2 09/13] mm: prepare anon_node replacement " tao
2026-07-07  9:12   ` sashiko-bot
2026-07-07  6:33 ` [RFC PATCH v2 10/13] mm: replace anon_vma with anon_node " tao
2026-07-07  9:25   ` sashiko-bot
2026-07-07  6:33 ` [RFC PATCH v2 11/13] mm: optimize rmap for ANON_VMA_FRACTAL with PVL tao
2026-07-07  9:41   ` sashiko-bot
2026-07-07  6:33 ` [RFC PATCH v2 12/13] mm: shared semaphores for ANON_VMA_FRACTAL tao
2026-07-07  9:59   ` sashiko-bot
2026-07-07  6:33 ` [RFC PATCH v2 13/13] mm: Enable CONFIG_ANON_VMA_FRACTAL by default tao
2026-07-07 10:21   ` sashiko-bot
2026-07-07  7:01 ` [RFC PATCH v2 00/13] mm: rework anon_vma and remove anon_vma_chain David Hildenbrand (Arm)
2026-07-07  8:21   ` wangtao
2026-07-07  8:31     ` David Hildenbrand (Arm)
2026-07-07  9:20       ` wangtao
2026-07-07 16:19         ` Gregory Price
2026-07-07 17:09         ` David Hildenbrand (Arm)
2026-07-08  3:26           ` wangtao
2026-07-08  8:18             ` David Hildenbrand (Arm)
2026-07-07  9:07     ` Pedro Falcato
2026-07-08  4:37   ` Hillf Danton
2026-07-08  7:45     ` David Hildenbrand (Arm)
2026-07-08  9:15       ` Hillf Danton
2026-07-08 11:05         ` David Hildenbrand (Arm)
2026-07-07 15:27 ` Borislav Petkov
2026-07-07 21:32 ` [syzbot ci] " syzbot ci

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=20260707073929.046021F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tao.wangtao@honor.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.