All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <ljs@kernel.org>
To: tao <tao.wangtao@honor.com>
Cc: catalin.marinas@arm.com, will@kernel.org, tglx@kernel.org,
	 mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	x86@kernel.org,  akpm@linux-foundation.org, david@kernel.org,
	willy@infradead.org, sj@kernel.org,  kees@kernel.org,
	luizcap@redhat.com, zhangjiao2@cmss.chinamobile.com,
	 kas@kernel.org, hpa@zytor.com, liam@infradead.org,
	vbabka@kernel.org,  rppt@kernel.org, surenb@google.com,
	mhocko@suse.com, jack@suse.cz,  riel@surriel.com,
	harry@kernel.org, jannh@google.com, jgg@ziepe.ca,
	 jhubbard@nvidia.com, peterx@redhat.com, ziy@nvidia.com,
	baolin.wang@linux.alibaba.com,  npache@redhat.com,
	ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org,
	 lance.yang@linux.dev, xu.xin16@zte.com.cn,
	chengming.zhou@linux.dev,  nao.horiguchi@gmail.com,
	matthew.brost@intel.com, joshua.hahnjy@gmail.com,
	 rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net,
	 ying.huang@linux.alibaba.com, apopple@nvidia.com,
	pfalcato@suse.de,  linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	 linux-mm@kvack.org, damon@lists.linux.dev,
	shakeel.butt@linux.dev, ryncsn@gmail.com,  21cnbao@gmail.com,
	jparsana@google.com, dvander@google.com, zhangji1@honor.com,
	 wangzicheng@honor.com
Subject: Re: [PATCH 03/15] mm: introduce anon_vma_tree_t for multiple anon_vma topologies
Date: Wed, 27 May 2026 12:56:35 +0100	[thread overview]
Message-ID: <ahbatfs3G-Qkh7Vk@lucifer> (raw)
In-Reply-To: <20260527110147.17815-4-tao.wangtao@honor.com>

On Wed, May 27, 2026 at 07:01:35PM +0800, tao wrote:
> Prepare for upcoming ANON_VMA_LAZY support and RCU-based lockless rmap
> traversal by clearly separating anon_vma topology handling from the
> anon_rmap semantics.

RCU is not 'lockless'... and if you truly get RCU semantics you break a bunch of
stuff as I found out.

>
> Prepare for supporting multiple anon_vma topologies by introducing
> lightweight abstractions used by the VMA and rmap code.
>
> Introduce anon_vma_tree_t as the type stored in vma->anon_vma:
>
>     typedef unsigned long anon_vma_tree_t;
>
> It represents a tagged pointer encoding a reference to the anon_vma
> topology. The low bits are reserved as type tags to distinguish
> different implementations (e.g. regular anon_vma and lazy anon_vma).
> This keeps the VMA representation compact while allowing the topology
> to evolve without changing the VMA layout.
>
> Signed-off-by: tao <tao.wangtao@honor.com>

The commit message is at least better on this one, but this approach is again,
predicated on extending a broken abstraction.

You could have saved time and effort by coming forward with this earlier to the
community.

You're also adding a bunch more messy code on top of anon_vma. It's just the
wrong direction.

> ---
>  include/linux/mm_types.h |  3 +++
>  mm/internal.h            | 54 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 57 insertions(+)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index a308e2c23b82..5f4961ea1572 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -917,6 +917,9 @@ struct vm_area_desc {
>  	struct mmap_action action;
>  };
>
> +/* Tagged pointer stored in vma->anon_vma. Low bits encode anon_vma type. */
> +typedef unsigned long anon_vma_tree_t;
> +
>  /*
>   * This struct describes a virtual memory area. There is one of these
>   * per VM-area/task. A VM area is any part of the process virtual memory
> diff --git a/mm/internal.h b/mm/internal.h
> index 5a2ddcf68e0b..76544ad44ff0 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -246,6 +246,60 @@ static inline void anon_vma_unlock_read(struct anon_vma *anon_vma)
>  	up_read(&anon_vma->root->rwsem);
>  }
>
> +/* anon_vma_tree_t APIs */
> +
> +static inline anon_vma_tree_t make_anon_vma_tree(struct anon_vma *anon_vma)
> +{
> +	return (anon_vma_tree_t)anon_vma;
> +}

You're literally returning an unsigned long of an anon_vma here?

Why is the anon_rmap_t a wrapped struct and this an unsigned long?

> +
> +static inline struct anon_vma *anon_vma_tree_anon_vma(anon_vma_tree_t anon_tree)
> +{
> +	return (struct anon_vma *)anon_tree;
> +}

The anon_tree is an anon_vma? What?

And it's a tagged pointer but we don't bother clearing any bits right?...!

> +
> +static inline void anon_vma_tree_lock_write(anon_vma_tree_t anon_tree)
> +{
> +	struct anon_vma *anon_vma = anon_vma_tree_anon_vma(anon_tree);
> +
> +	anon_vma_lock_write(anon_vma);
> +}
> +
> +static inline int anon_vma_tree_trylock_write(anon_vma_tree_t anon_tree)
> +{
> +	struct anon_vma *anon_vma = anon_vma_tree_anon_vma(anon_tree);
> +
> +	return anon_vma_trylock_write(anon_vma);
> +}
> +
> +static inline void anon_vma_tree_unlock_write(anon_vma_tree_t anon_tree)
> +{
> +	struct anon_vma *anon_vma = anon_vma_tree_anon_vma(anon_tree);
> +
> +	anon_vma_unlock_write(anon_vma);
> +}
> +
> +static inline void anon_vma_tree_lock_read(anon_vma_tree_t anon_tree)
> +{
> +	struct anon_vma *anon_vma = anon_vma_tree_anon_vma(anon_tree);
> +
> +	anon_vma_lock_read(anon_vma);
> +}
> +
> +static inline int anon_vma_tree_trylock_read(anon_vma_tree_t anon_tree)
> +{
> +	struct anon_vma *anon_vma = anon_vma_tree_anon_vma(anon_tree);
> +
> +	return anon_vma_trylock_read(anon_vma);
> +}
> +
> +static inline void anon_vma_tree_unlock_read(anon_vma_tree_t anon_tree)
> +{
> +	struct anon_vma *anon_vma = anon_vma_tree_anon_vma(anon_tree);
> +
> +	anon_vma_unlock_read(anon_vma);
> +}
> +

You keep adding more and more code on top of the existing mess. This is NOT what
we want.

>  struct anon_vma *folio_get_anon_vma(const struct folio *folio);
>
>  /* Operations which modify VMAs. */
> --
> 2.17.1
>

  reply	other threads:[~2026-05-27 11:56 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27 11:01 [PATCH 0/15] mm: introduce ANON_VMA_LAZY for deferred anon_vma creation tao
2026-05-27 11:01 ` [PATCH 01/15] mm/rmap: introduce anon_rmap APIs for anonymous folios tao
2026-05-27 11:32   ` sashiko-bot
2026-05-27 11:44   ` Lorenzo Stoakes
2026-05-28  7:47     ` wangtao
2026-05-27 11:01 ` [PATCH 02/15] mm: convert anon_vma rmap APIs to anon_rmap tao
2026-05-27 11:49   ` Lorenzo Stoakes
2026-05-28  8:55     ` wangtao
2026-05-27 11:01 ` [PATCH 03/15] mm: introduce anon_vma_tree_t for multiple anon_vma topologies tao
2026-05-27 11:56   ` Lorenzo Stoakes [this message]
2026-05-28  9:00     ` wangtao
2026-05-27 11:01 ` [PATCH 04/15] mm: switch to anon_vma_tree_t APIs in preparation for ANON_VMA_LAZY tao
2026-05-27 11:53   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 05/15] mm: add CONFIG_ANON_VMA_LAZY and folio helpers tao
2026-05-27 11:01 ` [PATCH 06/15] mm: add CONFIG_VMA_REF and VMA helpers tao
2026-05-27 11:42   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 07/15] mm: replace direct FOLIO_MAPPING_ANON usage with helpers tao
2026-05-27 11:43   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 08/15] mm: prepare rmap infrastructure for ANON_VMA_LAZY tao
2026-05-27 14:01   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 09/15] mm: implement ANON_VMA_LAZY rmap semantics tao
2026-05-27 12:15   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 10/15] mm: defer anon_vma creation with ANON_VMA_LAZY tao
2026-05-27 12:29   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 11/15] mm: handle ANON_VMA_LAZY in huge page operations tao
2026-05-27 12:21   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 12/15] mm: handle ANON_VMA_LAZY during migration tao
2026-05-27 12:23   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 13/15] mm: support setup and upgrade of ANON_VMA_LAZY folios tao
2026-05-27 13:02   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 14/15] mm: support merging of ANON_VMA_LAZY VMAs tao
2026-05-27 12:49   ` sashiko-bot
2026-05-27 11:01 ` [PATCH 15/15] mm: enable CONFIG_ANON_VMA_LAZY on arm64 and x86_64 tao
2026-05-27 17:19   ` sashiko-bot
2026-05-27 11:23 ` [PATCH 0/15] mm: introduce ANON_VMA_LAZY for deferred anon_vma creation Pedro Falcato
2026-05-28  6:45   ` wangtao
2026-05-28  7:14     ` Lorenzo Stoakes
2026-05-27 11:30 ` Lorenzo Stoakes
2026-05-28  7:11   ` wangtao
2026-05-28  7:22     ` Lorenzo Stoakes
2026-05-27 14:33 ` Lorenzo Stoakes
2026-05-28  7:57   ` wangtao
2026-05-28  8:14     ` Lorenzo Stoakes
2026-05-28 23:31       ` Barry Song
2026-05-29  2:20         ` wangzicheng
2026-05-29  6:56           ` Lorenzo Stoakes
2026-05-29  6:45         ` Lorenzo Stoakes
2026-05-29  9:41         ` wangtao
2026-05-29 12:03           ` Lorenzo Stoakes
2026-06-01  1:46             ` wangtao
2026-06-02  2:15               ` Barry Song
2026-06-02  2:46                 ` Lance Yang
2026-06-02 15:37                   ` Lorenzo Stoakes
2026-06-02 19:44                     ` Pedro Falcato
2026-06-02 23:03                     ` Barry Song
2026-06-03  7:07                       ` Lorenzo Stoakes
2026-06-02 19:56                 ` Harry Yoo
2026-06-02 22:27                   ` Barry Song
2026-06-02 20:47             ` Lorenzo Stoakes
2026-05-29 15:07         ` Jonathan Corbet
2026-05-29 15:40           ` Lorenzo Stoakes
2026-05-30 11:28             ` Barry Song
2026-06-02 16:07 ` Harry Yoo
2026-06-03  2:59   ` wangtao
2026-06-03  3:12     ` wangtao
2026-06-03  7:54     ` Lorenzo Stoakes
2026-06-03 11:05       ` wangtao
2026-06-03 11:53         ` Lorenzo Stoakes
2026-06-04  3:50           ` wangtao
2026-06-03 20:25 ` David Hildenbrand (Arm)
2026-06-03 22:14   ` Barry Song
2026-06-04  4:03     ` wangtao
2026-06-04  4:20       ` Barry Song
2026-06-04  7:35         ` wangtao
2026-06-09 15:26           ` Suren Baghdasaryan
2026-06-09 15:49             ` David Hildenbrand (Arm)
2026-06-04  3:10   ` xu.xin16
2026-06-04  4:10     ` wangtao
2026-06-05  9:38     ` David Hildenbrand (Arm)
2026-06-05 10:07       ` Lorenzo Stoakes
2026-06-05 10:56         ` David Hildenbrand (Arm)
2026-06-04  9:40   ` Lorenzo Stoakes

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=ahbatfs3G-Qkh7Vk@lucifer \
    --to=ljs@kernel.org \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=bp@alien8.de \
    --cc=byungchul@sk.com \
    --cc=catalin.marinas@arm.com \
    --cc=chengming.zhou@linux.dev \
    --cc=damon@lists.linux.dev \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=dvander@google.com \
    --cc=gourry@gourry.net \
    --cc=harry@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=joshua.hahnjy@gmail.com \
    --cc=jparsana@google.com \
    --cc=kas@kernel.org \
    --cc=kees@kernel.org \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luizcap@redhat.com \
    --cc=matthew.brost@intel.com \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=nao.horiguchi@gmail.com \
    --cc=npache@redhat.com \
    --cc=peterx@redhat.com \
    --cc=pfalcato@suse.de \
    --cc=rakie.kim@sk.com \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=ryncsn@gmail.com \
    --cc=shakeel.butt@linux.dev \
    --cc=sj@kernel.org \
    --cc=surenb@google.com \
    --cc=tao.wangtao@honor.com \
    --cc=tglx@kernel.org \
    --cc=vbabka@kernel.org \
    --cc=wangzicheng@honor.com \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=xu.xin16@zte.com.cn \
    --cc=ying.huang@linux.alibaba.com \
    --cc=zhangji1@honor.com \
    --cc=zhangjiao2@cmss.chinamobile.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.