linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Alexandru Elisei <alexandru.elisei@arm.com>,
	catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev,
	maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com,
	yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org,
	mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org,
	rppt@kernel.org, hughd@google.com
Cc: pcc@google.com, steven.price@arm.com, anshuman.khandual@arm.com,
	vincenzo.frascino@arm.com, eugenis@google.com, kcc@google.com,
	hyesoo.yu@samsung.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
	linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 00/37] Add support for arm64 MTE dynamic tag storage reuse
Date: Thu, 24 Aug 2023 09:50:32 +0200	[thread overview]
Message-ID: <33def4fe-fdb8-6388-1151-fabd2adc8220@redhat.com> (raw)
In-Reply-To: <20230823131350.114942-1-alexandru.elisei@arm.com>

On 23.08.23 15:13, Alexandru Elisei wrote:
> Introduction
> ============
> 
> Arm has implemented memory coloring in hardware, and the feature is called
> Memory Tagging Extensions (MTE). It works by embedding a 4 bit tag in bits
> 59..56 of a pointer, and storing this tag to a reserved memory location.
> When the pointer is dereferenced, the hardware compares the tag embedded in
> the pointer (logical tag) with the tag stored in memory (allocation tag).
> 
> The relation between memory and where the tag for that memory is stored is
> static.
> 
> The memory where the tags are stored have been so far unaccessible to Linux.
> This series aims to change that, by adding support for using the tag storage
> memory only as data memory; tag storage memory cannot be itself tagged.
> 
> 
> Implementation
> ==============
> 
> The series is based on v6.5-rc3 with these two patches cherry picked:
> 
> - mm: Call arch_swap_restore() from unuse_pte():
> 
>      https://lore.kernel.org/all/20230523004312.1807357-3-pcc@google.com/
> 
> - arm64: mte: Simplify swap tag restoration logic:
> 
>      https://lore.kernel.org/all/20230523004312.1807357-4-pcc@google.com/
> 
> The above two patches are queued for the v6.6 merge window:
> 
>      https://lore.kernel.org/all/20230702123821.04e64ea2c04dd0fdc947bda3@linux-foundation.org/
> 
> The entire series, including the above patches, can be cloned with:
> 
> $ git clone https://gitlab.arm.com/linux-arm/linux-ae.git \
> 	-b arm-mte-dynamic-carveout-rfc-v1
> 
> On the arm64 architecture side, an extension is being worked on that will
> clarify how MTE tag storage reuse should behave. The extension will be
> made public soon.
> 
> On the Linux side, MTE tag storage reuse is accomplished with the
> following changes:
> 
> 1. The tag storage memory is exposed to the memory allocator as a new
> migratetype, MIGRATE_METADATA. It behaves similarly to MIGRATE_CMA, with
> the restriction that it cannot be used to allocate tagged memory (tag
> storage memory cannot be tagged). On tagged page allocation, the
> corresponding tag storage is reserved via alloc_contig_range().
> 
> 2. mprotect(PROT_MTE) is implemented by changing the pte prot to
> PAGE_METADATA_NONE. When the page is next accessed, a fault is taken and
> the corresponding tag storage is reserved.
> 
> 3. When the code tries to copy tags to a page which doesn't have the tag
> storage reserved, the tags are copied to an xarray and restored in
> set_pte_at(), when the page is eventually mapped with the tag storage
> reserved.

Hi!

after re-reading it 2 times, I still have no clue what your patch set is 
actually trying to achieve. Probably there is a way to describe how user 
space intents to interact with this feature, so to see which value this 
actually has for user space -- and if we are using the right APIs and 
allocators.

So some dummy questions / statements

1) Is this about re-propusing the memory used to hold tags for different 
purpose? Or what exactly is user space going to do with the PROT_MTE 
memory? The whole mprotect(PROT_MTE) approach might not eb the right 
thing to do.

2) Why do we even have to involve the page allocator if this is some 
special-purpose memory? Re-porpusing the buddy when later using 
alloc_contig_range() either way feels wrong.


[...]

>   arch/arm64/Kconfig                       |  13 +
>   arch/arm64/include/asm/assembler.h       |  10 +
>   arch/arm64/include/asm/memory_metadata.h |  49 ++
>   arch/arm64/include/asm/mte-def.h         |  16 +-
>   arch/arm64/include/asm/mte.h             |  40 +-
>   arch/arm64/include/asm/mte_tag_storage.h |  36 ++
>   arch/arm64/include/asm/page.h            |   5 +-
>   arch/arm64/include/asm/pgtable-prot.h    |   2 +
>   arch/arm64/include/asm/pgtable.h         |  33 +-
>   arch/arm64/kernel/Makefile               |   1 +
>   arch/arm64/kernel/elfcore.c              |  14 +-
>   arch/arm64/kernel/hibernate.c            |  46 +-
>   arch/arm64/kernel/mte.c                  |  31 +-
>   arch/arm64/kernel/mte_tag_storage.c      | 667 +++++++++++++++++++++++
>   arch/arm64/kernel/setup.c                |   7 +
>   arch/arm64/kvm/arm.c                     |   6 +-
>   arch/arm64/lib/mte.S                     |  30 +-
>   arch/arm64/mm/copypage.c                 |  26 +
>   arch/arm64/mm/fault.c                    |  35 +-
>   arch/arm64/mm/mteswap.c                  | 113 +++-
>   fs/proc/meminfo.c                        |   8 +
>   fs/proc/page.c                           |   1 +
>   include/asm-generic/Kbuild               |   1 +
>   include/asm-generic/memory_metadata.h    |  50 ++
>   include/linux/gfp.h                      |  10 +
>   include/linux/gfp_types.h                |  14 +-
>   include/linux/huge_mm.h                  |   6 +
>   include/linux/kernel-page-flags.h        |   1 +
>   include/linux/migrate_mode.h             |   1 +
>   include/linux/mm.h                       |  12 +-
>   include/linux/mmzone.h                   |  26 +-
>   include/linux/page-flags.h               |   1 +
>   include/linux/pgtable.h                  |  19 +
>   include/linux/sched.h                    |   2 +-
>   include/linux/sched/mm.h                 |  13 +
>   include/linux/vm_event_item.h            |   5 +
>   include/linux/vmstat.h                   |   2 +
>   include/trace/events/mmflags.h           |   5 +-
>   mm/Kconfig                               |   5 +
>   mm/compaction.c                          |  52 +-
>   mm/huge_memory.c                         | 109 ++++
>   mm/internal.h                            |   7 +
>   mm/khugepaged.c                          |   7 +
>   mm/memory.c                              | 180 +++++-
>   mm/mempolicy.c                           |   7 +
>   mm/migrate.c                             |   6 +
>   mm/mm_init.c                             |  23 +-
>   mm/mprotect.c                            |  46 ++
>   mm/page_alloc.c                          | 136 ++++-
>   mm/page_isolation.c                      |  19 +-
>   mm/page_owner.c                          |   3 +-
>   mm/shmem.c                               |  14 +-
>   mm/show_mem.c                            |   4 +
>   mm/swapfile.c                            |   4 +
>   mm/vmscan.c                              |   3 +
>   mm/vmstat.c                              |  13 +-
>   56 files changed, 1834 insertions(+), 161 deletions(-)
>   create mode 100644 arch/arm64/include/asm/memory_metadata.h
>   create mode 100644 arch/arm64/include/asm/mte_tag_storage.h
>   create mode 100644 arch/arm64/kernel/mte_tag_storage.c
>   create mode 100644 include/asm-generic/memory_metadata.h

The core-mm changes don't look particularly appealing :)

-- 
Cheers,

David / dhildenb


  parent reply	other threads:[~2023-08-24  7:52 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-23 13:13 [PATCH RFC 00/37] Add support for arm64 MTE dynamic tag storage reuse Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 01/37] mm: page_alloc: Rename gfp_to_alloc_flags_cma -> gfp_to_alloc_flags_fast Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 02/37] arm64: mte: Rework naming for tag manipulation functions Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 03/37] arm64: mte: Rename __GFP_ZEROTAGS to __GFP_TAGGED Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 04/37] mm: Add MIGRATE_METADATA allocation policy Alexandru Elisei
     [not found]   ` <CGME20231012013834epcas2p28ff3162673294077caef3b0794b69e72@epcas2p2.samsung.com>
2023-10-12  1:28     ` Hyesoo Yu
2023-10-16 12:40       ` Alexandru Elisei
2023-10-23  7:52         ` Hyesoo Yu
2023-08-23 13:13 ` [PATCH RFC 05/37] mm: Add memory statistics for the " Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 06/37] mm: page_alloc: Allocate from movable pcp lists only if ALLOC_FROM_METADATA Alexandru Elisei
     [not found]   ` <CGME20231012013524epcas2p4b50f306e3e4d0b937b31f978022844e5@epcas2p4.samsung.com>
2023-10-12  1:25     ` Hyesoo Yu
2023-10-16 12:41       ` Alexandru Elisei
2023-10-17 10:26         ` Catalin Marinas
2023-10-23  7:16           ` Hyesoo Yu
2023-10-23 10:50             ` Catalin Marinas
2023-10-23 11:55               ` David Hildenbrand
2023-10-23 17:08                 ` Catalin Marinas
2023-10-23 17:22                   ` David Hildenbrand
2023-08-23 13:13 ` [PATCH RFC 07/37] mm: page_alloc: Bypass pcp when freeing MIGRATE_METADATA pages Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 08/37] mm: compaction: Account for free metadata pages in __compact_finished() Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 09/37] mm: compaction: Handle metadata pages as source for direct compaction Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 10/37] mm: compaction: Do not use MIGRATE_METADATA to replace pages with metadata Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 11/37] mm: migrate/mempolicy: Allocate metadata-enabled destination page Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 12/37] mm: gup: Don't allow longterm pinning of MIGRATE_METADATA pages Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 13/37] arm64: mte: Reserve tag storage memory Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 14/37] arm64: mte: Expose tag storage pages to the MIGRATE_METADATA freelist Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 15/37] arm64: mte: Make tag storage depend on ARCH_KEEP_MEMBLOCK Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 16/37] arm64: mte: Move tag storage to MIGRATE_MOVABLE when MTE is disabled Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 17/37] arm64: mte: Disable dynamic tag storage management if HW KASAN is enabled Alexandru Elisei
     [not found]   ` <CGME20231012014514epcas2p3ca99a067f3044c5753309a08cd0b05c4@epcas2p3.samsung.com>
2023-10-12  1:35     ` Hyesoo Yu
2023-10-16 12:42       ` Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 18/37] arm64: mte: Check that tag storage blocks are in the same zone Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 19/37] mm: page_alloc: Manage metadata storage on page allocation Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 20/37] mm: compaction: Reserve metadata storage in compaction_alloc() Alexandru Elisei
2023-11-21  4:49   ` Peter Collingbourne
2023-11-21 11:54     ` Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 21/37] mm: khugepaged: Handle metadata-enabled VMAs Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 22/37] mm: shmem: Allocate metadata storage for in-memory filesystems Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 23/37] mm: Teach vma_alloc_folio() about metadata-enabled VMAs Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 24/37] mm: page_alloc: Teach alloc_contig_range() about MIGRATE_METADATA Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 25/37] arm64: mte: Manage tag storage on page allocation Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 26/37] arm64: mte: Perform CMOs for tag blocks on tagged page allocation/free Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 27/37] arm64: mte: Reserve tag block for the zero page Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 28/37] mm: sched: Introduce PF_MEMALLOC_ISOLATE Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 29/37] mm: arm64: Define the PAGE_METADATA_NONE page protection Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 30/37] mm: mprotect: arm64: Set PAGE_METADATA_NONE for mprotect(PROT_MTE) Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 31/37] mm: arm64: Set PAGE_METADATA_NONE in set_pte_at() if missing metadata storage Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 32/37] mm: Call arch_swap_prepare_to_restore() before arch_swap_restore() Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 33/37] arm64: mte: swap/copypage: Handle tag restoring when missing tag storage Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 34/37] arm64: mte: Handle fatal signal in reserve_metadata_storage() Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 35/37] mm: hugepage: Handle PAGE_METADATA_NONE faults for huge pages Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 36/37] KVM: arm64: Disable MTE is tag storage is enabled Alexandru Elisei
2023-08-23 13:13 ` [PATCH RFC 37/37] arm64: mte: Enable tag storage management Alexandru Elisei
2023-08-24  7:50 ` David Hildenbrand [this message]
2023-08-24 10:44   ` [PATCH RFC 00/37] Add support for arm64 MTE dynamic tag storage reuse Catalin Marinas
2023-08-24 11:06     ` David Hildenbrand
2023-08-24 11:25       ` David Hildenbrand
2023-08-24 15:24         ` Catalin Marinas
2023-09-06 11:23           ` Alexandru Elisei
2023-09-11 11:52             ` Catalin Marinas
2023-09-11 12:29               ` David Hildenbrand
2023-09-13 15:29                 ` Catalin Marinas
     [not found]                   ` <CGME20231025031004epcas2p485a0b7a9247bc61d54064d7f7bdd1e89@epcas2p4.samsung.com>
2023-10-25  2:59                     ` Hyesoo Yu
2023-10-25  8:47                       ` Alexandru Elisei
2023-10-25  8:52                         ` Hyesoo Yu
2023-10-27 11:04                           ` Catalin Marinas
2023-09-13  8:11 ` Kuan-Ying Lee (李冠穎)
2023-09-14 17:37   ` Catalin Marinas

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=33def4fe-fdb8-6388-1151-fabd2adc8220@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandru.elisei@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=arnd@arndb.de \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=eugenis@google.com \
    --cc=hughd@google.com \
    --cc=hyesoo.yu@samsung.com \
    --cc=james.morse@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kcc@google.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arch@vger.kernel.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=linux-trace-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=mgorman@suse.de \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oliver.upton@linux.dev \
    --cc=pcc@google.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vincenzo.frascino@arm.com \
    --cc=vschneid@redhat.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@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;
as well as URLs for NNTP newsgroup(s).