From: Alexandru Elisei <alexandru.elisei@arm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Hyesoo Yu <hyesoo.yu@samsung.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, pcc@google.com,
steven.price@arm.com, anshuman.khandual@arm.com,
vincenzo.frascino@arm.com, eugenis@google.com, kcc@google.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 v2 19/27] mm: mprotect: Introduce PAGE_FAULT_ON_ACCESS for mprotect(PROT_MTE)
Date: Thu, 30 Nov 2023 13:32:16 +0000 [thread overview]
Message-ID: <ZWiO4PWfK2gKDLGr@raptor> (raw)
In-Reply-To: <4e7a4054-092c-4e34-ae00-0105d7c9343c@redhat.com>
Hi,
On Thu, Nov 30, 2023 at 01:49:34PM +0100, David Hildenbrand wrote:
> > > > +
> > > > +out_retry:
> > > > + put_page(page);
> > > > + if (vmf->flags & FAULT_FLAG_VMA_LOCK)
> > > > + vma_end_read(vma);
> > > > + if (fault_flag_allow_retry_first(vmf->flags)) {
> > > > + err = VM_FAULT_RETRY;
> > > > + } else {
> > > > + /* Replay the fault. */
> > > > + err = 0;
> > >
> > > Hello!
> > >
> > > Unfortunately, if the page continues to be pinned, it seems like fault will continue to occur.
> > > I guess it makes system stability issue. (but I'm not familiar with that, so please let me know if I'm mistaken!)
> > >
> > > How about migrating the page when migration problem repeats.
> >
> > Yes, I had the same though in the previous iteration of the series, the
> > page was migrated out of the VMA if tag storage couldn't be reserved.
> >
> > Only short term pins are allowed on MIGRATE_CMA pages, so I expect that the
> > pin will be released before the fault is replayed. Because of this, and
> > because it makes the code simpler, I chose not to migrate the page if tag
> > storage couldn't be reserved.
>
> There are still some cases that are theoretically problematic: vmsplice()
> can pin pages forever and doesn't use FOLL_LONGTERM yet.
>
> All these things also affect other users that rely on movability (e.g., CMA,
> memory hotunplug).
I wasn't aware of that, thank you for the information. Then to ensure that the
process doesn't hang by replying the loop indefinitely, I'll migrate the page if
tag storage cannot be reserved. Looking over the code again, I think I can reuse
the same function that migrates tag storage pages out of the MTE VMA (added in
patch #21), so no major changes needed.
Thanks,
Alex
>
> --
> Cheers,
>
> David / dhildenb
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Hyesoo Yu <hyesoo.yu@samsung.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, pcc@google.com,
steven.price@arm.com, anshuman.khandual@arm.com,
vincenzo.frascino@arm.com, eugenis@google.com, kcc@google.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 v2 19/27] mm: mprotect: Introduce PAGE_FAULT_ON_ACCESS for mprotect(PROT_MTE)
Date: Thu, 30 Nov 2023 13:32:16 +0000 [thread overview]
Message-ID: <ZWiO4PWfK2gKDLGr@raptor> (raw)
In-Reply-To: <4e7a4054-092c-4e34-ae00-0105d7c9343c@redhat.com>
Hi,
On Thu, Nov 30, 2023 at 01:49:34PM +0100, David Hildenbrand wrote:
> > > > +
> > > > +out_retry:
> > > > + put_page(page);
> > > > + if (vmf->flags & FAULT_FLAG_VMA_LOCK)
> > > > + vma_end_read(vma);
> > > > + if (fault_flag_allow_retry_first(vmf->flags)) {
> > > > + err = VM_FAULT_RETRY;
> > > > + } else {
> > > > + /* Replay the fault. */
> > > > + err = 0;
> > >
> > > Hello!
> > >
> > > Unfortunately, if the page continues to be pinned, it seems like fault will continue to occur.
> > > I guess it makes system stability issue. (but I'm not familiar with that, so please let me know if I'm mistaken!)
> > >
> > > How about migrating the page when migration problem repeats.
> >
> > Yes, I had the same though in the previous iteration of the series, the
> > page was migrated out of the VMA if tag storage couldn't be reserved.
> >
> > Only short term pins are allowed on MIGRATE_CMA pages, so I expect that the
> > pin will be released before the fault is replayed. Because of this, and
> > because it makes the code simpler, I chose not to migrate the page if tag
> > storage couldn't be reserved.
>
> There are still some cases that are theoretically problematic: vmsplice()
> can pin pages forever and doesn't use FOLL_LONGTERM yet.
>
> All these things also affect other users that rely on movability (e.g., CMA,
> memory hotunplug).
I wasn't aware of that, thank you for the information. Then to ensure that the
process doesn't hang by replying the loop indefinitely, I'll migrate the page if
tag storage cannot be reserved. Looking over the code again, I think I can reuse
the same function that migrates tag storage pages out of the MTE VMA (added in
patch #21), so no major changes needed.
Thanks,
Alex
>
> --
> Cheers,
>
> David / dhildenb
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-30 13:32 UTC|newest]
Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-19 16:56 [PATCH RFC v2 00/27] Add support for arm64 MTE dynamic tag storage reuse Alexandru Elisei
2023-11-19 16:56 ` Alexandru Elisei
2023-11-19 16:56 ` [PATCH RFC v2 01/27] arm64: mte: Rework naming for tag manipulation functions Alexandru Elisei
2023-11-19 16:56 ` Alexandru Elisei
2023-11-19 16:56 ` [PATCH RFC v2 02/27] arm64: mte: Rename __GFP_ZEROTAGS to __GFP_TAGGED Alexandru Elisei
2023-11-19 16:56 ` Alexandru Elisei
2023-11-19 16:56 ` [PATCH RFC v2 03/27] mm: cma: Make CMA_ALLOC_SUCCESS/FAIL count the number of pages Alexandru Elisei
2023-11-19 16:56 ` Alexandru Elisei
2023-11-19 16:56 ` [PATCH RFC v2 04/27] mm: migrate/mempolicy: Add hook to modify migration target gfp Alexandru Elisei
2023-11-19 16:56 ` Alexandru Elisei
2023-11-25 10:03 ` Mike Rapoport
2023-11-25 10:03 ` Mike Rapoport
2023-11-27 11:52 ` Alexandru Elisei
2023-11-27 11:52 ` Alexandru Elisei
2023-11-28 6:49 ` Mike Rapoport
2023-11-28 6:49 ` Mike Rapoport
2023-11-28 17:21 ` Alexandru Elisei
2023-11-28 17:21 ` Alexandru Elisei
2023-11-19 16:56 ` [PATCH RFC v2 05/27] mm: page_alloc: Add an arch hook to allow prep_new_page() to fail Alexandru Elisei
2023-11-19 16:56 ` Alexandru Elisei
2023-11-24 11:46 ` kernel test robot
2023-11-24 19:35 ` David Hildenbrand
2023-11-24 19:35 ` David Hildenbrand
2023-11-27 12:09 ` Alexandru Elisei
2023-11-27 12:09 ` Alexandru Elisei
2023-11-28 16:57 ` David Hildenbrand
2023-11-28 16:57 ` David Hildenbrand
2023-11-28 17:17 ` Alexandru Elisei
2023-11-28 17:17 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 06/27] mm: page_alloc: Allow an arch to hook early into free_pages_prepare() Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-24 13:19 ` kernel test robot
2023-11-24 19:36 ` David Hildenbrand
2023-11-24 19:36 ` David Hildenbrand
2023-11-27 13:03 ` Alexandru Elisei
2023-11-27 13:03 ` Alexandru Elisei
2023-11-28 16:58 ` David Hildenbrand
2023-11-28 16:58 ` David Hildenbrand
2023-11-28 17:17 ` Alexandru Elisei
2023-11-28 17:17 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 07/27] mm: page_alloc: Add an arch hook to filter MIGRATE_CMA allocations Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 08/27] mm: page_alloc: Partially revert "mm: page_alloc: remove stale CMA guard code" Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 09/27] mm: Allow an arch to hook into folio allocation when VMA is known Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 10/27] mm: Call arch_swap_prepare_to_restore() before arch_swap_restore() Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-29 8:44 ` Hyesoo Yu
2023-11-29 8:44 ` Hyesoo Yu
2023-11-30 11:56 ` Alexandru Elisei
2023-11-30 11:56 ` Alexandru Elisei
2023-12-03 12:14 ` Alexandru Elisei
2023-12-03 12:14 ` Alexandru Elisei
2023-12-08 5:03 ` Hyesoo Yu
2023-12-08 5:03 ` Hyesoo Yu
2023-12-11 14:45 ` Alexandru Elisei
2023-12-11 14:45 ` Alexandru Elisei
2023-12-11 17:29 ` Rob Herring
2023-12-11 17:29 ` Rob Herring
2023-12-12 16:38 ` Alexandru Elisei
2023-12-12 16:38 ` Alexandru Elisei
2023-12-12 18:44 ` Rob Herring
2023-12-12 18:44 ` Rob Herring
2023-12-13 13:04 ` Alexandru Elisei
2023-12-13 13:04 ` Alexandru Elisei
2023-12-13 14:06 ` Rob Herring
2023-12-13 14:06 ` Rob Herring
2023-12-13 14:51 ` Alexandru Elisei
2023-12-13 14:51 ` Alexandru Elisei
2023-12-13 17:22 ` Rob Herring
2023-12-13 17:22 ` Rob Herring
2023-12-13 17:44 ` Alexandru Elisei
2023-12-13 17:44 ` Alexandru Elisei
2023-12-13 20:30 ` Rob Herring
2023-12-13 20:30 ` Rob Herring
2023-12-14 15:45 ` Alexandru Elisei
2023-12-14 15:45 ` Alexandru Elisei
2023-12-14 18:55 ` Rob Herring
2023-12-14 18:55 ` Rob Herring
2023-12-18 10:59 ` Alexandru Elisei
2023-12-18 10:59 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 12/27] arm64: mte: Add tag storage pages to the MIGRATE_CMA migratetype Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-24 19:40 ` David Hildenbrand
2023-11-24 19:40 ` David Hildenbrand
2023-11-27 15:01 ` Alexandru Elisei
2023-11-27 15:01 ` Alexandru Elisei
2023-11-28 17:03 ` David Hildenbrand
2023-11-28 17:03 ` David Hildenbrand
2023-11-29 10:44 ` Alexandru Elisei
2023-11-29 10:44 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 13/27] arm64: mte: Make tag storage depend on ARCH_KEEP_MEMBLOCK Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-24 19:51 ` David Hildenbrand
2023-11-24 19:51 ` David Hildenbrand
2023-11-27 15:04 ` Alexandru Elisei
2023-11-27 15:04 ` Alexandru Elisei
2023-11-28 17:05 ` David Hildenbrand
2023-11-28 17:05 ` David Hildenbrand
2023-11-29 10:46 ` Alexandru Elisei
2023-11-29 10:46 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 14/27] arm64: mte: Disable dynamic tag storage management if HW KASAN is enabled Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-24 19:54 ` David Hildenbrand
2023-11-24 19:54 ` David Hildenbrand
2023-11-27 15:07 ` Alexandru Elisei
2023-11-27 15:07 ` Alexandru Elisei
2023-11-28 17:05 ` David Hildenbrand
2023-11-28 17:05 ` David Hildenbrand
2023-11-19 16:57 ` [PATCH RFC v2 15/27] arm64: mte: Check that tag storage blocks are in the same zone Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-24 19:56 ` David Hildenbrand
2023-11-24 19:56 ` David Hildenbrand
2023-11-27 15:10 ` Alexandru Elisei
2023-11-27 15:10 ` Alexandru Elisei
2023-11-29 8:57 ` Hyesoo Yu
2023-11-29 8:57 ` Hyesoo Yu
2023-11-30 12:00 ` Alexandru Elisei
2023-11-30 12:00 ` Alexandru Elisei
2023-12-08 5:27 ` Hyesoo Yu
2023-12-08 5:27 ` Hyesoo Yu
2023-12-11 14:21 ` Alexandru Elisei
2023-12-11 14:21 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 16/27] arm64: mte: Manage tag storage on page allocation Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-29 9:10 ` Hyesoo Yu
2023-11-29 9:10 ` Hyesoo Yu
2023-11-29 13:33 ` Alexandru Elisei
2023-11-29 13:33 ` Alexandru Elisei
2023-12-08 5:29 ` Hyesoo Yu
2023-12-08 5:29 ` Hyesoo Yu
2023-11-19 16:57 ` [PATCH RFC v2 17/27] arm64: mte: Perform CMOs for tag blocks on tagged page allocation/free Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 18/27] arm64: mte: Reserve tag block for the zero page Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-28 17:06 ` David Hildenbrand
2023-11-28 17:06 ` David Hildenbrand
2023-11-29 11:30 ` Alexandru Elisei
2023-11-29 11:30 ` Alexandru Elisei
2023-11-29 13:13 ` David Hildenbrand
2023-11-29 13:13 ` David Hildenbrand
2023-11-29 13:41 ` Alexandru Elisei
2023-11-29 13:41 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 19/27] mm: mprotect: Introduce PAGE_FAULT_ON_ACCESS for mprotect(PROT_MTE) Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-28 17:55 ` David Hildenbrand
2023-11-28 17:55 ` David Hildenbrand
2023-11-28 18:00 ` David Hildenbrand
2023-11-28 18:00 ` David Hildenbrand
2023-11-29 11:55 ` Alexandru Elisei
2023-11-29 11:55 ` Alexandru Elisei
2023-11-29 12:48 ` David Hildenbrand
2023-11-29 12:48 ` David Hildenbrand
2023-11-29 9:27 ` Hyesoo Yu
2023-11-29 9:27 ` Hyesoo Yu
2023-11-30 12:06 ` Alexandru Elisei
2023-11-30 12:06 ` Alexandru Elisei
2023-11-30 12:49 ` David Hildenbrand
2023-11-30 12:49 ` David Hildenbrand
2023-11-30 13:32 ` Alexandru Elisei [this message]
2023-11-30 13:32 ` Alexandru Elisei
2023-11-30 13:43 ` David Hildenbrand
2023-11-30 13:43 ` David Hildenbrand
2023-11-30 14:33 ` Alexandru Elisei
2023-11-30 14:33 ` Alexandru Elisei
2023-11-30 14:39 ` David Hildenbrand
2023-11-30 14:39 ` David Hildenbrand
2023-11-19 16:57 ` [PATCH RFC v2 20/27] mm: hugepage: Handle huge page fault on access Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-22 1:28 ` Peter Collingbourne
2023-11-22 1:28 ` Peter Collingbourne
2023-11-22 9:22 ` Alexandru Elisei
2023-11-22 9:22 ` Alexandru Elisei
2023-11-28 17:56 ` David Hildenbrand
2023-11-28 17:56 ` David Hildenbrand
2023-11-29 11:56 ` Alexandru Elisei
2023-11-29 11:56 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 21/27] mm: arm64: Handle tag storage pages mapped before mprotect(PROT_MTE) Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-28 5:39 ` Peter Collingbourne
2023-11-28 5:39 ` Peter Collingbourne
2023-11-30 17:43 ` Alexandru Elisei
2023-11-30 17:43 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 22/27] arm64: mte: swap: Handle tag restoring when missing tag storage Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 23/27] arm64: mte: copypage: " Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 24/27] arm64: mte: Handle fatal signal in reserve_tag_storage() Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 25/27] KVM: arm64: Disable MTE if tag storage is enabled Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 26/27] arm64: mte: Fast track reserving tag storage when the block is free Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
2023-11-19 16:57 ` [PATCH RFC v2 27/27] arm64: mte: Enable dynamic tag storage reuse Alexandru Elisei
2023-11-19 16:57 ` Alexandru Elisei
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=ZWiO4PWfK2gKDLGr@raptor \
--to=alexandru.elisei@arm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=arnd@arndb.de \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.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 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.