From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
David Hildenbrand <david@redhat.com>,
Jann Horn <jannh@google.com>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Colin Cross <ccross@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/4] mm, madvise: use standard madvise locking in madvise_set_anon_name()
Date: Tue, 24 Jun 2025 16:45:55 +0100 [thread overview]
Message-ID: <667e6631-8e2f-4154-8fcc-55fb5ab49a07@lucifer.local> (raw)
In-Reply-To: <20250624-anon_name_cleanup-v2-4-600075462a11@suse.cz>
On Tue, Jun 24, 2025 at 03:03:48PM +0200, Vlastimil Babka wrote:
> Use madvise_lock()/madvise_unlock() in madvise_set_anon_name() in the
> same way as in do_madvise(). This narrows the lock scope a bit and
> reuses existing functionality. get_lock_mode() already picks the correct
> MADVISE_MMAP_WRITE_LOCK mode for __MADV_SET_ANON_VMA_NAME so we can just
> remove the explicit assignment.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
This is a nice idea, hadn't thought of it :) aren't we making anon vma name
behave now :P
I mean this is a _minor_ difference in functionality in that we will now
use mmap_write_lock_killable() and could fail to lock on fatal signal
whereas before we unconditionally lock but I think that's fine, and
possibly even... desirable actually?
At any rate this is all nice, thanks again!
> ---
> mm/madvise.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/mm/madvise.c b/mm/madvise.c
> index cae064479cdf908707c45b941bd03d43d095eab6..ee02ccd0315a146cdb3001cd189e03be9e48a2ea 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -2082,10 +2082,10 @@ static int madvise_set_anon_name(struct mm_struct *mm, unsigned long start,
> {
> unsigned long end;
> unsigned long len;
> + int error;
> struct madvise_behavior madv_behavior = {
> .mm = mm,
> .behavior = __MADV_SET_ANON_VMA_NAME,
> - .lock_mode = MADVISE_MMAP_WRITE_LOCK,
> .anon_name = anon_name,
> };
>
> @@ -2106,7 +2106,14 @@ static int madvise_set_anon_name(struct mm_struct *mm, unsigned long start,
>
> madv_behavior.range.start = start;
> madv_behavior.range.end = end;
> - return madvise_walk_vmas(&madv_behavior);
> +
> + error = madvise_lock(&madv_behavior);
> + if (error)
> + return error;
> + error = madvise_walk_vmas(&madv_behavior);
> + madvise_unlock(&madv_behavior);
> +
> + return error;
> }
>
> int set_anon_vma_name(unsigned long addr, unsigned long size,
> @@ -2136,9 +2143,7 @@ int set_anon_vma_name(unsigned long addr, unsigned long size,
> return -ENOMEM;
> }
>
> - mmap_write_lock(mm);
> error = madvise_set_anon_name(mm, addr, size, anon_name);
> - mmap_write_unlock(mm);
> anon_vma_name_put(anon_name);
>
> return error;
>
> --
> 2.50.0
>
next prev parent reply other threads:[~2025-06-24 15:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 13:03 [PATCH v2 0/4] madvise anon_name cleanups Vlastimil Babka
2025-06-24 13:03 ` [PATCH v2 1/4] mm, madvise: simplify anon_name handling Vlastimil Babka
2025-06-24 13:58 ` David Hildenbrand
2025-06-24 14:28 ` Suren Baghdasaryan
2025-06-24 16:41 ` Vlastimil Babka
2025-06-24 16:38 ` Vlastimil Babka
2025-06-24 15:26 ` Lorenzo Stoakes
2025-06-24 16:42 ` Vlastimil Babka
2025-06-24 17:01 ` Vlastimil Babka
2025-06-24 13:03 ` [PATCH v2 2/4] mm, madvise: extract mm code from prctl_set_vma() to mm/madvise.c Vlastimil Babka
2025-06-24 14:04 ` David Hildenbrand
2025-06-24 14:31 ` Suren Baghdasaryan
2025-06-24 15:28 ` Lorenzo Stoakes
2025-06-24 13:03 ` [PATCH v2 3/4] mm, madvise: move madvise_set_anon_name() down the file Vlastimil Babka
2025-06-24 14:05 ` David Hildenbrand
2025-06-24 14:33 ` Suren Baghdasaryan
2025-06-24 16:46 ` Vlastimil Babka
2025-06-24 15:36 ` Lorenzo Stoakes
2025-06-24 17:02 ` Vlastimil Babka
2025-06-24 13:03 ` [PATCH v2 4/4] mm, madvise: use standard madvise locking in madvise_set_anon_name() Vlastimil Babka
2025-06-24 14:06 ` David Hildenbrand
2025-06-24 14:35 ` Suren Baghdasaryan
2025-06-24 15:45 ` Lorenzo Stoakes [this message]
2025-06-24 16:48 ` Vlastimil Babka
2025-06-24 17:03 ` Vlastimil Babka
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=667e6631-8e2f-4154-8fcc-55fb5ab49a07@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ccross@google.com \
--cc=david@redhat.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/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).