linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>

  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).