linux-kernel - Re: [PATCH] mm: swap: check for xa_zero

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: <7e7bfd05-434c-40b7-98ec-8ce352a8147d@redhat.com>
Date: Mon, 11 Aug 2025 15:19:53 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Charan Teja Kalla <quic_charante@...cinc.com>, akpm@...ux-foundation.org,
 shikemeng@...weicloud.com, kasong@...cent.com, nphamcs@...il.com,
 bhe@...hat.com, baohua@...nel.org, chrisl@...nel.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH] mm: swap: check for xa_zero_entry() on vma in swapoff
 path

>>>
>>>> When registering vmas for uprobe, skip the vmas in an mm that is marked
>>>> unstable.  Modifying a vma in an unstable mm may cause issues if the mm
>>>> isn't fully initialised.__
>>>>
>>>>> Is there anything preventing us from just leaving a proper tree that
>>>>> reflects reality in place before we drop the write lock?
>>>>
>>>> When you mean proper tree, is this about the your previous question? --
>>>> Shouldn't we just remove anything from the tree here that was not copied
>>>> immediately?
>>>
>>> Commit d24062914837 (" fork: use __mt_dup() to duplicate maple tree in
>>> dup_mmap()") did this for efficiency, so it'd be a regression to do this.
>>
>> We're talking about the case where fork *fails*. That cannot possibly be
>> relevant for performance, can it? :)
> 
> I think it optimises the overall operation, but as a product of that, has to
> handle this edge case, and that necessitated this rather horrble stuff.
> 
> Obviously we don't need to optimise a 'we are about to die' case :)

Right, so my original question was whether we could just drop all stale 
stuff from the tree before we lift the mmap write lock, leaving only the 
VMAs in there that we actually processed successfully.

-- 
Cheers,

David / dhildenb