linux-kernel - Re: [PATCH v2 4/4] mm, madvise: use standard madvise locking in madvise_set_anon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d6dd13e2-1bd3-4b3f-bb88-781ad79ff358@suse.cz>
Date: Tue, 24 Jun 2025 18:48:17 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 David Hildenbrand <david@...hat.com>, Jann Horn <jannh@...gle.com>,
 Mike Rapoport <rppt@...nel.org>, Suren Baghdasaryan <surenb@...gle.com>,
 Michal Hocko <mhocko@...e.com>, Colin Cross <ccross@...gle.com>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/4] mm, madvise: use standard madvise locking in
 madvise_set_anon_name()

On 6/24/25 17:45, Lorenzo Stoakes wrote:
> 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@...e.cz>
> 
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.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?

Right! I'll add a note to the changelog. It's changing existing uapi but
hopefully not in a way that userspace would become broken. I mean even the
other madvise modes only got killable locks later tat some point after
introduction, no?

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